From owner-ips@ece.cmu.edu  Wed Aug  1 12:09:00 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19239
	for <ips-archive@odin.ietf.org>; Wed, 1 Aug 2001 12:09:00 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f71FRAs26645
	for ips-outgoing; Wed, 1 Aug 2001 11:27:10 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from msgbas1t.cos.agilent.com (msgbas1tx.cos.agilent.com [192.6.9.34])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f71FR8e26641
	for <ips@ece.cmu.edu>; Wed, 1 Aug 2001 11:27:08 -0400 (EDT)
Received: from msgrel1t.cos.agilent.com (msgrel1t.cos.agilent.com [130.29.152.157])
	by msgbas1t.cos.agilent.com (Postfix) with ESMTP id 1BA421419
	for <ips@ece.cmu.edu>; Wed,  1 Aug 2001 09:27:07 -0600 (MDT)
Received: from axandbh3.and.agilent.com (axandbh3.and.agilent.com [130.30.32.200])
	by msgrel1t.cos.agilent.com (Postfix) with ESMTP id 9992F566
	for <ips@ece.cmu.edu>; Wed,  1 Aug 2001 09:27:06 -0600 (MDT)
Received: by axandbh3.and.agilent.com with Internet Mail Service (5.5.2653.19)
	id <P9K57AMH>; Wed, 1 Aug 2001 11:27:06 -0400
Message-ID: <35ED54E37A5ED511B8960090278CE58A07B5F6@axcs02.cos.agilent.com>
From: "CARCIDO,GLENN (A-Roseville,ex1)" <glenn_carcido@agilent.com>
To: ips@ece.cmu.edu
Subject: Remove
Date: Wed, 1 Aug 2001 11:27:04 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk




From owner-ips@ece.cmu.edu  Wed Aug  1 12:17:09 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19669
	for <ips-archive@odin.ietf.org>; Wed, 1 Aug 2001 12:17:09 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f71F7an25728
	for ips-outgoing; Wed, 1 Aug 2001 11:07:36 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mxic2.us.dg.com (mxic2.us.dg.com [128.221.31.40])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f71F7Ze25724
	for <ips@ece.cmu.edu>; Wed, 1 Aug 2001 11:07:35 -0400 (EDT)
Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19)
	id <PJ5VMYP1>; Wed, 1 Aug 2001 11:05:40 -0400
Message-ID: <93F527C91A6ED411AFE10050040665D00286D2B3@corpusmx1.us.dg.com>
From: Brown_Jeff@emc.com
To: ips@ece.cmu.edu
Subject: remove
Date: Wed, 1 Aug 2001 11:06:41 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk




From owner-ips@ece.cmu.edu  Wed Aug  1 13:33:27 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23647
	for <ips-archive@odin.ietf.org>; Wed, 1 Aug 2001 13:33:26 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f71GG1T28904
	for ips-outgoing; Wed, 1 Aug 2001 12:16:01 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from lightsand.com ([64.214.104.163])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f71GFxe28900
	for <ips@ece.cmu.edu>; Wed, 1 Aug 2001 12:16:00 -0400 (EDT)
Received: from muralipc (dhcp094.lightsand.com [192.168.1.94])
	by lightsand.com (8.9.3+Sun/8.9.1) with SMTP id JAA28623;
	Wed, 1 Aug 2001 09:15:45 -0700 (PDT)
From: "Murali Rajagopal" <muralir@lightsand.com>
To: <Black_David@emc.com>
Cc: <ips@ece.cmu.edu>
Subject: FCIP: RE: Security Gateways
Date: Wed, 1 Aug 2001 09:17:25 -0700
Message-ID: <MABBKAENHGDNNGLLHCPKOEEECJAA.muralir@lightsand.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <277DD60FB639D511AC0400B0D068B71E070AA3@CORPMX14>
Importance: Normal
X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

David:

The FCIP WG is just beginning to address the security topic. It is expected
that by the Interim Irvine meeting the FCIP Group will have had some time to
understand the implications of  the different approaches. It is too
premature at this time for the group to conclude one way or the other.
Please bear with us for some more time.

-Murali

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Black_David@emc.com
Sent: Tuesday, July 24, 2001 7:11 PM
To: ips@ece.cmu.edu
Subject: Security Gateways

The following issue was hidden in my long set of
comments on the -03 version of FCIP:

> > Delete 12 b).  If an FCIP entity is operating with an external
> > security gateway, only the interface on the public side of the
> > gateway is compliant with this specification.  The interface
> > between the FCIP entity and the gateway is not compliant because
> > it is lacking required security features - the FCIP entity
> > *includes* the security gateway in this structure.
>
> Please post this as a separate issue because several of the
> FCIP Authors believe it is appropriate for FCIP and I cannot
> represent their opinions.

The issue is not whether it's "appropriate".  The issue
is that if an implementation uses an FCIP Entity plus
an external security gateway, the only interface that
conforms to the forthcoming RFC is the public/external
interface on the security gateway.  The interface between
the FCIP Entity and the security gateway is private
and fails to conform to the security that will be
required of all FCIP implementations.

The above paragraph also applies to iSCSI (substitute iSCSI
for FCIP in all instances).  Let me also note that iSCSI's
ability to use a security gateway is not final at this
juncture.  The spectrum of security possibilities includes
things like SRP keying of ESP and IPsec transport mode that
would make external gateways difficult or impossible to use.

Those who care about being able to use security gateways
(or think that there's no need to support their use)
should speak up on the list, in London, and/or in Orange
County (I would expect the decision not to be made prior
to Orange County) and *EXPLAIN WHY* [technical rationale].

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------



From owner-ips@ece.cmu.edu  Wed Aug  1 14:45:04 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27281
	for <ips-archive@odin.ietf.org>; Wed, 1 Aug 2001 14:45:04 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f71HIIt02115
	for ips-outgoing; Wed, 1 Aug 2001 13:18:18 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f71HIHe02111
	for <ips@ece.cmu.edu>; Wed, 1 Aug 2001 13:18:17 -0400 (EDT)
Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <3W0T32XQ>; Wed, 1 Aug 2001 13:18:10 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD542@CORPMX14>
From: Black_David@emc.com
To: rsnively@Brocade.COM, ips@ece.cmu.edu
Subject: RE: Security Gateways
Date: Wed, 1 Aug 2001 13:13:13 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Bob,

You've made a good case for "optional to use", but not
"optional to implement".  The basic reason is that there
is no way to ensure that vendors and/or users will
restrict the use of an implementation that does not
include security to situations where "paths of a
storage environment are physically secured and have 
no requirement for additional security mechanisms".
Hence security needs to be present so that it
can be used when FCIP is deployed in an environment
that requires security.  Further, the IETF has no
interest in specification of protocols that are
*solely* for use in the sort of closed environment
that you describe, and the IPS WG charter contains
explicit words to that effect.

Therefore, the basic FCIP security mechanisms MUST be
implemented, but usage MAY be negotiated.  At the moment,
"basic security mechanisms" means authentication and
cryptographic integrity.  Confidentiality can currently
be optional to implement, but I think it's a very good
idea to specify the basic confidentiality mechanism
(*if* confidentiality of any form is implemented, *then*
<XXX> MUST be implemented).  The design and specification
of any negotiation mechanism must resist man-in-the-middle
attacks on negotiation that would result in turning off
security where that was not the intended outcome - such
an approach can include restrictions on implementation
behavior (e.g., if "no authentication" is not acceptable,
do not offer or accept it during negotiation).

If the FCIP draft is sent to the IESG without requiring
implementation of the basic security mechanisms, it will
be returned to the WG with instructions to correct
that shortcoming, along with some choice words from the
ADs wondering how the WG chairs could have overlooked
something like this.  As a result, an FCIP draft that
does not require implementation of the basic security
mechanisms will not be Last Called in the WG until that
requirement is added.

Sorry to be blunt, but there is no flexibility on whether
the basic security mechanisms are mandatory to implement;
they will be mandatory to implement, period.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


> -----Original Message-----
> From: Robert Snively [mailto:rsnively@brocade.com]
> Sent: Wednesday, August 01, 2001 12:08 PM
> To: 'Black_David@emc.com'; ips@ece.cmu.edu
> Subject: RE: Security Gateways
> 
> 
> Dear David,
> 
> I would like to address the rather serious question you have
> raised here about both architectural layering and market
> requirements.  After considerable thought, based on the
> explanations below, I have concluded that the FCIP RFC should
> specify that security is optional to implement and optional to use.
> 
> 1)  Concerning architectural layering:
> 
> It is clear that the problems of security are well understood
> within IETF. Numerous solutions have been proposed and
> many of those have become standard implementations.  The most
> successful of those (as an example, IPSec) have used the
> principles of architectural layering very well.  IPSec
> provides a secure mechanism for transporting any IP-based
> protocol if the protocol requires such security.  However,
> the overlaying protocols (as an example, TCP) have no requirement
> to actually make use of IPSec, and in fact have no particular
> requirement to make use of IP.  This is as it should be.
> Each layer is implemented independently of the other.  The
> services that each layer implements depend on the market
> requirements for the environment.  By that logic, it is 
> unnecessary for FCIP to specify any security mechanism at all, 
> since so many security mechanisms are available.  However,
> FCIP has provided the additional guidance that, if security
> in a TCP environment is used, it shall be provided at a layer
> below the TCP interface.  In particular, it recommends the
> use of IPSec for TCP/IP environments (and will recommend the
> appropriate IPSec options).  This additional guidance has nothing
> to do with the architecture or definition of FCIP and is 
> merely a recommendation that should improve interoperability.
> 
> 2)  Concerning market requirements:
> 
> A very high percentage of storage environments today manage
> their configurations very carefully.  Such careful management is
> necessary to guarantee redundant paths for proper availability,
> to provide sufficient paths to provide the required 
> performance, and to
> guarantee known paths to improve reparability and consistency
> of behavior.  As a side effect, a very high percentage of
> the paths of a storage environment are physically secured and have
> no requirement for additional security mechanisms.  At present,
> the only paths that are using security are those very few paths
> that leave one physically secure environment to transport data to
> another physically secure environment.  Those few paths 
> almost universally
> use security mechanisms at a lower level (as an example, a virtual
> private network) to achieve their goals.  As a first guess, such
> paths are well under 1% of the storage paths being used today.
> 
> I do not believe that this paradigm will change significantly over
> the next several years, although of course the percentage of paths
> requiring transport security may rise over 1%.  The requirements for
> storage performance and the desire to maintain the storage devices
> and many of their primary processors in a physically secure
> environment will assure similar configurations.
> 
> In this environment, the market will demand low cost and high
> performance for the great majority of interconnects and will demand
> security for a relatively low percentage of interconnects.  
> 
> What this implies for technologies like FCIP is that security
> be available as a separate option, outside the primary FCIP
> definition.  While still allowing the integration of security
> inside an FCIP unit, the IETF draft for FCIP  must also allow security
> to be provided either not at all or by an outside mechanism.  
> The most common outside mechanism would be a gateway box of some sort.
> In many cases, the gateway box will be a secure router placed on the
> external link and servicing a large number of locally attached
> unsecured FCIP boxes.
> 
> CONCLUSIONS:
> 
> The FCIP draft should continue to specify a security mechanism,
> with IPSec being the appropriate candidate, to guarantee 
> interoperability
> when security is provided.  The FCIP draft should be modified to
> indicate that security is optional to implement and optional to use.
> In addition, it should explicitly indicate that external gateway
> boxes are allowed implementation mechanisms for security.
> 
> As a side question, note that management of storage area networks
> and FCIP boxes is a separate question and is outside the scope of
> the FCIP draft.  Both Fibre Channel and Ethernet management paths
> have security appropriate to the particular management mechanism.
> As an example, web-based management mechanisms use web-based
> security tools. 
> 
> Bob Snively                        e-mail:    rsnively@brocade.com
> Brocade Communications Systems     phone:  408 487 8135
> 1745 Technology Drive
> San Jose, CA 95110
> 
> 
> 
> -----Original Message-----
> From: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Tuesday, July 24, 2001 7:11 PM
> To: ips@ece.cmu.edu
> Subject: Security Gateways
> 
> 
> The following issue was hidden in my long set of
> comments on the -03 version of FCIP:
> 
> > > Delete 12 b).  If an FCIP entity is operating with an external
> > > security gateway, only the interface on the public side of the
> > > gateway is compliant with this specification.  The interface
> > > between the FCIP entity and the gateway is not compliant because
> > > it is lacking required security features - the FCIP entity
> > > *includes* the security gateway in this structure.
> > 
> > Please post this as a separate issue because several of the
> > FCIP Authors believe it is appropriate for FCIP and I cannot
> > represent their opinions.
> 
> The issue is not whether it's "appropriate".  The issue
> is that if an implementation uses an FCIP Entity plus
> an external security gateway, the only interface that
> conforms to the forthcoming RFC is the public/external
> interface on the security gateway.  The interface between
> the FCIP Entity and the security gateway is private
> and fails to conform to the security that will be
> required of all FCIP implementations.
> 
> The above paragraph also applies to iSCSI (substitute iSCSI
> for FCIP in all instances).  Let me also note that iSCSI's
> ability to use a security gateway is not final at this
> juncture.  The spectrum of security possibilities includes
> things like SRP keying of ESP and IPsec transport mode that
> would make external gateways difficult or impossible to use.
> 
> Those who care about being able to use security gateways
> (or think that there's no need to support their use)
> should speak up on the list, in London, and/or in Orange
> County (I would expect the decision not to be made prior
> to Orange County) and *EXPLAIN WHY* [technical rationale].
> 
> Thanks,
> --David
> 
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------
>  
> 


From owner-ips@ece.cmu.edu  Wed Aug  1 17:50:50 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA06377
	for <ips-archive@odin.ietf.org>; Wed, 1 Aug 2001 17:50:49 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f71KaTb11860
	for ips-outgoing; Wed, 1 Aug 2001 16:36:29 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f71KaRe11855
	for <ips@ece.cmu.edu>; Wed, 1 Aug 2001 16:36:27 -0400 (EDT)
Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <3W0T34W5>; Wed, 1 Aug 2001 16:36:22 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD544@CORPMX14>
From: Black_David@emc.com
To: ips@ece.cmu.edu
Cc: agenda@ietf.org
Subject: RE: IP Storage Agenda for London
Date: Wed, 1 Aug 2001 16:31:29 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Typo in the agenda.  The Tuesday meeting is:

---- Tuesday, August 7, 0900-1130 ----

NOT August 21.

Sorry, --David

> -----Original Message-----
> From: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Monday, July 30, 2001 2:50 PM
> To: ips@ece.cmu.edu
> Cc: agenda@ietf.org
> Subject: IP Storage Agenda for London
> 
> 
> IETF IP Storage (IPS) Working Group
> London IETF Meeting, August 5-10, 2001
> -------------------------------------------
> 
> CHAIRS:
> 	David Black <black_david@emc.com>
> 	Elizabeth Rodriguez <egrodriguez@lucent.com>
> 
> AGENDA: SUBJECT TO CHANGE
> 
> NOTE: The London IETF meetings conflict with T11 meetings (T11 is the
> standards
> 	organization for Fibre Channel).  Therefore the IP 
> Storage Working
> Group will
> 	not be able to work on the FCIP or iFCP protocols or 
> related items
> in London.
> 
> INTERIM MEETING: August 27-28, Orange County, CA, USA
> 	Main topics will be Fibre Channel related protocols 
> (FCIP and iFCP)
> and
> 	Security for all IPS protocols (iSCSI, FCIP, and iFCP).  An
> announcement
> 	with location and additional details is available at:
> 		
> http://www.pdl.cmu.edu/mailinglists/ips/mail/msg05297.html
> 
> ---- Monday, August 6, 1930-2200 ----
> 
> - Agenda Bashing and Administrivia (10 min)
> 
> - iSCSI Plugfest Results and Discussion (30 min)
> 
> - iSCSI Security (35 min)
> 	draft-black-ips-iscsi-security-00.txt
> 
> 	NOTE: This draft covers both security requirements and 
> SRP keying.
> 	Use of IKE for keying and considerations for selecting ESP
> algorithms
> 	(authentication and encryption) for iSCSI will also be 
> discussed.
> 
> - iSCSI Framing Mechanism Requirements (30 min)
> 	draft-ietf-tsvwg-tcp-ulp-frame-00.txt
> 
> 	NOTE: The contents of this draft will be discussed in 
> TSVWG.  This
> IPS WG
> 		time is to discuss iSCSI requirements for use of these
> mechanisms.
> 			
> - iSCSI (45 min)
> 	draft-ietf-ips-iscsi-07.txt
> 
> 	Includes Error Recovery
> 
> ---- Tuesday, August 21, 0900-1130 ----  XXX - actually August 7
> 
> - Agenda Bashing and Administrivia (5 min)
> 
> - iSCSI [continued] (65 minutes)
> 	draft-ietf-ips-iscsi-07.txt
> 
> 	Includes opportunities for simplification.
> 
> - iSCSI Naming and Discovery Requirements (45 min)
> 	draft-ietf-ips-iscsi-name-disc-02.txt
> 
> 	Includes mapping of SAM-2 SCSI abstractions to iSCSI and
> consequences.
> 
> - Use of SLP and iSNS with ISCSI (20 min)
> 	draft-ietf-ips-iscsi-slp-01.txt
> 	draft-ietf-ips-isns-04.txt
> 
> - iSNS MIB (5 min)
> 	draft-gibbons-isnsmib-00.txt
> 
> 	NOTE: The authors would like the WG to adopt this as an official
> work item.
> 
> - iSCSI MIB (10 min)
> 	draft-ietf-ips-iscsi-mib-02.txt
> 
> 	UML model diagram available at:
> 	
> ftp://ftpeng.cisco.com/mbakke/iscsi/Visio-ietf-iscsi-uml-model-02.pdf
> 	Table structure diagram available at:
> 	
> ftp://ftpeng.cisco.com/mbakke/iscsi/Visio-ietf-iscsi-mib-struc
ture-02.pdf

DESCRIPTION:

	The IP Storage WG works on using IP-based networks to transport
block storage
	traffic.  See http://www.ietf.org/html.charters/ips-charter.html


From owner-ips@ece.cmu.edu  Wed Aug  1 18:57:23 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA08853
	for <ips-archive@odin.ietf.org>; Wed, 1 Aug 2001 18:57:23 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f71LcSj15824
	for ips-outgoing; Wed, 1 Aug 2001 17:38:28 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from smtp016.mail.yahoo.com (smtp016.mail.yahoo.com [216.136.174.113])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f71LcRe15820
	for <ips@ece.cmu.edu>; Wed, 1 Aug 2001 17:38:27 -0400 (EDT)
Received: from sdsl-216-36-75-164.dsl.sjc.megapath.net (HELO somesh) (216.36.75.164)
  by smtp.mail.vip.sc5.yahoo.com with SMTP; 1 Aug 2001 21:38:25 -0000
X-Apparently-From: <someshg@yahoo.com>
Reply-To: <someshg@yahoo.com>
From: "Somesh Gupta" <someshg@yahoo.com>
To: "Julian Satran" <Julian_Satran@il.ibm.com>, <ips@ece.cmu.edu>
Subject: RE: iSCSI connection recovery
Date: Wed, 1 Aug 2001 14:28:02 -0700
Message-ID: <NMEALCLOIBCHBDHLCMIJIECJCGAA.someshg@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <OF4FCD9FD2.8EA07A4B-ONC2256A9A.0023A551@telaviv.ibm.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

The victory of the dull, detail-oriented engineer over
elegance :-) I would also prefer a very formal and
fully specified 10 - 20 page document which leaves no
ambiguity and no holes. But for that we would have to
simplify the spec a lot.

regards,
Somesh

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Julian Satran
> Sent: Monday, July 30, 2001 11:34 PM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI connection recovery
>
>
>
> Sandeep,
>
> Don't blame me for size.  I would prefer the spec to be 10-20 pages and
> have a formal spec.
> The past of this list has clearly shown that more text helps at least to
> gain consensus :-)
>
> Regards,
> Julo
>
> Sandeep Joshi <sandeepj@research.bell-labs.com> on 30-07-2001 21:03:04
>
> Please respond to Sandeep Joshi <sandeepj@research.bell-labs.com>
>
> To:   ips@ece.cmu.edu
> cc:
> Subject:  Re: iSCSI connection recovery
>
>
>
>
>
> > I assume you are not suggesting a FinalLogout ;-), are you?
>
> No I was not :-)  I missed reading the 4th paragraph of
> Section 2.14 which alludes to this logout processing.
> The spec is getting monstrous at 185 pages.
>
> regards,
> -Sandeep
>
>
> Julian Satran wrote:
> >
> > Sandeep,
> >
> > There is nothing to stop them sending the state but there is no way for
> the
> > initiator to acknowledge those (Logout takes it out of the full feature
> > phase - nothing valid after) and a new connection is a new day ...
> >
> > I assume you are not suggesting a FinalLogout ;-), are you?
> >
> > Regards,
> > Julo
> >
> > Sandeep Joshi <sandeepj@research.bell-labs.com> on 30-07-2001 18:38:48
> >
> > Please respond to Sandeep Joshi <sandeepj@research.bell-labs.com>
> >
> > To:   Julian Satran/Haifa/IBM@IBMIL
> > cc:
> > Subject:  Re: iSCSI connection recovery
> >
> > Julian
> >
> > Wait..!  I was proposing that the expStatSN could be used to send back
> > the responses (even *before* commands get retried)   See below
> >
> > -Sandeep
> >
> > Julian Satran wrote:
> > >
> > > Sandeep,
> > >
> > > Both Login (with the X bit it is a logout/login) and Logout have an
> > > ExpStatSN just for this reason.
> > > If this does not come through clear in the text please let me know.
> > >
> > > Regards,
> > > Julo
> > >
> > > Sandeep Joshi <sandeepj@research.bell-labs.com> on 30-07-2001 17:33:49
> > >
> > > Please respond to Sandeep Joshi <sandeepj@research.bell-labs.com>
> > >
> > > To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> > > cc:
> > > Subject:  Re: iSCSI connection recovery
> > >
> > > Julian,
> > >
> > > The explanation helps.  Now that the model is clear, let me
> > > ask if something like this would work..
> > >
> > > It seems possible for the target to send back SCSI responses
> > > during recovery logout, even before commands are retried.
> > > The recovery logout could act as a final (& appetizing) SNACK.
> > >
> > > Since the target still has a statSN index on the responses,
> > > it could use the expStatSN field in the Logout Command
> > > and send all responses from [expStatSN-endStatSN].
> > >
> > > Initiator            Target
> > > ---------            ---------
> > > Logout (for recovery) ---->>
> > >    <<--- SCSI Data+Responses from [expStatSN-endStatSN]
> > >    <<--- Logout Response
> > >
> > > Once the logout occurs, the statSN ranges for the CID are
> > > lost and command retry cannot be avoided.
> > >
> > > This logout optimization has larger benefits for Writes.
> > > Retrying Write Commands (e.g. tape backup) may involve
> > > sending all the data (or minimally FirstBurst) all over
> > > again!   Of course, cost-benefit depends on queue lengths,
> > > bandwidth, frequency of connection recovery, transfer
> > > sizes, ULP timeouts, etc.
> > >
> > > Comments ?
> > >
> > > -Sandeep
> > >
> > > Julian Satran wrote:
> > > >
> > > > Sandeep,
> > > >
> > > > Your status cache is made of some task  related structures.  You can
> > > reuse
> > > > those - just link them to a new connection.
> > > > As for StatSN - you can't reuse those as each connection establishes
> > its
> > > > own (new) StatSN at login (even if reusing the old CID).
> > > >
> > > > Regardless of what CID the connection bears - it is a new connection
> > and
> > > > you can issue new commands. Even for the old ones by
> reissuing you in
> > > fact
> > > > indicate the new allegiance (the logout suspended them and the retry
> > > > establishes the new allegiance).
> > > >
> > > > sandeepj@research.bell-labs.com (Sandeep Joshi) on 29-07-2001
> 01:01:54
> > > >
> > > > Please respond to sandeepj@research.bell-labs.com (Sandeep Joshi)
> > > >
> > > > To:   ips@ece.cmu.edu
> > > > cc:
> > > > Subject:  Re: iSCSI connection recovery
> > > >
> > > > Er..I mixed up the terminology.  By "same connection", I meant
> > > > "same CID" - so one could retry cmds ONLY on the new TCP connection
> > > > with the same CID, after the old TCP connection had failed.
> > > > This avoids having to change connection allegiance on
> > > > the stuck commands, as part of connection logout.
> > > >
> > > > The main questions, however, were these :
> > > >
> > > > 1) What is the effect of a CID logout on the status (statSN)
> > > >    cache ?  Can it be reused when the commands are retried ?
> > > >    (Think not..)
> > > >
> > > > 2) After one does a login for recovery using an old CID,
> > > >    can new SCSI commands be issued on that new TCP connection.
> > > >    (though it bears an old CID identifier)
> > > >
> > > > -Sandeep
> > > >
> > > > > Sandeep,
> > > > >
> > > > > Retry over any connection was always the case.
> > > > > Commands can change allegiance only after a logout.
> > > > > The commands get quiesced anyway and you have to mark them ready
> for
> > a
> > > > > retry anyhow (you don't want retry at arbitrary times to hit
> > unpunished
> > > > the
> > > > > target). After that it doesn't matter where you retry (same
> > connection,
> > > > > another old one, a new one).
> > > > >
> > > > > The only new thing is command replay (after status was sent but
> > before
> > > it
> > > > > is acked).
> > > > >
> > > > > Regards,
> > > > > Julo
> > > > >
> > > > > sandeepj@research.bell-labs.com (Sandeep Joshi) on 28-07-2001
> > 06:37:33
> > > > >
> > > > > Please respond to sandeepj@research.bell-labs.com (Sandeep Joshi)
> > > > >
> > > > > To:   ips@ece.cmu.edu
> > > > > cc:
> > > > > Subject:  iSCSI connection recovery
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > I had a "big-picture" question about the connection
> > > > > recovery model.
> > > > >
> > > > > The current draft suggests that, once the broken connection
> > > > > is logged out, the commands allegiant to the old connection
> > > > > can now be retried over *any* connection. (See Section 7.11.3
> > > > > bullet 1 and also Appendix F Session Recovery algo for
> > > > > initiator.)
> > > > >
> > > > > I may be mistaken, but in previous drafts, this was not
> > > > > the case and commands always stayed allegiant to a CID.
> > > > >
> > > > > So the question is.. how does one use a Status cache
> > > > > belonging to the old connection in this new model (now that
> > > > > the commands are going to be retried over any connection)
> > > > > Doesnt this become more complex ?
> > > > >
> > > > > Secondly, this also means that one must walk the command
> > > > > list at the target and quiesce connection allegiance during
> > > > > logout - which may not be required if the commands were to be
> > > > > retried over the same connection always.
> > > > >
> > > > > Comments  ?
> > > > >
> > > > > -Sandeep
> > > > >
> > > > >
> > > > >
>
>


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com



From owner-ips@ece.cmu.edu  Wed Aug  1 20:29:59 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA12905
	for <ips-archive@odin.ietf.org>; Wed, 1 Aug 2001 20:29:59 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f71NfQd21400
	for ips-outgoing; Wed, 1 Aug 2001 19:41:26 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from ns.strahm.net (sub18-42.member.dsl-only.net [63.105.18.42])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f71NfNe21396
	for <ips@ece.cmu.edu>; Wed, 1 Aug 2001 19:41:24 -0400 (EDT)
Received: (qmail 26938 invoked by uid 500); 1 Aug 2001 22:11:50 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
  by localhost with SMTP; 1 Aug 2001 22:11:50 -0000
Date: Wed, 1 Aug 2001 15:11:50 -0700 (PDT)
From: Bill Strahm <bill@strahm.net>
To: Black_David@emc.com
cc: rsnively@Brocade.COM, ips@ece.cmu.edu
Subject: RE: Security Gateways
In-Reply-To: <277DD60FB639D511AC0400B0D068B71ECAD542@CORPMX14>
Message-ID: <Pine.LNX.4.10.10108011459070.26884-100000@homegate.strahm.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Ok,

I believe I have to disagree with you David.  The IESG WILL approve specs
that do not offically include encryption.  An example might be RFC 2801
The Internet Open Trading Protocol - IOTP Version 1.0.

From this documents own security section comes the statement
5.3 Data Privacy

   Privacy of information is provided by sending IOTP Messages between
   the various Trading Roles using a secure channel such as [SSL/TLS].
   Use of a secure channel within IOTP is optional.

The security section also talks about why you might or might not want to
use digital signatures for performing Online transactions.

It boils down to allowing vendors to create products that customers wish
to buy.  If it turns out that custommers ARE NOT willing to pay a single
dime for security, why are you going to burden a vendors implementation
with security requirements that do not provide value to the customer.  If
customers value security, you will see a quick rise in the sale of secure
storage products.

I think it is perfectly acceptable to point to a security implementation
(IPsec, TLS, or roll our own in a seperate document), but to require it
for protocol correctness I do not think is needed for any reason.

Bill

On Wed, 1 Aug 2001 Black_David@emc.com wrote:

> Bob,
> 
> You've made a good case for "optional to use", but not
> "optional to implement".  The basic reason is that there
> is no way to ensure that vendors and/or users will
> restrict the use of an implementation that does not
> include security to situations where "paths of a
> storage environment are physically secured and have 
> no requirement for additional security mechanisms".
> Hence security needs to be present so that it
> can be used when FCIP is deployed in an environment
> that requires security.  Further, the IETF has no
> interest in specification of protocols that are
> *solely* for use in the sort of closed environment
> that you describe, and the IPS WG charter contains
> explicit words to that effect.
> 
> Therefore, the basic FCIP security mechanisms MUST be
> implemented, but usage MAY be negotiated.  At the moment,
> "basic security mechanisms" means authentication and
> cryptographic integrity.  Confidentiality can currently
> be optional to implement, but I think it's a very good
> idea to specify the basic confidentiality mechanism
> (*if* confidentiality of any form is implemented, *then*
> <XXX> MUST be implemented).  The design and specification
> of any negotiation mechanism must resist man-in-the-middle
> attacks on negotiation that would result in turning off
> security where that was not the intended outcome - such
> an approach can include restrictions on implementation
> behavior (e.g., if "no authentication" is not acceptable,
> do not offer or accept it during negotiation).
> 
> If the FCIP draft is sent to the IESG without requiring
> implementation of the basic security mechanisms, it will
> be returned to the WG with instructions to correct
> that shortcoming, along with some choice words from the
> ADs wondering how the WG chairs could have overlooked
> something like this.  As a result, an FCIP draft that
> does not require implementation of the basic security
> mechanisms will not be Last Called in the WG until that
> requirement is added.
> 
> Sorry to be blunt, but there is no flexibility on whether
> the basic security mechanisms are mandatory to implement;
> they will be mandatory to implement, period.
> 
> Thanks,
> --David
> 
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------
> 
> 
> > -----Original Message-----
> > From: Robert Snively [mailto:rsnively@brocade.com]
> > Sent: Wednesday, August 01, 2001 12:08 PM
> > To: 'Black_David@emc.com'; ips@ece.cmu.edu
> > Subject: RE: Security Gateways
> > 
> > 
> > Dear David,
> > 
> > I would like to address the rather serious question you have
> > raised here about both architectural layering and market
> > requirements.  After considerable thought, based on the
> > explanations below, I have concluded that the FCIP RFC should
> > specify that security is optional to implement and optional to use.
> > 
> > 1)  Concerning architectural layering:
> > 
> > It is clear that the problems of security are well understood
> > within IETF. Numerous solutions have been proposed and
> > many of those have become standard implementations.  The most
> > successful of those (as an example, IPSec) have used the
> > principles of architectural layering very well.  IPSec
> > provides a secure mechanism for transporting any IP-based
> > protocol if the protocol requires such security.  However,
> > the overlaying protocols (as an example, TCP) have no requirement
> > to actually make use of IPSec, and in fact have no particular
> > requirement to make use of IP.  This is as it should be.
> > Each layer is implemented independently of the other.  The
> > services that each layer implements depend on the market
> > requirements for the environment.  By that logic, it is 
> > unnecessary for FCIP to specify any security mechanism at all, 
> > since so many security mechanisms are available.  However,
> > FCIP has provided the additional guidance that, if security
> > in a TCP environment is used, it shall be provided at a layer
> > below the TCP interface.  In particular, it recommends the
> > use of IPSec for TCP/IP environments (and will recommend the
> > appropriate IPSec options).  This additional guidance has nothing
> > to do with the architecture or definition of FCIP and is 
> > merely a recommendation that should improve interoperability.
> > 
> > 2)  Concerning market requirements:
> > 
> > A very high percentage of storage environments today manage
> > their configurations very carefully.  Such careful management is
> > necessary to guarantee redundant paths for proper availability,
> > to provide sufficient paths to provide the required 
> > performance, and to
> > guarantee known paths to improve reparability and consistency
> > of behavior.  As a side effect, a very high percentage of
> > the paths of a storage environment are physically secured and have
> > no requirement for additional security mechanisms.  At present,
> > the only paths that are using security are those very few paths
> > that leave one physically secure environment to transport data to
> > another physically secure environment.  Those few paths 
> > almost universally
> > use security mechanisms at a lower level (as an example, a virtual
> > private network) to achieve their goals.  As a first guess, such
> > paths are well under 1% of the storage paths being used today.
> > 
> > I do not believe that this paradigm will change significantly over
> > the next several years, although of course the percentage of paths
> > requiring transport security may rise over 1%.  The requirements for
> > storage performance and the desire to maintain the storage devices
> > and many of their primary processors in a physically secure
> > environment will assure similar configurations.
> > 
> > In this environment, the market will demand low cost and high
> > performance for the great majority of interconnects and will demand
> > security for a relatively low percentage of interconnects.  
> > 
> > What this implies for technologies like FCIP is that security
> > be available as a separate option, outside the primary FCIP
> > definition.  While still allowing the integration of security
> > inside an FCIP unit, the IETF draft for FCIP  must also allow security
> > to be provided either not at all or by an outside mechanism.  
> > The most common outside mechanism would be a gateway box of some sort.
> > In many cases, the gateway box will be a secure router placed on the
> > external link and servicing a large number of locally attached
> > unsecured FCIP boxes.
> > 
> > CONCLUSIONS:
> > 
> > The FCIP draft should continue to specify a security mechanism,
> > with IPSec being the appropriate candidate, to guarantee 
> > interoperability
> > when security is provided.  The FCIP draft should be modified to
> > indicate that security is optional to implement and optional to use.
> > In addition, it should explicitly indicate that external gateway
> > boxes are allowed implementation mechanisms for security.
> > 
> > As a side question, note that management of storage area networks
> > and FCIP boxes is a separate question and is outside the scope of
> > the FCIP draft.  Both Fibre Channel and Ethernet management paths
> > have security appropriate to the particular management mechanism.
> > As an example, web-based management mechanisms use web-based
> > security tools. 
> > 
> > Bob Snively                        e-mail:    rsnively@brocade.com
> > Brocade Communications Systems     phone:  408 487 8135
> > 1745 Technology Drive
> > San Jose, CA 95110
> > 
> > 
> > 
> > -----Original Message-----
> > From: Black_David@emc.com [mailto:Black_David@emc.com]
> > Sent: Tuesday, July 24, 2001 7:11 PM
> > To: ips@ece.cmu.edu
> > Subject: Security Gateways
> > 
> > 
> > The following issue was hidden in my long set of
> > comments on the -03 version of FCIP:
> > 
> > > > Delete 12 b).  If an FCIP entity is operating with an external
> > > > security gateway, only the interface on the public side of the
> > > > gateway is compliant with this specification.  The interface
> > > > between the FCIP entity and the gateway is not compliant because
> > > > it is lacking required security features - the FCIP entity
> > > > *includes* the security gateway in this structure.
> > > 
> > > Please post this as a separate issue because several of the
> > > FCIP Authors believe it is appropriate for FCIP and I cannot
> > > represent their opinions.
> > 
> > The issue is not whether it's "appropriate".  The issue
> > is that if an implementation uses an FCIP Entity plus
> > an external security gateway, the only interface that
> > conforms to the forthcoming RFC is the public/external
> > interface on the security gateway.  The interface between
> > the FCIP Entity and the security gateway is private
> > and fails to conform to the security that will be
> > required of all FCIP implementations.
> > 
> > The above paragraph also applies to iSCSI (substitute iSCSI
> > for FCIP in all instances).  Let me also note that iSCSI's
> > ability to use a security gateway is not final at this
> > juncture.  The spectrum of security possibilities includes
> > things like SRP keying of ESP and IPsec transport mode that
> > would make external gateways difficult or impossible to use.
> > 
> > Those who care about being able to use security gateways
> > (or think that there's no need to support their use)
> > should speak up on the list, in London, and/or in Orange
> > County (I would expect the decision not to be made prior
> > to Orange County) and *EXPLAIN WHY* [technical rationale].
> > 
> > Thanks,
> > --David
> > 
> > ---------------------------------------------------
> > David L. Black, Senior Technologist
> > EMC Corporation, 42 South St., Hopkinton, MA  01748
> > +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> > black_david@emc.com       Mobile: +1 (978) 394-7754
> > ---------------------------------------------------
> >  
> > 
> 



From owner-ips@ece.cmu.edu  Wed Aug  1 20:30:16 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA12947
	for <ips-archive@odin.ietf.org>; Wed, 1 Aug 2001 20:30:11 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f71NgcW21453
	for ips-outgoing; Wed, 1 Aug 2001 19:42:38 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f71Ngae21444
	for <ips@ece.cmu.edu>; Wed, 1 Aug 2001 19:42:36 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id TAA46054;
	Wed, 1 Aug 2001 19:40:33 -0400
Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f71NgZh200634;
	Wed, 1 Aug 2001 17:42:35 -0600
Importance: Normal
Subject: Re: iSCSI: draft 7: iSCSI response and SCSI sense data
To: "Elliott, Robert" <Robert.Elliott@compaq.com>
Cc: "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
From: "Jim Hafner" <hafner@almaden.ibm.com>
Date: Wed, 1 Aug 2001 16:42:33 -0700
Message-ID: <OF03A728A1.985FA6E5-ON88256A9B.008220CF@boulder.ibm.com>
X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.6 |December 14, 2000) at
 08/01/2001 04:42:35 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Rob,

I agree with you.  These layering violations (and some of the others you've
also noted on the reflector) should be removed from the draft.

Jim Hafner


"Elliott, Robert" <Robert.Elliott@compaq.com>@ece.cmu.edu on 08-01-2001
04:26:57 PM

Sent by:  owner-ips@ece.cmu.edu


To:   "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
cc:
Subject:  iSCSI: draft 7: iSCSI response and SCSI sense data



iSCSI draft 7 section 2.4.3 includes a table relating the iSCSI
response codes to various CHECK CONDITION status additional
sense codes:

  "0x01 Target Failure
    ASC=0x44 ASCQ=0x00 INTERNAL TARGET FAILURE
  0x02 Delivery Subsystem Failure
    ASC=0x47 ASCQ=0x03 INFORMATION UNIT CRC ERROR DETECTED
  0x03 Unsolicited data rejected
    ASC=0x49 ASCQ=0x00 INVALID MESSAGE ERROR
  0x04 Not enough unsolicited [data]
    ASC=0x49 ASCQ=0x00 INVALID MESSAGE ERROR
  0x05 SNACK rejected [Command in progress]
    ASC=0x47 ASCQ=0x03 INFORMATION UNIT CRC ERROR DETECTED

  As listed above, each defined response code MUST be used (under the
  conditions described in the 'Reason' field), only when the
  corresponding SCSI CHECK CONDITION is signaled, to convey additional
  protocol service information.  A SCSI CHECK CONDITION with the ASC
  and ASCQ values as tabulated MUST be signaled by iSCSI targets for
  all the instances in this document referring to usage of one of the
  above defined response codes."

No other SCSI protocol does this. iSCSI seems to be granting the
SCSI-level status a priority over the iSCSI-level response data.
I think the other protocols treat the response data as more
important; if the response data indicates a problem, the SCSI layer
is considered broken and the SCSI status is undefined.

Forcing the iSCSI layer to fill in those fields seems to break the
layering model.

I suggest removing the CHECK CONDITION status and additional sense
code linkage and leave the SCSI status undefined if the iSCSI
response is nonzero.

This is compatible with SAM-2, which only requires status be returned
when the service response is TASK COMPLETE (SAM-2 revision 18
section 5.3.1):
  "Status shall be sent from the logical unit to the application
   client whenever a command ends with a service response of
   TASK COMPLETE or LINKED COMMAND COMPLETE."

Furthermore, SAM-2 requires that status be ignored when the service
response indicates an error (SAM-2 revision 18 section 5.1):
  "Status: A one-byte field containing command completion status
  (see 5.3). If the command ends with a service response of
  SERVICE DELIVERY OR TARGET FAILURE, the application client
  shall consider this parameter to be undefined."

I think iSCSI's current wording may violate this rule.
---
Rob Elliott, Compaq Server Storage
Robert.Elliott@compaq.com






From owner-ips@ece.cmu.edu  Wed Aug  1 20:32:44 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13076
	for <ips-archive@odin.ietf.org>; Wed, 1 Aug 2001 20:32:44 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f71NjwA21588
	for ips-outgoing; Wed, 1 Aug 2001 19:45:58 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f71Njue21583
	for <ips@ece.cmu.edu>; Wed, 1 Aug 2001 19:45:56 -0400 (EDT)
Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Wed Aug  1 19:45:53 EDT 2001
Received: from aura.research.bell-labs.com (aura.research.bell-labs.com [135.104.46.10])
	by scummy.research.bell-labs.com (8.11.4/8.11.4) with ESMTP id f71NjlT20622
	for <ips@ece.cmu.edu>; Wed, 1 Aug 2001 19:45:47 -0400 (EDT)
Received: from research.bell-labs.com (IDENT:sandeepj@sandeepj-pcmh.research.bell-labs.com [135.104.47.90])
	by aura.research.bell-labs.com (8.9.1/8.9.1) with ESMTP id TAA03744
	for <ips@ece.cmu.edu>; Wed, 1 Aug 2001 19:45:46 -0400 (EDT)
Message-ID: <3B6894AA.D78251B8@research.bell-labs.com>
Date: Wed, 01 Aug 2001 19:45:46 -0400
From: Sandeep Joshi <sandeepj@research.bell-labs.com>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-3 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: ips@ece.cmu.edu
Subject: Re: iSCSI connection recovery
References: <NMEALCLOIBCHBDHLCMIJIECJCGAA.someshg@yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


Simplifying the spec is one aspect.  The other issue is that 
there is a quite some overlap in the various sections.  As 
details have got added everywhere, the sections have expanded 
and now seem due for a "realignment". 

Someone with a fresh eye, who is reading this document for 
the first time, could be able to suggest a better format.

Let me, however, just point out a few things to illustrate :

1) Security issues :
   Described are Sec 4.2, Sec 9 and Appendix A 
   Section 9 is IETF-recommended (Security Considerations)
   but the other sections got added as details evolved.
2) Login processing:
   Described in Sec 1.2.3, Section 4, Section 2.10 and 2.11
3) Synch & Steering (hopefully gets absorbed into Framing draft)
   Described in Sec 1.2.9.2 as well as Sec 8.5
4) Error Handling 
   Sec 7.4, Sec 7.5  and Sec 7.11.1 seem to overlap at a 
   sentence level.  One must also correlate it with Appendix F.
5) Text negotiation
   Sec 7.7 talks of operational negotiation failures
   Sec 4.3 talks of operational negotiation
   Sec 2.8 and Sec 2.9 also describe negotiation details.

-Sandeep

Somesh Gupta wrote:
> 
> The victory of the dull, detail-oriented engineer over
> elegance :-) I would also prefer a very formal and
> fully specified 10 - 20 page document which leaves no
> ambiguity and no holes. But for that we would have to
> simplify the spec a lot.
> 
> regards,
> Somesh
> 
> > -----Original Message-----
> > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> > Julian Satran
> > Sent: Monday, July 30, 2001 11:34 PM
> > To: ips@ece.cmu.edu
> > Subject: Re: iSCSI connection recovery
> >
> >
> >
> > Sandeep,
> >
> > Don't blame me for size.  I would prefer the spec to be 10-20 pages and
> > have a formal spec.
> > The past of this list has clearly shown that more text helps at least to
> > gain consensus :-)
> >
> > Regards,
> > Julo
> >
> > Sandeep Joshi <sandeepj@research.bell-labs.com> on 30-07-2001 21:03:04
> >
> > Please respond to Sandeep Joshi <sandeepj@research.bell-labs.com>
> >
> > To:   ips@ece.cmu.edu
> > cc:
> > Subject:  Re: iSCSI connection recovery
> >
> >
> >
> >
> >
> > > I assume you are not suggesting a FinalLogout ;-), are you?
> >
> > No I was not :-)  I missed reading the 4th paragraph of
> > Section 2.14 which alludes to this logout processing.
> > The spec is getting monstrous at 185 pages.
> >
> > regards,
> > -Sandeep
> >
> >
> > Julian Satran wrote:
> > >
> > > Sandeep,
> > >
> > > There is nothing to stop them sending the state but there is no way for
> > the
> > > initiator to acknowledge those (Logout takes it out of the full feature
> > > phase - nothing valid after) and a new connection is a new day ...
> > >
> > > I assume you are not suggesting a FinalLogout ;-), are you?
> > >
> > > Regards,
> > > Julo
> > >
> > > Sandeep Joshi <sandeepj@research.bell-labs.com> on 30-07-2001 18:38:48
> > >
> > > Please respond to Sandeep Joshi <sandeepj@research.bell-labs.com>
> > >
> > > To:   Julian Satran/Haifa/IBM@IBMIL
> > > cc:
> > > Subject:  Re: iSCSI connection recovery
> > >
> > > Julian
> > >
> > > Wait..!  I was proposing that the expStatSN could be used to send back
> > > the responses (even *before* commands get retried)   See below
> > >
> > > -Sandeep
> > >
> > > Julian Satran wrote:
> > > >
> > > > Sandeep,
> > > >
> > > > Both Login (with the X bit it is a logout/login) and Logout have an
> > > > ExpStatSN just for this reason.
> > > > If this does not come through clear in the text please let me know.
> > > >
> > > > Regards,
> > > > Julo
> > > >
> > > > Sandeep Joshi <sandeepj@research.bell-labs.com> on 30-07-2001 17:33:49
> > > >
> > > > Please respond to Sandeep Joshi <sandeepj@research.bell-labs.com>
> > > >
> > > > To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> > > > cc:
> > > > Subject:  Re: iSCSI connection recovery
> > > >
> > > > Julian,
> > > >
> > > > The explanation helps.  Now that the model is clear, let me
> > > > ask if something like this would work..
> > > >
> > > > It seems possible for the target to send back SCSI responses
> > > > during recovery logout, even before commands are retried.
> > > > The recovery logout could act as a final (& appetizing) SNACK.
> > > >
> > > > Since the target still has a statSN index on the responses,
> > > > it could use the expStatSN field in the Logout Command
> > > > and send all responses from [expStatSN-endStatSN].
> > > >
> > > > Initiator            Target
> > > > ---------            ---------
> > > > Logout (for recovery) ---->>
> > > >    <<--- SCSI Data+Responses from [expStatSN-endStatSN]
> > > >    <<--- Logout Response
> > > >
> > > > Once the logout occurs, the statSN ranges for the CID are
> > > > lost and command retry cannot be avoided.
> > > >
> > > > This logout optimization has larger benefits for Writes.
> > > > Retrying Write Commands (e.g. tape backup) may involve
> > > > sending all the data (or minimally FirstBurst) all over
> > > > again!   Of course, cost-benefit depends on queue lengths,
> > > > bandwidth, frequency of connection recovery, transfer
> > > > sizes, ULP timeouts, etc.
> > > >
> > > > Comments ?
> > > >
> > > > -Sandeep
> > > >
> > > > Julian Satran wrote:
> > > > >
> > > > > Sandeep,
> > > > >
> > > > > Your status cache is made of some task  related structures.  You can
> > > > reuse
> > > > > those - just link them to a new connection.
> > > > > As for StatSN - you can't reuse those as each connection establishes
> > > its
> > > > > own (new) StatSN at login (even if reusing the old CID).
> > > > >
> > > > > Regardless of what CID the connection bears - it is a new connection
> > > and
> > > > > you can issue new commands. Even for the old ones by
> > reissuing you in
> > > > fact
> > > > > indicate the new allegiance (the logout suspended them and the retry
> > > > > establishes the new allegiance).
> > > > >
> > > > > sandeepj@research.bell-labs.com (Sandeep Joshi) on 29-07-2001
> > 01:01:54
> > > > >
> > > > > Please respond to sandeepj@research.bell-labs.com (Sandeep Joshi)
> > > > >
> > > > > To:   ips@ece.cmu.edu
> > > > > cc:
> > > > > Subject:  Re: iSCSI connection recovery
> > > > >
> > > > > Er..I mixed up the terminology.  By "same connection", I meant
> > > > > "same CID" - so one could retry cmds ONLY on the new TCP connection
> > > > > with the same CID, after the old TCP connection had failed.
> > > > > This avoids having to change connection allegiance on
> > > > > the stuck commands, as part of connection logout.
> > > > >
> > > > > The main questions, however, were these :
> > > > >
> > > > > 1) What is the effect of a CID logout on the status (statSN)
> > > > >    cache ?  Can it be reused when the commands are retried ?
> > > > >    (Think not..)
> > > > >
> > > > > 2) After one does a login for recovery using an old CID,
> > > > >    can new SCSI commands be issued on that new TCP connection.
> > > > >    (though it bears an old CID identifier)
> > > > >
> > > > > -Sandeep
> > > > >
> > > > > > Sandeep,
> > > > > >
> > > > > > Retry over any connection was always the case.
> > > > > > Commands can change allegiance only after a logout.
> > > > > > The commands get quiesced anyway and you have to mark them ready
> > for
> > > a
> > > > > > retry anyhow (you don't want retry at arbitrary times to hit
> > > unpunished
> > > > > the
> > > > > > target). After that it doesn't matter where you retry (same
> > > connection,
> > > > > > another old one, a new one).
> > > > > >
> > > > > > The only new thing is command replay (after status was sent but
> > > before
> > > > it
> > > > > > is acked).
> > > > > >
> > > > > > Regards,
> > > > > > Julo
> > > > > >
> > > > > > sandeepj@research.bell-labs.com (Sandeep Joshi) on 28-07-2001
> > > 06:37:33
> > > > > >
> > > > > > Please respond to sandeepj@research.bell-labs.com (Sandeep Joshi)
> > > > > >
> > > > > > To:   ips@ece.cmu.edu
> > > > > > cc:
> > > > > > Subject:  iSCSI connection recovery
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > I had a "big-picture" question about the connection
> > > > > > recovery model.
> > > > > >
> > > > > > The current draft suggests that, once the broken connection
> > > > > > is logged out, the commands allegiant to the old connection
> > > > > > can now be retried over *any* connection. (See Section 7.11.3
> > > > > > bullet 1 and also Appendix F Session Recovery algo for
> > > > > > initiator.)
> > > > > >
> > > > > > I may be mistaken, but in previous drafts, this was not
> > > > > > the case and commands always stayed allegiant to a CID.
> > > > > >
> > > > > > So the question is.. how does one use a Status cache
> > > > > > belonging to the old connection in this new model (now that
> > > > > > the commands are going to be retried over any connection)
> > > > > > Doesnt this become more complex ?
> > > > > >
> > > > > > Secondly, this also means that one must walk the command
> > > > > > list at the target and quiesce connection allegiance during
> > > > > > logout - which may not be required if the commands were to be
> > > > > > retried over the same connection always.
> > > > > >
> > > > > > Comments  ?
> > > > > >
> > > > > > -Sandeep
> > > > > >
> > > > > >
> > > > > >
> >
> >
> 
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com


From owner-ips@ece.cmu.edu  Wed Aug  1 20:33:47 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13096
	for <ips-archive@odin.ietf.org>; Wed, 1 Aug 2001 20:33:47 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f71NsYr21968
	for ips-outgoing; Wed, 1 Aug 2001 19:54:34 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f71NsWe21963
	for <ips@ece.cmu.edu>; Wed, 1 Aug 2001 19:54:32 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id BAA113182
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 01:54:25 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f71NsPt133942
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 01:54:25 +0200
Importance: Normal
Subject: Re: iSCSI: draft 7: iSCSI response and SCSI sense data
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF6C381003.6433C6E8-ONC2256A9B.008362D0@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Thu, 2 Aug 2001 03:00:31 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 02/08/2001 02:54:25
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Elliot,

This issue has some history.  After many took the position you are
advocating
and I had to drop the check condition all list participants that had
something to say adopted the current position in order the benefit from the
"serializing" effect of ACA whenever a check condition is originated at the
target and the delivery subsystem is still operational.

Julo


"Elliott, Robert" <Robert.Elliott@compaq.com> on 02-08-2001 02:26:57

Please respond to "Elliott, Robert" <Robert.Elliott@compaq.com>

To:   "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
cc:
Subject:  iSCSI: draft 7: iSCSI response and SCSI sense data




iSCSI draft 7 section 2.4.3 includes a table relating the iSCSI
response codes to various CHECK CONDITION status additional
sense codes:

  "0x01 Target Failure
    ASC=0x44 ASCQ=0x00 INTERNAL TARGET FAILURE
  0x02 Delivery Subsystem Failure
    ASC=0x47 ASCQ=0x03 INFORMATION UNIT CRC ERROR DETECTED
  0x03 Unsolicited data rejected
    ASC=0x49 ASCQ=0x00 INVALID MESSAGE ERROR
  0x04 Not enough unsolicited [data]
    ASC=0x49 ASCQ=0x00 INVALID MESSAGE ERROR
  0x05 SNACK rejected [Command in progress]
    ASC=0x47 ASCQ=0x03 INFORMATION UNIT CRC ERROR DETECTED

  As listed above, each defined response code MUST be used (under the
  conditions described in the 'Reason' field), only when the
  corresponding SCSI CHECK CONDITION is signaled, to convey additional
  protocol service information.  A SCSI CHECK CONDITION with the ASC
  and ASCQ values as tabulated MUST be signaled by iSCSI targets for
  all the instances in this document referring to usage of one of the
  above defined response codes."

No other SCSI protocol does this. iSCSI seems to be granting the
SCSI-level status a priority over the iSCSI-level response data.
I think the other protocols treat the response data as more
important; if the response data indicates a problem, the SCSI layer
is considered broken and the SCSI status is undefined.

Forcing the iSCSI layer to fill in those fields seems to break the
layering model.

I suggest removing the CHECK CONDITION status and additional sense
code linkage and leave the SCSI status undefined if the iSCSI
response is nonzero.

This is compatible with SAM-2, which only requires status be returned
when the service response is TASK COMPLETE (SAM-2 revision 18
section 5.3.1):
  "Status shall be sent from the logical unit to the application
   client whenever a command ends with a service response of
   TASK COMPLETE or LINKED COMMAND COMPLETE."

Furthermore, SAM-2 requires that status be ignored when the service
response indicates an error (SAM-2 revision 18 section 5.1):
  "Status: A one-byte field containing command completion status
  (see 5.3). If the command ends with a service response of
  SERVICE DELIVERY OR TARGET FAILURE, the application client
  shall consider this parameter to be undefined."

I think iSCSI's current wording may violate this rule.
---
Rob Elliott, Compaq Server Storage
Robert.Elliott@compaq.com






From owner-ips@ece.cmu.edu  Wed Aug  1 20:36:00 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13165
	for <ips-archive@odin.ietf.org>; Wed, 1 Aug 2001 20:36:00 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f71NRCe20796
	for ips-outgoing; Wed, 1 Aug 2001 19:27:12 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f71NRBe20791
	for <ips@ece.cmu.edu>; Wed, 1 Aug 2001 19:27:11 -0400 (EDT)
Received: by zmamail05.zma.compaq.com (Postfix, from userid 12345)
	id BD88ADAB; Wed,  1 Aug 2001 19:27:05 -0400 (EDT)
Received: from exchou-gh02.cca.cpqcorp.net (exchou-gh02.cca.cpqcorp.net [16.110.248.202])
	by zmamail05.zma.compaq.com (Postfix) with ESMTP id AAF19E49
	for <ips@ece.cmu.edu>; Wed,  1 Aug 2001 19:27:03 -0400 (EDT)
Received: by exchou-gh02.cca.cpqcorp.net with Internet Mail Service (5.5.2652.78)
	id <QCJKPGA6>; Wed, 1 Aug 2001 18:27:03 -0500
Message-ID: <78AF3C342AEAEF4BA33B35A8A15668C6019E2006@cceexc17.americas.cpqcorp.net>
From: "Elliott, Robert" <Robert.Elliott@compaq.com>
To: "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
Subject: iSCSI: draft 7: iSCSI response and SCSI sense data
Date: Wed, 1 Aug 2001 18:26:57 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

iSCSI draft 7 section 2.4.3 includes a table relating the iSCSI 
response codes to various CHECK CONDITION status additional 
sense codes:

  "0x01 Target Failure
    ASC=0x44 ASCQ=0x00 INTERNAL TARGET FAILURE
  0x02 Delivery Subsystem Failure 
    ASC=0x47 ASCQ=0x03 INFORMATION UNIT CRC ERROR DETECTED
  0x03 Unsolicited data rejected
    ASC=0x49 ASCQ=0x00 INVALID MESSAGE ERROR
  0x04 Not enough unsolicited [data]
    ASC=0x49 ASCQ=0x00 INVALID MESSAGE ERROR
  0x05 SNACK rejected [Command in progress]
    ASC=0x47 ASCQ=0x03 INFORMATION UNIT CRC ERROR DETECTED

  As listed above, each defined response code MUST be used (under the 
  conditions described in the 'Reason' field), only when the 
  corresponding SCSI CHECK CONDITION is signaled, to convey additional 
  protocol service information.  A SCSI CHECK CONDITION with the ASC 
  and ASCQ values as tabulated MUST be signaled by iSCSI targets for 
  all the instances in this document referring to usage of one of the 
  above defined response codes."
 
No other SCSI protocol does this. iSCSI seems to be granting the 
SCSI-level status a priority over the iSCSI-level response data.  
I think the other protocols treat the response data as more 
important; if the response data indicates a problem, the SCSI layer 
is considered broken and the SCSI status is undefined.  

Forcing the iSCSI layer to fill in those fields seems to break the 
layering model.

I suggest removing the CHECK CONDITION status and additional sense 
code linkage and leave the SCSI status undefined if the iSCSI 
response is nonzero.

This is compatible with SAM-2, which only requires status be returned
when the service response is TASK COMPLETE (SAM-2 revision 18
section 5.3.1):
  "Status shall be sent from the logical unit to the application 
   client whenever a command ends with a service response of 
   TASK COMPLETE or LINKED COMMAND COMPLETE."

Furthermore, SAM-2 requires that status be ignored when the service
response indicates an error (SAM-2 revision 18 section 5.1):
  "Status: A one-byte field containing command completion status 
  (see 5.3). If the command ends with a service response of 
  SERVICE DELIVERY OR TARGET FAILURE, the application client 
  shall consider this parameter to be undefined."

I think iSCSI's current wording may violate this rule.
---
Rob Elliott, Compaq Server Storage
Robert.Elliott@compaq.com



From owner-ips@ece.cmu.edu  Wed Aug  1 20:36:08 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13199
	for <ips-archive@odin.ietf.org>; Wed, 1 Aug 2001 20:36:08 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f71NlN521657
	for ips-outgoing; Wed, 1 Aug 2001 19:47:23 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mxic1.isus.emc.com ([168.159.129.100])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f71NlLe21653
	for <ips@ece.cmu.edu>; Wed, 1 Aug 2001 19:47:22 -0400 (EDT)
Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <QCBJ1ZRQ>; Wed, 1 Aug 2001 19:49:16 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD549@CORPMX14>
From: Black_David@emc.com
To: rsnively@Brocade.COM, ips@ece.cmu.edu
Subject: RE: Security Gateways
Date: Wed, 1 Aug 2001 19:42:24 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Bob,

An RFC does not tell anyone what can or cannot be built;
it specifies what is required for compliance with the RFC.
If someone builds a protocol implementations that doesn't
comply with the requirements of the RFC, they should not
expect to be able to claim RFC compliance for devices 
based on that implementation.

> The marketplace does demand that
> security be possible and available for a device.  

The compliance requirement here is that "possible and
available" be realizable without having to add anything
to the device.  For the structure of interest here,
an FCIP device plus a security gateway, the complete system
[FCIP device, cable, security gateway] would comply with
the FCIP RFC at its external interface (i.e., the external
interface of the security gateway).  The interface between
the FCIP device and the security gateway would be missing
some required security functionality and hence would
not comply with the RFC.  As a result, the FCIP device by
itself would not comply with the RFC.

> I can understand why the IESG would push back on this
> question, but I would expect that they also believe that
> an FCIP device without optional security implemented
> is still an FCIP device and is compliant with the FCIP RFC. 

If "optional" means "MUST implement, but MAY use", that
expectation would be incorrect.  "MUST implement" (cf.
RFC 2119) is the level of requirement for authentication
and cryptographic integrity that is necessary for FCIP
to be approved as an RFC.  This isn't just "push back"
from the IESG - it is a condition that the IESG required
for its original approval of the IPS WG charter.

> With an edge security device installed 
> in front of it, it is also a
> secure FCIP device, just like the end-point of a 
> virtual private network is a secure device. 

That combination will comply with the RFC.  OTOH, the
IESG will not permit the FCIP RFC to allow an FCIP device
that lacks the basic security mechanisms to be compliant,
and hence the FCIP device *without* the edge security
device will not comply.

> By definition, "man in the middle" attacks are impossible
> for a security edge device, since the only place that the
> "man in the middle" can be placed is in the encrypted path.

"By definition" is not the best wording.  Assuming that the
"security edge device" is an IPsec security gateway, the IKE
and ISAKMP  protocols are to negotiate security functionality
and parameters; those protocols are resistant to man-in-the-
middle attacks, but that resistance is based on careful design.

--David


> -----Original Message-----
> From: Robert Snively [mailto:rsnively@brocade.com]
> Sent: Wednesday, August 01, 2001 6:25 PM
> To: 'Black_David@emc.com'; Robert Snively; ips@ece.cmu.edu
> Subject: RE: Security Gateways
> 
> 
> David,
> 
> I believe this is really a very difficult question, not
> susceptible to a simple SHALL/SHALL NOT response.  
> The technology absolutely allows and encourages
> security edge devices and absolutely allows devices using
> TCP and other protocols to exploit those edge devices or
> not as the system administrator requires.  The marketplace
> absolutely demands those capabilities.  A significant percentage
> of the internet economy is based on separately supplied security.
> I understand that the IETF
> has no interest in devices that are solely for closed
> environments, but the marketplace does not demand that
> a device have security built in to qualify for compliance with a
> protocol.  The marketplace does demand that
> security be possible and available for a device.  
> 
> That is what we have been proposing.
> 
> By definition, "man in the middle" attacks are impossible
> for a security edge device, since the only place that the
> "man in the middle" can be placed is in the encrypted path.
> The physically secured path has no possibility of an
> entry point for such an attack.  
> 
> I can understand why the IESG would push back on this
> question, but I would expect that they also believe that
> an FCIP device without optional security implemented
> is still an FCIP device and is compliant with the FCIP RFC. 
> This should be true whether the TCP path is based on IP,
> HIPPI, IB, a proprietary backplane or any other transport 
> that supports TCP. With an edge security device installed 
> in front of it, it is also a
> secure FCIP device, just like the end-point of a 
> virtual private network is a secure device. 
> 
> That is what we would like the RFC to say.
> 
> Bob
> 
> -----Original Message-----
> From: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Wednesday, August 01, 2001 10:13 AM
> To: rsnively@brocade.com; ips@ece.cmu.edu
> Subject: RE: Security Gateways
> 
> 
> Bob,
> 
> You've made a good case for "optional to use", but not
> "optional to implement".  The basic reason is that there
> is no way to ensure that vendors and/or users will
> restrict the use of an implementation that does not
> include security to situations where "paths of a
> storage environment are physically secured and have 
> no requirement for additional security mechanisms".
> Hence security needs to be present so that it
> can be used when FCIP is deployed in an environment
> that requires security.  Further, the IETF has no
> interest in specification of protocols that are
> *solely* for use in the sort of closed environment
> that you describe, and the IPS WG charter contains
> explicit words to that effect.
> 
> Therefore, the basic FCIP security mechanisms MUST be
> implemented, but usage MAY be negotiated.  At the moment,
> "basic security mechanisms" means authentication and
> cryptographic integrity.  Confidentiality can currently
> be optional to implement, but I think it's a very good
> idea to specify the basic confidentiality mechanism
> (*if* confidentiality of any form is implemented, *then*
> <XXX> MUST be implemented).  The design and specification
> of any negotiation mechanism must resist man-in-the-middle
> attacks on negotiation that would result in turning off
> security where that was not the intended outcome - such
> an approach can include restrictions on implementation
> behavior (e.g., if "no authentication" is not acceptable,
> do not offer or accept it during negotiation).
> 
> If the FCIP draft is sent to the IESG without requiring
> implementation of the basic security mechanisms, it will
> be returned to the WG with instructions to correct
> that shortcoming, along with some choice words from the
> ADs wondering how the WG chairs could have overlooked
> something like this.  As a result, an FCIP draft that
> does not require implementation of the basic security
> mechanisms will not be Last Called in the WG until that
> requirement is added.
> 
> Sorry to be blunt, but there is no flexibility on whether
> the basic security mechanisms are mandatory to implement;
> they will be mandatory to implement, period.
> 
> Thanks,
> --David
> 
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------
> 
> 
> > -----Original Message-----
> > From: Robert Snively [mailto:rsnively@brocade.com]
> > Sent: Wednesday, August 01, 2001 12:08 PM
> > To: 'Black_David@emc.com'; ips@ece.cmu.edu
> > Subject: RE: Security Gateways
> > 
> > 
> > Dear David,
> > 
> > I would like to address the rather serious question you have
> > raised here about both architectural layering and market
> > requirements.  After considerable thought, based on the
> > explanations below, I have concluded that the FCIP RFC should
> > specify that security is optional to implement and optional to use.
> > 
> > 1)  Concerning architectural layering:
> > 
> > It is clear that the problems of security are well understood
> > within IETF. Numerous solutions have been proposed and
> > many of those have become standard implementations.  The most
> > successful of those (as an example, IPSec) have used the
> > principles of architectural layering very well.  IPSec
> > provides a secure mechanism for transporting any IP-based
> > protocol if the protocol requires such security.  However,
> > the overlaying protocols (as an example, TCP) have no requirement
> > to actually make use of IPSec, and in fact have no particular
> > requirement to make use of IP.  This is as it should be.
> > Each layer is implemented independently of the other.  The
> > services that each layer implements depend on the market
> > requirements for the environment.  By that logic, it is 
> > unnecessary for FCIP to specify any security mechanism at all, 
> > since so many security mechanisms are available.  However,
> > FCIP has provided the additional guidance that, if security
> > in a TCP environment is used, it shall be provided at a layer
> > below the TCP interface.  In particular, it recommends the
> > use of IPSec for TCP/IP environments (and will recommend the
> > appropriate IPSec options).  This additional guidance has nothing
> > to do with the architecture or definition of FCIP and is 
> > merely a recommendation that should improve interoperability.
> > 
> > 2)  Concerning market requirements:
> > 
> > A very high percentage of storage environments today manage
> > their configurations very carefully.  Such careful management is
> > necessary to guarantee redundant paths for proper availability,
> > to provide sufficient paths to provide the required 
> > performance, and to
> > guarantee known paths to improve reparability and consistency
> > of behavior.  As a side effect, a very high percentage of
> > the paths of a storage environment are physically secured and have
> > no requirement for additional security mechanisms.  At present,
> > the only paths that are using security are those very few paths
> > that leave one physically secure environment to transport data to
> > another physically secure environment.  Those few paths 
> > almost universally
> > use security mechanisms at a lower level (as an example, a virtual
> > private network) to achieve their goals.  As a first guess, such
> > paths are well under 1% of the storage paths being used today.
> > 
> > I do not believe that this paradigm will change significantly over
> > the next several years, although of course the percentage of paths
> > requiring transport security may rise over 1%.  The requirements for
> > storage performance and the desire to maintain the storage devices
> > and many of their primary processors in a physically secure
> > environment will assure similar configurations.
> > 
> > In this environment, the market will demand low cost and high
> > performance for the great majority of interconnects and will demand
> > security for a relatively low percentage of interconnects.  
> > 
> > What this implies for technologies like FCIP is that security
> > be available as a separate option, outside the primary FCIP
> > definition.  While still allowing the integration of security
> > inside an FCIP unit, the IETF draft for FCIP  must also 
> allow security
> > to be provided either not at all or by an outside mechanism.  
> > The most common outside mechanism would be a gateway box of 
> some sort.
> > In many cases, the gateway box will be a secure router placed on the
> > external link and servicing a large number of locally attached
> > unsecured FCIP boxes.
> > 
> > CONCLUSIONS:
> > 
> > The FCIP draft should continue to specify a security mechanism,
> > with IPSec being the appropriate candidate, to guarantee 
> > interoperability
> > when security is provided.  The FCIP draft should be modified to
> > indicate that security is optional to implement and optional to use.
> > In addition, it should explicitly indicate that external gateway
> > boxes are allowed implementation mechanisms for security.
> > 
> > As a side question, note that management of storage area networks
> > and FCIP boxes is a separate question and is outside the scope of
> > the FCIP draft.  Both Fibre Channel and Ethernet management paths
> > have security appropriate to the particular management mechanism.
> > As an example, web-based management mechanisms use web-based
> > security tools. 
> > 
> > Bob Snively                        e-mail:    rsnively@brocade.com
> > Brocade Communications Systems     phone:  408 487 8135
> > 1745 Technology Drive
> > San Jose, CA 95110
> > 
> > 
> > 
> > -----Original Message-----
> > From: Black_David@emc.com [mailto:Black_David@emc.com]
> > Sent: Tuesday, July 24, 2001 7:11 PM
> > To: ips@ece.cmu.edu
> > Subject: Security Gateways
> > 
> > 
> > The following issue was hidden in my long set of
> > comments on the -03 version of FCIP:
> > 
> > > > Delete 12 b).  If an FCIP entity is operating with an external
> > > > security gateway, only the interface on the public side of the
> > > > gateway is compliant with this specification.  The interface
> > > > between the FCIP entity and the gateway is not compliant because
> > > > it is lacking required security features - the FCIP entity
> > > > *includes* the security gateway in this structure.
> > > 
> > > Please post this as a separate issue because several of the
> > > FCIP Authors believe it is appropriate for FCIP and I cannot
> > > represent their opinions.
> > 
> > The issue is not whether it's "appropriate".  The issue
> > is that if an implementation uses an FCIP Entity plus
> > an external security gateway, the only interface that
> > conforms to the forthcoming RFC is the public/external
> > interface on the security gateway.  The interface between
> > the FCIP Entity and the security gateway is private
> > and fails to conform to the security that will be
> > required of all FCIP implementations.
> > 
> > The above paragraph also applies to iSCSI (substitute iSCSI
> > for FCIP in all instances).  Let me also note that iSCSI's
> > ability to use a security gateway is not final at this
> > juncture.  The spectrum of security possibilities includes
> > things like SRP keying of ESP and IPsec transport mode that
> > would make external gateways difficult or impossible to use.
> > 
> > Those who care about being able to use security gateways
> > (or think that there's no need to support their use)
> > should speak up on the list, in London, and/or in Orange
> > County (I would expect the decision not to be made prior
> > to Orange County) and *EXPLAIN WHY* [technical rationale].
> > 
> > Thanks,
> > --David
> > 
> > ---------------------------------------------------
> > David L. Black, Senior Technologist
> > EMC Corporation, 42 South St., Hopkinton, MA  01748
> > +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> > black_david@emc.com       Mobile: +1 (978) 394-7754
> > ---------------------------------------------------
> >  
> > 
> 


From owner-ips@ece.cmu.edu  Wed Aug  1 22:00:33 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA16835
	for <ips-archive@odin.ietf.org>; Wed, 1 Aug 2001 22:00:29 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f721Bhm24912
	for ips-outgoing; Wed, 1 Aug 2001 21:11:43 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from chmls16.mediaone.net (chmls16.mediaone.net [24.147.1.151])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f721Bge24908
	for <ips@ece.cmu.edu>; Wed, 1 Aug 2001 21:11:42 -0400 (EDT)
Received: from cs.uchicago.edu (h005018030f43.ne.mediaone.net [24.91.87.73])
	by chmls16.mediaone.net (8.11.1/8.11.1) with ESMTP id f721BfP01317
	for <ips@ece.cmu.edu>; Wed, 1 Aug 2001 21:11:41 -0400 (EDT)
Message-Id: <200108020111.f721BfP01317@chmls16.mediaone.net>
To: ips@ece.cmu.edu
Subject: Re: iSCSI: draft 7: iSCSI response and SCSI sense data 
In-Reply-To: Message from "Julian Satran" <Julian_Satran@il.ibm.com> 
   of "Thu, 02 Aug 2001 03:00:31 +0300." <OF6C381003.6433C6E8-ONC2256A9B.008362D0@telaviv.ibm.com> 
References: <OF6C381003.6433C6E8-ONC2256A9B.008362D0@telaviv.ibm.com> 
Date: Wed, 01 Aug 2001 21:11:36 -0400
From: Stephen Bailey <steph@cs.uchicago.edu>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Robert,

> This issue has some history.

I agree that the mapping from response codes to check conditions,
while explanatory, is not appropriate in the iSCSI spec.  I think we
HAVE made a muddle of what's been a somewhat clear, acceptable
tradition.

The key technical point is that a SCSI target SHOULD (and we should
make this a MUST by providing no other mechanism) report every error
that it can report within the confines of SCSI status using SCSI
status.

Specifically, for every SCSI Command PDU, the target should return a
valid SCSI status, or nothing at all (e.g. timeout).

In my opinion, FCP did not necessarily get this quite right, but some
target's do the right thing implementations actually do the right
thing anyway.  Specifically, the definition of the response codes
seems to suggest that if you set both data direction bits (R&W), or
perhaps set the data direction in opposition to the command, you
should get an RSP_CODE=FCP_CMND fields invalid.  It's quite irritating
that FCP targets have this choice, and while one alternative (picking
SCSI status, e.g. 0xb/0x4700---parity error is traditional) can be
signalled cleanly to the end client (the class driver), the other may
be more difficult.

Really, the best use for response information in FCP is to return
status on task management operations.  In this case, SCSI doesn't
define particular status values anyway.  Given that iSCSI have separate
the SCSI Response and Task Management Response PDUs, I don't see why
we need Response information in the SCSI Response at all.  I think we
should dump this field completely.

I particularly think that `target failure' and `delivery subsystem
failure' are two status that should never be explicitly communicated
from the target to the initiator.  These are statuses that the
initiator infers as a result of something like a timeout, a link state
change, or whatnot.

Steph


From owner-ips@ece.cmu.edu  Wed Aug  1 22:22:00 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA17470
	for <ips-archive@odin.ietf.org>; Wed, 1 Aug 2001 22:22:00 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f721OQW25389
	for ips-outgoing; Wed, 1 Aug 2001 21:24:26 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f721OPe25385
	for <ips@ece.cmu.edu>; Wed, 1 Aug 2001 21:24:25 -0400 (EDT)
Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <3W0T30QH>; Wed, 1 Aug 2001 21:24:20 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD54D@CORPMX14>
From: Black_David@emc.com
To: Julian_Satran@il.ibm.com, ips@ece.cmu.edu
Subject: RE: iSCSI: draft 7: iSCSI response and SCSI sense data
Date: Wed, 1 Aug 2001 21:19:27 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

In my lousy Indiana Jones impression - "ACA, why does it
always have to be ACA?" ....

This whole notion that ACA is a fundamental coordination
mechanism for shared SCSI access to a target is not headed
in a good direction - see the recent message from Ralph Weber
expressing T10's concern that expansion of the usage of ACA is
an invitation to undesirable denial of service possibilities.
I will note that the reservation example that Ralph used in his
message is the sort of thing that can break clustering software,
although I don't know for certain whether there's any existing
clustering software that it does in fact break.

I think Rob and Jim are correct when they describe the current
2.4.3 text as being at odds with SAM-2.  So, I think:

- The text in 2.4.3 that is at odds with SAM-2 should come out.
	The fact that it was caused by a desire to use ACA makes
	it doubly suspect.
- The current mandate for ACA in Section 8.2 exceeds the level
	stated in the iSCSI requirements draft and I don't believe
	it represents rough consensus of the WG.  Support for
	ACA should be a "SHOULD", not a "MUST".
- The entire effort to use ACA or something like it to serialize
	error conditions for multiple commands in flight has not been
	explained well to T10, and what has been explained has not
	received a good reception.

The last bullet has a couple of consequences.  First, we should 
take out anything else that's crept into iSCSI in support of this
use of ACA.  Second, those who want to use ACA or something ACA-like
for this error coordination across multiple commands in flight
should write up a submission to T10 explaining what the problem
is and how ACA or something like it solves the problem.

I think Ralph is conveying a message from T10 that whatever the
problem iSCSI has, T10 is not inclined to believe that more use
of ACA is NOT the solution.  It may take a while to work with T10
to get the right solution designed, but I'd prefer doing nothing
over force-fitting ACA to a use that T10 doesn't think is appropriate.
When we figure out what the right thing is, we can put in the right
text to describe it.

Comments?
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------



> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Wednesday, August 01, 2001 8:01 PM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI: draft 7: iSCSI response and SCSI sense data
> 
> 
> 
> Elliot,
> 
> This issue has some history.  After many took the position you are
> advocating
> and I had to drop the check condition all list participants that had
> something to say adopted the current position in order the 
> benefit from the
> "serializing" effect of ACA whenever a check condition is 
> originated at the
> target and the delivery subsystem is still operational.
> 
> Julo
> 
> 
> "Elliott, Robert" <Robert.Elliott@compaq.com> on 02-08-2001 02:26:57
> 
> Please respond to "Elliott, Robert" <Robert.Elliott@compaq.com>
> 
> To:   "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
> cc:
> Subject:  iSCSI: draft 7: iSCSI response and SCSI sense data
> 
> 
> 
> 
> iSCSI draft 7 section 2.4.3 includes a table relating the iSCSI
> response codes to various CHECK CONDITION status additional
> sense codes:
> 
>   "0x01 Target Failure
>     ASC=0x44 ASCQ=0x00 INTERNAL TARGET FAILURE
>   0x02 Delivery Subsystem Failure
>     ASC=0x47 ASCQ=0x03 INFORMATION UNIT CRC ERROR DETECTED
>   0x03 Unsolicited data rejected
>     ASC=0x49 ASCQ=0x00 INVALID MESSAGE ERROR
>   0x04 Not enough unsolicited [data]
>     ASC=0x49 ASCQ=0x00 INVALID MESSAGE ERROR
>   0x05 SNACK rejected [Command in progress]
>     ASC=0x47 ASCQ=0x03 INFORMATION UNIT CRC ERROR DETECTED
> 
>   As listed above, each defined response code MUST be used (under the
>   conditions described in the 'Reason' field), only when the
>   corresponding SCSI CHECK CONDITION is signaled, to convey additional
>   protocol service information.  A SCSI CHECK CONDITION with the ASC
>   and ASCQ values as tabulated MUST be signaled by iSCSI targets for
>   all the instances in this document referring to usage of one of the
>   above defined response codes."
> 
> No other SCSI protocol does this. iSCSI seems to be granting the
> SCSI-level status a priority over the iSCSI-level response data.
> I think the other protocols treat the response data as more
> important; if the response data indicates a problem, the SCSI layer
> is considered broken and the SCSI status is undefined.
> 
> Forcing the iSCSI layer to fill in those fields seems to break the
> layering model.
> 
> I suggest removing the CHECK CONDITION status and additional sense
> code linkage and leave the SCSI status undefined if the iSCSI
> response is nonzero.
> 
> This is compatible with SAM-2, which only requires status be returned
> when the service response is TASK COMPLETE (SAM-2 revision 18
> section 5.3.1):
>   "Status shall be sent from the logical unit to the application
>    client whenever a command ends with a service response of
>    TASK COMPLETE or LINKED COMMAND COMPLETE."
> 
> Furthermore, SAM-2 requires that status be ignored when the service
> response indicates an error (SAM-2 revision 18 section 5.1):
>   "Status: A one-byte field containing command completion status
>   (see 5.3). If the command ends with a service response of
>   SERVICE DELIVERY OR TARGET FAILURE, the application client
>   shall consider this parameter to be undefined."
> 
> I think iSCSI's current wording may violate this rule.
> ---
> Rob Elliott, Compaq Server Storage
> Robert.Elliott@compaq.com
> 
> 
> 
> 


From owner-ips@ece.cmu.edu  Wed Aug  1 22:22:03 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA17481
	for <ips-archive@odin.ietf.org>; Wed, 1 Aug 2001 22:22:02 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f721pps26437
	for ips-outgoing; Wed, 1 Aug 2001 21:51:51 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mxic2.us.dg.com (mxic2.us.dg.com [128.221.31.40])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f721poe26432
	for <ips@ece.cmu.edu>; Wed, 1 Aug 2001 21:51:50 -0400 (EDT)
Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19)
	id <PJ5VNSZN>; Wed, 1 Aug 2001 21:49:59 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD54F@CORPMX14>
From: Black_David@emc.com
To: ips@ece.cmu.edu
Subject: iSCSI - three negotiation items
Date: Wed, 1 Aug 2001 21:46:53 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Going through the list of simplification suggestions,
I found a few items that look like they
should be reasonable to deal with on the list.

(1) For any key that can take a numeric value, could
we specify the required base for the number, either
decimal or hex, not both.  The practical issue is that
the sort of large values used for keys and the like
in security are much easier to deal with in hex than
decimal.

(2) The KRB5 and SPKM inband cryptographic integrity
digests on p.136 seem to be relics of a prior inband
approach to security.  Has anyone implemented them?
Does anyone want them to remain?  Can we just delete
them?

(3) Can HeaderDigest and DataDigest be combined?
If (2) is done, this is about making use of CRC-32C
a single on/off switch rather than two separate switches
for header and data?

Comments?  Objections (with rationale)?

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


From owner-ips@ece.cmu.edu  Wed Aug  1 22:51:29 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA19350
	for <ips-archive@odin.ietf.org>; Wed, 1 Aug 2001 22:51:29 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f720qnH24211
	for ips-outgoing; Wed, 1 Aug 2001 20:52:49 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f720qme24207
	for <ips@ece.cmu.edu>; Wed, 1 Aug 2001 20:52:48 -0400 (EDT)
Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <3W0T39WN>; Wed, 1 Aug 2001 20:52:43 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD54C@CORPMX14>
From: Black_David@emc.com
To: bill@strahm.net, ips@ece.cmu.edu
Subject: RE: Security Gateways
Date: Wed, 1 Aug 2001 20:47:51 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Bill,

> I believe I have to disagree with you David.  The IESG WILL approve specs
> that do not offically include encryption.  An example might be RFC 2801
> The Internet Open Trading Protocol - IOTP Version 1.0.

Unfortunately, that's a red herring ...

(1) The issue is not encryption - that's OPTIONAL to implement and
	OPTIONAL to use for FCIP at the moment, but should be specified.
	The issue is authentication and cryptographic integrity, which
	RFC 2801 doesn't appear to require either.  This may be because ...

(2) RFC 2801 is Informational.  Informational RFCs generally don't
	state requirements for compliance or conformance, and RFC 2801
	is running somewhat true to that form by not even referencing
	RFC 2119 for definitions of MUST/SHOULD/MAY.  In contrast ...

(3) FCIP will be standards-track, and hence will be held to a higher
	standard by the IESG.  This set of security requirements is
	doubtless one of a number of things that might be acceptable
	in an Informational RFC but not in a Standards-Track RFC.

Also, my description of what the IESG is requiring was specific
to the IPS WG (and my original words were specific to FCIP), so
the fact that an Informational RFC in a different area did something
different is not particularly relevant.

I've received rather direct guidance on this topic from the
Area Directors, and I believe I'm accurately representing the
requirements.  

--David

> -----Original Message-----
> From: Bill Strahm [mailto:bill@strahm.net]
> Sent: Wednesday, August 01, 2001 6:12 PM
> To: Black_David@emc.com
> Cc: rsnively@Brocade.COM; ips@ece.cmu.edu
> Subject: RE: Security Gateways
> 
> 
> Ok,
> 
> I believe I have to disagree with you David.  The IESG WILL 
> approve specs
> that do not offically include encryption.  An example might 
> be RFC 2801
> The Internet Open Trading Protocol - IOTP Version 1.0.
> 
> From this documents own security section comes the statement
> 5.3 Data Privacy
> 
>    Privacy of information is provided by sending IOTP Messages between
>    the various Trading Roles using a secure channel such as [SSL/TLS].
>    Use of a secure channel within IOTP is optional.
> 
> The security section also talks about why you might or might 
> not want to
> use digital signatures for performing Online transactions.
> 
> It boils down to allowing vendors to create products that 
> customers wish
> to buy.  If it turns out that custommers ARE NOT willing to 
> pay a single
> dime for security, why are you going to burden a vendors 
> implementation
> with security requirements that do not provide value to the 
> customer.  If
> customers value security, you will see a quick rise in the 
> sale of secure
> storage products.
> 
> I think it is perfectly acceptable to point to a security 
> implementation
> (IPsec, TLS, or roll our own in a seperate document), but to 
> require it
> for protocol correctness I do not think is needed for any reason.
> 
> Bill
> 
> On Wed, 1 Aug 2001 Black_David@emc.com wrote:
> 
> > Bob,
> > 
> > You've made a good case for "optional to use", but not
> > "optional to implement".  The basic reason is that there
> > is no way to ensure that vendors and/or users will
> > restrict the use of an implementation that does not
> > include security to situations where "paths of a
> > storage environment are physically secured and have 
> > no requirement for additional security mechanisms".
> > Hence security needs to be present so that it
> > can be used when FCIP is deployed in an environment
> > that requires security.  Further, the IETF has no
> > interest in specification of protocols that are
> > *solely* for use in the sort of closed environment
> > that you describe, and the IPS WG charter contains
> > explicit words to that effect.
> > 
> > Therefore, the basic FCIP security mechanisms MUST be
> > implemented, but usage MAY be negotiated.  At the moment,
> > "basic security mechanisms" means authentication and
> > cryptographic integrity.  Confidentiality can currently
> > be optional to implement, but I think it's a very good
> > idea to specify the basic confidentiality mechanism
> > (*if* confidentiality of any form is implemented, *then*
> > <XXX> MUST be implemented).  The design and specification
> > of any negotiation mechanism must resist man-in-the-middle
> > attacks on negotiation that would result in turning off
> > security where that was not the intended outcome - such
> > an approach can include restrictions on implementation
> > behavior (e.g., if "no authentication" is not acceptable,
> > do not offer or accept it during negotiation).
> > 
> > If the FCIP draft is sent to the IESG without requiring
> > implementation of the basic security mechanisms, it will
> > be returned to the WG with instructions to correct
> > that shortcoming, along with some choice words from the
> > ADs wondering how the WG chairs could have overlooked
> > something like this.  As a result, an FCIP draft that
> > does not require implementation of the basic security
> > mechanisms will not be Last Called in the WG until that
> > requirement is added.
> > 
> > Sorry to be blunt, but there is no flexibility on whether
> > the basic security mechanisms are mandatory to implement;
> > they will be mandatory to implement, period.
> > 
> > Thanks,
> > --David
> > 
> > ---------------------------------------------------
> > David L. Black, Senior Technologist
> > EMC Corporation, 42 South St., Hopkinton, MA  01748
> > +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> > black_david@emc.com       Mobile: +1 (978) 394-7754
> > ---------------------------------------------------
> > 
> > 
> > > -----Original Message-----
> > > From: Robert Snively [mailto:rsnively@brocade.com]
> > > Sent: Wednesday, August 01, 2001 12:08 PM
> > > To: 'Black_David@emc.com'; ips@ece.cmu.edu
> > > Subject: RE: Security Gateways
> > > 
> > > 
> > > Dear David,
> > > 
> > > I would like to address the rather serious question you have
> > > raised here about both architectural layering and market
> > > requirements.  After considerable thought, based on the
> > > explanations below, I have concluded that the FCIP RFC should
> > > specify that security is optional to implement and 
> optional to use.
> > > 
> > > 1)  Concerning architectural layering:
> > > 
> > > It is clear that the problems of security are well understood
> > > within IETF. Numerous solutions have been proposed and
> > > many of those have become standard implementations.  The most
> > > successful of those (as an example, IPSec) have used the
> > > principles of architectural layering very well.  IPSec
> > > provides a secure mechanism for transporting any IP-based
> > > protocol if the protocol requires such security.  However,
> > > the overlaying protocols (as an example, TCP) have no requirement
> > > to actually make use of IPSec, and in fact have no particular
> > > requirement to make use of IP.  This is as it should be.
> > > Each layer is implemented independently of the other.  The
> > > services that each layer implements depend on the market
> > > requirements for the environment.  By that logic, it is 
> > > unnecessary for FCIP to specify any security mechanism at all, 
> > > since so many security mechanisms are available.  However,
> > > FCIP has provided the additional guidance that, if security
> > > in a TCP environment is used, it shall be provided at a layer
> > > below the TCP interface.  In particular, it recommends the
> > > use of IPSec for TCP/IP environments (and will recommend the
> > > appropriate IPSec options).  This additional guidance has nothing
> > > to do with the architecture or definition of FCIP and is 
> > > merely a recommendation that should improve interoperability.
> > > 
> > > 2)  Concerning market requirements:
> > > 
> > > A very high percentage of storage environments today manage
> > > their configurations very carefully.  Such careful management is
> > > necessary to guarantee redundant paths for proper availability,
> > > to provide sufficient paths to provide the required 
> > > performance, and to
> > > guarantee known paths to improve reparability and consistency
> > > of behavior.  As a side effect, a very high percentage of
> > > the paths of a storage environment are physically secured and have
> > > no requirement for additional security mechanisms.  At present,
> > > the only paths that are using security are those very few paths
> > > that leave one physically secure environment to transport data to
> > > another physically secure environment.  Those few paths 
> > > almost universally
> > > use security mechanisms at a lower level (as an example, a virtual
> > > private network) to achieve their goals.  As a first guess, such
> > > paths are well under 1% of the storage paths being used today.
> > > 
> > > I do not believe that this paradigm will change significantly over
> > > the next several years, although of course the percentage of paths
> > > requiring transport security may rise over 1%.  The 
> requirements for
> > > storage performance and the desire to maintain the storage devices
> > > and many of their primary processors in a physically secure
> > > environment will assure similar configurations.
> > > 
> > > In this environment, the market will demand low cost and high
> > > performance for the great majority of interconnects and 
> will demand
> > > security for a relatively low percentage of interconnects.  
> > > 
> > > What this implies for technologies like FCIP is that security
> > > be available as a separate option, outside the primary FCIP
> > > definition.  While still allowing the integration of security
> > > inside an FCIP unit, the IETF draft for FCIP  must also 
> allow security
> > > to be provided either not at all or by an outside mechanism.  
> > > The most common outside mechanism would be a gateway box 
> of some sort.
> > > In many cases, the gateway box will be a secure router 
> placed on the
> > > external link and servicing a large number of locally attached
> > > unsecured FCIP boxes.
> > > 
> > > CONCLUSIONS:
> > > 
> > > The FCIP draft should continue to specify a security mechanism,
> > > with IPSec being the appropriate candidate, to guarantee 
> > > interoperability
> > > when security is provided.  The FCIP draft should be modified to
> > > indicate that security is optional to implement and 
> optional to use.
> > > In addition, it should explicitly indicate that external gateway
> > > boxes are allowed implementation mechanisms for security.
> > > 
> > > As a side question, note that management of storage area networks
> > > and FCIP boxes is a separate question and is outside the scope of
> > > the FCIP draft.  Both Fibre Channel and Ethernet management paths
> > > have security appropriate to the particular management mechanism.
> > > As an example, web-based management mechanisms use web-based
> > > security tools. 
> > > 
> > > Bob Snively                        e-mail:    rsnively@brocade.com
> > > Brocade Communications Systems     phone:  408 487 8135
> > > 1745 Technology Drive
> > > San Jose, CA 95110
> > > 
> > > 
> > > 
> > > -----Original Message-----
> > > From: Black_David@emc.com [mailto:Black_David@emc.com]
> > > Sent: Tuesday, July 24, 2001 7:11 PM
> > > To: ips@ece.cmu.edu
> > > Subject: Security Gateways
> > > 
> > > 
> > > The following issue was hidden in my long set of
> > > comments on the -03 version of FCIP:
> > > 
> > > > > Delete 12 b).  If an FCIP entity is operating with an external
> > > > > security gateway, only the interface on the public side of the
> > > > > gateway is compliant with this specification.  The interface
> > > > > between the FCIP entity and the gateway is not 
> compliant because
> > > > > it is lacking required security features - the FCIP entity
> > > > > *includes* the security gateway in this structure.
> > > > 
> > > > Please post this as a separate issue because several of the
> > > > FCIP Authors believe it is appropriate for FCIP and I cannot
> > > > represent their opinions.
> > > 
> > > The issue is not whether it's "appropriate".  The issue
> > > is that if an implementation uses an FCIP Entity plus
> > > an external security gateway, the only interface that
> > > conforms to the forthcoming RFC is the public/external
> > > interface on the security gateway.  The interface between
> > > the FCIP Entity and the security gateway is private
> > > and fails to conform to the security that will be
> > > required of all FCIP implementations.
> > > 
> > > The above paragraph also applies to iSCSI (substitute iSCSI
> > > for FCIP in all instances).  Let me also note that iSCSI's
> > > ability to use a security gateway is not final at this
> > > juncture.  The spectrum of security possibilities includes
> > > things like SRP keying of ESP and IPsec transport mode that
> > > would make external gateways difficult or impossible to use.
> > > 
> > > Those who care about being able to use security gateways
> > > (or think that there's no need to support their use)
> > > should speak up on the list, in London, and/or in Orange
> > > County (I would expect the decision not to be made prior
> > > to Orange County) and *EXPLAIN WHY* [technical rationale].
> > > 
> > > Thanks,
> > > --David
> > > 
> > > ---------------------------------------------------
> > > David L. Black, Senior Technologist
> > > EMC Corporation, 42 South St., Hopkinton, MA  01748
> > > +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> > > black_david@emc.com       Mobile: +1 (978) 394-7754
> > > ---------------------------------------------------
> > >  
> > > 
> > 
> 


From owner-ips@ece.cmu.edu  Wed Aug  1 23:16:32 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA19950
	for <ips-archive@odin.ietf.org>; Wed, 1 Aug 2001 23:16:31 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7226I527050
	for ips-outgoing; Wed, 1 Aug 2001 22:06:18 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from elmo.ece.cmu.edu (ELMO.ECE.CMU.EDU [128.2.136.21])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f7226He27045
	for <ips@ece.cmu.edu>; Wed, 1 Aug 2001 22:06:17 -0400 (EDT)
Date: Wed, 1 Aug 2001 22:06:17 -0400 (EDT)
Message-Id: <200108020206.f7226He27045@ece.cmu.edu>
From: Jim McKinney <jmck+@ece.cmu.edu>
X-Mailer: BatIMail version 3.2
To: ips@ece.cmu.edu
Subject: RE: Security Gateways
References: <200108011608.f71G8FD28580@ece.cmu.edu>
Mime-Version: 1.0 (generated by tm-edit 1.5)
Content-Type: text/plain; charset=US-ASCII
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Dear David,

I would like to address the rather serious question you have
raised here about both architectural layering and market
requirements.  After considerable thought, based on the
explanations below, I have concluded that the FCIP RFC should
specify that security is optional to implement and optional to use.

1)  Concerning architectural layering:

It is clear that the problems of security are well understood
within IETF. Numerous solutions have been proposed and
many of those have become standard implementations.  The most
successful of those (as an example, IPSec) have used the
principles of architectural layering very well.  IPSec
provides a secure mechanism for transporting any IP-based
protocol if the protocol requires such security.  However,
the overlaying protocols (as an example, TCP) have no requirement
to actually make use of IPSec, and in fact have no particular
requirement to make use of IP.  This is as it should be.
Each layer is implemented independently of the other.  The
services that each layer implements depend on the market
requirements for the environment.  By that logic, it is 
unnecessary for FCIP to specify any security mechanism at all, 
since so many security mechanisms are available.  However,
FCIP has provided the additional guidance that, if security
in a TCP environment is used, it shall be provided at a layer
below the TCP interface.  In particular, it recommends the
use of IPSec for TCP/IP environments (and will recommend the
appropriate IPSec options).  This additional guidance has nothing
to do with the architecture or definition of FCIP and is 
merely a recommendation that should improve interoperability.

2)  Concerning market requirements:

A very high percentage of storage environments today manage
their configurations very carefully.  Such careful management is
necessary to guarantee redundant paths for proper availability,
to provide sufficient paths to provide the required performance, and to
guarantee known paths to improve reparability and consistency
of behavior.  As a side effect, a very high percentage of
the paths of a storage environment are physically secured and have
no requirement for additional security mechanisms.  At present,
the only paths that are using security are those very few paths
that leave one physically secure environment to transport data to
another physically secure environment.  Those few paths almost universally
use security mechanisms at a lower level (as an example, a virtual
private network) to achieve their goals.  As a first guess, such
paths are well under 1% of the storage paths being used today.

I do not believe that this paradigm will change significantly over
the next several years, although of course the percentage of paths
requiring transport security may rise over 1%.  The requirements for
storage performance and the desire to maintain the storage devices
and many of their primary processors in a physically secure
environment will assure similar configurations.

In this environment, the market will demand low cost and high
performance for the great majority of interconnects and will demand
security for a relatively low percentage of interconnects.  

What this implies for technologies like FCIP is that security
be available as a separate option, outside the primary FCIP
definition.  While still allowing the integration of security
inside an FCIP unit, the IETF draft for FCIP  must also allow security
to be provided either not at all or by an outside mechanism.  
The most common outside mechanism would be a gateway box of some sort.
In many cases, the gateway box will be a secure router placed on the
external link and servicing a large number of locally attached
unsecured FCIP boxes.

CONCLUSIONS:

The FCIP draft should continue to specify a security mechanism,
with IPSec being the appropriate candidate, to guarantee interoperability
when security is provided.  The FCIP draft should be modified to
indicate that security is optional to implement and optional to use.
In addition, it should explicitly indicate that external gateway
boxes are allowed implementation mechanisms for security.

As a side question, note that management of storage area networks
and FCIP boxes is a separate question and is outside the scope of
the FCIP draft.  Both Fibre Channel and Ethernet management paths
have security appropriate to the particular management mechanism.
As an example, web-based management mechanisms use web-based
security tools. 

Bob Snively                        e-mail:    rsnively@brocade.com
Brocade Communications Systems     phone:  408 487 8135
1745 Technology Drive
San Jose, CA 95110



-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Tuesday, July 24, 2001 7:11 PM
To: ips@ece.cmu.edu
Subject: Security Gateways


The following issue was hidden in my long set of
comments on the -03 version of FCIP:

> > Delete 12 b).  If an FCIP entity is operating with an external
> > security gateway, only the interface on the public side of the
> > gateway is compliant with this specification.  The interface
> > between the FCIP entity and the gateway is not compliant because
> > it is lacking required security features - the FCIP entity
> > *includes* the security gateway in this structure.
> 
> Please post this as a separate issue because several of the
> FCIP Authors believe it is appropriate for FCIP and I cannot
> represent their opinions.

The issue is not whether it's "appropriate".  The issue
is that if an implementation uses an FCIP Entity plus
an external security gateway, the only interface that
conforms to the forthcoming RFC is the public/external
interface on the security gateway.  The interface between
the FCIP Entity and the security gateway is private
and fails to conform to the security that will be
required of all FCIP implementations.

The above paragraph also applies to iSCSI (substitute iSCSI
for FCIP in all instances).  Let me also note that iSCSI's
ability to use a security gateway is not final at this
juncture.  The spectrum of security possibilities includes
things like SRP keying of ESP and IPsec transport mode that
would make external gateways difficult or impossible to use.

Those who care about being able to use security gateways
(or think that there's no need to support their use)
should speak up on the list, in London, and/or in Orange
County (I would expect the decision not to be made prior
to Orange County) and *EXPLAIN WHY* [technical rationale].

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------
 



From owner-ips@ece.cmu.edu  Wed Aug  1 23:19:14 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA20046
	for <ips-archive@odin.ietf.org>; Wed, 1 Aug 2001 23:19:14 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f722Cfe27351
	for ips-outgoing; Wed, 1 Aug 2001 22:12:41 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from elmo.ece.cmu.edu (ELMO.ECE.CMU.EDU [128.2.136.21])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f722Cee27347
	for <ips@ece.cmu.edu>; Wed, 1 Aug 2001 22:12:41 -0400 (EDT)
Date: Wed, 1 Aug 2001 22:12:41 -0400 (EDT)
Message-Id: <200108020212.f722Cee27347@ece.cmu.edu>
From: Jim McKinney <jmck+@ece.cmu.edu>
X-Mailer: BatIMail version 3.2
To: ips@ece.cmu.edu
Subject: RE: Security Gateways
References: <200108012225.f71MPZa18164@ece.cmu.edu>
Mime-Version: 1.0 (generated by tm-edit 1.5)
Content-Type: text/plain; charset=US-ASCII
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

David,

I believe this is really a very difficult question, not
susceptible to a simple SHALL/SHALL NOT response.  
The technology absolutely allows and encourages
security edge devices and absolutely allows devices using
TCP and other protocols to exploit those edge devices or
not as the system administrator requires.  The marketplace
absolutely demands those capabilities.  A significant percentage
of the internet economy is based on separately supplied security.
I understand that the IETF
has no interest in devices that are solely for closed
environments, but the marketplace does not demand that
a device have security built in to qualify for compliance with a
protocol.  The marketplace does demand that
security be possible and available for a device.  

That is what we have been proposing.

By definition, "man in the middle" attacks are impossible
for a security edge device, since the only place that the
"man in the middle" can be placed is in the encrypted path.
The physically secured path has no possibility of an
entry point for such an attack.  

I can understand why the IESG would push back on this
question, but I would expect that they also believe that
an FCIP device without optional security implemented
is still an FCIP device and is compliant with the FCIP RFC. 
This should be true whether the TCP path is based on IP,
HIPPI, IB, a proprietary backplane or any other transport 
that supports TCP. With an edge security device installed 
in front of it, it is also a
secure FCIP device, just like the end-point of a 
virtual private network is a secure device. 

That is what we would like the RFC to say.

Bob

-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Wednesday, August 01, 2001 10:13 AM
To: rsnively@brocade.com; ips@ece.cmu.edu
Subject: RE: Security Gateways


Bob,

You've made a good case for "optional to use", but not
"optional to implement".  The basic reason is that there
is no way to ensure that vendors and/or users will
restrict the use of an implementation that does not
include security to situations where "paths of a
storage environment are physically secured and have 
no requirement for additional security mechanisms".
Hence security needs to be present so that it
can be used when FCIP is deployed in an environment
that requires security.  Further, the IETF has no
interest in specification of protocols that are
*solely* for use in the sort of closed environment
that you describe, and the IPS WG charter contains
explicit words to that effect.

Therefore, the basic FCIP security mechanisms MUST be
implemented, but usage MAY be negotiated.  At the moment,
"basic security mechanisms" means authentication and
cryptographic integrity.  Confidentiality can currently
be optional to implement, but I think it's a very good
idea to specify the basic confidentiality mechanism
(*if* confidentiality of any form is implemented, *then*
<XXX> MUST be implemented).  The design and specification
of any negotiation mechanism must resist man-in-the-middle
attacks on negotiation that would result in turning off
security where that was not the intended outcome - such
an approach can include restrictions on implementation
behavior (e.g., if "no authentication" is not acceptable,
do not offer or accept it during negotiation).

If the FCIP draft is sent to the IESG without requiring
implementation of the basic security mechanisms, it will
be returned to the WG with instructions to correct
that shortcoming, along with some choice words from the
ADs wondering how the WG chairs could have overlooked
something like this.  As a result, an FCIP draft that
does not require implementation of the basic security
mechanisms will not be Last Called in the WG until that
requirement is added.

Sorry to be blunt, but there is no flexibility on whether
the basic security mechanisms are mandatory to implement;
they will be mandatory to implement, period.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


> -----Original Message-----
> From: Robert Snively [mailto:rsnively@brocade.com]
> Sent: Wednesday, August 01, 2001 12:08 PM
> To: 'Black_David@emc.com'; ips@ece.cmu.edu
> Subject: RE: Security Gateways
> 
> 
> Dear David,
> 
> I would like to address the rather serious question you have
> raised here about both architectural layering and market
> requirements.  After considerable thought, based on the
> explanations below, I have concluded that the FCIP RFC should
> specify that security is optional to implement and optional to use.
> 
> 1)  Concerning architectural layering:
> 
> It is clear that the problems of security are well understood
> within IETF. Numerous solutions have been proposed and
> many of those have become standard implementations.  The most
> successful of those (as an example, IPSec) have used the
> principles of architectural layering very well.  IPSec
> provides a secure mechanism for transporting any IP-based
> protocol if the protocol requires such security.  However,
> the overlaying protocols (as an example, TCP) have no requirement
> to actually make use of IPSec, and in fact have no particular
> requirement to make use of IP.  This is as it should be.
> Each layer is implemented independently of the other.  The
> services that each layer implements depend on the market
> requirements for the environment.  By that logic, it is 
> unnecessary for FCIP to specify any security mechanism at all, 
> since so many security mechanisms are available.  However,
> FCIP has provided the additional guidance that, if security
> in a TCP environment is used, it shall be provided at a layer
> below the TCP interface.  In particular, it recommends the
> use of IPSec for TCP/IP environments (and will recommend the
> appropriate IPSec options).  This additional guidance has nothing
> to do with the architecture or definition of FCIP and is 
> merely a recommendation that should improve interoperability.
> 
> 2)  Concerning market requirements:
> 
> A very high percentage of storage environments today manage
> their configurations very carefully.  Such careful management is
> necessary to guarantee redundant paths for proper availability,
> to provide sufficient paths to provide the required 
> performance, and to
> guarantee known paths to improve reparability and consistency
> of behavior.  As a side effect, a very high percentage of
> the paths of a storage environment are physically secured and have
> no requirement for additional security mechanisms.  At present,
> the only paths that are using security are those very few paths
> that leave one physically secure environment to transport data to
> another physically secure environment.  Those few paths 
> almost universally
> use security mechanisms at a lower level (as an example, a virtual
> private network) to achieve their goals.  As a first guess, such
> paths are well under 1% of the storage paths being used today.
> 
> I do not believe that this paradigm will change significantly over
> the next several years, although of course the percentage of paths
> requiring transport security may rise over 1%.  The requirements for
> storage performance and the desire to maintain the storage devices
> and many of their primary processors in a physically secure
> environment will assure similar configurations.
> 
> In this environment, the market will demand low cost and high
> performance for the great majority of interconnects and will demand
> security for a relatively low percentage of interconnects.  
> 
> What this implies for technologies like FCIP is that security
> be available as a separate option, outside the primary FCIP
> definition.  While still allowing the integration of security
> inside an FCIP unit, the IETF draft for FCIP  must also allow security
> to be provided either not at all or by an outside mechanism.  
> The most common outside mechanism would be a gateway box of some sort.
> In many cases, the gateway box will be a secure router placed on the
> external link and servicing a large number of locally attached
> unsecured FCIP boxes.
> 
> CONCLUSIONS:
> 
> The FCIP draft should continue to specify a security mechanism,
> with IPSec being the appropriate candidate, to guarantee 
> interoperability
> when security is provided.  The FCIP draft should be modified to
> indicate that security is optional to implement and optional to use.
> In addition, it should explicitly indicate that external gateway
> boxes are allowed implementation mechanisms for security.
> 
> As a side question, note that management of storage area networks
> and FCIP boxes is a separate question and is outside the scope of
> the FCIP draft.  Both Fibre Channel and Ethernet management paths
> have security appropriate to the particular management mechanism.
> As an example, web-based management mechanisms use web-based
> security tools. 
> 
> Bob Snively                        e-mail:    rsnively@brocade.com
> Brocade Communications Systems     phone:  408 487 8135
> 1745 Technology Drive
> San Jose, CA 95110
> 
> 
> 
> -----Original Message-----
> From: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Tuesday, July 24, 2001 7:11 PM
> To: ips@ece.cmu.edu
> Subject: Security Gateways
> 
> 
> The following issue was hidden in my long set of
> comments on the -03 version of FCIP:
> 
> > > Delete 12 b).  If an FCIP entity is operating with an external
> > > security gateway, only the interface on the public side of the
> > > gateway is compliant with this specification.  The interface
> > > between the FCIP entity and the gateway is not compliant because
> > > it is lacking required security features - the FCIP entity
> > > *includes* the security gateway in this structure.
> > 
> > Please post this as a separate issue because several of the
> > FCIP Authors believe it is appropriate for FCIP and I cannot
> > represent their opinions.
> 
> The issue is not whether it's "appropriate".  The issue
> is that if an implementation uses an FCIP Entity plus
> an external security gateway, the only interface that
> conforms to the forthcoming RFC is the public/external
> interface on the security gateway.  The interface between
> the FCIP Entity and the security gateway is private
> and fails to conform to the security that will be
> required of all FCIP implementations.
> 
> The above paragraph also applies to iSCSI (substitute iSCSI
> for FCIP in all instances).  Let me also note that iSCSI's
> ability to use a security gateway is not final at this
> juncture.  The spectrum of security possibilities includes
> things like SRP keying of ESP and IPsec transport mode that
> would make external gateways difficult or impossible to use.
> 
> Those who care about being able to use security gateways
> (or think that there's no need to support their use)
> should speak up on the list, in London, and/or in Orange
> County (I would expect the decision not to be made prior
> to Orange County) and *EXPLAIN WHY* [technical rationale].
> 
> Thanks,
> --David
> 
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------
>  
> 



From owner-ips@ece.cmu.edu  Wed Aug  1 23:33:24 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA20814
	for <ips-archive@odin.ietf.org>; Wed, 1 Aug 2001 23:33:24 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f720vDV24372
	for ips-outgoing; Wed, 1 Aug 2001 20:57:13 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from clyde.stargateip.com ([209.237.5.66])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f720vCe24368
	for <ips@ece.cmu.edu>; Wed, 1 Aug 2001 20:57:12 -0400 (EDT)
Received: from bluestar (dhcp-101.stargateip.com [10.10.5.101])
	by clyde.stargateip.com (8.9.1/8.9.1) with SMTP id RAA22419
	for <ips@ece.cmu.edu>; Wed, 1 Aug 2001 17:51:35 -0700 (PDT)
Reply-To: <deva@stargateip.com>
From: "Dev" <deva@stargateip.com>
To: <ips@ece.cmu.edu>
Subject: RE: iSCSI: draft 7: iSCSI response and SCSI sense data
Date: Wed, 1 Aug 2001 18:01:12 -0700
Message-ID: <NFBBKBDFJCDMGCBKJLCJCELIFCAA.deva@stargateip.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <78AF3C342AEAEF4BA33B35A8A15668C6019E2006@cceexc17.americas.cpqcorp.net>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Robert,

I agree with you fully on this.  

---
Forcing the iSCSI layer to fill in those fields seems to break the 
layering model.

I suggest removing the CHECK CONDITION status and additional sense 
code linkage and leave the SCSI status undefined if the iSCSI 
response is nonzero.

iSCSI draft 7 section 2.4.3 includes a table relating the iSCSI 
response codes to various CHECK CONDITION status additional 
sense codes:

------

Thanks

Deva
Platys Communications

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Elliott, Robert
Sent: Wednesday, August 01, 2001 4:27 PM
To: 'ips@ece.cmu.edu'
Subject: iSCSI: draft 7: iSCSI response and SCSI sense data


iSCSI draft 7 section 2.4.3 includes a table relating the iSCSI 
response codes to various CHECK CONDITION status additional 
sense codes:

  "0x01 Target Failure
    ASC=0x44 ASCQ=0x00 INTERNAL TARGET FAILURE
  0x02 Delivery Subsystem Failure 
    ASC=0x47 ASCQ=0x03 INFORMATION UNIT CRC ERROR DETECTED
  0x03 Unsolicited data rejected
    ASC=0x49 ASCQ=0x00 INVALID MESSAGE ERROR
  0x04 Not enough unsolicited [data]
    ASC=0x49 ASCQ=0x00 INVALID MESSAGE ERROR
  0x05 SNACK rejected [Command in progress]
    ASC=0x47 ASCQ=0x03 INFORMATION UNIT CRC ERROR DETECTED

  As listed above, each defined response code MUST be used (under the 
  conditions described in the 'Reason' field), only when the 
  corresponding SCSI CHECK CONDITION is signaled, to convey additional 
  protocol service information.  A SCSI CHECK CONDITION with the ASC 
  and ASCQ values as tabulated MUST be signaled by iSCSI targets for 
  all the instances in this document referring to usage of one of the 
  above defined response codes."
 
No other SCSI protocol does this. iSCSI seems to be granting the 
SCSI-level status a priority over the iSCSI-level response data.  
I think the other protocols treat the response data as more 
important; if the response data indicates a problem, the SCSI layer 
is considered broken and the SCSI status is undefined.  

Forcing the iSCSI layer to fill in those fields seems to break the 
layering model.

I suggest removing the CHECK CONDITION status and additional sense 
code linkage and leave the SCSI status undefined if the iSCSI 
response is nonzero.

This is compatible with SAM-2, which only requires status be returned
when the service response is TASK COMPLETE (SAM-2 revision 18
section 5.3.1):
  "Status shall be sent from the logical unit to the application 
   client whenever a command ends with a service response of 
   TASK COMPLETE or LINKED COMMAND COMPLETE."

Furthermore, SAM-2 requires that status be ignored when the service
response indicates an error (SAM-2 revision 18 section 5.1):
  "Status: A one-byte field containing command completion status 
  (see 5.3). If the command ends with a service response of 
  SERVICE DELIVERY OR TARGET FAILURE, the application client 
  shall consider this parameter to be undefined."

I think iSCSI's current wording may violate this rule.
---
Rob Elliott, Compaq Server Storage
Robert.Elliott@compaq.com



From owner-ips@ece.cmu.edu  Thu Aug  2 01:05:56 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA24146
	for <ips-archive@odin.ietf.org>; Thu, 2 Aug 2001 01:05:56 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7240d901390
	for ips-outgoing; Thu, 2 Aug 2001 00:00:39 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7240be01386
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 00:00:37 -0400 (EDT)
Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100])
	by palrel2.hp.com (Postfix) with ESMTP
	id 0AA0B1930; Wed,  1 Aug 2001 21:00:33 -0700 (PDT)
Received: from rose.hp.com (dhcp-rosefl-bba163.rose.hp.com [15.3.110.163]) by core.rose.hp.com with ESMTP (8.8.6 (PHNE_14041)/8.8.6 SMKit7.02) id VAA17016; Wed, 1 Aug 2001 21:01:47 -0700 (PDT)
Message-ID: <3B68D18B.885682C3@rose.hp.com>
Date: Wed, 01 Aug 2001 21:05:31 -0700
From: "Mallikarjun C." <cbm@rose.hp.com>
Reply-To: cbm@rose.hp.com
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: "Elliott, Robert" <Robert.Elliott@compaq.com>
Cc: "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
Subject: Re: iSCSI: draft 7: iSCSI response and SCSI sense data
References: <78AF3C342AEAEF4BA33B35A8A15668C6019E2006@cceexc17.americas.cpqcorp.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Robert and all,

As the one who suggested that wording into the draft, let me 
add some comments. (Please see
http://www.pdl.cmu.edu/mailinglists/ips/mail/msg05089.html
for my initial proposal.)

> I suggest removing the CHECK CONDITION status and additional sense
> code linkage and leave the SCSI status undefined if the iSCSI
> response is nonzero.

I agree, as Steph already alluded to in a separate email, the ideal 
solution appears to: 
          a) drop the response code *definitions* (ie. leave
             room for vendor-unique codes) altogether, and
          b) continue to specify the right SCSI CHECK CONDITION 
             (ASC, ASCQ) values for the iSCSI error events (such
             as digest failures).

As I said in the earlier referenced message "mandate a standard 
SCSI CHECK CONDITION on these errors with the current response codes 
acting as detailed descriptions.".  But you bring up a good point 
that this "detailed descriptions" may be violating SAM-2's expectations. 

> Forcing the iSCSI layer to fill in those fields seems to break the
> layering model.

I disagree.  If the affected SCSI task can be reliably ascertained
by the target, it appears highly desirable to report the status 
using a SCSI CHECK CONDITION.  Target iSCSI layer has to internally
terminate the pre-instantiated SCSI task anyway informing its SCSI 
layer of the fact.  Besides, there are precedents in FCP-2 for similar
cases where the task is identifiable.

Regards.
-- 
Mallikarjun 

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

"Elliott, Robert" wrote:
> 
> iSCSI draft 7 section 2.4.3 includes a table relating the iSCSI
> response codes to various CHECK CONDITION status additional
> sense codes:
> 
>   "0x01 Target Failure
>     ASC=0x44 ASCQ=0x00 INTERNAL TARGET FAILURE
>   0x02 Delivery Subsystem Failure
>     ASC=0x47 ASCQ=0x03 INFORMATION UNIT CRC ERROR DETECTED
>   0x03 Unsolicited data rejected
>     ASC=0x49 ASCQ=0x00 INVALID MESSAGE ERROR
>   0x04 Not enough unsolicited [data]
>     ASC=0x49 ASCQ=0x00 INVALID MESSAGE ERROR
>   0x05 SNACK rejected [Command in progress]
>     ASC=0x47 ASCQ=0x03 INFORMATION UNIT CRC ERROR DETECTED
> 
>   As listed above, each defined response code MUST be used (under the
>   conditions described in the 'Reason' field), only when the
>   corresponding SCSI CHECK CONDITION is signaled, to convey additional
>   protocol service information.  A SCSI CHECK CONDITION with the ASC
>   and ASCQ values as tabulated MUST be signaled by iSCSI targets for
>   all the instances in this document referring to usage of one of the
>   above defined response codes."
> 
> No other SCSI protocol does this. iSCSI seems to be granting the
> SCSI-level status a priority over the iSCSI-level response data.
> I think the other protocols treat the response data as more
> important; if the response data indicates a problem, the SCSI layer
> is considered broken and the SCSI status is undefined.
> 
> Forcing the iSCSI layer to fill in those fields seems to break the
> layering model.
> 
> I suggest removing the CHECK CONDITION status and additional sense
> code linkage and leave the SCSI status undefined if the iSCSI
> response is nonzero.
> 
> This is compatible with SAM-2, which only requires status be returned
> when the service response is TASK COMPLETE (SAM-2 revision 18
> section 5.3.1):
>   "Status shall be sent from the logical unit to the application
>    client whenever a command ends with a service response of
>    TASK COMPLETE or LINKED COMMAND COMPLETE."
> 
> Furthermore, SAM-2 requires that status be ignored when the service
> response indicates an error (SAM-2 revision 18 section 5.1):
>   "Status: A one-byte field containing command completion status
>   (see 5.3). If the command ends with a service response of
>   SERVICE DELIVERY OR TARGET FAILURE, the application client
>   shall consider this parameter to be undefined."
> 
> I think iSCSI's current wording may violate this rule.
> ---
> Rob Elliott, Compaq Server Storage
> Robert.Elliott@compaq.com


From owner-ips@ece.cmu.edu  Thu Aug  2 02:51:18 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA12323
	for <ips-archive@odin.ietf.org>; Thu, 2 Aug 2001 02:51:18 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f725hq605164
	for ips-outgoing; Thu, 2 Aug 2001 01:43:52 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f725hoe05160
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 01:43:50 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id HAB93746
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 07:43:43 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f725hgi128960
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 07:43:42 +0200
Importance: Normal
Subject: RE: iSCSI: draft 7: iSCSI response and SCSI sense data
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFC4BE2EC5.5ECF68AC-ONC2256A9C.001E0439@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Thu, 2 Aug 2001 08:49:47 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 02/08/2001 08:43:42
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Steph,

You change opinions faster than draft changes :-)

David,

Could you please quote us which part of SAM-2 this is violating. Please
keep in mind
that SAM has 2 return parameters in its Remote Procedure Call model that
can be sent independently.
FTP has following the older standards and set them exclusively but that is
not IMHO required by SAM.
ACA or not - we do require an interlocking mechanism. ACA can't be broken
that easy and certainly not that
total as you suggest.  And if we do not use the SCSI interlocking we will
have to invent a brand new one of our own.

And a procedural call - please do not quote layering as a reason for
tearing something down. Please quote a way of doing interlocking that is as
cheap as this and does not violate layering and I'll buy it.

A second line of argument says that layering is not a goal.

And a third says that all SCSI protocols access both SCSI level and
protocol specific functions that are common to all at the "SCSI levels".
That type of engineering is very common in computing (OSes are built this
way).
Interlocking is a problem for many protocols (not only iSCSI) and its
solution (for all) is at SCSI level. And ACA is a way to do interlocking
(there are not many others and yhey are all described in SAM).
If having it described in the same book means violating layering so be it
although I think that you are mistaken.

Regards,
Julo



Black_David@emc.com on 02-08-2001 04:19:27

Please respond to Black_David@emc.com

To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: draft 7: iSCSI response and SCSI sense data




In my lousy Indiana Jones impression - "ACA, why does it
always have to be ACA?" ....

This whole notion that ACA is a fundamental coordination
mechanism for shared SCSI access to a target is not headed
in a good direction - see the recent message from Ralph Weber
expressing T10's concern that expansion of the usage of ACA is
an invitation to undesirable denial of service possibilities.
I will note that the reservation example that Ralph used in his
message is the sort of thing that can break clustering software,
although I don't know for certain whether there's any existing
clustering software that it does in fact break.

I think Rob and Jim are correct when they describe the current
2.4.3 text as being at odds with SAM-2.  So, I think:

- The text in 2.4.3 that is at odds with SAM-2 should come out.
     The fact that it was caused by a desire to use ACA makes
     it doubly suspect.
- The current mandate for ACA in Section 8.2 exceeds the level
     stated in the iSCSI requirements draft and I don't believe
     it represents rough consensus of the WG.  Support for
     ACA should be a "SHOULD", not a "MUST".
- The entire effort to use ACA or something like it to serialize
     error conditions for multiple commands in flight has not been
     explained well to T10, and what has been explained has not
     received a good reception.

The last bullet has a couple of consequences.  First, we should
take out anything else that's crept into iSCSI in support of this
use of ACA.  Second, those who want to use ACA or something ACA-like
for this error coordination across multiple commands in flight
should write up a submission to T10 explaining what the problem
is and how ACA or something like it solves the problem.

I think Ralph is conveying a message from T10 that whatever the
problem iSCSI has, T10 is not inclined to believe that more use
of ACA is NOT the solution.  It may take a while to work with T10
to get the right solution designed, but I'd prefer doing nothing
over force-fitting ACA to a use that T10 doesn't think is appropriate.
When we figure out what the right thing is, we can put in the right
text to describe it.

Comments?
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------



> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Wednesday, August 01, 2001 8:01 PM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI: draft 7: iSCSI response and SCSI sense data
>
>
>
> Elliot,
>
> This issue has some history.  After many took the position you are
> advocating
> and I had to drop the check condition all list participants that had
> something to say adopted the current position in order the
> benefit from the
> "serializing" effect of ACA whenever a check condition is
> originated at the
> target and the delivery subsystem is still operational.
>
> Julo
>
>
> "Elliott, Robert" <Robert.Elliott@compaq.com> on 02-08-2001 02:26:57
>
> Please respond to "Elliott, Robert" <Robert.Elliott@compaq.com>
>
> To:   "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
> cc:
> Subject:  iSCSI: draft 7: iSCSI response and SCSI sense data
>
>
>
>
> iSCSI draft 7 section 2.4.3 includes a table relating the iSCSI
> response codes to various CHECK CONDITION status additional
> sense codes:
>
>   "0x01 Target Failure
>     ASC=0x44 ASCQ=0x00 INTERNAL TARGET FAILURE
>   0x02 Delivery Subsystem Failure
>     ASC=0x47 ASCQ=0x03 INFORMATION UNIT CRC ERROR DETECTED
>   0x03 Unsolicited data rejected
>     ASC=0x49 ASCQ=0x00 INVALID MESSAGE ERROR
>   0x04 Not enough unsolicited [data]
>     ASC=0x49 ASCQ=0x00 INVALID MESSAGE ERROR
>   0x05 SNACK rejected [Command in progress]
>     ASC=0x47 ASCQ=0x03 INFORMATION UNIT CRC ERROR DETECTED
>
>   As listed above, each defined response code MUST be used (under the
>   conditions described in the 'Reason' field), only when the
>   corresponding SCSI CHECK CONDITION is signaled, to convey additional
>   protocol service information.  A SCSI CHECK CONDITION with the ASC
>   and ASCQ values as tabulated MUST be signaled by iSCSI targets for
>   all the instances in this document referring to usage of one of the
>   above defined response codes."
>
> No other SCSI protocol does this. iSCSI seems to be granting the
> SCSI-level status a priority over the iSCSI-level response data.
> I think the other protocols treat the response data as more
> important; if the response data indicates a problem, the SCSI layer
> is considered broken and the SCSI status is undefined.
>
> Forcing the iSCSI layer to fill in those fields seems to break the
> layering model.
>
> I suggest removing the CHECK CONDITION status and additional sense
> code linkage and leave the SCSI status undefined if the iSCSI
> response is nonzero.
>
> This is compatible with SAM-2, which only requires status be returned
> when the service response is TASK COMPLETE (SAM-2 revision 18
> section 5.3.1):
>   "Status shall be sent from the logical unit to the application
>    client whenever a command ends with a service response of
>    TASK COMPLETE or LINKED COMMAND COMPLETE."
>
> Furthermore, SAM-2 requires that status be ignored when the service
> response indicates an error (SAM-2 revision 18 section 5.1):
>   "Status: A one-byte field containing command completion status
>   (see 5.3). If the command ends with a service response of
>   SERVICE DELIVERY OR TARGET FAILURE, the application client
>   shall consider this parameter to be undefined."
>
> I think iSCSI's current wording may violate this rule.
> ---
> Rob Elliott, Compaq Server Storage
> Robert.Elliott@compaq.com
>
>
>
>





From owner-ips@ece.cmu.edu  Thu Aug  2 04:21:51 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA16474
	for <ips-archive@odin.ietf.org>; Thu, 2 Aug 2001 04:21:51 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f724Gxj01982
	for ips-outgoing; Thu, 2 Aug 2001 00:16:59 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from atlrel7.hp.com (atlrel7.hp.com [192.151.27.9])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f724Gve01978
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 00:16:58 -0400 (EDT)
Received: from core.rose.hp.com (unknown [15.43.208.100])
	by atlrel7.hp.com (Postfix) with ESMTP
	id C14151F557; Thu,  2 Aug 2001 00:15:58 -0400 (EDT)
Received: from rose.hp.com (dhcp-rosefl-bba163.rose.hp.com [15.3.110.163]) by core.rose.hp.com with ESMTP (8.8.6 (PHNE_14041)/8.8.6 SMKit7.02) id VAA18855; Wed, 1 Aug 2001 21:18:06 -0700 (PDT)
Message-ID: <3B68D55E.AD118DE6@rose.hp.com>
Date: Wed, 01 Aug 2001 21:21:50 -0700
From: "Mallikarjun C." <cbm@rose.hp.com>
Reply-To: cbm@rose.hp.com
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Black_David@emc.com
Cc: ips@ece.cmu.edu
Subject: Re: iSCSI: draft 7: iSCSI response and SCSI sense data
References: <277DD60FB639D511AC0400B0D068B71ECAD54D@CORPMX14>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

David,

It appears to me that generating a SCSI CHECK CONDITION is
the right thing for iSCSI to do regardless of T10's eventual
decision (ACA/persistent-UA (T10 proposal 00-359r1)/something
totally different) on a mechanism to enforce ordering semantics.

Robert Elliott pointed out a violation by iSCSI in trying to 
additionally qualify ASC, ASCQ with its response codes.  I suggest 
that dropping this "additional description" attempt in all these 
cases is all iSCSI needs to do to meet SAM's expectations.

Regards.
-- 
Mallikarjun 

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


Black_David@emc.com wrote:
> 
> In my lousy Indiana Jones impression - "ACA, why does it
> always have to be ACA?" ....
> 
> This whole notion that ACA is a fundamental coordination
> mechanism for shared SCSI access to a target is not headed
> in a good direction - see the recent message from Ralph Weber
> expressing T10's concern that expansion of the usage of ACA is
> an invitation to undesirable denial of service possibilities.
> I will note that the reservation example that Ralph used in his
> message is the sort of thing that can break clustering software,
> although I don't know for certain whether there's any existing
> clustering software that it does in fact break.
> 
> I think Rob and Jim are correct when they describe the current
> 2.4.3 text as being at odds with SAM-2.  So, I think:
> 
> - The text in 2.4.3 that is at odds with SAM-2 should come out.
>         The fact that it was caused by a desire to use ACA makes
>         it doubly suspect.
> - The current mandate for ACA in Section 8.2 exceeds the level
>         stated in the iSCSI requirements draft and I don't believe
>         it represents rough consensus of the WG.  Support for
>         ACA should be a "SHOULD", not a "MUST".
> - The entire effort to use ACA or something like it to serialize
>         error conditions for multiple commands in flight has not been
>         explained well to T10, and what has been explained has not
>         received a good reception.
> 
> The last bullet has a couple of consequences.  First, we should
> take out anything else that's crept into iSCSI in support of this
> use of ACA.  Second, those who want to use ACA or something ACA-like
> for this error coordination across multiple commands in flight
> should write up a submission to T10 explaining what the problem
> is and how ACA or something like it solves the problem.
> 
> I think Ralph is conveying a message from T10 that whatever the
> problem iSCSI has, T10 is not inclined to believe that more use
> of ACA is NOT the solution.  It may take a while to work with T10
> to get the right solution designed, but I'd prefer doing nothing
> over force-fitting ACA to a use that T10 doesn't think is appropriate.
> When we figure out what the right thing is, we can put in the right
> text to describe it.
> 
> Comments?
> --David
> 
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------
> 
> > -----Original Message-----
> > From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > Sent: Wednesday, August 01, 2001 8:01 PM
> > To: ips@ece.cmu.edu
> > Subject: Re: iSCSI: draft 7: iSCSI response and SCSI sense data
> >
> >
> >
> > Elliot,
> >
> > This issue has some history.  After many took the position you are
> > advocating
> > and I had to drop the check condition all list participants that had
> > something to say adopted the current position in order the
> > benefit from the
> > "serializing" effect of ACA whenever a check condition is
> > originated at the
> > target and the delivery subsystem is still operational.
> >
> > Julo
> >
> >
> > "Elliott, Robert" <Robert.Elliott@compaq.com> on 02-08-2001 02:26:57
> >
> > Please respond to "Elliott, Robert" <Robert.Elliott@compaq.com>
> >
> > To:   "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
> > cc:
> > Subject:  iSCSI: draft 7: iSCSI response and SCSI sense data
> >
> >
> >
> >
> > iSCSI draft 7 section 2.4.3 includes a table relating the iSCSI
> > response codes to various CHECK CONDITION status additional
> > sense codes:
> >
> >   "0x01 Target Failure
> >     ASC=0x44 ASCQ=0x00 INTERNAL TARGET FAILURE
> >   0x02 Delivery Subsystem Failure
> >     ASC=0x47 ASCQ=0x03 INFORMATION UNIT CRC ERROR DETECTED
> >   0x03 Unsolicited data rejected
> >     ASC=0x49 ASCQ=0x00 INVALID MESSAGE ERROR
> >   0x04 Not enough unsolicited [data]
> >     ASC=0x49 ASCQ=0x00 INVALID MESSAGE ERROR
> >   0x05 SNACK rejected [Command in progress]
> >     ASC=0x47 ASCQ=0x03 INFORMATION UNIT CRC ERROR DETECTED
> >
> >   As listed above, each defined response code MUST be used (under the
> >   conditions described in the 'Reason' field), only when the
> >   corresponding SCSI CHECK CONDITION is signaled, to convey additional
> >   protocol service information.  A SCSI CHECK CONDITION with the ASC
> >   and ASCQ values as tabulated MUST be signaled by iSCSI targets for
> >   all the instances in this document referring to usage of one of the
> >   above defined response codes."
> >
> > No other SCSI protocol does this. iSCSI seems to be granting the
> > SCSI-level status a priority over the iSCSI-level response data.
> > I think the other protocols treat the response data as more
> > important; if the response data indicates a problem, the SCSI layer
> > is considered broken and the SCSI status is undefined.
> >
> > Forcing the iSCSI layer to fill in those fields seems to break the
> > layering model.
> >
> > I suggest removing the CHECK CONDITION status and additional sense
> > code linkage and leave the SCSI status undefined if the iSCSI
> > response is nonzero.
> >
> > This is compatible with SAM-2, which only requires status be returned
> > when the service response is TASK COMPLETE (SAM-2 revision 18
> > section 5.3.1):
> >   "Status shall be sent from the logical unit to the application
> >    client whenever a command ends with a service response of
> >    TASK COMPLETE or LINKED COMMAND COMPLETE."
> >
> > Furthermore, SAM-2 requires that status be ignored when the service
> > response indicates an error (SAM-2 revision 18 section 5.1):
> >   "Status: A one-byte field containing command completion status
> >   (see 5.3). If the command ends with a service response of
> >   SERVICE DELIVERY OR TARGET FAILURE, the application client
> >   shall consider this parameter to be undefined."
> >
> > I think iSCSI's current wording may violate this rule.
> > ---
> > Rob Elliott, Compaq Server Storage
> > Robert.Elliott@compaq.com
> >
> >
> >
> >


From owner-ips@ece.cmu.edu  Thu Aug  2 05:13:11 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA17818
	for <ips-archive@odin.ietf.org>; Thu, 2 Aug 2001 05:13:10 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7277hl07923
	for ips-outgoing; Thu, 2 Aug 2001 03:07:43 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7277ge07919
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 03:07:42 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id JAA164852
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 09:07:35 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7277YW19536
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 09:07:35 +0200
Importance: Normal
Subject: Re: iSCSI - three negotiation items
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF5C2F8B8F.CAF80272-ONC2256A9C.0026C394@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Thu, 2 Aug 2001 10:13:43 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 02/08/2001 10:07:34
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


comments in text. Julo



Black_David@emc.com on 02-08-2001 04:46:53

Please respond to Black_David@emc.com

To:   ips@ece.cmu.edu
cc:
Subject:  iSCSI - three negotiation items




Going through the list of simplification suggestions,
I found a few items that look like they
should be reasonable to deal with on the list.

(1) For any key that can take a numeric value, could
we specify the required base for the number, either
decimal or hex, not both.  The practical issue is that
the sort of large values used for keys and the like
in security are much easier to deal with in hex than
decimal.

+++ the current draft allows for both - Is there something wrong with that?
Hex is simpler but if data gets copied from somewhere else and that is a
decimal source then that is error prone +++

(2) The KRB5 and SPKM inband cryptographic integrity
digests on p.136 seem to be relics of a prior inband
approach to security.  Has anyone implemented them?
Does anyone want them to remain?  Can we just delete
them?

+++ Yes - I think we can take them out although UMAC may get-in at some
point :-) +++
(3) Can HeaderDigest and DataDigest be combined?
If (2) is done, this is about making use of CRC-32C
a single on/off switch rather than two separate switches
for header and data?

+++ combining defeats the purpose of the iSCSI CRC - to get you through
iSCSI proxies that may change the header but will not change the data +++

Comments?  Objections (with rationale)?

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------





From owner-ips@ece.cmu.edu  Thu Aug  2 09:42:38 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27068
	for <ips-archive@odin.ietf.org>; Thu, 2 Aug 2001 09:42:33 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f72BQ9g26907
	for ips-outgoing; Thu, 2 Aug 2001 07:26:09 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from elmo.ece.cmu.edu (ELMO.ECE.CMU.EDU [128.2.136.21])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f72BQ8e26903
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 07:26:08 -0400 (EDT)
Date: Thu, 2 Aug 2001 07:26:08 -0400 (EDT)
Message-Id: <200108021126.f72BQ8e26903@ece.cmu.edu>
From: Jim McKinney <jmck+@ece.cmu.edu>
X-Mailer: BatIMail version 3.2
To: ips@ece.cmu.edu
Subject: Re: Security Gateways
References: <200108020401.f7241wu01446@ece.cmu.edu>
Mime-Version: 1.0 (generated by tm-edit 1.5)
Content-Type: text/plain; charset=US-ASCII
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


This is a multi-part message in MIME format.

------=_NextPart_000_0017_01C11ACC.6B6C6140
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

David,
Do your comments also apply to iFCP gateways (i.e. will cryptographic
security be required in iFCP gateways in order for these to confirm to =
spec)?


Saqib Jang
Margalla Communications, Inc.
3301 El Camino Real, Suite 220
Atherton, CA 94027
Tel (650) 298 8462 Fax:( 650)  851 1613
http://www.margallacomm.com

-------------------------------------------------------------------------=
--------------------


                     The issue is not whether it's "appropriate".  The =
issue
                     is that if an implementation uses an FCIP Entity =
plus
                     an external security gateway, the only interface =
that
                     conforms to the forthcoming RFC is the =
public/external
                     interface on the security gateway.  The interface =
between
                     the FCIP Entity and the security gateway is private
                     and fails to conform to the security that will be
                     required of all FCIP implementations.

                     The above paragraph also applies to iSCSI =
(substitute iSCSI
                     for FCIP in all instances).  Let me also note that =
iSCSI's
                     ability to use a security gateway is not final at =
this
                     juncture.  The spectrum of security possibilities =
includes
                     things like SRP keying of ESP and IPsec transport =
mode that
                     would make external gateways difficult or =
impossible to use.

                     Those who care about being able to use security =
gateways
                     (or think that there's no need to support their =
use)
                     should speak up on the list, in London, and/or in =
Orange
                     County (I would expect the decision not to be made =
prior
                     to Orange County) and *EXPLAIN WHY* [technical =
rationale].

                     Thanks,
                     --David

                     ---------------------------------------------------
                     David L. Black, Senior Technologist
                     EMC Corporation, 42 South St., Hopkinton, MA  01748
                     +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
                     black_david@emc.com       Mobile: +1 (978) 394-7754
                     ---------------------------------------------------
                     =20

------=_NextPart_000_0017_01C11ACC.6B6C6140
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>David,</FONT></DIV>
<DIV><FONT size=3D2>Do your comments also apply to iFCP gateways (i.e. =
will=20
cryptographic</FONT></DIV>
<DIV><FONT size=3D2>security be required in iFCP gateways in order for =
these to=20
confirm to spec)?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>Saqib Jang<BR>Margalla Communications, Inc.<BR>3301 =
El Camino=20
Real, Suite 220<BR>Atherton, CA 94027<BR>Tel (650) 298 8462 Fax:( =
650)&nbsp; 851=20
1613<BR><A=20
href=3D"http://www.margallacomm.com">http://www.margallacomm.com</A></FON=
T></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT=20
size=3D2>----------------------------------------------------------------=
-----------------------------</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT=20
size=3D2><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
The issue is not whether it's "appropriate".&nbsp; The=20
issue<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
is that if an implementation uses an FCIP Entity=20
plus<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
an external security gateway, the only interface=20
that<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
conforms to the forthcoming RFC is the=20
public/external<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
interface on the security gateway.&nbsp; The interface=20
between<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
the FCIP Entity and the security gateway is=20
private<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
and fails to conform to the security that will=20
be<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
required of all FCIP implementations.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
The above paragraph also applies to iSCSI (substitute=20
iSCSI<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
for FCIP in all instances).&nbsp; Let me also note that=20
iSCSI's<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
ability to use a security gateway is not final at=20
this<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
juncture.&nbsp; The spectrum of security possibilities=20
includes<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
things like SRP keying of ESP and IPsec transport mode=20
that<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
would make external gateways difficult or impossible to =
use.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Those who care about being able to use security=20
gateways<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
(or think that there's no need to support their=20
use)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
should speak up on the list, in London, and/or in=20
Orange<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
County (I would expect the decision not to be made=20
prior<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
to Orange County) and *EXPLAIN WHY* [technical rationale].</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Thanks,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
--David</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
---------------------------------------------------<BR>&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
David L. Black, Senior=20
Technologist<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
EMC Corporation, 42 South St., Hopkinton, MA&nbsp;=20
01748<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
+1 (508) 435-1000 x75140&nbsp;&nbsp;&nbsp;&nbsp; FAX: +1 (508)=20
497-8500<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<A=20
href=3D"mailto:black_david@emc.com">black_david@emc.com</A>&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;=20
Mobile: +1 (978)=20
394-7754<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
---------------------------------------------------<BR>&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</FONT></DIV></BODY></HTML>

------=_NextPart_000_0017_01C11ACC.6B6C6140--




From owner-ips@ece.cmu.edu  Thu Aug  2 09:47:59 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27307
	for <ips-archive@odin.ietf.org>; Thu, 2 Aug 2001 09:47:58 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f72BRSx26954
	for ips-outgoing; Thu, 2 Aug 2001 07:27:28 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from elmo.ece.cmu.edu (ELMO.ECE.CMU.EDU [128.2.136.21])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f72BRRe26950
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 07:27:27 -0400 (EDT)
Date: Thu, 2 Aug 2001 07:27:27 -0400 (EDT)
Message-Id: <200108021127.f72BRRe26950@ece.cmu.edu>
From: Jim McKinney <jmck+@ece.cmu.edu>
X-Mailer: BatIMail version 3.2
To: ips@ece.cmu.edu
Subject: Fwd: BOUNCE ips@ece.cmu.edu:    Non-member submission from [Brian Pawlowski <beepy@netapp.com>]   
References: <200108020447.f724lUF03178@ece.cmu.edu>
Mime-Version: 1.0 (generated by tm-edit 1.5)
Content-Type: text/plain; charset=US-ASCII
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

From: Brian Pawlowski <beepy@netapp.com>
Message-Id: <200108020447.VAA02871@tooting-fe.eng.netapp.com>
Subject: Re: Security Gateways
In-Reply-To: <200108020206.f7226He27045@ece.cmu.edu> from Jim McKinney at "Aug 1, 1 10:06:17 pm"
To: jmck+@ece.cmu.edu (Jim McKinney)
Date: Wed, 1 Aug 2001 21:47:20 -0700 (PDT)
Cc: ips@ece.cmu.edu
X-Mailer: ELM [version 2.4ME++ PL40 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

> 2)  Concerning market requirements:
> 
> A very high percentage of storage environments today manage
> their configurations very carefully.  Such careful management is
> necessary to guarantee redundant paths for proper availability,
> to provide sufficient paths to provide the required performance, and to
> guarantee known paths to improve reparability and consistency
> of behavior.  As a side effect, a very high percentage of
> the paths of a storage environment are physically secured and have
> no requirement for additional security mechanisms.  

I've often mused that storage environments today based on FC are
physically secure as an artifact of the severe deployment restrictions
that the technology itself supports.

Replacing FC deployments with TCP/IP-based networks blows these
assumptions.

After years in the insecure wilderness within NFS, and the inability
to count on strong security from all vendors removing a motivation
to even invest in it (it was optional), the movement in NFS Version 4
to strong security was a key component of the evolution wrought since
it was handed to the IETF.

I look back on our lack of commitment to providing interoperable,
manadatory to implement (optional to enable) strong security as being
one of the greatest failures in NFS - that is finally being corrected.

It is certainly sobering when your PC on your desktop provides stronger
security guarantees in a simple network when it accesses data on some
server (CIFS) than you are guaranteed (through mandatory to implement)
in your enterprise class storage network. 

beepy




From owner-ips@ece.cmu.edu  Thu Aug  2 12:07:05 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03853
	for <ips-archive@odin.ietf.org>; Thu, 2 Aug 2001 12:07:05 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f72E1El03303
	for ips-outgoing; Thu, 2 Aug 2001 10:01:14 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from sandmail.sandburst.com (sandmail.sandburst.com [216.57.132.42])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f72E1Ce03299
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 10:01:12 -0400 (EDT)
To: ips@ece.cmu.edu
Subject: Re: iSCSI: draft 7: iSCSI response and SCSI sense data 
In-Reply-To: Message from "Mallikarjun C." <cbm@rose.hp.com> 
   of "Wed, 01 Aug 2001 21:21:50 PDT." <3B68D55E.AD118DE6@rose.hp.com> 
References: <277DD60FB639D511AC0400B0D068B71ECAD54D@CORPMX14>  <3B68D55E.AD118DE6@rose.hp.com> 
Date: Thu, 02 Aug 2001 10:01:11 -0400
From: Stephen Bailey <steph@cs.uchicago.edu>
Message-Id: <20010802140111.8D1FA4E8D@sandmail.sandburst.com>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

> It appears to me that generating a SCSI CHECK CONDITION is
> the right thing for iSCSI to do regardless of T10's eventual
> decision (ACA/persistent-UA (T10 proposal 00-359r1)/something
> totally different) on a mechanism to enforce ordering semantics.

I agree.  The ACA issue may be important, but it's not the point here.

Targets should report everything they can using transport-independent
mechanisms.  The task is a class-driver <-> LUN exchange, and status
should return in the same layer.  In other words, if you had a storage
array that reported errors in some way on ||SCSI and FCP, it will
(want to) do the same on iSCSI.

Steph


From owner-ips@ece.cmu.edu  Thu Aug  2 12:35:16 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05649
	for <ips-archive@odin.ietf.org>; Thu, 2 Aug 2001 12:35:16 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f72EaPW05023
	for ips-outgoing; Thu, 2 Aug 2001 10:36:25 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mxic2.us.dg.com (mxic2.us.dg.com [128.221.31.40])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f72EaOe05019
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 10:36:24 -0400 (EDT)
Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19)
	id <PJ5V3JS4>; Thu, 2 Aug 2001 10:34:20 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD555@CORPMX14>
From: Black_David@emc.com
To: Julian_Satran@il.ibm.com, ips@ece.cmu.edu
Subject: RE: iSCSI - three negotiation items
Date: Thu, 2 Aug 2001 10:31:14 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Comments below.  --David

> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Thursday, August 02, 2001 3:14 AM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI - three negotiation items
> 
> 
> 
> comments in text. Julo
> 
> 
> 
> Black_David@emc.com on 02-08-2001 04:46:53
> 
> Please respond to Black_David@emc.com
> 
> To:   ips@ece.cmu.edu
> cc:
> Subject:  iSCSI - three negotiation items
> 
> 
> 
> 
> Going through the list of simplification suggestions,
> I found a few items that look like they
> should be reasonable to deal with on the list.
> 
> (1) For any key that can take a numeric value, could
> we specify the required base for the number, either
> decimal or hex, not both.  The practical issue is that
> the sort of large values used for keys and the like
> in security are much easier to deal with in hex than
> decimal.
> 
> +++ the current draft allows for both - Is there something 
> wrong with that?
> Hex is simpler but if data gets copied from somewhere else 
> and that is a
> decimal source then that is error prone +++

DLB> Possibly.  The implementation issue is that converting
DLB> large quantities (e.g., 128 bit) from decimal to hex
DLB> is annoying (it's bignum arithmetic).  Does anyone
DLB> ever use decimal to represent this sort of keying
DLB> material?  The major concern is apparently the
DLB> security-related stuff (e.g., I doubt it's
DLB> a big deal if someone wants to use hex instead of
DLB> decimal for MaxConnections).
 
> (2) The KRB5 and SPKM inband cryptographic integrity
> digests on p.136 seem to be relics of a prior inband
> approach to security.  Has anyone implemented them?
> Does anyone want them to remain?  Can we just delete
> them?
> 
> +++ Yes - I think we can take them out although UMAC may 
> get-in at some
> point :-) +++

DLB> Good.  

> (3) Can HeaderDigest and DataDigest be combined?
> If (2) is done, this is about making use of CRC-32C
> a single on/off switch rather than two separate switches
> for header and data?
> 
> +++ combining defeats the purpose of the iSCSI CRC - to get 
> you through
> iSCSI proxies that may change the header but will not change 
> the data +++

DLB> My fault for not being clear.  The proposal is to still
DLB> compute separate CRCs on header and data for exactly
DLB> that iSCSI proxy reason that Julian cites, but to
DLB> combine the negotiation keys into one key so that
DLB> the only two possibilities are:
DLB>  - Both CRCs are generated.
DLB>  - Neither CRC is generated.
DLB> Does anyone see a compelling case for one of these
DLB> CRCs without the other?


From owner-ips@ece.cmu.edu  Thu Aug  2 12:40:36 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05913
	for <ips-archive@odin.ietf.org>; Thu, 2 Aug 2001 12:40:35 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f72EVFc04749
	for ips-outgoing; Thu, 2 Aug 2001 10:31:15 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from MAIL.NetOctave.com (netoctave-gw.customer.alter.net [65.195.230.86])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f72EVDe04744;
	Thu, 2 Aug 2001 10:31:14 -0400 (EDT)
Received: by MAIL.NetOctave.com with Internet Mail Service (5.5.2650.21)
	id <P9HWVZXS>; Thu, 2 Aug 2001 10:27:27 -0400
Message-ID: <49B96FCC784BC54F9675A6B558C3464E17CFD6@MAIL.NetOctave.com>
From: Mark Winstead <Mark.Winstead@NetOctave.com>
To: "'Jim McKinney'" <jmck+@ece.cmu.edu>, ips@ece.cmu.edu
Cc: David Blaker <DBlaker@NetOctave.com>
Subject: RE: Security Gateways
Date: Thu, 2 Aug 2001 10:27:17 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

On market requirements:

1) Curious, what is your basis for the guess of 1% of storage
environments/paths not being physically secure? While I tend to agree that
currently this is a low percentage, 1% seems too low. Do you have any hard
numbers to justify this your guess?

Large companies and companies experiencing rapid growth often have multiple
locations across a metropolitan area. Do these companies not have some
commonly accessible storage facility for at least some of their data? Don't
other companies have or would like to have workers at multiple locations
across miles if not hundreds of miles to collaborate, requiring access to
the same data, not just mirrored (and thus often dated) data?

2) Even if the % of paths are in single digits, do you think there won't be
a paradigm shift?

With increased capacities for bandwidth (OC-12, 0C-48, faster networks
switches, et al) coming available, it would seem logical that it will become
practical for more and more companies to shift data storage facilities to
lower rent facilities than their office and/or research space, and to
increase collaboration among workers at multiple locations (or even true
telecommuters connected through broadband technologies).


Mark Winstead

NetOctave, Inc.
P.O. Box 14824
RTP, NC 27709
www.netoctave.com
919.463.9903 x328
mark.winstead@netoctave.com <mailto:mark.winstead@netoctave.com> 

-----Original Message-----
From: Jim McKinney [mailto:jmck+@ece.cmu.edu]
Sent: Wednesday, August 01, 2001 10:06 PM
To: ips@ece.cmu.edu
Subject: RE: Security Gateways


Dear David,

I would like to address the rather serious question you have
raised here about both architectural layering and market
requirements.  After considerable thought, based on the
explanations below, I have concluded that the FCIP RFC should
specify that security is optional to implement and optional to use.

1)  Concerning architectural layering:

It is clear that the problems of security are well understood
within IETF. Numerous solutions have been proposed and
many of those have become standard implementations.  The most
successful of those (as an example, IPSec) have used the
principles of architectural layering very well.  IPSec
provides a secure mechanism for transporting any IP-based
protocol if the protocol requires such security.  However,
the overlaying protocols (as an example, TCP) have no requirement
to actually make use of IPSec, and in fact have no particular
requirement to make use of IP.  This is as it should be.
Each layer is implemented independently of the other.  The
services that each layer implements depend on the market
requirements for the environment.  By that logic, it is 
unnecessary for FCIP to specify any security mechanism at all, 
since so many security mechanisms are available.  However,
FCIP has provided the additional guidance that, if security
in a TCP environment is used, it shall be provided at a layer
below the TCP interface.  In particular, it recommends the
use of IPSec for TCP/IP environments (and will recommend the
appropriate IPSec options).  This additional guidance has nothing
to do with the architecture or definition of FCIP and is 
merely a recommendation that should improve interoperability.

2)  Concerning market requirements:

A very high percentage of storage environments today manage
their configurations very carefully.  Such careful management is
necessary to guarantee redundant paths for proper availability,
to provide sufficient paths to provide the required performance, and to
guarantee known paths to improve reparability and consistency
of behavior.  As a side effect, a very high percentage of
the paths of a storage environment are physically secured and have
no requirement for additional security mechanisms.  At present,
the only paths that are using security are those very few paths
that leave one physically secure environment to transport data to
another physically secure environment.  Those few paths almost universally
use security mechanisms at a lower level (as an example, a virtual
private network) to achieve their goals.  As a first guess, such
paths are well under 1% of the storage paths being used today.

I do not believe that this paradigm will change significantly over
the next several years, although of course the percentage of paths
requiring transport security may rise over 1%.  The requirements for
storage performance and the desire to maintain the storage devices
and many of their primary processors in a physically secure
environment will assure similar configurations.

In this environment, the market will demand low cost and high
performance for the great majority of interconnects and will demand
security for a relatively low percentage of interconnects.  

What this implies for technologies like FCIP is that security
be available as a separate option, outside the primary FCIP
definition.  While still allowing the integration of security
inside an FCIP unit, the IETF draft for FCIP  must also allow security
to be provided either not at all or by an outside mechanism.  
The most common outside mechanism would be a gateway box of some sort.
In many cases, the gateway box will be a secure router placed on the
external link and servicing a large number of locally attached
unsecured FCIP boxes.

CONCLUSIONS:

The FCIP draft should continue to specify a security mechanism,
with IPSec being the appropriate candidate, to guarantee interoperability
when security is provided.  The FCIP draft should be modified to
indicate that security is optional to implement and optional to use.
In addition, it should explicitly indicate that external gateway
boxes are allowed implementation mechanisms for security.

As a side question, note that management of storage area networks
and FCIP boxes is a separate question and is outside the scope of
the FCIP draft.  Both Fibre Channel and Ethernet management paths
have security appropriate to the particular management mechanism.
As an example, web-based management mechanisms use web-based
security tools. 

Bob Snively                        e-mail:    rsnively@brocade.com
Brocade Communications Systems     phone:  408 487 8135
1745 Technology Drive
San Jose, CA 95110



-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Tuesday, July 24, 2001 7:11 PM
To: ips@ece.cmu.edu
Subject: Security Gateways


The following issue was hidden in my long set of
comments on the -03 version of FCIP:

> > Delete 12 b).  If an FCIP entity is operating with an external
> > security gateway, only the interface on the public side of the
> > gateway is compliant with this specification.  The interface
> > between the FCIP entity and the gateway is not compliant because
> > it is lacking required security features - the FCIP entity
> > *includes* the security gateway in this structure.
> 
> Please post this as a separate issue because several of the
> FCIP Authors believe it is appropriate for FCIP and I cannot
> represent their opinions.

The issue is not whether it's "appropriate".  The issue
is that if an implementation uses an FCIP Entity plus
an external security gateway, the only interface that
conforms to the forthcoming RFC is the public/external
interface on the security gateway.  The interface between
the FCIP Entity and the security gateway is private
and fails to conform to the security that will be
required of all FCIP implementations.

The above paragraph also applies to iSCSI (substitute iSCSI
for FCIP in all instances).  Let me also note that iSCSI's
ability to use a security gateway is not final at this
juncture.  The spectrum of security possibilities includes
things like SRP keying of ESP and IPsec transport mode that
would make external gateways difficult or impossible to use.

Those who care about being able to use security gateways
(or think that there's no need to support their use)
should speak up on the list, in London, and/or in Orange
County (I would expect the decision not to be made prior
to Orange County) and *EXPLAIN WHY* [technical rationale].

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------
 


From owner-ips@ece.cmu.edu  Thu Aug  2 12:41:52 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05988
	for <ips-archive@odin.ietf.org>; Thu, 2 Aug 2001 12:41:52 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f72Et8s05953
	for ips-outgoing; Thu, 2 Aug 2001 10:55:08 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f72Et7e05948
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 10:55:07 -0400 (EDT)
Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <3W0TP8GZ>; Thu, 2 Aug 2001 10:55:02 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD556@CORPMX14>
From: Black_David@emc.com
To: ips@ece.cmu.edu
Subject: RE: iSCSI: draft 7: iSCSI response and SCSI sense data
Date: Thu, 2 Aug 2001 10:50:08 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

I've got to stop writing email late at night ...

> I think Ralph is conveying a message from T10 that whatever the
> problem iSCSI has, T10 is not inclined to believe that more use
> of ACA is NOT the solution.

That should have been a single negative, not double. i.e., "T10
is inclined to believe that more use of ACA is NOT the solution."

> It may take a while to work with T10
> to get the right solution designed, but I'd prefer doing nothing
> over force-fitting ACA to a use that T10 doesn't think is appropriate.
> When we figure out what the right thing is, we can put in the right
> text to describe it.

At least that's still correct :-).

Sorry/Thanks,
--David

> -----Original Message-----
> From: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Wednesday, August 01, 2001 9:19 PM
> To: Julian_Satran@il.ibm.com; ips@ece.cmu.edu
> Subject: RE: iSCSI: draft 7: iSCSI response and SCSI sense data
> 
> 
> In my lousy Indiana Jones impression - "ACA, why does it
> always have to be ACA?" ....
> 
> This whole notion that ACA is a fundamental coordination
> mechanism for shared SCSI access to a target is not headed
> in a good direction - see the recent message from Ralph Weber
> expressing T10's concern that expansion of the usage of ACA is
> an invitation to undesirable denial of service possibilities.
> I will note that the reservation example that Ralph used in his
> message is the sort of thing that can break clustering software,
> although I don't know for certain whether there's any existing
> clustering software that it does in fact break.
> 
> I think Rob and Jim are correct when they describe the current
> 2.4.3 text as being at odds with SAM-2.  So, I think:
> 
> - The text in 2.4.3 that is at odds with SAM-2 should come out.
> 	The fact that it was caused by a desire to use ACA makes
> 	it doubly suspect.
> - The current mandate for ACA in Section 8.2 exceeds the level
> 	stated in the iSCSI requirements draft and I don't believe
> 	it represents rough consensus of the WG.  Support for
> 	ACA should be a "SHOULD", not a "MUST".
> - The entire effort to use ACA or something like it to serialize
> 	error conditions for multiple commands in flight has not been
> 	explained well to T10, and what has been explained has not
> 	received a good reception.
> 
> The last bullet has a couple of consequences.  First, we should 
> take out anything else that's crept into iSCSI in support of this
> use of ACA.  Second, those who want to use ACA or something ACA-like
> for this error coordination across multiple commands in flight
> should write up a submission to T10 explaining what the problem
> is and how ACA or something like it solves the problem.
> 
> I think Ralph is conveying a message from T10 that whatever the
> problem iSCSI has, T10 is not inclined to believe that more use
> of ACA is NOT the solution.  It may take a while to work with T10
> to get the right solution designed, but I'd prefer doing nothing
> over force-fitting ACA to a use that T10 doesn't think is appropriate.
> When we figure out what the right thing is, we can put in the right
> text to describe it.
> 
> Comments?
> --David
> 
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------
> 
> 
> 
> > -----Original Message-----
> > From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > Sent: Wednesday, August 01, 2001 8:01 PM
> > To: ips@ece.cmu.edu
> > Subject: Re: iSCSI: draft 7: iSCSI response and SCSI sense data
> > 
> > 
> > 
> > Elliot,
> > 
> > This issue has some history.  After many took the position you are
> > advocating
> > and I had to drop the check condition all list participants that had
> > something to say adopted the current position in order the 
> > benefit from the
> > "serializing" effect of ACA whenever a check condition is 
> > originated at the
> > target and the delivery subsystem is still operational.
> > 
> > Julo
> > 
> > 
> > "Elliott, Robert" <Robert.Elliott@compaq.com> on 02-08-2001 02:26:57
> > 
> > Please respond to "Elliott, Robert" <Robert.Elliott@compaq.com>
> > 
> > To:   "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
> > cc:
> > Subject:  iSCSI: draft 7: iSCSI response and SCSI sense data
> > 
> > 
> > 
> > 
> > iSCSI draft 7 section 2.4.3 includes a table relating the iSCSI
> > response codes to various CHECK CONDITION status additional
> > sense codes:
> > 
> >   "0x01 Target Failure
> >     ASC=0x44 ASCQ=0x00 INTERNAL TARGET FAILURE
> >   0x02 Delivery Subsystem Failure
> >     ASC=0x47 ASCQ=0x03 INFORMATION UNIT CRC ERROR DETECTED
> >   0x03 Unsolicited data rejected
> >     ASC=0x49 ASCQ=0x00 INVALID MESSAGE ERROR
> >   0x04 Not enough unsolicited [data]
> >     ASC=0x49 ASCQ=0x00 INVALID MESSAGE ERROR
> >   0x05 SNACK rejected [Command in progress]
> >     ASC=0x47 ASCQ=0x03 INFORMATION UNIT CRC ERROR DETECTED
> > 
> >   As listed above, each defined response code MUST be used 
> (under the
> >   conditions described in the 'Reason' field), only when the
> >   corresponding SCSI CHECK CONDITION is signaled, to convey 
> additional
> >   protocol service information.  A SCSI CHECK CONDITION with the ASC
> >   and ASCQ values as tabulated MUST be signaled by iSCSI targets for
> >   all the instances in this document referring to usage of 
> one of the
> >   above defined response codes."
> > 
> > No other SCSI protocol does this. iSCSI seems to be granting the
> > SCSI-level status a priority over the iSCSI-level response data.
> > I think the other protocols treat the response data as more
> > important; if the response data indicates a problem, the SCSI layer
> > is considered broken and the SCSI status is undefined.
> > 
> > Forcing the iSCSI layer to fill in those fields seems to break the
> > layering model.
> > 
> > I suggest removing the CHECK CONDITION status and additional sense
> > code linkage and leave the SCSI status undefined if the iSCSI
> > response is nonzero.
> > 
> > This is compatible with SAM-2, which only requires status 
> be returned
> > when the service response is TASK COMPLETE (SAM-2 revision 18
> > section 5.3.1):
> >   "Status shall be sent from the logical unit to the application
> >    client whenever a command ends with a service response of
> >    TASK COMPLETE or LINKED COMMAND COMPLETE."
> > 
> > Furthermore, SAM-2 requires that status be ignored when the service
> > response indicates an error (SAM-2 revision 18 section 5.1):
> >   "Status: A one-byte field containing command completion status
> >   (see 5.3). If the command ends with a service response of
> >   SERVICE DELIVERY OR TARGET FAILURE, the application client
> >   shall consider this parameter to be undefined."
> > 
> > I think iSCSI's current wording may violate this rule.
> > ---
> > Rob Elliott, Compaq Server Storage
> > Robert.Elliott@compaq.com
> > 
> > 
> > 
> > 
> 


From owner-ips@ece.cmu.edu  Thu Aug  2 13:19:59 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07979
	for <ips-archive@odin.ietf.org>; Thu, 2 Aug 2001 13:19:59 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f72EQPZ04532
	for ips-outgoing; Thu, 2 Aug 2001 10:26:25 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mxic2.us.dg.com (mxic2.us.dg.com [128.221.31.40])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f72EQOe04525
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 10:26:24 -0400 (EDT)
Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19)
	id <PJ5V3269>; Thu, 2 Aug 2001 10:24:32 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD554@CORPMX14>
From: Black_David@emc.com
To: Julian_Satran@il.ibm.com, ips@ece.cmu.edu
Subject: RE: iSCSI: draft 7: iSCSI response and SCSI sense data
Date: Thu, 2 Aug 2001 10:21:25 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

> Could you please quote us which part of SAM-2 this is 
> violating.

As Rob Elliott said:

> Furthermore, SAM-2 requires that status be ignored when the service
> response indicates an error (SAM-2 revision 18 section 5.1):
>   "Status: A one-byte field containing command completion status
>   (see 5.3). If the command ends with a service response of
>   SERVICE DELIVERY OR TARGET FAILURE, the application client
>   shall consider this parameter to be undefined."
>
> I think iSCSI's current wording may violate this rule.

So, just generate the CHECK CONDITION and don't try to use the
iSCSI Service Response to further qualify it, as Mallikarjun
suggests:

> Robert Elliott pointed out a violation by iSCSI in trying to 
> additionally qualify ASC, ASCQ with its response codes.  I suggest 
> that dropping this "additional description" attempt in all these 
> cases is all iSCSI needs to do to meet SAM's expectations.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


From owner-ips@ece.cmu.edu  Thu Aug  2 13:20:16 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07999
	for <ips-archive@odin.ietf.org>; Thu, 2 Aug 2001 13:20:16 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f72FVse08101
	for ips-outgoing; Thu, 2 Aug 2001 11:31:54 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f72FVre08097
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 11:31:53 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id RAA300878
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 17:31:46 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f72FVji71228
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 17:31:46 +0200
Importance: Normal
Subject: Re: iSCSI: draft 7: iSCSI response and SCSI sense data
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF945DE01F.A3B27ED3-ONC2256A9C.0055AA49@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Thu, 2 Aug 2001 18:37:54 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 02/08/2001 18:31:45
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


That is the current situation - statuse are generated (and responses) are
generated at the target.

Sorry - Steph - I am wrong and the right guy to blame for anything :-)

Julo

Stephen Bailey <steph@cs.uchicago.edu> on 02-08-2001 16:48:34

Please respond to Stephen Bailey <steph@cs.uchicago.edu>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:
Subject:  Re: iSCSI: draft 7: iSCSI response and SCSI sense data




> You change opinions faster than draft changes :-)

Actually, I think I do a bad job of explaining myself.

You already chastised me for a `reversal' on this topic.

My position, stated the last time you claimed I reversed (just a few
weeks ago, I think), is:
  1) target should report ALL forms of task completion using SCSI status
  2) the initiator should NOT synthesize SCSI status.

My originally stated opinion had to do with 2).  I never argued with
the target `synthesizing' SCSI status, because the target is NOT
synthesizing SCSI status, it's generating it.

I agree that I have been confused about the role of target-generated
response codes WRT to request protocol errors (that's FCP data length
& invalid FCP_CMND response codes).  I have decided that the FCP
approach is wrong and the ||SCSI approach is right.  The FCP targets
that I like use the ||SCSI approach anyway.

How many more times can I say uncle?  I said it on the list (check the
archive).  I'm saying it here.  You want me to say it on the list
again?

Are you ever wrong about anything?

Steph





From owner-ips@ece.cmu.edu  Thu Aug  2 13:30:23 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03852
	for <ips-archive@odin.ietf.org>; Thu, 2 Aug 2001 12:07:05 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f72DYfk02004
	for ips-outgoing; Thu, 2 Aug 2001 09:34:41 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from galileo5.galileo.co.il (pop3.galileo.co.il [199.203.130.130])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f72DYce01999
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 09:34:39 -0400 (EDT)
Received: from galileo.co.il ([10.4.1.11])
	by galileo.co.il (8.8.5/8.8.5) with ESMTP id QAA14407
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 16:33:48 +0200 (GMT-2)
Message-ID: <3B6965A6.908A4A1C@galileo.co.il>
Date: Thu, 02 Aug 2001 16:37:26 +0200
From: Saeed Bishara <saeed@galileo.co.il>
X-Mailer: Mozilla 4.74 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ips@ece.cmu.edu
Subject: remove
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit





From owner-ips@ece.cmu.edu  Thu Aug  2 14:23:22 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11226
	for <ips-archive@odin.ietf.org>; Thu, 2 Aug 2001 14:23:21 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f72GGQi10658
	for ips-outgoing; Thu, 2 Aug 2001 12:16:26 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from erie.mcdata.com (mcgate.mcdata.com [144.49.1.5])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f72GGNe10650
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 12:16:24 -0400 (EDT)
Received: by erie.mcdata.com with Internet Mail Service (5.5.2653.19)
	id <PWP3BVYB>; Thu, 2 Aug 2001 10:16:17 -0600
Message-ID: <F23E86F16912534DA9FA8937CFD7CA7403AB4C50@exchange5.mcdata.com>
From: Anil Rijhsinghani <anil.rijhsinghani@mcdata.com>
To: "'Black_David@emc.com'" <Black_David@emc.com>, rsnively@Brocade.COM,
        ips@ece.cmu.edu
Subject: RE: Security Gateways
Date: Thu, 2 Aug 2001 10:16:11 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

David:

I believe the security requirements for FCIP may be somewhat different
than those for iSCSI. While it is possible to secure iSCSI end-to-end,
it's not possible to do so for FCIP because of the fact that Fibre Channel
itself has no built-in security protocol. A user of FC needs to physically
secure the FC portion of the SAN in any case so the additional physical
security
for the FCIP device, or the wire between it and a sec gateway, is
much less of an issue.

Regards,
Anil

-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Wednesday, August 01, 2001 5:42 PM
To: rsnively@Brocade.COM; ips@ece.cmu.edu
Subject: RE: Security Gateways


Bob,

An RFC does not tell anyone what can or cannot be built;
it specifies what is required for compliance with the RFC.
If someone builds a protocol implementations that doesn't
comply with the requirements of the RFC, they should not
expect to be able to claim RFC compliance for devices 
based on that implementation.

> The marketplace does demand that
> security be possible and available for a device.  

The compliance requirement here is that "possible and
available" be realizable without having to add anything
to the device.  For the structure of interest here,
an FCIP device plus a security gateway, the complete system
[FCIP device, cable, security gateway] would comply with
the FCIP RFC at its external interface (i.e., the external
interface of the security gateway).  The interface between
the FCIP device and the security gateway would be missing
some required security functionality and hence would
not comply with the RFC.  As a result, the FCIP device by
itself would not comply with the RFC.

> I can understand why the IESG would push back on this
> question, but I would expect that they also believe that
> an FCIP device without optional security implemented
> is still an FCIP device and is compliant with the FCIP RFC. 

If "optional" means "MUST implement, but MAY use", that
expectation would be incorrect.  "MUST implement" (cf.
RFC 2119) is the level of requirement for authentication
and cryptographic integrity that is necessary for FCIP
to be approved as an RFC.  This isn't just "push back"
from the IESG - it is a condition that the IESG required
for its original approval of the IPS WG charter.

> With an edge security device installed 
> in front of it, it is also a
> secure FCIP device, just like the end-point of a 
> virtual private network is a secure device. 

That combination will comply with the RFC.  OTOH, the
IESG will not permit the FCIP RFC to allow an FCIP device
that lacks the basic security mechanisms to be compliant,
and hence the FCIP device *without* the edge security
device will not comply.

> By definition, "man in the middle" attacks are impossible
> for a security edge device, since the only place that the
> "man in the middle" can be placed is in the encrypted path.

"By definition" is not the best wording.  Assuming that the
"security edge device" is an IPsec security gateway, the IKE
and ISAKMP  protocols are to negotiate security functionality
and parameters; those protocols are resistant to man-in-the-
middle attacks, but that resistance is based on careful design.

--David


> -----Original Message-----
> From: Robert Snively [mailto:rsnively@brocade.com]
> Sent: Wednesday, August 01, 2001 6:25 PM
> To: 'Black_David@emc.com'; Robert Snively; ips@ece.cmu.edu
> Subject: RE: Security Gateways
> 
> 
> David,
> 
> I believe this is really a very difficult question, not
> susceptible to a simple SHALL/SHALL NOT response.  
> The technology absolutely allows and encourages
> security edge devices and absolutely allows devices using
> TCP and other protocols to exploit those edge devices or
> not as the system administrator requires.  The marketplace
> absolutely demands those capabilities.  A significant percentage
> of the internet economy is based on separately supplied security.
> I understand that the IETF
> has no interest in devices that are solely for closed
> environments, but the marketplace does not demand that
> a device have security built in to qualify for compliance with a
> protocol.  The marketplace does demand that
> security be possible and available for a device.  
> 
> That is what we have been proposing.
> 
> By definition, "man in the middle" attacks are impossible
> for a security edge device, since the only place that the
> "man in the middle" can be placed is in the encrypted path.
> The physically secured path has no possibility of an
> entry point for such an attack.  
> 
> I can understand why the IESG would push back on this
> question, but I would expect that they also believe that
> an FCIP device without optional security implemented
> is still an FCIP device and is compliant with the FCIP RFC. 
> This should be true whether the TCP path is based on IP,
> HIPPI, IB, a proprietary backplane or any other transport 
> that supports TCP. With an edge security device installed 
> in front of it, it is also a
> secure FCIP device, just like the end-point of a 
> virtual private network is a secure device. 
> 
> That is what we would like the RFC to say.
> 
> Bob
> 
> -----Original Message-----
> From: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Wednesday, August 01, 2001 10:13 AM
> To: rsnively@brocade.com; ips@ece.cmu.edu
> Subject: RE: Security Gateways
> 
> 
> Bob,
> 
> You've made a good case for "optional to use", but not
> "optional to implement".  The basic reason is that there
> is no way to ensure that vendors and/or users will
> restrict the use of an implementation that does not
> include security to situations where "paths of a
> storage environment are physically secured and have 
> no requirement for additional security mechanisms".
> Hence security needs to be present so that it
> can be used when FCIP is deployed in an environment
> that requires security.  Further, the IETF has no
> interest in specification of protocols that are
> *solely* for use in the sort of closed environment
> that you describe, and the IPS WG charter contains
> explicit words to that effect.
> 
> Therefore, the basic FCIP security mechanisms MUST be
> implemented, but usage MAY be negotiated.  At the moment,
> "basic security mechanisms" means authentication and
> cryptographic integrity.  Confidentiality can currently
> be optional to implement, but I think it's a very good
> idea to specify the basic confidentiality mechanism
> (*if* confidentiality of any form is implemented, *then*
> <XXX> MUST be implemented).  The design and specification
> of any negotiation mechanism must resist man-in-the-middle
> attacks on negotiation that would result in turning off
> security where that was not the intended outcome - such
> an approach can include restrictions on implementation
> behavior (e.g., if "no authentication" is not acceptable,
> do not offer or accept it during negotiation).
> 
> If the FCIP draft is sent to the IESG without requiring
> implementation of the basic security mechanisms, it will
> be returned to the WG with instructions to correct
> that shortcoming, along with some choice words from the
> ADs wondering how the WG chairs could have overlooked
> something like this.  As a result, an FCIP draft that
> does not require implementation of the basic security
> mechanisms will not be Last Called in the WG until that
> requirement is added.
> 
> Sorry to be blunt, but there is no flexibility on whether
> the basic security mechanisms are mandatory to implement;
> they will be mandatory to implement, period.
> 
> Thanks,
> --David
> 
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------
> 
> 
> > -----Original Message-----
> > From: Robert Snively [mailto:rsnively@brocade.com]
> > Sent: Wednesday, August 01, 2001 12:08 PM
> > To: 'Black_David@emc.com'; ips@ece.cmu.edu
> > Subject: RE: Security Gateways
> > 
> > 
> > Dear David,
> > 
> > I would like to address the rather serious question you have
> > raised here about both architectural layering and market
> > requirements.  After considerable thought, based on the
> > explanations below, I have concluded that the FCIP RFC should
> > specify that security is optional to implement and optional to use.
> > 
> > 1)  Concerning architectural layering:
> > 
> > It is clear that the problems of security are well understood
> > within IETF. Numerous solutions have been proposed and
> > many of those have become standard implementations.  The most
> > successful of those (as an example, IPSec) have used the
> > principles of architectural layering very well.  IPSec
> > provides a secure mechanism for transporting any IP-based
> > protocol if the protocol requires such security.  However,
> > the overlaying protocols (as an example, TCP) have no requirement
> > to actually make use of IPSec, and in fact have no particular
> > requirement to make use of IP.  This is as it should be.
> > Each layer is implemented independently of the other.  The
> > services that each layer implements depend on the market
> > requirements for the environment.  By that logic, it is 
> > unnecessary for FCIP to specify any security mechanism at all, 
> > since so many security mechanisms are available.  However,
> > FCIP has provided the additional guidance that, if security
> > in a TCP environment is used, it shall be provided at a layer
> > below the TCP interface.  In particular, it recommends the
> > use of IPSec for TCP/IP environments (and will recommend the
> > appropriate IPSec options).  This additional guidance has nothing
> > to do with the architecture or definition of FCIP and is 
> > merely a recommendation that should improve interoperability.
> > 
> > 2)  Concerning market requirements:
> > 
> > A very high percentage of storage environments today manage
> > their configurations very carefully.  Such careful management is
> > necessary to guarantee redundant paths for proper availability,
> > to provide sufficient paths to provide the required 
> > performance, and to
> > guarantee known paths to improve reparability and consistency
> > of behavior.  As a side effect, a very high percentage of
> > the paths of a storage environment are physically secured and have
> > no requirement for additional security mechanisms.  At present,
> > the only paths that are using security are those very few paths
> > that leave one physically secure environment to transport data to
> > another physically secure environment.  Those few paths 
> > almost universally
> > use security mechanisms at a lower level (as an example, a virtual
> > private network) to achieve their goals.  As a first guess, such
> > paths are well under 1% of the storage paths being used today.
> > 
> > I do not believe that this paradigm will change significantly over
> > the next several years, although of course the percentage of paths
> > requiring transport security may rise over 1%.  The requirements for
> > storage performance and the desire to maintain the storage devices
> > and many of their primary processors in a physically secure
> > environment will assure similar configurations.
> > 
> > In this environment, the market will demand low cost and high
> > performance for the great majority of interconnects and will demand
> > security for a relatively low percentage of interconnects.  
> > 
> > What this implies for technologies like FCIP is that security
> > be available as a separate option, outside the primary FCIP
> > definition.  While still allowing the integration of security
> > inside an FCIP unit, the IETF draft for FCIP  must also 
> allow security
> > to be provided either not at all or by an outside mechanism.  
> > The most common outside mechanism would be a gateway box of 
> some sort.
> > In many cases, the gateway box will be a secure router placed on the
> > external link and servicing a large number of locally attached
> > unsecured FCIP boxes.
> > 
> > CONCLUSIONS:
> > 
> > The FCIP draft should continue to specify a security mechanism,
> > with IPSec being the appropriate candidate, to guarantee 
> > interoperability
> > when security is provided.  The FCIP draft should be modified to
> > indicate that security is optional to implement and optional to use.
> > In addition, it should explicitly indicate that external gateway
> > boxes are allowed implementation mechanisms for security.
> > 
> > As a side question, note that management of storage area networks
> > and FCIP boxes is a separate question and is outside the scope of
> > the FCIP draft.  Both Fibre Channel and Ethernet management paths
> > have security appropriate to the particular management mechanism.
> > As an example, web-based management mechanisms use web-based
> > security tools. 
> > 
> > Bob Snively                        e-mail:    rsnively@brocade.com
> > Brocade Communications Systems     phone:  408 487 8135
> > 1745 Technology Drive
> > San Jose, CA 95110
> > 
> > 
> > 
> > -----Original Message-----
> > From: Black_David@emc.com [mailto:Black_David@emc.com]
> > Sent: Tuesday, July 24, 2001 7:11 PM
> > To: ips@ece.cmu.edu
> > Subject: Security Gateways
> > 
> > 
> > The following issue was hidden in my long set of
> > comments on the -03 version of FCIP:
> > 
> > > > Delete 12 b).  If an FCIP entity is operating with an external
> > > > security gateway, only the interface on the public side of the
> > > > gateway is compliant with this specification.  The interface
> > > > between the FCIP entity and the gateway is not compliant because
> > > > it is lacking required security features - the FCIP entity
> > > > *includes* the security gateway in this structure.
> > > 
> > > Please post this as a separate issue because several of the
> > > FCIP Authors believe it is appropriate for FCIP and I cannot
> > > represent their opinions.
> > 
> > The issue is not whether it's "appropriate".  The issue
> > is that if an implementation uses an FCIP Entity plus
> > an external security gateway, the only interface that
> > conforms to the forthcoming RFC is the public/external
> > interface on the security gateway.  The interface between
> > the FCIP Entity and the security gateway is private
> > and fails to conform to the security that will be
> > required of all FCIP implementations.
> > 
> > The above paragraph also applies to iSCSI (substitute iSCSI
> > for FCIP in all instances).  Let me also note that iSCSI's
> > ability to use a security gateway is not final at this
> > juncture.  The spectrum of security possibilities includes
> > things like SRP keying of ESP and IPsec transport mode that
> > would make external gateways difficult or impossible to use.
> > 
> > Those who care about being able to use security gateways
> > (or think that there's no need to support their use)
> > should speak up on the list, in London, and/or in Orange
> > County (I would expect the decision not to be made prior
> > to Orange County) and *EXPLAIN WHY* [technical rationale].
> > 
> > Thanks,
> > --David
> > 
> > ---------------------------------------------------
> > David L. Black, Senior Technologist
> > EMC Corporation, 42 South St., Hopkinton, MA  01748
> > +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> > black_david@emc.com       Mobile: +1 (978) 394-7754
> > ---------------------------------------------------
> >  
> > 
> 


From owner-ips@ece.cmu.edu  Thu Aug  2 14:24:25 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11254
	for <ips-archive@odin.ietf.org>; Thu, 2 Aug 2001 14:24:24 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f72Gquk12915
	for ips-outgoing; Thu, 2 Aug 2001 12:52:56 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from elmo.ece.cmu.edu (ELMO.ECE.CMU.EDU [128.2.136.21])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f72Gqte12910
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 12:52:55 -0400 (EDT)
Date: Thu, 2 Aug 2001 12:52:55 -0400 (EDT)
Message-Id: <200108021652.f72Gqte12910@ece.cmu.edu>
From: Jim McKinney <jmck+@ece.cmu.edu>
X-Mailer: BatIMail version 3.2
To: ips@ece.cmu.edu
Subject: Fwd: BOUNCE ips@ece.cmu.edu:    Non-member submission from [Robert Snively <rsnively@brocade.com>]   
References: <200108021634.f72GYkB11778@ece.cmu.edu>
Mime-Version: 1.0 (generated by tm-edit 1.5)
Content-Type: text/plain; charset=US-ASCII
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Date: Thu, 2 Aug 2001 12:34:46 -0400 (EDT)
From: owner-ips@ece.cmu.edu
Message-Id: <200108021634.f72GYkB11778@ece.cmu.edu>
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
To: owner-ips@ece.cmu.edu
Subject: BOUNCE ips@ece.cmu.edu:    Non-member submission from [Robert Snively <rsnively@brocade.com>]   

From owner-ips@ece.cmu.edu Thu Aug  2 12:34:44 2001
Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f72GYhe11772
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 12:34:44 -0400 (EDT)
Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35])
	by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id JAA02520;
	Thu, 2 Aug 2001 09:34:31 -0700 (PDT)
Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19)
	id <Q12Z7G3Z>; Thu, 2 Aug 2001 09:34:31 -0700
Message-ID: <FFD40DB4943CD411876500508BAD027902993717@sj5-ex2.brocade.com>
From: Robert Snively <rsnively@brocade.com>
To: "'Black_David@emc.com'" <Black_David@emc.com>,
   Robert Snively
	 <rsnively@brocade.com>, ips@ece.cmu.edu
Subject: RE: Security Gateways
Date: Thu, 2 Aug 2001 09:34:28 -0700 
X-Mailer: Internet Mail Service (5.5.2653.19)

David,

As introduction to this phase of our discussion, let me draw
a picture in (gag) ASCII.

  +-  -  -  -  -  -  -  -  -  -  -  -  -  -  -  +  -  -  -  -  -  -  +
     Securely Administered Secure Environment     Public Environment
  |                                             |                    |
     FC  +--------------+   TCP/IP w/o
  |  <-->| FC/FCIP dvc A|<----+ IPSec           |                    |
         +--------------+     |
  |                           |      +--------+ |                    |
     FC  +--------------+     +----->| Secure |     TCP/IP w/ IPSec
  |  <-->| FC/FCIP dvc B|<---------->| Router |<------------>        |
         +--------------+     +----->|        |
  |                           |      +--------+ |                    |
     FC  +--------------+     |
  |  <-->| FC/FCIP dvc C|<----+                 |                    |
         +--------------+
  |                                             |                    |

  +-  -  -  -  -  -  -  -  -  -  -  -  -  -  -  +  -  -  -  -  -  -  +

I believe that the interface provided by FC/FCIP dvc A, B, and C
should be called RFC "FCIP" compliant just as completely as
the public interface from the secure router is called RFC "FCIP"
compliant.  In this environment, the FCIP devices will be routinely
carrying on traffic among themselves without using IPSec, and will
be carrying on traffic with the public environment using
securely protected connections.  The secure protection may be
IPSec as recommended by the RFC "FCIP", but it may also be some
other sort of secure connection.  If there is a performance and
a monetary cost associated with IPSec (which my associates assure
me will be significant for some time in the future), that cost
is paid one time in this picture.  If IPSec was mandatory
to implement for RFC "FCIP" compliance, the financial cost would
be paid three (or maybe four) times in the picture and the
performance cost would be avoided by invoking the optional disabling
of the security feature within the securely administered 
secure environment.

This example will be a common structure in FCIP environments.

The example provides lots of options for various kinds of tradeoffs.
As time goes on, the full integration of security functions in
FCIP chips may increase the percentage of RFC "FCIP" complaint
devices that actually contain the optional to implement IPSec
functions in the FC/FCIP device itself.  At any time, individual
secure interface boxes (IPSec or other) can be attached loosely or 
tightly to those FC/FCIP devices that invoke the option to not install
security internally.  Even the definition of tightly and loosely
connected is an artificial distinction related to how long the 
bolts are and whether adjacent racks constitute tightly coupled
functions.

To meet these requirements, the only solution I can see is to
define the RFC "FCIP" such that security is optional to implement
and optional to use.  While defining the recommended security to
be IPSec, devices that use no security and devices that use
alternative security would also be RFC "FCIP" compliant.  They
of course would list in their manufacturing specifications other 
RFCs that would be supported, typically including TCP, IP, and 
the appropriate IPSec RFCs.

To address the second part of your comments below:

>>  This isn't just "push back"
>>  from the IESG - it is a condition that the IESG required
>>  for its original approval of the IPS WG charter.

The closest wording I can find to that in the charter is:

"  The WG will address at least the following: 

    - Security measures, including authentication and privacy, 
      sufficient to defend against threats up to and including 
      those that can be expected on a public network.

   The WG will address security and congestion control as 
   an integral part of bits protocol encapsulation(s); "

I can find no hint that those security measures are mandatory
to implement for compliance with the RFC "FCIP".  They are
certainly mandatory to specify in the RFC, and we will have done
so with big flashy warnings (or at least as flashy as ASCII
allows) that qualify the security limitations for those operating
in RFC "FCIP" compliant devices that elect not to install
the optional security mechanisms internally.  I believe that
our proposal would meet both the letter and spirit of the charter.

The wording in draft-ietf-ips-framework-00.txt, clause 9, 
similarly recognizes the requirement we see with wording like:

"  A partial solution may be obtained by providing enhanced security 
   services at the interfaces from the existing storage network to the 
   IP storage network. There, services such as encryption and 
   authentication may be applied to the non-physically secure portion 
   of the path, without requiring end-station changes.  
         
   Overall security for such a solution may be no better than that of a 
   SAN presumed to be physically secure, but at least it will not be 
   perceived as worse. 
    
   Link-level security need not be the only solution. In many 
   applications, privacy of data transmission across the network may be 
   less significant an issue than controlling who accesses the storage 
   resources. In such situations, access-control solutions such as the 
   resource login provided by iSCSI can add value."

Note that the FC entities making use of the FCIP entities have
a secure authentication mechanism being proposed as part of the
FC activities.

I hope that we have interpreted the wording and intent correctly,
because if not we should probably modify the charter to allow
the FCIP proposal.

Bob Snively                        e-mail:    rsnively@brocade.com
Brocade Communications Systems     phone:  408 487 8135
1745 Technology Drive
San Jose, CA 95110


-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Wednesday, August 01, 2001 4:42 PM
To: rsnively@brocade.com; ips@ece.cmu.edu
Subject: RE: Security Gateways


Bob,

An RFC does not tell anyone what can or cannot be built;
it specifies what is required for compliance with the RFC.
If someone builds a protocol implementations that doesn't
comply with the requirements of the RFC, they should not
expect to be able to claim RFC compliance for devices 
based on that implementation.

> The marketplace does demand that
> security be possible and available for a device.  

The compliance requirement here is that "possible and
available" be realizable without having to add anything
to the device.  For the structure of interest here,
an FCIP device plus a security gateway, the complete system
[FCIP device, cable, security gateway] would comply with
the FCIP RFC at its external interface (i.e., the external
interface of the security gateway).  The interface between
the FCIP device and the security gateway would be missing
some required security functionality and hence would
not comply with the RFC.  As a result, the FCIP device by
itself would not comply with the RFC.

> I can understand why the IESG would push back on this
> question, but I would expect that they also believe that
> an FCIP device without optional security implemented
> is still an FCIP device and is compliant with the FCIP RFC. 

If "optional" means "MUST implement, but MAY use", that
expectation would be incorrect.  "MUST implement" (cf.
RFC 2119) is the level of requirement for authentication
and cryptographic integrity that is necessary for FCIP
to be approved as an RFC.  This isn't just "push back"
from the IESG - it is a condition that the IESG required
for its original approval of the IPS WG charter.

> With an edge security device installed 
> in front of it, it is also a
> secure FCIP device, just like the end-point of a 
> virtual private network is a secure device. 

That combination will comply with the RFC.  OTOH, the
IESG will not permit the FCIP RFC to allow an FCIP device
that lacks the basic security mechanisms to be compliant,
and hence the FCIP device *without* the edge security
device will not comply.

> By definition, "man in the middle" attacks are impossible
> for a security edge device, since the only place that the
> "man in the middle" can be placed is in the encrypted path.

"By definition" is not the best wording.  Assuming that the
"security edge device" is an IPsec security gateway, the IKE
and ISAKMP  protocols are to negotiate security functionality
and parameters; those protocols are resistant to man-in-the-
middle attacks, but that resistance is based on careful design.

--David


> -----Original Message-----
> From: Robert Snively [mailto:rsnively@brocade.com]
> Sent: Wednesday, August 01, 2001 6:25 PM
> To: 'Black_David@emc.com'; Robert Snively; ips@ece.cmu.edu
> Subject: RE: Security Gateways
> 
> 
> David,
> 
> I believe this is really a very difficult question, not
> susceptible to a simple SHALL/SHALL NOT response.  
> The technology absolutely allows and encourages
> security edge devices and absolutely allows devices using
> TCP and other protocols to exploit those edge devices or
> not as the system administrator requires.  The marketplace
> absolutely demands those capabilities.  A significant percentage
> of the internet economy is based on separately supplied security.
> I understand that the IETF
> has no interest in devices that are solely for closed
> environments, but the marketplace does not demand that
> a device have security built in to qualify for compliance with a
> protocol.  The marketplace does demand that
> security be possible and available for a device.  
> 
> That is what we have been proposing.
> 
> By definition, "man in the middle" attacks are impossible
> for a security edge device, since the only place that the
> "man in the middle" can be placed is in the encrypted path.
> The physically secured path has no possibility of an
> entry point for such an attack.  
> 
> I can understand why the IESG would push back on this
> question, but I would expect that they also believe that
> an FCIP device without optional security implemented
> is still an FCIP device and is compliant with the FCIP RFC. 
> This should be true whether the TCP path is based on IP,
> HIPPI, IB, a proprietary backplane or any other transport 
> that supports TCP. With an edge security device installed 
> in front of it, it is also a
> secure FCIP device, just like the end-point of a 
> virtual private network is a secure device. 
> 
> That is what we would like the RFC to say.
> 
> Bob
> 
> -----Original Message-----
> From: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Wednesday, August 01, 2001 10:13 AM
> To: rsnively@brocade.com; ips@ece.cmu.edu
> Subject: RE: Security Gateways
> 
> 
> Bob,
> 
> You've made a good case for "optional to use", but not
> "optional to implement".  The basic reason is that there
> is no way to ensure that vendors and/or users will
> restrict the use of an implementation that does not
> include security to situations where "paths of a
> storage environment are physically secured and have 
> no requirement for additional security mechanisms".
> Hence security needs to be present so that it
> can be used when FCIP is deployed in an environment
> that requires security.  Further, the IETF has no
> interest in specification of protocols that are
> *solely* for use in the sort of closed environment
> that you describe, and the IPS WG charter contains
> explicit words to that effect.
> 
> Therefore, the basic FCIP security mechanisms MUST be
> implemented, but usage MAY be negotiated.  At the moment,
> "basic security mechanisms" means authentication and
> cryptographic integrity.  Confidentiality can currently
> be optional to implement, but I think it's a very good
> idea to specify the basic confidentiality mechanism
> (*if* confidentiality of any form is implemented, *then*
> <XXX> MUST be implemented).  The design and specification
> of any negotiation mechanism must resist man-in-the-middle
> attacks on negotiation that would result in turning off
> security where that was not the intended outcome - such
> an approach can include restrictions on implementation
> behavior (e.g., if "no authentication" is not acceptable,
> do not offer or accept it during negotiation).
> 
> If the FCIP draft is sent to the IESG without requiring
> implementation of the basic security mechanisms, it will
> be returned to the WG with instructions to correct
> that shortcoming, along with some choice words from the
> ADs wondering how the WG chairs could have overlooked
> something like this.  As a result, an FCIP draft that
> does not require implementation of the basic security
> mechanisms will not be Last Called in the WG until that
> requirement is added.
> 
> Sorry to be blunt, but there is no flexibility on whether
> the basic security mechanisms are mandatory to implement;
> they will be mandatory to implement, period.
> 
> Thanks,
> --David
> 
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------



From owner-ips@ece.cmu.edu  Thu Aug  2 14:34:05 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11878
	for <ips-archive@odin.ietf.org>; Thu, 2 Aug 2001 14:34:04 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f72GDPM10471
	for ips-outgoing; Thu, 2 Aug 2001 12:13:25 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from lucy.trebia.com ([65.192.191.151])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f72GDNe10464
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 12:13:23 -0400 (EDT)
Received: by LUCY with Internet Mail Service (5.5.2653.19)
	id <QASG4L9Y>; Thu, 2 Aug 2001 12:17:40 -0400
Message-ID: <63616B261CEFD411834D00D0B7A86CF7113FF4@LUCY>
From: Sudhir Srinivasan <SudhirS@trebia.com>
To: ips@ece.cmu.edu, "'beepy@netapp.com'" <beepy@netapp.com>
Cc: Sudhir Srinivasan <SudhirS@trebia.com>
Subject: RE: BOUNCE ips@ece.cmu.edu:    Non-member submission from [Brian 
	Pawlowski <beepy@netapp.com>]   
Date: Thu, 2 Aug 2001 12:17:40 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Beepy,

I have been thinking about NFSv4 also, in the context
of this discussion and I believe the analogy is not
particularly relevant for a few reasons:

1. The security holes in NFSv2/3 were much more fundamental
   than on-the-wire security - so the real fix in NFSv4 is the
   introduction of better access control through ACLs
   (a la CIFS). On-the-wire security, IMO doesn't add much
   value to NFSv4 in the most typical deployments (I'm very
   curious to see how many people actually use s/w based
   per-packet security in NFSv4 within the data center or
   office environment). To put some perspective, it is much
   more likely that a security breach will happen via hacks
   into servers rather than people spoofing wires inside a
   data center. So robust access control goes a long way here.

2. The main justification for on-the-wire security in NFSv4
   is, IMO, due to the stated goal of NFSv4 to be the file-access
   mechanism for the (big bad) Internet. The equivalent in
   the IPS world would be FCIP. Bob Snively has made some
   excellent points about the pragmatics of deploying security
   in these situations.

3. The per-packet security mechanism in NFSv4 (RPCSEC_GSS)
   implies NFSv4 vendors have to modify their RPC stacks --
   security cannot be "added on" by users if it's not
   implemented in the RPC stack. So it makes sense to
   mandate implementation.
   In the case of IPS, the security mechanism is quite
   amenable to a deployment using an adjunct device
   or a boundary gateway device (subject to acceptable
   resolution of the keying exchange issues).

It's important to understand that the IPSec discussion is 
different from the access-control aspect of NAS security.


Regards,
Sudhir

> -----Original Message-----
> From: Jim McKinney [mailto:jmck+@ece.cmu.edu]
> Sent: Thursday, August 02, 2001 7:27 AM
> To: ips@ece.cmu.edu
> Subject: Fwd: BOUNCE ips@ece.cmu.edu: Non-member submission 
> from [Brian
> Pawlowski <beepy@netapp.com>] 
> 
> 
> From: Brian Pawlowski <beepy@netapp.com>
> Message-Id: <200108020447.VAA02871@tooting-fe.eng.netapp.com>
> Subject: Re: Security Gateways
> In-Reply-To: <200108020206.f7226He27045@ece.cmu.edu> from Jim 
> McKinney at "Aug 1, 1 10:06:17 pm"
> To: jmck+@ece.cmu.edu (Jim McKinney)
> Date: Wed, 1 Aug 2001 21:47:20 -0700 (PDT)
> Cc: ips@ece.cmu.edu
> X-Mailer: ELM [version 2.4ME++ PL40 (25)]
> MIME-Version: 1.0
> Content-Type: text/plain; charset=US-ASCII
> Content-Transfer-Encoding: 7bit
> 
> > 2)  Concerning market requirements:
> > 
> > A very high percentage of storage environments today manage
> > their configurations very carefully.  Such careful management is
> > necessary to guarantee redundant paths for proper availability,
> > to provide sufficient paths to provide the required 
> performance, and to
> > guarantee known paths to improve reparability and consistency
> > of behavior.  As a side effect, a very high percentage of
> > the paths of a storage environment are physically secured and have
> > no requirement for additional security mechanisms.  
> 
> I've often mused that storage environments today based on FC are
> physically secure as an artifact of the severe deployment restrictions
> that the technology itself supports.
> 
> Replacing FC deployments with TCP/IP-based networks blows these
> assumptions.
> 
> After years in the insecure wilderness within NFS, and the inability
> to count on strong security from all vendors removing a motivation
> to even invest in it (it was optional), the movement in NFS Version 4
> to strong security was a key component of the evolution wrought since
> it was handed to the IETF.
> 
> I look back on our lack of commitment to providing interoperable,
> manadatory to implement (optional to enable) strong security as being
> one of the greatest failures in NFS - that is finally being corrected.
> 
> It is certainly sobering when your PC on your desktop 
> provides stronger
> security guarantees in a simple network when it accesses data on some
> server (CIFS) than you are guaranteed (through mandatory to implement)
> in your enterprise class storage network. 
> 
> beepy
> 
> 


From owner-ips@ece.cmu.edu  Thu Aug  2 14:56:54 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13289
	for <ips-archive@odin.ietf.org>; Thu, 2 Aug 2001 14:56:53 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f72HGji14318
	for ips-outgoing; Thu, 2 Aug 2001 13:16:45 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f72HGie14311
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 13:16:44 -0400 (EDT)
Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <3W0TQGVW>; Thu, 2 Aug 2001 13:16:36 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD55D@CORPMX14>
From: Black_David@emc.com
To: anil.rijhsinghani@mcdata.com, ips@ece.cmu.edu
Subject: RE: Security Gateways
Date: Thu, 2 Aug 2001 13:11:34 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

> I believe the security requirements for FCIP may be somewhat different
> than those for iSCSI.

I believe that's true, but that the most important differences
are in the area of authentication.  FCIP need only concern itself with
"machine" authentication, as FCIP is fundamentally connecting two switches.
iSCSI is more complex and involves a granularity of authentication
finer than "machine" (e.g., one might be authenticating the backup
application to the tape drive as opposed to authenticating the server
on which the backup application is running).

> While it is possible to secure iSCSI end-to-end,
> it's not possible to do so for FCIP because of the fact that Fibre Channel
> itself has no built-in security protocol.

True, but this actually increases the security requirements for FCIP
because there's no higher level security available.

> A user of FC needs to physically
> secure the FC portion of the SAN in any case so the additional physical
> security for the FCIP device, or the wire between it and a sec gateway, is
> much less of an issue.

This looks like violent agreement with what I've written.  A system
consisting
of [FCIP device, cable, security gateway] provides sufficient security to
comply with the RFC requirements at the external interface of the gateway.
In such a system, it is both highly advisable and feasible to physically
secure the (short) cable between the FCIP device and the gateway.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


From owner-ips@ece.cmu.edu  Thu Aug  2 14:57:41 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13334
	for <ips-archive@odin.ietf.org>; Thu, 2 Aug 2001 14:57:41 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f72HnFD16245
	for ips-outgoing; Thu, 2 Aug 2001 13:49:15 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from iol.unh.edu (mars.iol.unh.edu [132.177.121.222])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f72HnDe16241
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 13:49:13 -0400 (EDT)
Received: from localhost (rdr@localhost)
	by iol.unh.edu (8.9.3/8.9.3) with ESMTP id NAA11275;
	Thu, 2 Aug 2001 13:49:08 -0400 (EDT)
Date: Thu, 2 Aug 2001 13:49:08 -0400
From: "Robert D. Russell" <rdr@mars.iol.unh.edu>
To: Julian Satran <Julian_Satran@il.ibm.com>
cc: ips@ece.cmu.edu
Subject: Re: iSCSI: SendTargets in login or FFP?
In-Reply-To: <OF093E2221.6D6528DD-ONC2256A93.00327AC7@telaviv.ibm.com>
Message-ID: <Pine.SGI.4.20.0108021347250.11079-200000@mars.iol.unh.edu>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-2068743714-1923100529-996774548=:11079"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

---2068743714-1923100529-996774548=:11079
Content-Type: TEXT/PLAIN; charset=US-ASCII

Julian:

In order to try to organize information about the key parameters,
I developed the attached ASCII text file which characterizes each
key from draft 7 according to 4 attributes:

1.  what type of key it is, which determines in which login phase
    it can be used.
2.  when the key can be negotiated.
3.  who can send the key.
4.  the scope of application of the key's information.

The values of these attributes were drawn from Appendixes A and D.
The only new information added (i.e., information not in draft 7)
is the characterization of keys into 3 types - security, operational,
and informational, where the new category "informational"
applies to keys, such as TargetAddress, TargetName, InitiatorName,
etc. which can be sent in either the security or operational
subphases of login, and which simply provide information rather
than negotiate values.

There is still a question with regard to the SendTargets key
-- many of the recent postings regarding the use of SendTargets for
discovery sessions indicates that people expect this key to be used
only in Full Feature Phase.  Quoting from Mark Bakke's e-mail of
24-July:

> "Anyway, SendTargets is always done in full feature phase, and
> never during the login phase."

and later in the same message:

> No.  The point of doing SendTarget in full feature phase is that the
> initiators must first go through their normal authentication;
> SendTargets responses will often be based on the initiator's identity.

Is this limitation correct?  Or does this limitation apply only for
discovery sessions?

The draft currently characterizes SendTargets as ALL, which
does not imply this limitation.

If SendTargets is so limited, it would be the only key that could not
be used somewhere during login.  To cover this case in the attached table
I have added the category FFP to the 3 existing categories IO, LO,
and ALL.  Draft 7 would have to be modified to reflect this.

If this limitation is not correct, the category FPP
disappears and the ALL category would continue to apply to SendTargets
(and targest can expect to receive SendTargets during login).

Thanks,

Bob Russell
InterOperability Lab
University of New Hampshire
rdr@iol.unh.edu
603-862-3774



On Tue, 24 Jul 2001, Julian Satran wrote:

> Eddy,
> 
> SendTargets can be used in both discovery session and normal session.
> Would you please clarify when you think this restriction should apply?
> 
> Julo
> 
> "Eddy Quicksall" <EQuicksall@mediaone.net> on 24-07-2001 04:15:56
> 
> Please respond to "Eddy Quicksall" <EQuicksall@mediaone.net>
> 
> To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> cc:
> Subject:  iSCSI: SendTargets in login or FFP?
> 
> 
> 
> 
> The spec says:
> 
>   An initiator can log into this default target [iSCSI]
>   name, and use a command called "SendTargets" to retrieve a list of
>   iSCSI targets that exist at that address
> 
> I assume this means the SendTargets would be used in Full Feature Phase ...
> the initiator would login using TargetName=iSCSI. That would get into FFP
> and then the initiator would use SendTargets= to get the list of targets.
> Then, login again with the appropriate target.
> 
> The spec says:
> 
>   In full feature phase the initiator may send SCSI
>   commands and data to the various LUs on the target by wrapping them
>   in iSCSI PDUs that go over the established iSCSI session.
> 
> That means the target has to do something if a CDB is received to the iSCSI
> canonical target. The spec doesn't give any suggestions here. I am assuming
> the target would give a reject PDU with a reason of "Protocol Error" (code
> 5).
> 
> Do you agree that this is what should happen?
> 
> We shouldn't require that the target enter FFP when it would not be valid
> to
> send a CDB. I think SendTargets should be done only at LO or IO time and
> that iSCSI should not get you into FFP. That would simplify coding.
> 
> 
> Eddy_Quicksall@iVivity.com
> 
> 
> 
> 

---2068743714-1923100529-996774548=:11079
Content-Type: TEXT/plain; name="keys.txt"
Content-ID: <Pine.SGI.4.20.0108021349080.11079@mars.iol.unh.edu>
Content-Description: 
Content-Disposition: attachment; filename="keys.txt"
Content-Transfer-Encoding: BASE64

VGhlcmUgYXJlIDQgYXR0cmlidXRlcyBvciBwcm9wZXJ0aWVzIHRoYXQgY2hh
cmFjdGVyaXplIGVhY2gga2V5Og0KDQoxLiAgVGhlIHR5cGUgb2Yga2V5LCB3
aGljaCBkZXRlcm1pbmVzIGluIHdoaWNoIGxvZ2luIHBoYXNlIGl0IGNhbiBi
ZSB1c2VkOg0KICAgIGEuICBzZWN1cml0eSAtIHNlY3VyaXR5IHBoYXNlIG9u
bHkgLSBBcHBlbmRpeCBBIC0gbXkgbGFiZWwgU0VDDQogICAgYi4gIG9wZXJh
dGlvbmFsIC0gb3BlcmF0aW9uYWwgcGhhc2Ugb25seSAtIEFwcGVuZGl4IEQg
LSBteSBsYWJlbCBPUA0KICAgIGMuICBpbmZvcm1hdGlvbmFsIC0gYm90aCBw
aGFzZXMgLSBBcHBlbmRpeCBEIC0gbXkgbGFiZWwgSU5GTw0KDQoyLiAgV2hl
biB0aGUga2V5IGNhbiBiZSBuZWdvdGlhdGVkOg0KICAgIGEuICBkdXJpbmcg
dGhlIGxlYWRpbmcgbG9naW4gdGhhdCBlc3RhYmxpc2hlcyBhIG5ldyBzZXNz
aW9uIC0gIGxhYmVsIExPDQogICAgYi4gIGR1cmluZyBhbnkgbG9naW4gLSBs
YWJlbCBJTw0KICAgIGMuICBkdXJpbmcgYW55IGxvZ2luIG9yIGR1cmluZyBm
dWxsIGZlYXR1cmUgcGhhc2UgLSBsYWJlbCBBTEwNCiAgICBkLiAgZHVyaW5n
IGZ1bGwgZmVhdHVyZSBwaGFzZSBvbmx5IC0gbXkgbGFiZWwgRkZQDQoNCjMu
ICBXaG8gY2FuIHNlbmQgdGhlIGtleToNCiAgICBhLiAgSW5pdGlhdG9yIG9u
bHkgLSBteSBsYWJlbCBJDQogICAgYi4gIFRhcmdldCBvbmx5IC0gbXkgbGFi
ZWwgVA0KICAgIGMuICBJbml0aWF0b3IgYW5kIFRhcmdldCAtIElUDQoNCjQu
ICBUaGUgc2NvcGUgb2YgYXBwbGljYXRpb24gb2YgdGhlIGtleSdzIGluZm9y
bWF0aW9uOg0KICAgIGEuICBTZXNzaW9uIHNwZWNpZmljIC0gc2Vzc2lvbi13
aWRlIC0gbXkgbGFiZWwgU0VTUw0KICAgIGIuICBDb25uZWN0aW9uIHNwZWNp
ZmljIC0gcGFydGljdWxhciBjb25uZWN0aW9uIG9ubHkgLSBteSBsYWJlbCBD
T05ODQogICAgYy4gIE5vdCByZWxldmFudCAtIG15IGxhYmVsIE5SDQoNClRo
ZSBrZXlzIGRlZmluZWQgaW4gRHJhZnQgMDcgQXBwZW5kaXhlcyBBIGFuZCBE
ICh3aXRoIHNlY3Rpb24gYW5kIHBhZ2UgbnVtYmVycyk6DQoNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEF0dDEgICAgQXR0MiAgICBB
dHQzICAgIEF0dDQNCk5vICBLZXkgICAgICAgICAgICAgICAgICAgICBQYWdl
ICAgIFR5cGUgICAgV2hlbiAgICBXaG8gICAgIFNjb3BlDQotLSAgLS0tICAg
ICAgICAgICAgICAgICAgICAgLS0tLSAgICAtLS0tICAgIC0tLS0gICAgLS0t
LSAgICAtLS0tLQ0KMDEgIEhlYWRlckRpZ2VzdCAgICAgICAgICAgIDEzNSAg
ICAgU0VDICAgICBJTyAgICAgIElUICAgICAgQ09OTg0KMDEgIERhdGFEaWdl
c3QgICAgICAgICAgICAgIDEzNSAgICAgU0VDICAgICBJTyAgICAgIElUICAg
ICAgQ09OTg0KMDEgIEF1dGhNZXRob2QgICAgICAgICAgICAgIDEzNSAgICAg
U0VDICAgICBJTyAgICAgIElUICAgICAgQ09OTg0KMTAgIE1heENvbm5lY3Rp
b25zICAgICAgICAgIDE1NyAgICAgT1AgICAgICBMTyAgICAgIElUICAgICAg
U0VTUw0KDQoxMSAgU2VuZFRhcmdldHMgICAgICAgICAgICAgMTU3ICAgICBJ
TkZPICAgIEZGUCAgICAgSSAgICAgICBOUg0KMTIgIFRhcmdldEFkZHJlc3Mg
ICAgICAgICAgIDE1NyAgICAgSU5GTyAgICBBTEwgICAgIFQgICAgICAgTlIN
CjEzICBUYXJnZXROYW1lICAgICAgICAgICAgICAxNTggICAgIElORk8gICAg
TE8gICAgICBJICAgICAgIE5SDQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIEFMTCAgICAgVA0KMTQgIEluaXRpYXRvck5h
bWUgICAgICAgICAgIDE1OSAgICAgSU5GTyAgICBMTyAgICAgIEkgICAgICAg
TlINCjE1ICBUYXJnZXRBbGlhcyAgICAgICAgICAgICAxNTkgICAgIElORk8g
ICAgQUxMICAgICBUICAgICAgIE5SDQoxNiAgSW5pdGlhdG9yQWxpYXMgICAg
ICAgICAgMTU5ICAgICBJTkZPICAgIEFMTCAgICAgSSAgICAgICBOUg0KMTgg
IEFjY2Vzc0lEICAgICAgICAgICAgICAgIDE2MCAgICAgSU5GTyAgICBBTEwg
ICAgIEkgICAgICAgTlINCg0KMTkgIEZNYXJrZXIgICAgICAgICAgICAgICAg
IDE2MSAgICAgU0VDICAgICBMTyAgICAgIElUICAgICAgQ09OTg0KMjAgIFJG
TWFya0ludCAgICAgICAgICAgICAgIDE2MSAgICAgU0VDICAgICBMTyAgICAg
IElUICAgICAgQ09OTg0KMjEgIFNGTWFya0ludCAgICAgICAgICAgICAgIDE2
MiAgICAgU0VDICAgICBMTyAgICAgIElUICAgICAgQ09OTg0KMjIgIEluaXRp
YWxSMlQgICAgICAgICAgICAgIDE2MiAgICAgT1AgICAgICBBTEwgICAgIElU
ICAgICAgU0VTUw0KDQoyMyAgQmlkaUluaXRpYWxSMlQgICAgICAgICAgMTYy
ICAgICBPUCAgICAgIEFMTCAgICAgSVQgICAgICBTRVNTDQoyNCAgSW1tZWRp
YXRlRGF0YSAgICAgICAgICAgMTYzICAgICBPUCAgICAgIExPICAgICAgSVQg
ICAgICBTRVNTDQoyNSAgRGF0YVBEVUxlbmd0aCAgICAgICAgICAgMTY0ICAg
ICBPUCAgICAgIExPICAgICAgSVQgICAgICBTRVNTDQoyNiAgRmlyc3RCdXJz
dFNpemUgICAgICAgICAgMTY0ICAgICBPUCAgICAgIExPICAgICAgSVQgICAg
ICBTRVNTDQoNCjI3ICBMb2dvdXRMb2dpbk1pblRpbWUgICAgICAxNjUgICAg
IE9QICAgICAgTE8gICAgICBJVCAgICAgIFNFU1MNCjI4ICBMb2dvdXRMb2dp
bk1heFRpbWUgICAgICAxNjUgICAgIE9QICAgICAgTE8gICAgICBJVCAgICAg
IFNFU1MNCjI5ICBNYXhPdXRzdGFuZGluZ1IyVCAgICAgICAxNjUgICAgIE9Q
ICAgICAgTE8gICAgICBJVCAgICAgIFNFU1MNCjMwICBEYXRhT3JkZXIgICAg
ICAgICAgICAgICAxNjUgICAgIE9QICAgICAgTE8gICAgICBJVCAgICAgIFNF
U1MNCg0KMzEgIERhdGFEZWxpdmVyeU9yZGVyICAgICAgIDE2NiAgICAgT1Ag
ICAgICBMTyAgICAgIElUICAgICAgU0VTUw0KMzIgIENvbW1hbmRSZXBsYXlT
dXBwb3J0ICAgIDE2NiAgICAgT1AgICAgICBMTyAgICAgIElUICAgICAgU0VT
Uw0KMzMgIENvbW1hbmRGYWlsb3ZlclN1cHBvcnQgIDE2NyAgICAgT1AgICAg
ICBMTyAgICAgIElUICAgICAgU0VTUw0KMzQgIFNlc3Npb25UeXBlICAgICAg
ICAgICAgIDE2NyAgICAgSU5GTyAgICBMTyAgICAgIEkgICAgICAgU0VTUw0K
DQozNSAgT3BQYXJtUmVzZXQgICAgICAgICAgICAgMTY3ICAgICBPUCAgICAg
IElPICAgICAgSVQgICAgICBDT05ODQozNiAgWC0tLSAgICAgICAgICAgICAg
ICAgICAgMTY4ICAgICBPUCAgICAgIEFMTCAgICAgSVQgICAgICA/DQo=
---2068743714-1923100529-996774548=:11079--


From owner-ips@ece.cmu.edu  Thu Aug  2 17:10:46 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19706
	for <ips-archive@odin.ietf.org>; Thu, 2 Aug 2001 17:10:44 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f72Jvhk23790
	for ips-outgoing; Thu, 2 Aug 2001 15:57:43 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f72Jvge23786
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 15:57:42 -0400 (EDT)
Received: from nc8220exchange.ral.lucent.com (h135-92-100-21.lucent.com [135.92.100.21])
	by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f72Jve116652
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 15:57:40 -0400 (EDT)
content-class: urn:content-classes:message
Subject: First session of IPS will be multicast
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Thu, 2 Aug 2001 15:57:39 -0400
X-Mimeole: Produced By Microsoft Exchange V6.0.4712.0
Message-ID: <9410A0F67DFE7F4D998D453823649836040850@nc8220exchange.ral.lucent.com>
Thread-Topic: First session of IPS will be multicast
Thread-Index: AcEbjUL8tmu/L8O9QRmQToW53E2rtg==
From: "Elizabeth Rodriguez" <egrodriguez@lucent.com>
To: "IPS Mailing List (E-mail)" <ips@ece.cmu.edu>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f72Jvge23787
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit

All,

I know many of you will not be able to attend the meeting next week in
London.
I have been asked about multicast availability of the meetings, and did
now to make sure you were all aware that the first session, 
at 7:30 pm GMT on Monday August 5 will be multicast. 

Information on viewing multicast sessions can be found at
http://www.ietf.org/meetings/multicast_51.html

Thanks,

Elizabeth


From owner-ips@ece.cmu.edu  Thu Aug  2 17:32:50 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22988
	for <ips-archive@odin.ietf.org>; Thu, 2 Aug 2001 17:28:39 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f72HoEv16328
	for ips-outgoing; Thu, 2 Aug 2001 13:50:14 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from ns.strahm.net (sub18-42.member.dsl-only.net [63.105.18.42])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f72HoAe16308
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 13:50:11 -0400 (EDT)
Received: (qmail 28904 invoked by uid 500); 2 Aug 2001 16:20:36 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
  by localhost with SMTP; 2 Aug 2001 16:20:36 -0000
Date: Thu, 2 Aug 2001 09:20:36 -0700 (PDT)
From: Bill Strahm <bill@strahm.net>
To: Mark Winstead <Mark.Winstead@NetOctave.com>
cc: "'Jim McKinney'" <jmck+@ece.cmu.edu>, ips@ece.cmu.edu,
        David Blaker <DBlaker@NetOctave.com>
Subject: RE: Security Gateways
In-Reply-To: <49B96FCC784BC54F9675A6B558C3464E17CFD6@MAIL.NetOctave.com>
Message-ID: <Pine.LNX.4.10.10108020912480.28892-100000@homegate.strahm.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ips@ece.cmu.edu
Precedence: bulk



On Thu, 2 Aug 2001, Mark Winstead wrote:

> On market requirements:
> 
> 1) Curious, what is your basis for the guess of 1% of storage
> environments/paths not being physically secure? While I tend to agree that
> currently this is a low percentage, 1% seems too low. Do you have any hard
> numbers to justify this your guess?
> 
> Large companies and companies experiencing rapid growth often have multiple
> locations across a metropolitan area. Do these companies not have some
> commonly accessible storage facility for at least some of their data? Don't
> other companies have or would like to have workers at multiple locations
> across miles if not hundreds of miles to collaborate, requiring access to
> the same data, not just mirrored (and thus often dated) data?

These links can still be secure links.  For example, I might have multiple
remote offices around the world, each with their own OC-X connection to
the internet.  From there I attach a simple VPN box to the edge of each
connection and guess what, I now have a secure link over the internet
connecting all of my branch offices.

If a company isn't willing to invest in this simple proven technology,
what makes you think that they will care about other security
technologies.  Again, my point isn't to argue against security, but to
place the security arguement where it belongs within security groups that
have the expertise to create a truely secure system. 

I do see that you are talking about physical security, and in this case
the links themselves are not "physically" secure.  However with the
addition of VPN technologies using IPsec/PPTP/etc. I have virtually secure
links between my sites.

 
> 2) Even if the % of paths are in single digits, do you think there won't be
> a paradigm shift?
> 
> With increased capacities for bandwidth (OC-12, 0C-48, faster networks
> switches, et al) coming available, it would seem logical that it will become
> practical for more and more companies to shift data storage facilities to
> lower rent facilities than their office and/or research space, and to
> increase collaboration among workers at multiple locations (or even true
> telecommuters connected through broadband technologies).

Again, do we want to specify multiple layers of security.  Each layer
adding cost and burden to the entire protocol stack.  Right now I can see
us requiring a security solution for IPS, which will go over some
form of TLS, which goes over a end-end security solution, which goes over
a VPN solution, which goes over ...

The end result is that a host may end up being an endpoint for multiple
security subsystems, each requiring additional processing without
providing any additional "true" security (and possibly making security
worse through various problems with the security interactions)
 
> Mark Winstead
> 
> NetOctave, Inc.
> P.O. Box 14824
> RTP, NC 27709
> www.netoctave.com
> 919.463.9903 x328
> mark.winstead@netoctave.com <mailto:mark.winstead@netoctave.com> 
> 
> -----Original Message-----
> From: Jim McKinney [mailto:jmck+@ece.cmu.edu]
> Sent: Wednesday, August 01, 2001 10:06 PM
> To: ips@ece.cmu.edu
> Subject: RE: Security Gateways
> 
> 
> Dear David,
> 
> I would like to address the rather serious question you have
> raised here about both architectural layering and market
> requirements.  After considerable thought, based on the
> explanations below, I have concluded that the FCIP RFC should
> specify that security is optional to implement and optional to use.
> 
> 1)  Concerning architectural layering:
> 
> It is clear that the problems of security are well understood
> within IETF. Numerous solutions have been proposed and
> many of those have become standard implementations.  The most
> successful of those (as an example, IPSec) have used the
> principles of architectural layering very well.  IPSec
> provides a secure mechanism for transporting any IP-based
> protocol if the protocol requires such security.  However,
> the overlaying protocols (as an example, TCP) have no requirement
> to actually make use of IPSec, and in fact have no particular
> requirement to make use of IP.  This is as it should be.
> Each layer is implemented independently of the other.  The
> services that each layer implements depend on the market
> requirements for the environment.  By that logic, it is 
> unnecessary for FCIP to specify any security mechanism at all, 
> since so many security mechanisms are available.  However,
> FCIP has provided the additional guidance that, if security
> in a TCP environment is used, it shall be provided at a layer
> below the TCP interface.  In particular, it recommends the
> use of IPSec for TCP/IP environments (and will recommend the
> appropriate IPSec options).  This additional guidance has nothing
> to do with the architecture or definition of FCIP and is 
> merely a recommendation that should improve interoperability.
> 
> 2)  Concerning market requirements:
> 
> A very high percentage of storage environments today manage
> their configurations very carefully.  Such careful management is
> necessary to guarantee redundant paths for proper availability,
> to provide sufficient paths to provide the required performance, and to
> guarantee known paths to improve reparability and consistency
> of behavior.  As a side effect, a very high percentage of
> the paths of a storage environment are physically secured and have
> no requirement for additional security mechanisms.  At present,
> the only paths that are using security are those very few paths
> that leave one physically secure environment to transport data to
> another physically secure environment.  Those few paths almost universally
> use security mechanisms at a lower level (as an example, a virtual
> private network) to achieve their goals.  As a first guess, such
> paths are well under 1% of the storage paths being used today.
> 
> I do not believe that this paradigm will change significantly over
> the next several years, although of course the percentage of paths
> requiring transport security may rise over 1%.  The requirements for
> storage performance and the desire to maintain the storage devices
> and many of their primary processors in a physically secure
> environment will assure similar configurations.
> 
> In this environment, the market will demand low cost and high
> performance for the great majority of interconnects and will demand
> security for a relatively low percentage of interconnects.  
> 
> What this implies for technologies like FCIP is that security
> be available as a separate option, outside the primary FCIP
> definition.  While still allowing the integration of security
> inside an FCIP unit, the IETF draft for FCIP  must also allow security
> to be provided either not at all or by an outside mechanism.  
> The most common outside mechanism would be a gateway box of some sort.
> In many cases, the gateway box will be a secure router placed on the
> external link and servicing a large number of locally attached
> unsecured FCIP boxes.
> 
> CONCLUSIONS:
> 
> The FCIP draft should continue to specify a security mechanism,
> with IPSec being the appropriate candidate, to guarantee interoperability
> when security is provided.  The FCIP draft should be modified to
> indicate that security is optional to implement and optional to use.
> In addition, it should explicitly indicate that external gateway
> boxes are allowed implementation mechanisms for security.
> 
> As a side question, note that management of storage area networks
> and FCIP boxes is a separate question and is outside the scope of
> the FCIP draft.  Both Fibre Channel and Ethernet management paths
> have security appropriate to the particular management mechanism.
> As an example, web-based management mechanisms use web-based
> security tools. 
> 
> Bob Snively                        e-mail:    rsnively@brocade.com
> Brocade Communications Systems     phone:  408 487 8135
> 1745 Technology Drive
> San Jose, CA 95110
> 
> 
> 
> -----Original Message-----
> From: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Tuesday, July 24, 2001 7:11 PM
> To: ips@ece.cmu.edu
> Subject: Security Gateways
> 
> 
> The following issue was hidden in my long set of
> comments on the -03 version of FCIP:
> 
> > > Delete 12 b).  If an FCIP entity is operating with an external
> > > security gateway, only the interface on the public side of the
> > > gateway is compliant with this specification.  The interface
> > > between the FCIP entity and the gateway is not compliant because
> > > it is lacking required security features - the FCIP entity
> > > *includes* the security gateway in this structure.
> > 
> > Please post this as a separate issue because several of the
> > FCIP Authors believe it is appropriate for FCIP and I cannot
> > represent their opinions.
> 
> The issue is not whether it's "appropriate".  The issue
> is that if an implementation uses an FCIP Entity plus
> an external security gateway, the only interface that
> conforms to the forthcoming RFC is the public/external
> interface on the security gateway.  The interface between
> the FCIP Entity and the security gateway is private
> and fails to conform to the security that will be
> required of all FCIP implementations.
> 
> The above paragraph also applies to iSCSI (substitute iSCSI
> for FCIP in all instances).  Let me also note that iSCSI's
> ability to use a security gateway is not final at this
> juncture.  The spectrum of security possibilities includes
> things like SRP keying of ESP and IPsec transport mode that
> would make external gateways difficult or impossible to use.
> 
> Those who care about being able to use security gateways
> (or think that there's no need to support their use)
> should speak up on the list, in London, and/or in Orange
> County (I would expect the decision not to be made prior
> to Orange County) and *EXPLAIN WHY* [technical rationale].
> 
> Thanks,
> --David
> 
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------
>  
> 



From owner-ips@ece.cmu.edu  Thu Aug  2 18:13:16 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25853
	for <ips-archive@odin.ietf.org>; Thu, 2 Aug 2001 18:13:16 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f72GqOq12856
	for ips-outgoing; Thu, 2 Aug 2001 12:52:24 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f72GqLe12850
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 12:52:21 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id SAA146582
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 18:52:14 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f72GqEW62528
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 18:52:14 +0200
Importance: Normal
Subject: RE: iSCSI: draft 7: iSCSI response and SCSI sense data
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFEDF399E3.AF08B230-ONC2256A9C.0055FA50@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Thu, 2 Aug 2001 19:58:21 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 02/08/2001 19:52:13
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

David,

That's what will probably end-up doing.

Julo

Black_David@emc.com on 02-08-2001 17:21:25

Please respond to Black_David@emc.com

To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: draft 7: iSCSI response and SCSI sense data




> Could you please quote us which part of SAM-2 this is
> violating.

As Rob Elliott said:

> Furthermore, SAM-2 requires that status be ignored when the service
> response indicates an error (SAM-2 revision 18 section 5.1):
>   "Status: A one-byte field containing command completion status
>   (see 5.3). If the command ends with a service response of
>   SERVICE DELIVERY OR TARGET FAILURE, the application client
>   shall consider this parameter to be undefined."
>
> I think iSCSI's current wording may violate this rule.

So, just generate the CHECK CONDITION and don't try to use the
iSCSI Service Response to further qualify it, as Mallikarjun
suggests:

> Robert Elliott pointed out a violation by iSCSI in trying to
> additionally qualify ASC, ASCQ with its response codes.  I suggest
> that dropping this "additional description" attempt in all these
> cases is all iSCSI needs to do to meet SAM's expectations.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------





From owner-ips@ece.cmu.edu  Thu Aug  2 18:17:44 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26106
	for <ips-archive@odin.ietf.org>; Thu, 2 Aug 2001 18:17:39 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f72Hw2w16781
	for ips-outgoing; Thu, 2 Aug 2001 13:58:02 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mxic1.isus.emc.com ([168.159.129.100])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f72Hw0e16776
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 13:58:01 -0400 (EDT)
Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <QCBJF9R2>; Thu, 2 Aug 2001 13:59:55 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD55E@CORPMX14>
From: Black_David@emc.com
To: rsnively@brocade.com, ips@ece.cmu.edu
Subject: RE: Security Gateways
Date: Thu, 2 Aug 2001 13:53:00 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Bob,

We have a failure to communicate here.  I understand what you
want to build and why you want to build it.  The only interface
in your ASCII diagram that will be compliant with the FCIP RFC
is the Public Environment interface of the "Secure Router".  If
you want to build and sell FC/FCIP devices without security,
that's your choice, but they will not comply with the FCIP RFC.
I don't know how many times I need to say this - there appears
to be some part of the word "NO" that you're failing to grasp :-).
The IESG will not approve an RFC that allows a security-free
FCIP device to claim compliance.

Regarding the IPS charter wording on security - I've been in
contact with one of the Transport ADs in the past few hours,
and if the current charter wording isn't sufficiently explicit,
it will be made much more explicit in the revision to the IPS
charter that has to be prepared for the IESG in the near future.
Not only has this been in the charter, but the fact that
authentication and cryptographic integrity will have to be
"MUST implement" has been known since the discussion of this
topic at the IPS meeting in Pittsburgh almost a year ago.

The IPS framework draft was not written by the IESG - a relevant
draft that was written by an IESG member (one of the Security ADs),
is draft-ietf-saag-whyenc-00.txt, which advocates even more
stringent requirements than those currently imposed on FCIP -
confidentiality would become "MUST implement" in the absence
of a very good technical (not market, not cost) explanation
of why it should not be.

Time to get out the "clue by four" ... lengthy expositions of
why (in someone's opinion) the IESG is wrong (about this or any
other issue) are really not an appropriate use for the IPS mailing
list.  This sort of issue should be pursued directly with the
Area Directors and/or the IESG - among the opportunities for
doing so will be the IESG Open Plenary on Wednesday evening in
London.  Keep in mind that the IESG is the final approval
authority for all RFCs, including the ones we write here in IPS.

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------

> -----Original Message-----
> From: Robert Snively [mailto:rsnively@brocade.com]
> Sent: Thursday, August 02, 2001 12:34 PM
> To: 'Black_David@emc.com'; Robert Snively; ips@ece.cmu.edu
> Subject: RE: Security Gateways
> 
> 
> David,
> 
> As introduction to this phase of our discussion, let me draw
> a picture in (gag) ASCII.
> 
>   +-  -  -  -  -  -  -  -  -  -  -  -  -  -  -  +  -  -  -  -  -  -  +
>      Securely Administered Secure Environment     Public Environment
>   |                                             |                    |
>      FC  +--------------+   TCP/IP w/o
>   |  <-->| FC/FCIP dvc A|<----+ IPSec           |                    |
>          +--------------+     |
>   |                           |      +--------+ |                    |
>      FC  +--------------+     +----->| Secure |     TCP/IP w/ IPSec
>   |  <-->| FC/FCIP dvc B|<---------->| Router |<------------>        |
>          +--------------+     +----->|        |
>   |                           |      +--------+ |                    |
>      FC  +--------------+     |
>   |  <-->| FC/FCIP dvc C|<----+                 |                    |
>          +--------------+
>   |                                             |                    |
> 
>   +-  -  -  -  -  -  -  -  -  -  -  -  -  -  -  +  -  -  -  -  -  -  +
> 
> I believe that the interface provided by FC/FCIP dvc A, B, and C
> should be called RFC "FCIP" compliant just as completely as
> the public interface from the secure router is called RFC "FCIP"
> compliant.  In this environment, the FCIP devices will be routinely
> carrying on traffic among themselves without using IPSec, and will
> be carrying on traffic with the public environment using
> securely protected connections.  The secure protection may be
> IPSec as recommended by the RFC "FCIP", but it may also be some
> other sort of secure connection.  If there is a performance and
> a monetary cost associated with IPSec (which my associates assure
> me will be significant for some time in the future), that cost
> is paid one time in this picture.  If IPSec was mandatory
> to implement for RFC "FCIP" compliance, the financial cost would
> be paid three (or maybe four) times in the picture and the
> performance cost would be avoided by invoking the optional disabling
> of the security feature within the securely administered 
> secure environment.
> 
> This example will be a common structure in FCIP environments.
> 
> The example provides lots of options for various kinds of tradeoffs.
> As time goes on, the full integration of security functions in
> FCIP chips may increase the percentage of RFC "FCIP" complaint
> devices that actually contain the optional to implement IPSec
> functions in the FC/FCIP device itself.  At any time, individual
> secure interface boxes (IPSec or other) can be attached loosely or 
> tightly to those FC/FCIP devices that invoke the option to not install
> security internally.  Even the definition of tightly and loosely
> connected is an artificial distinction related to how long the 
> bolts are and whether adjacent racks constitute tightly coupled
> functions.
> 
> To meet these requirements, the only solution I can see is to
> define the RFC "FCIP" such that security is optional to implement
> and optional to use.  While defining the recommended security to
> be IPSec, devices that use no security and devices that use
> alternative security would also be RFC "FCIP" compliant.  They
> of course would list in their manufacturing specifications other 
> RFCs that would be supported, typically including TCP, IP, and 
> the appropriate IPSec RFCs.
> 
> To address the second part of your comments below:
> 
> >>  This isn't just "push back"
> >>  from the IESG - it is a condition that the IESG required
> >>  for its original approval of the IPS WG charter.
> 
> The closest wording I can find to that in the charter is:
> 
> "  The WG will address at least the following: 
> 
>     - Security measures, including authentication and privacy, 
>       sufficient to defend against threats up to and including 
>       those that can be expected on a public network.
> 
>    The WG will address security and congestion control as 
>    an integral part of bits protocol encapsulation(s); "
> 
> I can find no hint that those security measures are mandatory
> to implement for compliance with the RFC "FCIP".  They are
> certainly mandatory to specify in the RFC, and we will have done
> so with big flashy warnings (or at least as flashy as ASCII
> allows) that qualify the security limitations for those operating
> in RFC "FCIP" compliant devices that elect not to install
> the optional security mechanisms internally.  I believe that
> our proposal would meet both the letter and spirit of the charter.
> 
> The wording in draft-ietf-ips-framework-00.txt, clause 9, 
> similarly recognizes the requirement we see with wording like:
> 
> "  A partial solution may be obtained by providing enhanced security 
>    services at the interfaces from the existing storage 
> network to the 
>    IP storage network. There, services such as encryption and 
>    authentication may be applied to the non-physically secure portion 
>    of the path, without requiring end-station changes.  
>          
>    Overall security for such a solution may be no better than 
> that of a 
>    SAN presumed to be physically secure, but at least it will not be 
>    perceived as worse. 
>     
>    Link-level security need not be the only solution. In many 
>    applications, privacy of data transmission across the 
> network may be 
>    less significant an issue than controlling who accesses 
> the storage 
>    resources. In such situations, access-control solutions 
> such as the 
>    resource login provided by iSCSI can add value."
> 
> Note that the FC entities making use of the FCIP entities have
> a secure authentication mechanism being proposed as part of the
> FC activities.
> 
> I hope that we have interpreted the wording and intent correctly,
> because if not we should probably modify the charter to allow
> the FCIP proposal.
> 
> Bob Snively                        e-mail:    rsnively@brocade.com
> Brocade Communications Systems     phone:  408 487 8135
> 1745 Technology Drive
> San Jose, CA 95110
> 
> 
> -----Original Message-----
> From: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Wednesday, August 01, 2001 4:42 PM
> To: rsnively@brocade.com; ips@ece.cmu.edu
> Subject: RE: Security Gateways
> 
> 
> Bob,
> 
> An RFC does not tell anyone what can or cannot be built;
> it specifies what is required for compliance with the RFC.
> If someone builds a protocol implementations that doesn't
> comply with the requirements of the RFC, they should not
> expect to be able to claim RFC compliance for devices 
> based on that implementation.
> 
> > The marketplace does demand that
> > security be possible and available for a device.  
> 
> The compliance requirement here is that "possible and
> available" be realizable without having to add anything
> to the device.  For the structure of interest here,
> an FCIP device plus a security gateway, the complete system
> [FCIP device, cable, security gateway] would comply with
> the FCIP RFC at its external interface (i.e., the external
> interface of the security gateway).  The interface between
> the FCIP device and the security gateway would be missing
> some required security functionality and hence would
> not comply with the RFC.  As a result, the FCIP device by
> itself would not comply with the RFC.
> 
> > I can understand why the IESG would push back on this
> > question, but I would expect that they also believe that
> > an FCIP device without optional security implemented
> > is still an FCIP device and is compliant with the FCIP RFC. 
> 
> If "optional" means "MUST implement, but MAY use", that
> expectation would be incorrect.  "MUST implement" (cf.
> RFC 2119) is the level of requirement for authentication
> and cryptographic integrity that is necessary for FCIP
> to be approved as an RFC.  This isn't just "push back"
> from the IESG - it is a condition that the IESG required
> for its original approval of the IPS WG charter.
> 
> > With an edge security device installed 
> > in front of it, it is also a
> > secure FCIP device, just like the end-point of a 
> > virtual private network is a secure device. 
> 
> That combination will comply with the RFC.  OTOH, the
> IESG will not permit the FCIP RFC to allow an FCIP device
> that lacks the basic security mechanisms to be compliant,
> and hence the FCIP device *without* the edge security
> device will not comply.
> 
> > By definition, "man in the middle" attacks are impossible
> > for a security edge device, since the only place that the
> > "man in the middle" can be placed is in the encrypted path.
> 
> "By definition" is not the best wording.  Assuming that the
> "security edge device" is an IPsec security gateway, the IKE
> and ISAKMP  protocols are to negotiate security functionality
> and parameters; those protocols are resistant to man-in-the-
> middle attacks, but that resistance is based on careful design.
> 
> --David
> 
> 
> > -----Original Message-----
> > From: Robert Snively [mailto:rsnively@brocade.com]
> > Sent: Wednesday, August 01, 2001 6:25 PM
> > To: 'Black_David@emc.com'; Robert Snively; ips@ece.cmu.edu
> > Subject: RE: Security Gateways
> > 
> > 
> > David,
> > 
> > I believe this is really a very difficult question, not
> > susceptible to a simple SHALL/SHALL NOT response.  
> > The technology absolutely allows and encourages
> > security edge devices and absolutely allows devices using
> > TCP and other protocols to exploit those edge devices or
> > not as the system administrator requires.  The marketplace
> > absolutely demands those capabilities.  A significant percentage
> > of the internet economy is based on separately supplied security.
> > I understand that the IETF
> > has no interest in devices that are solely for closed
> > environments, but the marketplace does not demand that
> > a device have security built in to qualify for compliance with a
> > protocol.  The marketplace does demand that
> > security be possible and available for a device.  
> > 
> > That is what we have been proposing.
> > 
> > By definition, "man in the middle" attacks are impossible
> > for a security edge device, since the only place that the
> > "man in the middle" can be placed is in the encrypted path.
> > The physically secured path has no possibility of an
> > entry point for such an attack.  
> > 
> > I can understand why the IESG would push back on this
> > question, but I would expect that they also believe that
> > an FCIP device without optional security implemented
> > is still an FCIP device and is compliant with the FCIP RFC. 
> > This should be true whether the TCP path is based on IP,
> > HIPPI, IB, a proprietary backplane or any other transport 
> > that supports TCP. With an edge security device installed 
> > in front of it, it is also a
> > secure FCIP device, just like the end-point of a 
> > virtual private network is a secure device. 
> > 
> > That is what we would like the RFC to say.
> > 
> > Bob
> > 
> > -----Original Message-----
> > From: Black_David@emc.com [mailto:Black_David@emc.com]
> > Sent: Wednesday, August 01, 2001 10:13 AM
> > To: rsnively@brocade.com; ips@ece.cmu.edu
> > Subject: RE: Security Gateways
> > 
> > 
> > Bob,
> > 
> > You've made a good case for "optional to use", but not
> > "optional to implement".  The basic reason is that there
> > is no way to ensure that vendors and/or users will
> > restrict the use of an implementation that does not
> > include security to situations where "paths of a
> > storage environment are physically secured and have 
> > no requirement for additional security mechanisms".
> > Hence security needs to be present so that it
> > can be used when FCIP is deployed in an environment
> > that requires security.  Further, the IETF has no
> > interest in specification of protocols that are
> > *solely* for use in the sort of closed environment
> > that you describe, and the IPS WG charter contains
> > explicit words to that effect.
> > 
> > Therefore, the basic FCIP security mechanisms MUST be
> > implemented, but usage MAY be negotiated.  At the moment,
> > "basic security mechanisms" means authentication and
> > cryptographic integrity.  Confidentiality can currently
> > be optional to implement, but I think it's a very good
> > idea to specify the basic confidentiality mechanism
> > (*if* confidentiality of any form is implemented, *then*
> > <XXX> MUST be implemented).  The design and specification
> > of any negotiation mechanism must resist man-in-the-middle
> > attacks on negotiation that would result in turning off
> > security where that was not the intended outcome - such
> > an approach can include restrictions on implementation
> > behavior (e.g., if "no authentication" is not acceptable,
> > do not offer or accept it during negotiation).
> > 
> > If the FCIP draft is sent to the IESG without requiring
> > implementation of the basic security mechanisms, it will
> > be returned to the WG with instructions to correct
> > that shortcoming, along with some choice words from the
> > ADs wondering how the WG chairs could have overlooked
> > something like this.  As a result, an FCIP draft that
> > does not require implementation of the basic security
> > mechanisms will not be Last Called in the WG until that
> > requirement is added.
> > 
> > Sorry to be blunt, but there is no flexibility on whether
> > the basic security mechanisms are mandatory to implement;
> > they will be mandatory to implement, period.
> > 
> > Thanks,
> > --David
> > 
> > ---------------------------------------------------
> > David L. Black, Senior Technologist
> > EMC Corporation, 42 South St., Hopkinton, MA  01748
> > +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> > black_david@emc.com       Mobile: +1 (978) 394-7754
> > ---------------------------------------------------
> 


From owner-ips@ece.cmu.edu  Thu Aug  2 18:18:29 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26210
	for <ips-archive@odin.ietf.org>; Thu, 2 Aug 2001 18:18:29 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f72IRqB18686
	for ips-outgoing; Thu, 2 Aug 2001 14:27:52 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from hotmail.com (oe27.law11.hotmail.com [64.4.16.84])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f72IRoe18681
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 14:27:50 -0400 (EDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 2 Aug 2001 11:27:44 -0700
X-Originating-IP: [66.31.75.202]
From: "Eddy Quicksall" <ESQuicksall@hotmail.com>
To: <Black_David@emc.com>, <Julian_Satran@il.ibm.com>, <ips@ece.cmu.edu>
References: <277DD60FB639D511AC0400B0D068B71ECAD554@CORPMX14>
Subject: Re: iSCSI: draft 7: iSCSI response and SCSI sense data
Date: Thu, 2 Aug 2001 14:27:43 -0400
MIME-Version: 1.0
Content-Type: text/plain;	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Message-ID: <OE27niSnRMWuLn5U9T300000b66@hotmail.com>
X-OriginalArrivalTime: 02 Aug 2001 18:27:44.0566 (UTC) FILETIME=[D2926D60:01C11B80]
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Actually, I love layering myself...but this does not really seem to be a
layering issue because it is the iSCSI layer that is having the problem (and
from a ULP point of view, that is part of the target). Why should it not be
able to produce the check condition if the SCSI layer never gets involved.
Not to allow it to produce a check condition would be the same as saying
||SCSI is not allowed to say the same thing (e.g. 44h 00h  INTERNAL TARGET
FAILURE).

--Target Failure - there is a failure of the "target" and that includes the
iSCSI layer.
--Delivery Subsystem Failure - e.g., the "target" can't get to the next
layer
--Unsolicited Data Rejected - this should probably not cause a check
condition because the initiator SCSI layer did not do it ... the initiator
iSCSI layer did it and he should just check the iSCSI response.
--Not enough unsolicited - dito
--SNACK Rejected - dito

For the items that are strictly iSCSI, they should only report iSCSI
response codes and let the initiator iSCSI take care of reporting to the ULP
as it sees fit (or try to recover).

Eddy
----- Original Message -----
From: <Black_David@emc.com>
To: <Julian_Satran@il.ibm.com>; <ips@ece.cmu.edu>
Sent: Thursday, August 02, 2001 10:21 AM
Subject: RE: iSCSI: draft 7: iSCSI response and SCSI sense data


> > Could you please quote us which part of SAM-2 this is
> > violating.
>
> As Rob Elliott said:
>
> > Furthermore, SAM-2 requires that status be ignored when the service
> > response indicates an error (SAM-2 revision 18 section 5.1):
> >   "Status: A one-byte field containing command completion status
> >   (see 5.3). If the command ends with a service response of
> >   SERVICE DELIVERY OR TARGET FAILURE, the application client
> >   shall consider this parameter to be undefined."
> >
> > I think iSCSI's current wording may violate this rule.
>
> So, just generate the CHECK CONDITION and don't try to use the
> iSCSI Service Response to further qualify it, as Mallikarjun
> suggests:
>
> > Robert Elliott pointed out a violation by iSCSI in trying to
> > additionally qualify ASC, ASCQ with its response codes.  I suggest
> > that dropping this "additional description" attempt in all these
> > cases is all iSCSI needs to do to meet SAM's expectations.
>
> Thanks,
> --David
>
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------
>


From owner-ips@ece.cmu.edu  Thu Aug  2 19:18:34 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00319
	for <ips-archive@odin.ietf.org>; Thu, 2 Aug 2001 19:18:34 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f72M4MG00575
	for ips-outgoing; Thu, 2 Aug 2001 18:04:22 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f72M4Le00570
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 18:04:21 -0400 (EDT)
Received: by zmamail05.zma.compaq.com (Postfix, from userid 12345)
	id 6186D65E2; Thu,  2 Aug 2001 18:04:15 -0400 (EDT)
Received: from exchou-gh02.cca.cpqcorp.net (exchou-gh02.cca.cpqcorp.net [16.110.248.202])
	by zmamail05.zma.compaq.com (Postfix) with ESMTP id 1FE50650D
	for <ips@ece.cmu.edu>; Thu,  2 Aug 2001 18:04:15 -0400 (EDT)
Received: by exchou-gh02.cca.cpqcorp.net with Internet Mail Service (5.5.2652.78)
	id <QCJKSPG5>; Thu, 2 Aug 2001 17:04:14 -0500
Message-ID: <78AF3C342AEAEF4BA33B35A8A15668C6014D6915@cceexc17.americas.cpqcorp.net>
From: "Elliott, Robert" <Robert.Elliott@compaq.com>
To: "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
Subject: RE: iSCSI: draft 7: iSCSI response and SCSI sense data
Date: Thu, 2 Aug 2001 17:04:10 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

My view:
If a non-zero response code is present, the Status field is undefined
and the response data contains all information about the error (fed
from the iSCSI layer).

If the target is capable of reporting a Status, then the response
field is zero and the sense data contains all information about the
error (fed from the SCSI layer, which might communicate with the 
iSCSI layer internally to figure out some of the information).

---
Rob Elliott, Compaq Server Storage
Robert.Elliott@compaq.com



> -----Original Message-----
> From: Robert Snively [mailto:rsnively@brocade.com]
> Sent: Thursday, August 02, 2001 4:39 PM
> To: 'cbm@rose.hp.com'; Elliott, Robert
> Cc: 'ips@ece.cmu.edu'
> Subject: RE: iSCSI: draft 7: iSCSI response and SCSI sense data
> 
> 
> I am not sure that complete removal of the response codes 
> is the best approach.  There are some things
> that SCSI devices can know nothing about, and only TCP links
> can know about.  There are other things that iSCSI state machines
> know about that logical units do not know about (usually software
> generated inconsistencies in the protocol procedures).  These are
> natural candidates for response codes.  Note that vendor 
> specific is a synonym for non-interoperable and also for
> undesirable.  It is far better to reserve anything like that,
> since the behavior in the presence of a vendor specific value
> is not defined.  While it is clear that may response codes should
> move over to CHECK CONDITIONS, I think that there are
> still some protocol related response codes that will be required.
> 
> Bob
> 
> -----Original Message-----
> From: Mallikarjun C. [mailto:cbm@rose.hp.com]
> Sent: Wednesday, August 01, 2001 9:06 PM
> To: Elliott, Robert
> Cc: 'ips@ece.cmu.edu'
> Subject: Re: iSCSI: draft 7: iSCSI response and SCSI sense data
> 
> 
> Robert and all,
> 
> As the one who suggested that wording into the draft, let me 
> add some comments. (Please see
> http://www.pdl.cmu.edu/mailinglists/ips/mail/msg05089.html
> for my initial proposal.)
> 
> > I suggest removing the CHECK CONDITION status and additional sense
> > code linkage and leave the SCSI status undefined if the iSCSI
> > response is nonzero.
> 
> I agree, as Steph already alluded to in a separate email, the ideal 
> solution appears to: 
>           a) drop the response code *definitions* (ie. leave
>              room for vendor-unique codes) altogether, and
>           b) continue to specify the right SCSI CHECK CONDITION 
>              (ASC, ASCQ) values for the iSCSI error events (such
>              as digest failures).
> 
> As I said in the earlier referenced message "mandate a standard 
> SCSI CHECK CONDITION on these errors with the current response codes 
> acting as detailed descriptions.".  But you bring up a good point 
> that this "detailed descriptions" may be violating SAM-2's 
> expectations. 
> 
> > Forcing the iSCSI layer to fill in those fields seems to break the
> > layering model.
> 
> I disagree.  If the affected SCSI task can be reliably ascertained
> by the target, it appears highly desirable to report the status 
> using a SCSI CHECK CONDITION.  Target iSCSI layer has to internally
> terminate the pre-instantiated SCSI task anyway informing its SCSI 
> layer of the fact.  Besides, there are precedents in FCP-2 for similar
> cases where the task is identifiable.
> 
> Regards.
> -- 
> Mallikarjun 
> 
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> MS 5668 Hewlett-Packard, Roseville.
> cbm@rose.hp.com
> 
> "Elliott, Robert" wrote:
> > 
> > iSCSI draft 7 section 2.4.3 includes a table relating the iSCSI
> > response codes to various CHECK CONDITION status additional
> > sense codes:
> > 
> >   "0x01 Target Failure
> >     ASC=0x44 ASCQ=0x00 INTERNAL TARGET FAILURE
> >   0x02 Delivery Subsystem Failure
> >     ASC=0x47 ASCQ=0x03 INFORMATION UNIT CRC ERROR DETECTED
> >   0x03 Unsolicited data rejected
> >     ASC=0x49 ASCQ=0x00 INVALID MESSAGE ERROR
> >   0x04 Not enough unsolicited [data]
> >     ASC=0x49 ASCQ=0x00 INVALID MESSAGE ERROR
> >   0x05 SNACK rejected [Command in progress]
> >     ASC=0x47 ASCQ=0x03 INFORMATION UNIT CRC ERROR DETECTED
> > 
> >   As listed above, each defined response code MUST be used 
> (under the
> >   conditions described in the 'Reason' field), only when the
> >   corresponding SCSI CHECK CONDITION is signaled, to convey 
> additional
> >   protocol service information.  A SCSI CHECK CONDITION with the ASC
> >   and ASCQ values as tabulated MUST be signaled by iSCSI targets for
> >   all the instances in this document referring to usage of 
> one of the
> >   above defined response codes."
> > 
> > No other SCSI protocol does this. iSCSI seems to be granting the
> > SCSI-level status a priority over the iSCSI-level response data.
> > I think the other protocols treat the response data as more
> > important; if the response data indicates a problem, the SCSI layer
> > is considered broken and the SCSI status is undefined.
> > 
> > Forcing the iSCSI layer to fill in those fields seems to break the
> > layering model.
> > 
> > I suggest removing the CHECK CONDITION status and additional sense
> > code linkage and leave the SCSI status undefined if the iSCSI
> > response is nonzero.
> > 
> > This is compatible with SAM-2, which only requires status 
> be returned
> > when the service response is TASK COMPLETE (SAM-2 revision 18
> > section 5.3.1):
> >   "Status shall be sent from the logical unit to the application
> >    client whenever a command ends with a service response of
> >    TASK COMPLETE or LINKED COMMAND COMPLETE."
> > 
> > Furthermore, SAM-2 requires that status be ignored when the service
> > response indicates an error (SAM-2 revision 18 section 5.1):
> >   "Status: A one-byte field containing command completion status
> >   (see 5.3). If the command ends with a service response of
> >   SERVICE DELIVERY OR TARGET FAILURE, the application client
> >   shall consider this parameter to be undefined."
> > 
> > I think iSCSI's current wording may violate this rule.
> > ---
> > Rob Elliott, Compaq Server Storage
> > Robert.Elliott@compaq.com
> 


From owner-ips@ece.cmu.edu  Thu Aug  2 20:12:14 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA02955
	for <ips-archive@odin.ietf.org>; Thu, 2 Aug 2001 20:12:14 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f72NZA504194
	for ips-outgoing; Thu, 2 Aug 2001 19:35:10 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f72NZ8e04187
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 19:35:08 -0400 (EDT)
Received: (from sob@localhost)
	by newdev.harvard.edu (8.9.3/8.9.3) id TAA28469;
	Thu, 2 Aug 2001 19:33:02 -0400 (EDT)
Date: Thu, 2 Aug 2001 19:33:02 -0400 (EDT)
From: Scott Bradner <sob@harvard.edu>
Message-Id: <200108022333.TAA28469@newdev.harvard.edu>
To: bill@strahm.net, Black_David@emc.com, ips@ece.cmu.edu
Subject: Re: saag whyenc draft (was RE: Security Gateways)
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

> will talk with Jeff (if I can hunt him down in London)

Jeff will not be in London (his wife is due to have a kid right about now)

Scott


From owner-ips@ece.cmu.edu  Thu Aug  2 20:12:15 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA02967
	for <ips-archive@odin.ietf.org>; Thu, 2 Aug 2001 20:12:15 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f72NHmA03548
	for ips-outgoing; Thu, 2 Aug 2001 19:17:48 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from elmo.ece.cmu.edu (ELMO.ECE.CMU.EDU [128.2.136.21])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f72NHle03543
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 19:17:47 -0400 (EDT)
Date: Thu, 2 Aug 2001 19:17:47 -0400 (EDT)
Message-Id: <200108022317.f72NHle03543@ece.cmu.edu>
From: Jim McKinney <jmck+@ece.cmu.edu>
X-Mailer: BatIMail version 3.2
To: ips@ece.cmu.edu
Subject: Fwd: BOUNCE ips@ece.cmu.edu:    Non-member submission from [Robert Snively <rsnively@brocade.com>]   
References: <200108022142.f72Lg8T29518@ece.cmu.edu>
Mime-Version: 1.0 (generated by tm-edit 1.5)
Content-Type: text/plain; charset=US-ASCII
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


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 f72Lg8T29518;
	Thu, 2 Aug 2001 17:42:08 -0400 (EDT)
Date: Thu, 2 Aug 2001 17:42:08 -0400 (EDT)
From: owner-ips@ece.cmu.edu
Message-Id: <200108022142.f72Lg8T29518@ece.cmu.edu>
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
To: owner-ips@ece.cmu.edu
Subject: BOUNCE ips@ece.cmu.edu:    Non-member submission from [Robert Snively <rsnively@brocade.com>]   

From owner-ips@ece.cmu.edu Thu Aug  2 17:42:06 2001
Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f72Lg6e29513
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 17:42:06 -0400 (EDT)
Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35])
	by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id OAA29006;
	Thu, 2 Aug 2001 14:38:39 -0700 (PDT)
Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19)
	id <Q12Z73MB>; Thu, 2 Aug 2001 14:38:39 -0700
Message-ID: <FFD40DB4943CD411876500508BAD02790299371D@sj5-ex2.brocade.com>
From: Robert Snively <rsnively@brocade.com>
To: "'cbm@rose.hp.com'" <cbm@rose.hp.com>,
   "Elliott, Robert"
	 <Robert.Elliott@compaq.com>
Cc: "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
Subject: RE: iSCSI: draft 7: iSCSI response and SCSI sense data
Date: Thu, 2 Aug 2001 14:38:38 -0700 
X-Mailer: Internet Mail Service (5.5.2653.19)

I am not sure that complete removal of the response codes 
is the best approach.  There are some things
that SCSI devices can know nothing about, and only TCP links
can know about.  There are other things that iSCSI state machines
know about that logical units do not know about (usually software
generated inconsistencies in the protocol procedures).  These are
natural candidates for response codes.  Note that vendor 
specific is a synonym for non-interoperable and also for
undesirable.  It is far better to reserve anything like that,
since the behavior in the presence of a vendor specific value
is not defined.  While it is clear that may response codes should
move over to CHECK CONDITIONS, I think that there are
still some protocol related response codes that will be required.

Bob

-----Original Message-----
From: Mallikarjun C. [mailto:cbm@rose.hp.com]
Sent: Wednesday, August 01, 2001 9:06 PM
To: Elliott, Robert
Cc: 'ips@ece.cmu.edu'
Subject: Re: iSCSI: draft 7: iSCSI response and SCSI sense data


Robert and all,

As the one who suggested that wording into the draft, let me 
add some comments. (Please see
http://www.pdl.cmu.edu/mailinglists/ips/mail/msg05089.html
for my initial proposal.)

> I suggest removing the CHECK CONDITION status and additional sense
> code linkage and leave the SCSI status undefined if the iSCSI
> response is nonzero.

I agree, as Steph already alluded to in a separate email, the ideal 
solution appears to: 
          a) drop the response code *definitions* (ie. leave
             room for vendor-unique codes) altogether, and
          b) continue to specify the right SCSI CHECK CONDITION 
             (ASC, ASCQ) values for the iSCSI error events (such
             as digest failures).

As I said in the earlier referenced message "mandate a standard 
SCSI CHECK CONDITION on these errors with the current response codes 
acting as detailed descriptions.".  But you bring up a good point 
that this "detailed descriptions" may be violating SAM-2's expectations. 

> Forcing the iSCSI layer to fill in those fields seems to break the
> layering model.

I disagree.  If the affected SCSI task can be reliably ascertained
by the target, it appears highly desirable to report the status 
using a SCSI CHECK CONDITION.  Target iSCSI layer has to internally
terminate the pre-instantiated SCSI task anyway informing its SCSI 
layer of the fact.  Besides, there are precedents in FCP-2 for similar
cases where the task is identifiable.

Regards.
-- 
Mallikarjun 

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

"Elliott, Robert" wrote:
> 
> iSCSI draft 7 section 2.4.3 includes a table relating the iSCSI
> response codes to various CHECK CONDITION status additional
> sense codes:
> 
>   "0x01 Target Failure
>     ASC=0x44 ASCQ=0x00 INTERNAL TARGET FAILURE
>   0x02 Delivery Subsystem Failure
>     ASC=0x47 ASCQ=0x03 INFORMATION UNIT CRC ERROR DETECTED
>   0x03 Unsolicited data rejected
>     ASC=0x49 ASCQ=0x00 INVALID MESSAGE ERROR
>   0x04 Not enough unsolicited [data]
>     ASC=0x49 ASCQ=0x00 INVALID MESSAGE ERROR
>   0x05 SNACK rejected [Command in progress]
>     ASC=0x47 ASCQ=0x03 INFORMATION UNIT CRC ERROR DETECTED
> 
>   As listed above, each defined response code MUST be used (under the
>   conditions described in the 'Reason' field), only when the
>   corresponding SCSI CHECK CONDITION is signaled, to convey additional
>   protocol service information.  A SCSI CHECK CONDITION with the ASC
>   and ASCQ values as tabulated MUST be signaled by iSCSI targets for
>   all the instances in this document referring to usage of one of the
>   above defined response codes."
> 
> No other SCSI protocol does this. iSCSI seems to be granting the
> SCSI-level status a priority over the iSCSI-level response data.
> I think the other protocols treat the response data as more
> important; if the response data indicates a problem, the SCSI layer
> is considered broken and the SCSI status is undefined.
> 
> Forcing the iSCSI layer to fill in those fields seems to break the
> layering model.
> 
> I suggest removing the CHECK CONDITION status and additional sense
> code linkage and leave the SCSI status undefined if the iSCSI
> response is nonzero.
> 
> This is compatible with SAM-2, which only requires status be returned
> when the service response is TASK COMPLETE (SAM-2 revision 18
> section 5.3.1):
>   "Status shall be sent from the logical unit to the application
>    client whenever a command ends with a service response of
>    TASK COMPLETE or LINKED COMMAND COMPLETE."
> 
> Furthermore, SAM-2 requires that status be ignored when the service
> response indicates an error (SAM-2 revision 18 section 5.1):
>   "Status: A one-byte field containing command completion status
>   (see 5.3). If the command ends with a service response of
>   SERVICE DELIVERY OR TARGET FAILURE, the application client
>   shall consider this parameter to be undefined."
> 
> I think iSCSI's current wording may violate this rule.
> ---
> Rob Elliott, Compaq Server Storage
> Robert.Elliott@compaq.com



From owner-ips@ece.cmu.edu  Thu Aug  2 20:13:33 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA03039
	for <ips-archive@odin.ietf.org>; Thu, 2 Aug 2001 20:13:33 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f72Nnf804857
	for ips-outgoing; Thu, 2 Aug 2001 19:49:41 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from internaut.com ([64.38.134.99])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f72Nnde04853
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 19:49:39 -0400 (EDT)
Received: from localhost (aboba@localhost)
	by internaut.com (8.9.3/8.9.3) with ESMTP id QAA93568;
	Thu, 2 Aug 2001 16:38:33 -0700 (PDT)
	(envelope-from aboba@internaut.com)
Date: Thu, 2 Aug 2001 16:38:33 -0700 (PDT)
From: Bernard Aboba <aboba@internaut.com>
To: Bill Strahm <bill@strahm.net>
cc: Black_David@emc.com, rsnively@Brocade.COM, ips@ece.cmu.edu
Subject: RE: Security Gateways
In-Reply-To: <Pine.LNX.4.10.10108021350480.29318-100000@homegate.strahm.net>
Message-ID: <Pine.BSF.4.21.0108021629090.93529-100000@internaut.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

> In otherwords if you want to buy a device it
> would not implement security, but there is an option pack that I will sell
> you at cost to implement the additional security protocols.

Time has shown that if security is "mandatory to implement" then security
will be widely available, otherwise it will be (expensive) option. At this
point, given the advent of highly efficient MACs such as UMAC,
cryptographic integrity protection is little more expensive than the CRC
that is already in iSCSI. Therefore there is no valid justification for
ommitting at least this level of security functionality. 

Encryption is another story -- but my understanding is that this is
optional. 

> What I am getting at is cryptography is expensive, especially at multi
> gigabit speeds.  

Integrity protection via new MACs such as UMAC is *not* expensive. This is
a myth. See http://www.cs.ucdavis.edu/~rogaway/umac/perf00.html 

> I would not want to require products to incur this cost
> if the feature wasn't determined to be useful by the end customer who has
> the wallet.  

If the "customer" thinks that CRC-32 is useful, then why not give them a
cryptographic integrity check at minimal additional cost? Not only will
this give them security, but it can also dramatically decrease the
probability of data invalidation. 

> I also want to be careful about products that are multi
> gigabit products, but to be "standards compliant" include a software
> encryption module that runs at 12 Mbit/Sec and is completely useless. 

Since encryption is not required, only integrity protection, and
algorithms are available that can run at the required linerate, this
argument doesn't up.




From owner-ips@ece.cmu.edu  Thu Aug  2 20:16:06 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA03170
	for <ips-archive@odin.ietf.org>; Thu, 2 Aug 2001 20:16:06 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f72NIYk03579
	for ips-outgoing; Thu, 2 Aug 2001 19:18:34 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from elmo.ece.cmu.edu (ELMO.ECE.CMU.EDU [128.2.136.21])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f72NIXe03575
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 19:18:33 -0400 (EDT)
Date: Thu, 2 Aug 2001 19:18:33 -0400 (EDT)
Message-Id: <200108022318.f72NIXe03575@ece.cmu.edu>
From: Jim McKinney <jmck+@ece.cmu.edu>
X-Mailer: BatIMail version 3.2
To: ips@ece.cmu.edu
Subject: RE: Security Gateways
References: <200108022202.f72M2Sp00494@ece.cmu.edu>
Mime-Version: 1.0 (generated by tm-edit 1.5)
Content-Type: text/plain; charset=US-ASCII
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Date: Thu, 2 Aug 2001 18:02:28 -0400 (EDT)
From: owner-ips@ece.cmu.edu
Message-Id: <200108022202.f72M2Sp00494@ece.cmu.edu>
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
To: owner-ips@ece.cmu.edu
Subject: BOUNCE ips@ece.cmu.edu:    Non-member submission from [Robert Snively <rsnively@brocade.com>]   

From owner-ips@ece.cmu.edu Thu Aug  2 18:02:25 2001
Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f72M2Oe00488;
	Thu, 2 Aug 2001 18:02:25 -0400 (EDT)
Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35])
	by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id PAA01023;
	Thu, 2 Aug 2001 15:02:17 -0700 (PDT)
Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19)
	id <Q12Z739A>; Thu, 2 Aug 2001 15:02:16 -0700
Message-ID: <FFD40DB4943CD411876500508BAD02790299371E@sj5-ex2.brocade.com>
From: Robert Snively <rsnively@brocade.com>
To: "'Mark Winstead'" <Mark.Winstead@NetOctave.com>,
   "'Jim McKinney'"
	 <jmck+@ece.cmu.edu>, ips@ece.cmu.edu
Cc: David Blaker <DBlaker@NetOctave.com>
Subject: RE: Security Gateways
Date: Thu, 2 Aug 2001 15:02:15 -0700 
X-Mailer: Internet Mail Service (5.5.2653.19)

My first guess, which is admittedly just a guess, is that

	a)  All SCSI paths are physically secure (the longest
		is less than 25 meters).

	b)  All FC N_Port copper and multi-mode paths are 
		physically secure (the longest is less than 
		500 meters and most are on newly installed
		50 micron cable).

That leaves FCIP-like paths and ATM/SONET paths, which are
available, but still rare in the industry.  That is why my
swag is less than 1%.  The metro SAN interconnects typically
have 2 such connections for each fabric island.  Each fabric
island may have dozens of other physically secured connections.

I believe that there will be a paradigm evolution, but nothing
as dramatic as a paradigm shift.  While more bandwidth will
open among glass-fronted rooms, the bandwidth contained within
the rooms will increase as fast.  The low latency, high 
performance, disciplined centralized management, and physical 
protection of valuable assets will maintain the "physically
secure" to "logically secure" ratios a lot higher than might
otherwise be expected.  Secure communication will certainly be mandated 
among the rooms, but within a glass-fronted room, there does not
seem to be the same compelling reason for security, except as it
applies to system management functions.

For telecommuters, I expect secure access will be mandatory, but
I expect that it will not be at the FCIP or iSCSI level, but 
rather at the file level.

Hope that explains why I feel those numbers are important.

Bob Snively                        e-mail:    rsnively@brocade.com
Brocade Communications Systems     phone:  408 487 8135
1745 Technology Drive
San Jose, CA 95110

-----Original Message-----
From: Mark Winstead [mailto:Mark.Winstead@NetOctave.com]
Sent: Thursday, August 02, 2001 7:27 AM
To: 'Jim McKinney'; ips@ece.cmu.edu
Cc: David Blaker
Subject: RE: Security Gateways


On market requirements:

1) Curious, what is your basis for the guess of 1% of storage
environments/paths not being physically secure? While I tend to agree that
currently this is a low percentage, 1% seems too low. Do you have any hard
numbers to justify this your guess?

Large companies and companies experiencing rapid growth often have multiple
locations across a metropolitan area. Do these companies not have some
commonly accessible storage facility for at least some of their data? Don't
other companies have or would like to have workers at multiple locations
across miles if not hundreds of miles to collaborate, requiring access to
the same data, not just mirrored (and thus often dated) data?

2) Even if the % of paths are in single digits, do you think there won't be
a paradigm shift?

With increased capacities for bandwidth (OC-12, 0C-48, faster networks
switches, et al) coming available, it would seem logical that it will become
practical for more and more companies to shift data storage facilities to
lower rent facilities than their office and/or research space, and to
increase collaboration among workers at multiple locations (or even true
telecommuters connected through broadband technologies).


Mark Winstead

NetOctave, Inc.
P.O. Box 14824
RTP, NC 27709
www.netoctave.com
919.463.9903 x328
mark.winstead@netoctave.com <mailto:mark.winstead@netoctave.com> 

-----Original Message-----
From: Jim McKinney [mailto:jmck+@ece.cmu.edu]
Sent: Wednesday, August 01, 2001 10:06 PM
To: ips@ece.cmu.edu
Subject: RE: Security Gateways


Dear David,

I would like to address the rather serious question you have
raised here about both architectural layering and market
requirements.  After considerable thought, based on the
explanations below, I have concluded that the FCIP RFC should
specify that security is optional to implement and optional to use.

1)  Concerning architectural layering:

It is clear that the problems of security are well understood
within IETF. Numerous solutions have been proposed and
many of those have become standard implementations.  The most
successful of those (as an example, IPSec) have used the
principles of architectural layering very well.  IPSec
provides a secure mechanism for transporting any IP-based
protocol if the protocol requires such security.  However,
the overlaying protocols (as an example, TCP) have no requirement
to actually make use of IPSec, and in fact have no particular
requirement to make use of IP.  This is as it should be.
Each layer is implemented independently of the other.  The
services that each layer implements depend on the market
requirements for the environment.  By that logic, it is 
unnecessary for FCIP to specify any security mechanism at all, 
since so many security mechanisms are available.  However,
FCIP has provided the additional guidance that, if security
in a TCP environment is used, it shall be provided at a layer
below the TCP interface.  In particular, it recommends the
use of IPSec for TCP/IP environments (and will recommend the
appropriate IPSec options).  This additional guidance has nothing
to do with the architecture or definition of FCIP and is 
merely a recommendation that should improve interoperability.

2)  Concerning market requirements:

A very high percentage of storage environments today manage
their configurations very carefully.  Such careful management is
necessary to guarantee redundant paths for proper availability,
to provide sufficient paths to provide the required performance, and to
guarantee known paths to improve reparability and consistency
of behavior.  As a side effect, a very high percentage of
the paths of a storage environment are physically secured and have
no requirement for additional security mechanisms.  At present,
the only paths that are using security are those very few paths
that leave one physically secure environment to transport data to
another physically secure environment.  Those few paths almost universally
use security mechanisms at a lower level (as an example, a virtual
private network) to achieve their goals.  As a first guess, such
paths are well under 1% of the storage paths being used today.

I do not believe that this paradigm will change significantly over
the next several years, although of course the percentage of paths
requiring transport security may rise over 1%.  The requirements for
storage performance and the desire to maintain the storage devices
and many of their primary processors in a physically secure
environment will assure similar configurations.

In this environment, the market will demand low cost and high
performance for the great majority of interconnects and will demand
security for a relatively low percentage of interconnects.  

What this implies for technologies like FCIP is that security
be available as a separate option, outside the primary FCIP
definition.  While still allowing the integration of security
inside an FCIP unit, the IETF draft for FCIP  must also allow security
to be provided either not at all or by an outside mechanism.  
The most common outside mechanism would be a gateway box of some sort.
In many cases, the gateway box will be a secure router placed on the
external link and servicing a large number of locally attached
unsecured FCIP boxes.

CONCLUSIONS:

The FCIP draft should continue to specify a security mechanism,
with IPSec being the appropriate candidate, to guarantee interoperability
when security is provided.  The FCIP draft should be modified to
indicate that security is optional to implement and optional to use.
In addition, it should explicitly indicate that external gateway
boxes are allowed implementation mechanisms for security.

As a side question, note that management of storage area networks
and FCIP boxes is a separate question and is outside the scope of
the FCIP draft.  Both Fibre Channel and Ethernet management paths
have security appropriate to the particular management mechanism.
As an example, web-based management mechanisms use web-based
security tools. 

Bob Snively                        e-mail:    rsnively@brocade.com
Brocade Communications Systems     phone:  408 487 8135
1745 Technology Drive
San Jose, CA 95110



-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Tuesday, July 24, 2001 7:11 PM
To: ips@ece.cmu.edu
Subject: Security Gateways


The following issue was hidden in my long set of
comments on the -03 version of FCIP:

> > Delete 12 b).  If an FCIP entity is operating with an external
> > security gateway, only the interface on the public side of the
> > gateway is compliant with this specification.  The interface
> > between the FCIP entity and the gateway is not compliant because
> > it is lacking required security features - the FCIP entity
> > *includes* the security gateway in this structure.
> 
> Please post this as a separate issue because several of the
> FCIP Authors believe it is appropriate for FCIP and I cannot
> represent their opinions.

The issue is not whether it's "appropriate".  The issue
is that if an implementation uses an FCIP Entity plus
an external security gateway, the only interface that
conforms to the forthcoming RFC is the public/external
interface on the security gateway.  The interface between
the FCIP Entity and the security gateway is private
and fails to conform to the security that will be
required of all FCIP implementations.

The above paragraph also applies to iSCSI (substitute iSCSI
for FCIP in all instances).  Let me also note that iSCSI's
ability to use a security gateway is not final at this
juncture.  The spectrum of security possibilities includes
things like SRP keying of ESP and IPsec transport mode that
would make external gateways difficult or impossible to use.

Those who care about being able to use security gateways
(or think that there's no need to support their use)
should speak up on the list, in London, and/or in Orange
County (I would expect the decision not to be made prior
to Orange County) and *EXPLAIN WHY* [technical rationale].

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------
 



From owner-ips@ece.cmu.edu  Thu Aug  2 20:17:32 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA03246
	for <ips-archive@odin.ietf.org>; Thu, 2 Aug 2001 20:17:32 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f72NFwE03468
	for ips-outgoing; Thu, 2 Aug 2001 19:15:58 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mxic1.isus.emc.com ([168.159.129.100])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f72NFve03464
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 19:15:57 -0400 (EDT)
Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <QCBJGMGY>; Thu, 2 Aug 2001 19:17:52 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD567@CORPMX14>
From: Black_David@emc.com
To: bill@strahm.net, ips@ece.cmu.edu
Subject: saag whyenc draft (was RE: Security Gateways)
Date: Thu, 2 Aug 2001 19:10:55 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Bill,

> I don't see the text in
> http://www.ietf.org/internet-drafts/draft-ietf-saag-whyenc-00.txt

I suggest reading all of Section 6, which has a strong bias towards
requiring "the best security available", and keeping that in mind
when reading the "depends heavily on the application" text in
Section 8.  Are you prepared to argue that data requiring
confidentiality will never or almost never be sent via iSCSI or
FCIP?  That is the line of reasoning that this draft leads to.

> With the final statement being that security must be a MUST IMPLEMENT so
> that users have to option of enabling it when the situation calls for.  I
> will talk with Jeff (if I can hunt him down in London) and determine if
> the meaning of this is to require security in all devices, or if it can be
> an optional cost pack... In other words if you want to buy a device it
> would not implement security, but there is an option pack that I will sell
> you at cost to implement the additional security protocols.

Perhaps I can save you some time.  RFC 2119 says:

1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.

The words "absolute requirement" seem clear and straightforward to me.
Therefore if an RFC says "MUST implement <X>" and <X> exists only in
the optional cost pack, the device without the optional cost pack
does not comply with the requirements of the RFC.  It really is that
simple - any device that complies with the RFC MUST implement
all of the "MUST implement" items.

> What I am getting at is cryptography is expensive, especially at multi
> gigabit speeds.  I would not want to require products to incur this cost
> if the feature wasn't determined to be useful by the end customer who has
> the wallet.

IMHO, this argument is unlikely to go very far.  See the last paragraph
of Section 4 and the last four paragraphs of Section 6 in the whyenc draft.

Regarding computational/implementation expense, AES appear to be the best
that's possible for an encryption algorithm, but there are some new
integrity MACs that are much less expensive to implement than HMAC.
I expect more to be said about this during the Security portion of the
IPS meeting in London on Monday evening.

> I also want to be careful about products that are multi
> gigabit products, but to be "standards compliant" include a software
> encryption module that runs at 12 Mbit/Sec and is completely useless.  I
> would rather have that product without security, so that I KNOW that the
> security isn't there...

OTOH, this argument may have some merit, as I would definitely expect
to see things like this sort of brain-damaged software encryption module
if confidentiality becomes a "MUST implement".  Let me be clear that
this applies only to confidentiality -- a small amount of thought about
the consequences of impersonation and a script kiddie's TCP hijack attack
leads to the conclusion that authentication and cryptographic integrity
have to be "MUST implement" for iSCSI, FCIP, and iFCP.

Let us know the results of your discussion.

Thanks,  --David

> -----Original Message-----
> From: Bill Strahm [mailto:bill@strahm.net]
> Sent: Thursday, August 02, 2001 4:59 PM
> To: Black_David@emc.com
> Cc: rsnively@Brocade.COM; ips@ece.cmu.edu
> Subject: RE: Security Gateways
> 
> 
> I don't see the text in
> http://www.ietf.org/internet-drafts/draft-ietf-saag-whyenc-00.txt
> 
> Infact what I see is
> 8.  Is Encryption a MUST?
> 
>    Not necessarily. However we need to be a bit more precise here.
>    Exactly what security services are appropriate for a given protocol
>    depends heavily on the application it is implementing. Many people
>    assume that encryption means confidentiality. In other words the
>    encryption of the content of protocol messages.
> 
> That being said from the section right above it comes this text
> 
> 7.  MUST is for Implementors
> 
>    We often say that Security is a MUST implement. It is worth noting
>    that there is a significant different between MUST 
> implement and MUST
>    use.
> 
> With the final statement being that security must be a MUST 
> IMPLEMENT so
> that users have to option of enabling it when the situation 
> calls for.  I
> will talk with Jeff (if I can hunt him down in London) and 
> determine if
> the meaning of this is to require security in all devices, or 
> if it can be
> an optional cost pack... In otherwords if you want to buy a device it
> would not implement security, but there is an option pack 
> that I will sell
> you at cost to implement the additional security protocols.
> 
> What I am getting at is cryptography is expensive, especially at multi
> gigabit speeds.  I would not want to require products to 
> incur this cost
> if the feature wasn't determined to be useful by the end 
> customer who has
> the wallet.  I also want to be careful about products that are multi
> gigabit products, but to be "standards compliant" include a software
> encryption module that runs at 12 Mbit/Sec and is completely 
> useless.  I
> would rather have that product without security, so that I 
> KNOW that the
> security isn't there...
> 
> Bill
> 
> 
> On Thu, 2 Aug 2001 Black_David@emc.com wrote:
> 
> > Bob,
> > 
> > We have a failure to communicate here.  I understand what you
> > want to build and why you want to build it.  The only interface
> > in your ASCII diagram that will be compliant with the FCIP RFC
> > is the Public Environment interface of the "Secure Router".  If
> > you want to build and sell FC/FCIP devices without security,
> > that's your choice, but they will not comply with the FCIP RFC.
> > I don't know how many times I need to say this - there appears
> > to be some part of the word "NO" that you're failing to grasp :-).
> > The IESG will not approve an RFC that allows a security-free
> > FCIP device to claim compliance.
> > 
> > Regarding the IPS charter wording on security - I've been in
> > contact with one of the Transport ADs in the past few hours,
> > and if the current charter wording isn't sufficiently explicit,
> > it will be made much more explicit in the revision to the IPS
> > charter that has to be prepared for the IESG in the near future.
> > Not only has this been in the charter, but the fact that
> > authentication and cryptographic integrity will have to be
> > "MUST implement" has been known since the discussion of this
> > topic at the IPS meeting in Pittsburgh almost a year ago.
> > 
> > The IPS framework draft was not written by the IESG - a relevant
> > draft that was written by an IESG member (one of the Security ADs),
> > is draft-ietf-saag-whyenc-00.txt, which advocates even more
> > stringent requirements than those currently imposed on FCIP -
> > confidentiality would become "MUST implement" in the absence
> > of a very good technical (not market, not cost) explanation
> > of why it should not be.
> > 
> > Time to get out the "clue by four" ... lengthy expositions of
> > why (in someone's opinion) the IESG is wrong (about this or any
> > other issue) are really not an appropriate use for the IPS mailing
> > list.  This sort of issue should be pursued directly with the
> > Area Directors and/or the IESG - among the opportunities for
> > doing so will be the IESG Open Plenary on Wednesday evening in
> > London.  Keep in mind that the IESG is the final approval
> > authority for all RFCs, including the ones we write here in IPS.
> > 
> > Thanks,
> > --David
> > ---------------------------------------------------
> > David L. Black, Senior Technologist
> > EMC Corporation, 42 South St., Hopkinton, MA  01748
> > +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> > black_david@emc.com       Mobile: +1 (978) 394-7754
> > ---------------------------------------------------
> > 
> > > -----Original Message-----
> > > From: Robert Snively [mailto:rsnively@brocade.com]
> > > Sent: Thursday, August 02, 2001 12:34 PM
> > > To: 'Black_David@emc.com'; Robert Snively; ips@ece.cmu.edu
> > > Subject: RE: Security Gateways
> > > 
> > > 
> > > David,
> > > 
> > > As introduction to this phase of our discussion, let me draw
> > > a picture in (gag) ASCII.
> > > 
> > >   +-  -  -  -  -  -  -  -  -  -  -  -  -  -  -  +  -  -  
> -  -  -  -  +
> > >      Securely Administered Secure Environment     Public 
> Environment
> > >   |                                             |         
>            |
> > >      FC  +--------------+   TCP/IP w/o
> > >   |  <-->| FC/FCIP dvc A|<----+ IPSec           |         
>            |
> > >          +--------------+     |
> > >   |                           |      +--------+ |         
>            |
> > >      FC  +--------------+     +----->| Secure |     
> TCP/IP w/ IPSec
> > >   |  <-->| FC/FCIP dvc B|<---------->| Router 
> |<------------>        |
> > >          +--------------+     +----->|        |
> > >   |                           |      +--------+ |         
>            |
> > >      FC  +--------------+     |
> > >   |  <-->| FC/FCIP dvc C|<----+                 |         
>            |
> > >          +--------------+
> > >   |                                             |         
>            |
> > > 
> > >   +-  -  -  -  -  -  -  -  -  -  -  -  -  -  -  +  -  -  
> -  -  -  -  +
> > > 
> > > I believe that the interface provided by FC/FCIP dvc A, B, and C
> > > should be called RFC "FCIP" compliant just as completely as
> > > the public interface from the secure router is called RFC "FCIP"
> > > compliant.  In this environment, the FCIP devices will be 
> routinely
> > > carrying on traffic among themselves without using IPSec, and will
> > > be carrying on traffic with the public environment using
> > > securely protected connections.  The secure protection may be
> > > IPSec as recommended by the RFC "FCIP", but it may also be some
> > > other sort of secure connection.  If there is a performance and
> > > a monetary cost associated with IPSec (which my associates assure
> > > me will be significant for some time in the future), that cost
> > > is paid one time in this picture.  If IPSec was mandatory
> > > to implement for RFC "FCIP" compliance, the financial cost would
> > > be paid three (or maybe four) times in the picture and the
> > > performance cost would be avoided by invoking the 
> optional disabling
> > > of the security feature within the securely administered 
> > > secure environment.
> > > 
> > > This example will be a common structure in FCIP environments.
> > > 
> > > The example provides lots of options for various kinds of 
> tradeoffs.
> > > As time goes on, the full integration of security functions in
> > > FCIP chips may increase the percentage of RFC "FCIP" complaint
> > > devices that actually contain the optional to implement IPSec
> > > functions in the FC/FCIP device itself.  At any time, individual
> > > secure interface boxes (IPSec or other) can be attached 
> loosely or 
> > > tightly to those FC/FCIP devices that invoke the option 
> to not install
> > > security internally.  Even the definition of tightly and loosely
> > > connected is an artificial distinction related to how long the 
> > > bolts are and whether adjacent racks constitute tightly coupled
> > > functions.
> > > 
> > > To meet these requirements, the only solution I can see is to
> > > define the RFC "FCIP" such that security is optional to implement
> > > and optional to use.  While defining the recommended security to
> > > be IPSec, devices that use no security and devices that use
> > > alternative security would also be RFC "FCIP" compliant.  They
> > > of course would list in their manufacturing specifications other 
> > > RFCs that would be supported, typically including TCP, IP, and 
> > > the appropriate IPSec RFCs.
> > > 
> > > To address the second part of your comments below:
> > > 
> > > >>  This isn't just "push back"
> > > >>  from the IESG - it is a condition that the IESG required
> > > >>  for its original approval of the IPS WG charter.
> > > 
> > > The closest wording I can find to that in the charter is:
> > > 
> > > "  The WG will address at least the following: 
> > > 
> > >     - Security measures, including authentication and privacy, 
> > >       sufficient to defend against threats up to and including 
> > >       those that can be expected on a public network.
> > > 
> > >    The WG will address security and congestion control as 
> > >    an integral part of bits protocol encapsulation(s); "
> > > 
> > > I can find no hint that those security measures are mandatory
> > > to implement for compliance with the RFC "FCIP".  They are
> > > certainly mandatory to specify in the RFC, and we will have done
> > > so with big flashy warnings (or at least as flashy as ASCII
> > > allows) that qualify the security limitations for those operating
> > > in RFC "FCIP" compliant devices that elect not to install
> > > the optional security mechanisms internally.  I believe that
> > > our proposal would meet both the letter and spirit of the charter.
> > > 
> > > The wording in draft-ietf-ips-framework-00.txt, clause 9, 
> > > similarly recognizes the requirement we see with wording like:
> > > 
> > > "  A partial solution may be obtained by providing 
> enhanced security 
> > >    services at the interfaces from the existing storage 
> > > network to the 
> > >    IP storage network. There, services such as encryption and 
> > >    authentication may be applied to the non-physically 
> secure portion 
> > >    of the path, without requiring end-station changes.  
> > >          
> > >    Overall security for such a solution may be no better than 
> > > that of a 
> > >    SAN presumed to be physically secure, but at least it 
> will not be 
> > >    perceived as worse. 
> > >     
> > >    Link-level security need not be the only solution. In many 
> > >    applications, privacy of data transmission across the 
> > > network may be 
> > >    less significant an issue than controlling who accesses 
> > > the storage 
> > >    resources. In such situations, access-control solutions 
> > > such as the 
> > >    resource login provided by iSCSI can add value."
> > > 
> > > Note that the FC entities making use of the FCIP entities have
> > > a secure authentication mechanism being proposed as part of the
> > > FC activities.
> > > 
> > > I hope that we have interpreted the wording and intent correctly,
> > > because if not we should probably modify the charter to allow
> > > the FCIP proposal.
> > > 
> > > Bob Snively                        e-mail:    rsnively@brocade.com
> > > Brocade Communications Systems     phone:  408 487 8135
> > > 1745 Technology Drive
> > > San Jose, CA 95110
> > > 
> > > 
> > > -----Original Message-----
> > > From: Black_David@emc.com [mailto:Black_David@emc.com]
> > > Sent: Wednesday, August 01, 2001 4:42 PM
> > > To: rsnively@brocade.com; ips@ece.cmu.edu
> > > Subject: RE: Security Gateways
> > > 
> > > 
> > > Bob,
> > > 
> > > An RFC does not tell anyone what can or cannot be built;
> > > it specifies what is required for compliance with the RFC.
> > > If someone builds a protocol implementations that doesn't
> > > comply with the requirements of the RFC, they should not
> > > expect to be able to claim RFC compliance for devices 
> > > based on that implementation.
> > > 
> > > > The marketplace does demand that
> > > > security be possible and available for a device.  
> > > 
> > > The compliance requirement here is that "possible and
> > > available" be realizable without having to add anything
> > > to the device.  For the structure of interest here,
> > > an FCIP device plus a security gateway, the complete system
> > > [FCIP device, cable, security gateway] would comply with
> > > the FCIP RFC at its external interface (i.e., the external
> > > interface of the security gateway).  The interface between
> > > the FCIP device and the security gateway would be missing
> > > some required security functionality and hence would
> > > not comply with the RFC.  As a result, the FCIP device by
> > > itself would not comply with the RFC.
> > > 
> > > > I can understand why the IESG would push back on this
> > > > question, but I would expect that they also believe that
> > > > an FCIP device without optional security implemented
> > > > is still an FCIP device and is compliant with the FCIP RFC. 
> > > 
> > > If "optional" means "MUST implement, but MAY use", that
> > > expectation would be incorrect.  "MUST implement" (cf.
> > > RFC 2119) is the level of requirement for authentication
> > > and cryptographic integrity that is necessary for FCIP
> > > to be approved as an RFC.  This isn't just "push back"
> > > from the IESG - it is a condition that the IESG required
> > > for its original approval of the IPS WG charter.
> > > 
> > > > With an edge security device installed 
> > > > in front of it, it is also a
> > > > secure FCIP device, just like the end-point of a 
> > > > virtual private network is a secure device. 
> > > 
> > > That combination will comply with the RFC.  OTOH, the
> > > IESG will not permit the FCIP RFC to allow an FCIP device
> > > that lacks the basic security mechanisms to be compliant,
> > > and hence the FCIP device *without* the edge security
> > > device will not comply.
> > > 
> > > > By definition, "man in the middle" attacks are impossible
> > > > for a security edge device, since the only place that the
> > > > "man in the middle" can be placed is in the encrypted path.
> > > 
> > > "By definition" is not the best wording.  Assuming that the
> > > "security edge device" is an IPsec security gateway, the IKE
> > > and ISAKMP  protocols are to negotiate security functionality
> > > and parameters; those protocols are resistant to man-in-the-
> > > middle attacks, but that resistance is based on careful design.
> > > 
> > > --David
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Robert Snively [mailto:rsnively@brocade.com]
> > > > Sent: Wednesday, August 01, 2001 6:25 PM
> > > > To: 'Black_David@emc.com'; Robert Snively; ips@ece.cmu.edu
> > > > Subject: RE: Security Gateways
> > > > 
> > > > 
> > > > David,
> > > > 
> > > > I believe this is really a very difficult question, not
> > > > susceptible to a simple SHALL/SHALL NOT response.  
> > > > The technology absolutely allows and encourages
> > > > security edge devices and absolutely allows devices using
> > > > TCP and other protocols to exploit those edge devices or
> > > > not as the system administrator requires.  The marketplace
> > > > absolutely demands those capabilities.  A significant percentage
> > > > of the internet economy is based on separately supplied 
> security.
> > > > I understand that the IETF
> > > > has no interest in devices that are solely for closed
> > > > environments, but the marketplace does not demand that
> > > > a device have security built in to qualify for compliance with a
> > > > protocol.  The marketplace does demand that
> > > > security be possible and available for a device.  
> > > > 
> > > > That is what we have been proposing.
> > > > 
> > > > By definition, "man in the middle" attacks are impossible
> > > > for a security edge device, since the only place that the
> > > > "man in the middle" can be placed is in the encrypted path.
> > > > The physically secured path has no possibility of an
> > > > entry point for such an attack.  
> > > > 
> > > > I can understand why the IESG would push back on this
> > > > question, but I would expect that they also believe that
> > > > an FCIP device without optional security implemented
> > > > is still an FCIP device and is compliant with the FCIP RFC. 
> > > > This should be true whether the TCP path is based on IP,
> > > > HIPPI, IB, a proprietary backplane or any other transport 
> > > > that supports TCP. With an edge security device installed 
> > > > in front of it, it is also a
> > > > secure FCIP device, just like the end-point of a 
> > > > virtual private network is a secure device. 
> > > > 
> > > > That is what we would like the RFC to say.
> > > > 
> > > > Bob
> > > > 
> > > > -----Original Message-----
> > > > From: Black_David@emc.com [mailto:Black_David@emc.com]
> > > > Sent: Wednesday, August 01, 2001 10:13 AM
> > > > To: rsnively@brocade.com; ips@ece.cmu.edu
> > > > Subject: RE: Security Gateways
> > > > 
> > > > 
> > > > Bob,
> > > > 
> > > > You've made a good case for "optional to use", but not
> > > > "optional to implement".  The basic reason is that there
> > > > is no way to ensure that vendors and/or users will
> > > > restrict the use of an implementation that does not
> > > > include security to situations where "paths of a
> > > > storage environment are physically secured and have 
> > > > no requirement for additional security mechanisms".
> > > > Hence security needs to be present so that it
> > > > can be used when FCIP is deployed in an environment
> > > > that requires security.  Further, the IETF has no
> > > > interest in specification of protocols that are
> > > > *solely* for use in the sort of closed environment
> > > > that you describe, and the IPS WG charter contains
> > > > explicit words to that effect.
> > > > 
> > > > Therefore, the basic FCIP security mechanisms MUST be
> > > > implemented, but usage MAY be negotiated.  At the moment,
> > > > "basic security mechanisms" means authentication and
> > > > cryptographic integrity.  Confidentiality can currently
> > > > be optional to implement, but I think it's a very good
> > > > idea to specify the basic confidentiality mechanism
> > > > (*if* confidentiality of any form is implemented, *then*
> > > > <XXX> MUST be implemented).  The design and specification
> > > > of any negotiation mechanism must resist man-in-the-middle
> > > > attacks on negotiation that would result in turning off
> > > > security where that was not the intended outcome - such
> > > > an approach can include restrictions on implementation
> > > > behavior (e.g., if "no authentication" is not acceptable,
> > > > do not offer or accept it during negotiation).
> > > > 
> > > > If the FCIP draft is sent to the IESG without requiring
> > > > implementation of the basic security mechanisms, it will
> > > > be returned to the WG with instructions to correct
> > > > that shortcoming, along with some choice words from the
> > > > ADs wondering how the WG chairs could have overlooked
> > > > something like this.  As a result, an FCIP draft that
> > > > does not require implementation of the basic security
> > > > mechanisms will not be Last Called in the WG until that
> > > > requirement is added.
> > > > 
> > > > Sorry to be blunt, but there is no flexibility on whether
> > > > the basic security mechanisms are mandatory to implement;
> > > > they will be mandatory to implement, period.
> > > > 
> > > > Thanks,
> > > > --David
> > > > 
> > > > ---------------------------------------------------
> > > > David L. Black, Senior Technologist
> > > > EMC Corporation, 42 South St., Hopkinton, MA  01748
> > > > +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> > > > black_david@emc.com       Mobile: +1 (978) 394-7754
> > > > ---------------------------------------------------
> > > 
> > 
> 


From owner-ips@ece.cmu.edu  Thu Aug  2 22:05:30 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA08706
	for <ips-archive@odin.ietf.org>; Thu, 2 Aug 2001 22:05:29 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f72MSD101577
	for ips-outgoing; Thu, 2 Aug 2001 18:28:13 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from ns.strahm.net (sub18-42.member.dsl-only.net [63.105.18.42])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f72MS9e01571
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 18:28:09 -0400 (EDT)
Received: (qmail 29323 invoked by uid 500); 2 Aug 2001 20:58:36 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
  by localhost with SMTP; 2 Aug 2001 20:58:36 -0000
Date: Thu, 2 Aug 2001 13:58:36 -0700 (PDT)
From: Bill Strahm <bill@strahm.net>
To: Black_David@emc.com
cc: rsnively@Brocade.COM, ips@ece.cmu.edu
Subject: RE: Security Gateways
In-Reply-To: <277DD60FB639D511AC0400B0D068B71ECAD55E@CORPMX14>
Message-ID: <Pine.LNX.4.10.10108021350480.29318-100000@homegate.strahm.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

I don't see the text in
http://www.ietf.org/internet-drafts/draft-ietf-saag-whyenc-00.txt

Infact what I see is
8.  Is Encryption a MUST?

   Not necessarily. However we need to be a bit more precise here.
   Exactly what security services are appropriate for a given protocol
   depends heavily on the application it is implementing. Many people
   assume that encryption means confidentiality. In other words the
   encryption of the content of protocol messages.

That being said from the section right above it comes this text

7.  MUST is for Implementors

   We often say that Security is a MUST implement. It is worth noting
   that there is a significant different between MUST implement and MUST
   use.

With the final statement being that security must be a MUST IMPLEMENT so
that users have to option of enabling it when the situation calls for.  I
will talk with Jeff (if I can hunt him down in London) and determine if
the meaning of this is to require security in all devices, or if it can be
an optional cost pack... In otherwords if you want to buy a device it
would not implement security, but there is an option pack that I will sell
you at cost to implement the additional security protocols.

What I am getting at is cryptography is expensive, especially at multi
gigabit speeds.  I would not want to require products to incur this cost
if the feature wasn't determined to be useful by the end customer who has
the wallet.  I also want to be careful about products that are multi
gigabit products, but to be "standards compliant" include a software
encryption module that runs at 12 Mbit/Sec and is completely useless.  I
would rather have that product without security, so that I KNOW that the
security isn't there...

Bill


On Thu, 2 Aug 2001 Black_David@emc.com wrote:

> Bob,
> 
> We have a failure to communicate here.  I understand what you
> want to build and why you want to build it.  The only interface
> in your ASCII diagram that will be compliant with the FCIP RFC
> is the Public Environment interface of the "Secure Router".  If
> you want to build and sell FC/FCIP devices without security,
> that's your choice, but they will not comply with the FCIP RFC.
> I don't know how many times I need to say this - there appears
> to be some part of the word "NO" that you're failing to grasp :-).
> The IESG will not approve an RFC that allows a security-free
> FCIP device to claim compliance.
> 
> Regarding the IPS charter wording on security - I've been in
> contact with one of the Transport ADs in the past few hours,
> and if the current charter wording isn't sufficiently explicit,
> it will be made much more explicit in the revision to the IPS
> charter that has to be prepared for the IESG in the near future.
> Not only has this been in the charter, but the fact that
> authentication and cryptographic integrity will have to be
> "MUST implement" has been known since the discussion of this
> topic at the IPS meeting in Pittsburgh almost a year ago.
> 
> The IPS framework draft was not written by the IESG - a relevant
> draft that was written by an IESG member (one of the Security ADs),
> is draft-ietf-saag-whyenc-00.txt, which advocates even more
> stringent requirements than those currently imposed on FCIP -
> confidentiality would become "MUST implement" in the absence
> of a very good technical (not market, not cost) explanation
> of why it should not be.
> 
> Time to get out the "clue by four" ... lengthy expositions of
> why (in someone's opinion) the IESG is wrong (about this or any
> other issue) are really not an appropriate use for the IPS mailing
> list.  This sort of issue should be pursued directly with the
> Area Directors and/or the IESG - among the opportunities for
> doing so will be the IESG Open Plenary on Wednesday evening in
> London.  Keep in mind that the IESG is the final approval
> authority for all RFCs, including the ones we write here in IPS.
> 
> Thanks,
> --David
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------
> 
> > -----Original Message-----
> > From: Robert Snively [mailto:rsnively@brocade.com]
> > Sent: Thursday, August 02, 2001 12:34 PM
> > To: 'Black_David@emc.com'; Robert Snively; ips@ece.cmu.edu
> > Subject: RE: Security Gateways
> > 
> > 
> > David,
> > 
> > As introduction to this phase of our discussion, let me draw
> > a picture in (gag) ASCII.
> > 
> >   +-  -  -  -  -  -  -  -  -  -  -  -  -  -  -  +  -  -  -  -  -  -  +
> >      Securely Administered Secure Environment     Public Environment
> >   |                                             |                    |
> >      FC  +--------------+   TCP/IP w/o
> >   |  <-->| FC/FCIP dvc A|<----+ IPSec           |                    |
> >          +--------------+     |
> >   |                           |      +--------+ |                    |
> >      FC  +--------------+     +----->| Secure |     TCP/IP w/ IPSec
> >   |  <-->| FC/FCIP dvc B|<---------->| Router |<------------>        |
> >          +--------------+     +----->|        |
> >   |                           |      +--------+ |                    |
> >      FC  +--------------+     |
> >   |  <-->| FC/FCIP dvc C|<----+                 |                    |
> >          +--------------+
> >   |                                             |                    |
> > 
> >   +-  -  -  -  -  -  -  -  -  -  -  -  -  -  -  +  -  -  -  -  -  -  +
> > 
> > I believe that the interface provided by FC/FCIP dvc A, B, and C
> > should be called RFC "FCIP" compliant just as completely as
> > the public interface from the secure router is called RFC "FCIP"
> > compliant.  In this environment, the FCIP devices will be routinely
> > carrying on traffic among themselves without using IPSec, and will
> > be carrying on traffic with the public environment using
> > securely protected connections.  The secure protection may be
> > IPSec as recommended by the RFC "FCIP", but it may also be some
> > other sort of secure connection.  If there is a performance and
> > a monetary cost associated with IPSec (which my associates assure
> > me will be significant for some time in the future), that cost
> > is paid one time in this picture.  If IPSec was mandatory
> > to implement for RFC "FCIP" compliance, the financial cost would
> > be paid three (or maybe four) times in the picture and the
> > performance cost would be avoided by invoking the optional disabling
> > of the security feature within the securely administered 
> > secure environment.
> > 
> > This example will be a common structure in FCIP environments.
> > 
> > The example provides lots of options for various kinds of tradeoffs.
> > As time goes on, the full integration of security functions in
> > FCIP chips may increase the percentage of RFC "FCIP" complaint
> > devices that actually contain the optional to implement IPSec
> > functions in the FC/FCIP device itself.  At any time, individual
> > secure interface boxes (IPSec or other) can be attached loosely or 
> > tightly to those FC/FCIP devices that invoke the option to not install
> > security internally.  Even the definition of tightly and loosely
> > connected is an artificial distinction related to how long the 
> > bolts are and whether adjacent racks constitute tightly coupled
> > functions.
> > 
> > To meet these requirements, the only solution I can see is to
> > define the RFC "FCIP" such that security is optional to implement
> > and optional to use.  While defining the recommended security to
> > be IPSec, devices that use no security and devices that use
> > alternative security would also be RFC "FCIP" compliant.  They
> > of course would list in their manufacturing specifications other 
> > RFCs that would be supported, typically including TCP, IP, and 
> > the appropriate IPSec RFCs.
> > 
> > To address the second part of your comments below:
> > 
> > >>  This isn't just "push back"
> > >>  from the IESG - it is a condition that the IESG required
> > >>  for its original approval of the IPS WG charter.
> > 
> > The closest wording I can find to that in the charter is:
> > 
> > "  The WG will address at least the following: 
> > 
> >     - Security measures, including authentication and privacy, 
> >       sufficient to defend against threats up to and including 
> >       those that can be expected on a public network.
> > 
> >    The WG will address security and congestion control as 
> >    an integral part of bits protocol encapsulation(s); "
> > 
> > I can find no hint that those security measures are mandatory
> > to implement for compliance with the RFC "FCIP".  They are
> > certainly mandatory to specify in the RFC, and we will have done
> > so with big flashy warnings (or at least as flashy as ASCII
> > allows) that qualify the security limitations for those operating
> > in RFC "FCIP" compliant devices that elect not to install
> > the optional security mechanisms internally.  I believe that
> > our proposal would meet both the letter and spirit of the charter.
> > 
> > The wording in draft-ietf-ips-framework-00.txt, clause 9, 
> > similarly recognizes the requirement we see with wording like:
> > 
> > "  A partial solution may be obtained by providing enhanced security 
> >    services at the interfaces from the existing storage 
> > network to the 
> >    IP storage network. There, services such as encryption and 
> >    authentication may be applied to the non-physically secure portion 
> >    of the path, without requiring end-station changes.  
> >          
> >    Overall security for such a solution may be no better than 
> > that of a 
> >    SAN presumed to be physically secure, but at least it will not be 
> >    perceived as worse. 
> >     
> >    Link-level security need not be the only solution. In many 
> >    applications, privacy of data transmission across the 
> > network may be 
> >    less significant an issue than controlling who accesses 
> > the storage 
> >    resources. In such situations, access-control solutions 
> > such as the 
> >    resource login provided by iSCSI can add value."
> > 
> > Note that the FC entities making use of the FCIP entities have
> > a secure authentication mechanism being proposed as part of the
> > FC activities.
> > 
> > I hope that we have interpreted the wording and intent correctly,
> > because if not we should probably modify the charter to allow
> > the FCIP proposal.
> > 
> > Bob Snively                        e-mail:    rsnively@brocade.com
> > Brocade Communications Systems     phone:  408 487 8135
> > 1745 Technology Drive
> > San Jose, CA 95110
> > 
> > 
> > -----Original Message-----
> > From: Black_David@emc.com [mailto:Black_David@emc.com]
> > Sent: Wednesday, August 01, 2001 4:42 PM
> > To: rsnively@brocade.com; ips@ece.cmu.edu
> > Subject: RE: Security Gateways
> > 
> > 
> > Bob,
> > 
> > An RFC does not tell anyone what can or cannot be built;
> > it specifies what is required for compliance with the RFC.
> > If someone builds a protocol implementations that doesn't
> > comply with the requirements of the RFC, they should not
> > expect to be able to claim RFC compliance for devices 
> > based on that implementation.
> > 
> > > The marketplace does demand that
> > > security be possible and available for a device.  
> > 
> > The compliance requirement here is that "possible and
> > available" be realizable without having to add anything
> > to the device.  For the structure of interest here,
> > an FCIP device plus a security gateway, the complete system
> > [FCIP device, cable, security gateway] would comply with
> > the FCIP RFC at its external interface (i.e., the external
> > interface of the security gateway).  The interface between
> > the FCIP device and the security gateway would be missing
> > some required security functionality and hence would
> > not comply with the RFC.  As a result, the FCIP device by
> > itself would not comply with the RFC.
> > 
> > > I can understand why the IESG would push back on this
> > > question, but I would expect that they also believe that
> > > an FCIP device without optional security implemented
> > > is still an FCIP device and is compliant with the FCIP RFC. 
> > 
> > If "optional" means "MUST implement, but MAY use", that
> > expectation would be incorrect.  "MUST implement" (cf.
> > RFC 2119) is the level of requirement for authentication
> > and cryptographic integrity that is necessary for FCIP
> > to be approved as an RFC.  This isn't just "push back"
> > from the IESG - it is a condition that the IESG required
> > for its original approval of the IPS WG charter.
> > 
> > > With an edge security device installed 
> > > in front of it, it is also a
> > > secure FCIP device, just like the end-point of a 
> > > virtual private network is a secure device. 
> > 
> > That combination will comply with the RFC.  OTOH, the
> > IESG will not permit the FCIP RFC to allow an FCIP device
> > that lacks the basic security mechanisms to be compliant,
> > and hence the FCIP device *without* the edge security
> > device will not comply.
> > 
> > > By definition, "man in the middle" attacks are impossible
> > > for a security edge device, since the only place that the
> > > "man in the middle" can be placed is in the encrypted path.
> > 
> > "By definition" is not the best wording.  Assuming that the
> > "security edge device" is an IPsec security gateway, the IKE
> > and ISAKMP  protocols are to negotiate security functionality
> > and parameters; those protocols are resistant to man-in-the-
> > middle attacks, but that resistance is based on careful design.
> > 
> > --David
> > 
> > 
> > > -----Original Message-----
> > > From: Robert Snively [mailto:rsnively@brocade.com]
> > > Sent: Wednesday, August 01, 2001 6:25 PM
> > > To: 'Black_David@emc.com'; Robert Snively; ips@ece.cmu.edu
> > > Subject: RE: Security Gateways
> > > 
> > > 
> > > David,
> > > 
> > > I believe this is really a very difficult question, not
> > > susceptible to a simple SHALL/SHALL NOT response.  
> > > The technology absolutely allows and encourages
> > > security edge devices and absolutely allows devices using
> > > TCP and other protocols to exploit those edge devices or
> > > not as the system administrator requires.  The marketplace
> > > absolutely demands those capabilities.  A significant percentage
> > > of the internet economy is based on separately supplied security.
> > > I understand that the IETF
> > > has no interest in devices that are solely for closed
> > > environments, but the marketplace does not demand that
> > > a device have security built in to qualify for compliance with a
> > > protocol.  The marketplace does demand that
> > > security be possible and available for a device.  
> > > 
> > > That is what we have been proposing.
> > > 
> > > By definition, "man in the middle" attacks are impossible
> > > for a security edge device, since the only place that the
> > > "man in the middle" can be placed is in the encrypted path.
> > > The physically secured path has no possibility of an
> > > entry point for such an attack.  
> > > 
> > > I can understand why the IESG would push back on this
> > > question, but I would expect that they also believe that
> > > an FCIP device without optional security implemented
> > > is still an FCIP device and is compliant with the FCIP RFC. 
> > > This should be true whether the TCP path is based on IP,
> > > HIPPI, IB, a proprietary backplane or any other transport 
> > > that supports TCP. With an edge security device installed 
> > > in front of it, it is also a
> > > secure FCIP device, just like the end-point of a 
> > > virtual private network is a secure device. 
> > > 
> > > That is what we would like the RFC to say.
> > > 
> > > Bob
> > > 
> > > -----Original Message-----
> > > From: Black_David@emc.com [mailto:Black_David@emc.com]
> > > Sent: Wednesday, August 01, 2001 10:13 AM
> > > To: rsnively@brocade.com; ips@ece.cmu.edu
> > > Subject: RE: Security Gateways
> > > 
> > > 
> > > Bob,
> > > 
> > > You've made a good case for "optional to use", but not
> > > "optional to implement".  The basic reason is that there
> > > is no way to ensure that vendors and/or users will
> > > restrict the use of an implementation that does not
> > > include security to situations where "paths of a
> > > storage environment are physically secured and have 
> > > no requirement for additional security mechanisms".
> > > Hence security needs to be present so that it
> > > can be used when FCIP is deployed in an environment
> > > that requires security.  Further, the IETF has no
> > > interest in specification of protocols that are
> > > *solely* for use in the sort of closed environment
> > > that you describe, and the IPS WG charter contains
> > > explicit words to that effect.
> > > 
> > > Therefore, the basic FCIP security mechanisms MUST be
> > > implemented, but usage MAY be negotiated.  At the moment,
> > > "basic security mechanisms" means authentication and
> > > cryptographic integrity.  Confidentiality can currently
> > > be optional to implement, but I think it's a very good
> > > idea to specify the basic confidentiality mechanism
> > > (*if* confidentiality of any form is implemented, *then*
> > > <XXX> MUST be implemented).  The design and specification
> > > of any negotiation mechanism must resist man-in-the-middle
> > > attacks on negotiation that would result in turning off
> > > security where that was not the intended outcome - such
> > > an approach can include restrictions on implementation
> > > behavior (e.g., if "no authentication" is not acceptable,
> > > do not offer or accept it during negotiation).
> > > 
> > > If the FCIP draft is sent to the IESG without requiring
> > > implementation of the basic security mechanisms, it will
> > > be returned to the WG with instructions to correct
> > > that shortcoming, along with some choice words from the
> > > ADs wondering how the WG chairs could have overlooked
> > > something like this.  As a result, an FCIP draft that
> > > does not require implementation of the basic security
> > > mechanisms will not be Last Called in the WG until that
> > > requirement is added.
> > > 
> > > Sorry to be blunt, but there is no flexibility on whether
> > > the basic security mechanisms are mandatory to implement;
> > > they will be mandatory to implement, period.
> > > 
> > > Thanks,
> > > --David
> > > 
> > > ---------------------------------------------------
> > > David L. Black, Senior Technologist
> > > EMC Corporation, 42 South St., Hopkinton, MA  01748
> > > +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> > > black_david@emc.com       Mobile: +1 (978) 394-7754
> > > ---------------------------------------------------
> > 
> 



From owner-ips@ece.cmu.edu  Fri Aug  3 06:09:07 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA11802
	for <ips-archive@odin.ietf.org>; Fri, 3 Aug 2001 06:09:07 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f739VqP25947
	for ips-outgoing; Fri, 3 Aug 2001 05:31:52 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7329ve10178
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 22:09:58 -0400 (EDT)
Received: from postoffice.sarnoff.com ([127.0.0.1]) by
          postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
          SMTP id GHGZ8R00.EE9 for <ips@ece.cmu.edu>; Thu, 2 Aug 2001
          22:07:39 -0400 
Received: from nova.sarnoff.com ([130.33.8.27]) by
          postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
          ESMTP id GH5UTG00.AJ5; Fri, 27 Jul 2001 21:58:28 -0400 
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
	by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id HAA08330;
	Tue, 24 Jul 2001 07:44:23 -0400 (EDT)
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA13645
	for ietf-123-outbound.05@ietf.org; Tue, 24 Jul 2001 07:25:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA12598
	for <all-ietf@loki.ietf.org>; Tue, 24 Jul 2001 06:29:13 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05842;
	Tue, 24 Jul 2001 06:29:13 -0400 (EDT)
Message-Id: <200107241029.GAA05842@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ips@ece.cmu.edu
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ips-iscsi-07.txt
Date: Tue, 24 Jul 2001 06:29:13 -0400
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Storage Working Group of the IETF.

	Title		: iSCSI
	Author(s)	: J. Satran et al.
	Filename	: draft-ietf-ips-iscsi-07.txt
	Pages		: 187
	Date		: 23-Jul-01
	
The Small Computer Systems Interface (SCSI) is a popular family of 
protocols for communicating with I/O devices, especially storage 
devices.  This memo describes a transport protocol for SCSI that 
operates on top of TCP.  The iSCSI protocol aims to be fully 
compliant with the requirements laid out in the SCSI Architecture 
Model - 2 [SAM2] document.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-07.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ips-iscsi-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ips-iscsi-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010723140355.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ips-iscsi-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ips-iscsi-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010723140355.I-D@ietf.org>

--OtherAccess--

--NextPart--



From owner-ips@ece.cmu.edu  Fri Aug  3 06:10:39 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA11839
	for <ips-archive@odin.ietf.org>; Fri, 3 Aug 2001 06:10:38 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f739VhP25938
	for ips-outgoing; Fri, 3 Aug 2001 05:31:43 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7329ve10170
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 22:09:57 -0400 (EDT)
Received: from postoffice.sarnoff.com ([127.0.0.1]) by
          postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
          SMTP id GHGYZA00.DDW for <ips@ece.cmu.edu>; Thu, 2 Aug 2001
          22:01:58 -0400 
Received: from nova.sarnoff.com ([130.33.8.27]) by
          postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
          ESMTP id GH5PIY00.UCW; Fri, 27 Jul 2001 20:04:10 -0400 
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
	by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id IAA25799;
	Wed, 25 Jul 2001 08:01:03 -0400 (EDT)
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA26299
	for ietf-123-outbound.05@ietf.org; Wed, 25 Jul 2001 07:35:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA25413
	for <all-ietf@loki.ietf.org>; Wed, 25 Jul 2001 06:31:53 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07322;
	Wed, 25 Jul 2001 06:31:52 -0400 (EDT)
Message-Id: <200107251031.GAA07322@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ips@ece.cmu.edu
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ips-iscsi-slp-01.txt
Date: Wed, 25 Jul 2001 06:31:51 -0400
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Storage Working Group of the IETF.

	Title		: Finding iSCSI Targets and Name Servers Using SLP
	Author(s)	: M. Bakke et al.
	Filename	: draft-ietf-ips-iscsi-slp-01.txt
	Pages		: 17
	Date		: 24-Jul-01
	
The iSCSI protocol provides a way for hosts to access SCSI devices
over an IP network.  This document defines the use of the Service
Location Protocol (SLP) by iSCSI hosts, devices, and name services,
along with the SLP service type templates that describe the services   they provide.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-slp-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ips-iscsi-slp-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ips-iscsi-slp-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010724132056.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ips-iscsi-slp-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ips-iscsi-slp-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010724132056.I-D@ietf.org>

--OtherAccess--

--NextPart--



From owner-ips@ece.cmu.edu  Fri Aug  3 06:10:40 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA11851
	for <ips-archive@odin.ietf.org>; Fri, 3 Aug 2001 06:10:40 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f739VXX25926
	for ips-outgoing; Fri, 3 Aug 2001 05:31:33 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7329ue10161
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 22:09:56 -0400 (EDT)
Received: from postoffice.sarnoff.com ([127.0.0.1]) by
          postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
          SMTP id GHGYI100.RCE for <ips@ece.cmu.edu>; Thu, 2 Aug 2001
          21:51:37 -0400 
Received: from nova.sarnoff.com ([130.33.8.27]) by
          postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
          ESMTP id GH5D0K00.S1Q; Fri, 27 Jul 2001 15:33:56 -0400 
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
	by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id JAA01333;
	Fri, 27 Jul 2001 09:53:00 -0400 (EDT)
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA14865
	for ietf-123-outbound.05@ietf.org; Fri, 27 Jul 2001 09:35:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA12899
	for <all-ietf@loki.ietf.org>; Fri, 27 Jul 2001 07:08:08 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06726;
	Fri, 27 Jul 2001 07:08:01 -0400 (EDT)
Message-Id: <200107271108.HAA06726@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ips@ece.cmu.edu
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ips-iscsi-name-disc-02.txt
Date: Fri, 27 Jul 2001 07:08:00 -0400
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Storage Working Group of the IETF.

	Title		: iSCSI Naming and Discovery Requirements
	Author(s)	: M. Bakke et al.
	Filename	: draft-ietf-ips-iscsi-name-disc-02.txt
	Pages		: 22
	Date		: 26-Jul-01
	
This document describes iSCSI [7] naming and discovery details. This  
document complements the iSCSI Protocol draft. Flexibility is the key  
guiding principle behind this document. That is, an  
effort has been made to satisfy the needs of both small isolated  
environments, as well as large environments requiring secure/scalable  
solutions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-name-disc-02.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ips-iscsi-name-disc-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ips-iscsi-name-disc-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010726170641.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ips-iscsi-name-disc-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ips-iscsi-name-disc-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010726170641.I-D@ietf.org>

--OtherAccess--

--NextPart--



From owner-ips@ece.cmu.edu  Fri Aug  3 06:10:44 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA11871
	for <ips-archive@odin.ietf.org>; Fri, 3 Aug 2001 06:10:43 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f739MVu25587
	for ips-outgoing; Fri, 3 Aug 2001 05:22:31 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f72GYhe11772
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 12:34:44 -0400 (EDT)
Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35])
	by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id JAA02520;
	Thu, 2 Aug 2001 09:34:31 -0700 (PDT)
Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19)
	id <Q12Z7G3Z>; Thu, 2 Aug 2001 09:34:31 -0700
Message-ID: <FFD40DB4943CD411876500508BAD027902993717@sj5-ex2.brocade.com>
From: Robert Snively <rsnively@Brocade.COM>
To: "'Black_David@emc.com'" <Black_David@emc.com>,
        Robert Snively
	 <rsnively@Brocade.COM>, ips@ece.cmu.edu
Subject: RE: Security Gateways
Date: Thu, 2 Aug 2001 09:34:28 -0700 
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

David,

As introduction to this phase of our discussion, let me draw
a picture in (gag) ASCII.

  +-  -  -  -  -  -  -  -  -  -  -  -  -  -  -  +  -  -  -  -  -  -  +
     Securely Administered Secure Environment     Public Environment
  |                                             |                    |
     FC  +--------------+   TCP/IP w/o
  |  <-->| FC/FCIP dvc A|<----+ IPSec           |                    |
         +--------------+     |
  |                           |      +--------+ |                    |
     FC  +--------------+     +----->| Secure |     TCP/IP w/ IPSec
  |  <-->| FC/FCIP dvc B|<---------->| Router |<------------>        |
         +--------------+     +----->|        |
  |                           |      +--------+ |                    |
     FC  +--------------+     |
  |  <-->| FC/FCIP dvc C|<----+                 |                    |
         +--------------+
  |                                             |                    |

  +-  -  -  -  -  -  -  -  -  -  -  -  -  -  -  +  -  -  -  -  -  -  +

I believe that the interface provided by FC/FCIP dvc A, B, and C
should be called RFC "FCIP" compliant just as completely as
the public interface from the secure router is called RFC "FCIP"
compliant.  In this environment, the FCIP devices will be routinely
carrying on traffic among themselves without using IPSec, and will
be carrying on traffic with the public environment using
securely protected connections.  The secure protection may be
IPSec as recommended by the RFC "FCIP", but it may also be some
other sort of secure connection.  If there is a performance and
a monetary cost associated with IPSec (which my associates assure
me will be significant for some time in the future), that cost
is paid one time in this picture.  If IPSec was mandatory
to implement for RFC "FCIP" compliance, the financial cost would
be paid three (or maybe four) times in the picture and the
performance cost would be avoided by invoking the optional disabling
of the security feature within the securely administered 
secure environment.

This example will be a common structure in FCIP environments.

The example provides lots of options for various kinds of tradeoffs.
As time goes on, the full integration of security functions in
FCIP chips may increase the percentage of RFC "FCIP" complaint
devices that actually contain the optional to implement IPSec
functions in the FC/FCIP device itself.  At any time, individual
secure interface boxes (IPSec or other) can be attached loosely or 
tightly to those FC/FCIP devices that invoke the option to not install
security internally.  Even the definition of tightly and loosely
connected is an artificial distinction related to how long the 
bolts are and whether adjacent racks constitute tightly coupled
functions.

To meet these requirements, the only solution I can see is to
define the RFC "FCIP" such that security is optional to implement
and optional to use.  While defining the recommended security to
be IPSec, devices that use no security and devices that use
alternative security would also be RFC "FCIP" compliant.  They
of course would list in their manufacturing specifications other 
RFCs that would be supported, typically including TCP, IP, and 
the appropriate IPSec RFCs.

To address the second part of your comments below:

>>  This isn't just "push back"
>>  from the IESG - it is a condition that the IESG required
>>  for its original approval of the IPS WG charter.

The closest wording I can find to that in the charter is:

"  The WG will address at least the following: 

    - Security measures, including authentication and privacy, 
      sufficient to defend against threats up to and including 
      those that can be expected on a public network.

   The WG will address security and congestion control as 
   an integral part of bits protocol encapsulation(s); "

I can find no hint that those security measures are mandatory
to implement for compliance with the RFC "FCIP".  They are
certainly mandatory to specify in the RFC, and we will have done
so with big flashy warnings (or at least as flashy as ASCII
allows) that qualify the security limitations for those operating
in RFC "FCIP" compliant devices that elect not to install
the optional security mechanisms internally.  I believe that
our proposal would meet both the letter and spirit of the charter.

The wording in draft-ietf-ips-framework-00.txt, clause 9, 
similarly recognizes the requirement we see with wording like:

"  A partial solution may be obtained by providing enhanced security 
   services at the interfaces from the existing storage network to the 
   IP storage network. There, services such as encryption and 
   authentication may be applied to the non-physically secure portion 
   of the path, without requiring end-station changes.  
         
   Overall security for such a solution may be no better than that of a 
   SAN presumed to be physically secure, but at least it will not be 
   perceived as worse. 
    
   Link-level security need not be the only solution. In many 
   applications, privacy of data transmission across the network may be 
   less significant an issue than controlling who accesses the storage 
   resources. In such situations, access-control solutions such as the 
   resource login provided by iSCSI can add value."

Note that the FC entities making use of the FCIP entities have
a secure authentication mechanism being proposed as part of the
FC activities.

I hope that we have interpreted the wording and intent correctly,
because if not we should probably modify the charter to allow
the FCIP proposal.

Bob Snively                        e-mail:    rsnively@brocade.com
Brocade Communications Systems     phone:  408 487 8135
1745 Technology Drive
San Jose, CA 95110


-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Wednesday, August 01, 2001 4:42 PM
To: rsnively@brocade.com; ips@ece.cmu.edu
Subject: RE: Security Gateways


Bob,

An RFC does not tell anyone what can or cannot be built;
it specifies what is required for compliance with the RFC.
If someone builds a protocol implementations that doesn't
comply with the requirements of the RFC, they should not
expect to be able to claim RFC compliance for devices 
based on that implementation.

> The marketplace does demand that
> security be possible and available for a device.  

The compliance requirement here is that "possible and
available" be realizable without having to add anything
to the device.  For the structure of interest here,
an FCIP device plus a security gateway, the complete system
[FCIP device, cable, security gateway] would comply with
the FCIP RFC at its external interface (i.e., the external
interface of the security gateway).  The interface between
the FCIP device and the security gateway would be missing
some required security functionality and hence would
not comply with the RFC.  As a result, the FCIP device by
itself would not comply with the RFC.

> I can understand why the IESG would push back on this
> question, but I would expect that they also believe that
> an FCIP device without optional security implemented
> is still an FCIP device and is compliant with the FCIP RFC. 

If "optional" means "MUST implement, but MAY use", that
expectation would be incorrect.  "MUST implement" (cf.
RFC 2119) is the level of requirement for authentication
and cryptographic integrity that is necessary for FCIP
to be approved as an RFC.  This isn't just "push back"
from the IESG - it is a condition that the IESG required
for its original approval of the IPS WG charter.

> With an edge security device installed 
> in front of it, it is also a
> secure FCIP device, just like the end-point of a 
> virtual private network is a secure device. 

That combination will comply with the RFC.  OTOH, the
IESG will not permit the FCIP RFC to allow an FCIP device
that lacks the basic security mechanisms to be compliant,
and hence the FCIP device *without* the edge security
device will not comply.

> By definition, "man in the middle" attacks are impossible
> for a security edge device, since the only place that the
> "man in the middle" can be placed is in the encrypted path.

"By definition" is not the best wording.  Assuming that the
"security edge device" is an IPsec security gateway, the IKE
and ISAKMP  protocols are to negotiate security functionality
and parameters; those protocols are resistant to man-in-the-
middle attacks, but that resistance is based on careful design.

--David


> -----Original Message-----
> From: Robert Snively [mailto:rsnively@brocade.com]
> Sent: Wednesday, August 01, 2001 6:25 PM
> To: 'Black_David@emc.com'; Robert Snively; ips@ece.cmu.edu
> Subject: RE: Security Gateways
> 
> 
> David,
> 
> I believe this is really a very difficult question, not
> susceptible to a simple SHALL/SHALL NOT response.  
> The technology absolutely allows and encourages
> security edge devices and absolutely allows devices using
> TCP and other protocols to exploit those edge devices or
> not as the system administrator requires.  The marketplace
> absolutely demands those capabilities.  A significant percentage
> of the internet economy is based on separately supplied security.
> I understand that the IETF
> has no interest in devices that are solely for closed
> environments, but the marketplace does not demand that
> a device have security built in to qualify for compliance with a
> protocol.  The marketplace does demand that
> security be possible and available for a device.  
> 
> That is what we have been proposing.
> 
> By definition, "man in the middle" attacks are impossible
> for a security edge device, since the only place that the
> "man in the middle" can be placed is in the encrypted path.
> The physically secured path has no possibility of an
> entry point for such an attack.  
> 
> I can understand why the IESG would push back on this
> question, but I would expect that they also believe that
> an FCIP device without optional security implemented
> is still an FCIP device and is compliant with the FCIP RFC. 
> This should be true whether the TCP path is based on IP,
> HIPPI, IB, a proprietary backplane or any other transport 
> that supports TCP. With an edge security device installed 
> in front of it, it is also a
> secure FCIP device, just like the end-point of a 
> virtual private network is a secure device. 
> 
> That is what we would like the RFC to say.
> 
> Bob
> 
> -----Original Message-----
> From: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Wednesday, August 01, 2001 10:13 AM
> To: rsnively@brocade.com; ips@ece.cmu.edu
> Subject: RE: Security Gateways
> 
> 
> Bob,
> 
> You've made a good case for "optional to use", but not
> "optional to implement".  The basic reason is that there
> is no way to ensure that vendors and/or users will
> restrict the use of an implementation that does not
> include security to situations where "paths of a
> storage environment are physically secured and have 
> no requirement for additional security mechanisms".
> Hence security needs to be present so that it
> can be used when FCIP is deployed in an environment
> that requires security.  Further, the IETF has no
> interest in specification of protocols that are
> *solely* for use in the sort of closed environment
> that you describe, and the IPS WG charter contains
> explicit words to that effect.
> 
> Therefore, the basic FCIP security mechanisms MUST be
> implemented, but usage MAY be negotiated.  At the moment,
> "basic security mechanisms" means authentication and
> cryptographic integrity.  Confidentiality can currently
> be optional to implement, but I think it's a very good
> idea to specify the basic confidentiality mechanism
> (*if* confidentiality of any form is implemented, *then*
> <XXX> MUST be implemented).  The design and specification
> of any negotiation mechanism must resist man-in-the-middle
> attacks on negotiation that would result in turning off
> security where that was not the intended outcome - such
> an approach can include restrictions on implementation
> behavior (e.g., if "no authentication" is not acceptable,
> do not offer or accept it during negotiation).
> 
> If the FCIP draft is sent to the IESG without requiring
> implementation of the basic security mechanisms, it will
> be returned to the WG with instructions to correct
> that shortcoming, along with some choice words from the
> ADs wondering how the WG chairs could have overlooked
> something like this.  As a result, an FCIP draft that
> does not require implementation of the basic security
> mechanisms will not be Last Called in the WG until that
> requirement is added.
> 
> Sorry to be blunt, but there is no flexibility on whether
> the basic security mechanisms are mandatory to implement;
> they will be mandatory to implement, period.
> 
> Thanks,
> --David
> 
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------


From owner-ips@ece.cmu.edu  Fri Aug  3 06:10:48 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA11882
	for <ips-archive@odin.ietf.org>; Fri, 3 Aug 2001 06:10:47 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f739DgK25128
	for ips-outgoing; Fri, 3 Aug 2001 05:13:42 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f71G8De28576
	for <ips@ece.cmu.edu>; Wed, 1 Aug 2001 12:08:13 -0400 (EDT)
Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35])
	by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id JAA20057;
	Wed, 1 Aug 2001 09:08:00 -0700 (PDT)
Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19)
	id <N5DRBMRB>; Wed, 1 Aug 2001 09:07:59 -0700
Message-ID: <FFD40DB4943CD411876500508BAD02790299370B@sj5-ex2.brocade.com>
From: Robert Snively <rsnively@Brocade.COM>
To: "'Black_David@emc.com'" <Black_David@emc.com>, ips@ece.cmu.edu
Subject: RE: Security Gateways
Date: Wed, 1 Aug 2001 09:07:57 -0700 
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Dear David,

I would like to address the rather serious question you have
raised here about both architectural layering and market
requirements.  After considerable thought, based on the
explanations below, I have concluded that the FCIP RFC should
specify that security is optional to implement and optional to use.

1)  Concerning architectural layering:

It is clear that the problems of security are well understood
within IETF. Numerous solutions have been proposed and
many of those have become standard implementations.  The most
successful of those (as an example, IPSec) have used the
principles of architectural layering very well.  IPSec
provides a secure mechanism for transporting any IP-based
protocol if the protocol requires such security.  However,
the overlaying protocols (as an example, TCP) have no requirement
to actually make use of IPSec, and in fact have no particular
requirement to make use of IP.  This is as it should be.
Each layer is implemented independently of the other.  The
services that each layer implements depend on the market
requirements for the environment.  By that logic, it is 
unnecessary for FCIP to specify any security mechanism at all, 
since so many security mechanisms are available.  However,
FCIP has provided the additional guidance that, if security
in a TCP environment is used, it shall be provided at a layer
below the TCP interface.  In particular, it recommends the
use of IPSec for TCP/IP environments (and will recommend the
appropriate IPSec options).  This additional guidance has nothing
to do with the architecture or definition of FCIP and is 
merely a recommendation that should improve interoperability.

2)  Concerning market requirements:

A very high percentage of storage environments today manage
their configurations very carefully.  Such careful management is
necessary to guarantee redundant paths for proper availability,
to provide sufficient paths to provide the required performance, and to
guarantee known paths to improve reparability and consistency
of behavior.  As a side effect, a very high percentage of
the paths of a storage environment are physically secured and have
no requirement for additional security mechanisms.  At present,
the only paths that are using security are those very few paths
that leave one physically secure environment to transport data to
another physically secure environment.  Those few paths almost universally
use security mechanisms at a lower level (as an example, a virtual
private network) to achieve their goals.  As a first guess, such
paths are well under 1% of the storage paths being used today.

I do not believe that this paradigm will change significantly over
the next several years, although of course the percentage of paths
requiring transport security may rise over 1%.  The requirements for
storage performance and the desire to maintain the storage devices
and many of their primary processors in a physically secure
environment will assure similar configurations.

In this environment, the market will demand low cost and high
performance for the great majority of interconnects and will demand
security for a relatively low percentage of interconnects.  

What this implies for technologies like FCIP is that security
be available as a separate option, outside the primary FCIP
definition.  While still allowing the integration of security
inside an FCIP unit, the IETF draft for FCIP  must also allow security
to be provided either not at all or by an outside mechanism.  
The most common outside mechanism would be a gateway box of some sort.
In many cases, the gateway box will be a secure router placed on the
external link and servicing a large number of locally attached
unsecured FCIP boxes.

CONCLUSIONS:

The FCIP draft should continue to specify a security mechanism,
with IPSec being the appropriate candidate, to guarantee interoperability
when security is provided.  The FCIP draft should be modified to
indicate that security is optional to implement and optional to use.
In addition, it should explicitly indicate that external gateway
boxes are allowed implementation mechanisms for security.

As a side question, note that management of storage area networks
and FCIP boxes is a separate question and is outside the scope of
the FCIP draft.  Both Fibre Channel and Ethernet management paths
have security appropriate to the particular management mechanism.
As an example, web-based management mechanisms use web-based
security tools. 

Bob Snively                        e-mail:    rsnively@brocade.com
Brocade Communications Systems     phone:  408 487 8135
1745 Technology Drive
San Jose, CA 95110



-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Tuesday, July 24, 2001 7:11 PM
To: ips@ece.cmu.edu
Subject: Security Gateways


The following issue was hidden in my long set of
comments on the -03 version of FCIP:

> > Delete 12 b).  If an FCIP entity is operating with an external
> > security gateway, only the interface on the public side of the
> > gateway is compliant with this specification.  The interface
> > between the FCIP entity and the gateway is not compliant because
> > it is lacking required security features - the FCIP entity
> > *includes* the security gateway in this structure.
> 
> Please post this as a separate issue because several of the
> FCIP Authors believe it is appropriate for FCIP and I cannot
> represent their opinions.

The issue is not whether it's "appropriate".  The issue
is that if an implementation uses an FCIP Entity plus
an external security gateway, the only interface that
conforms to the forthcoming RFC is the public/external
interface on the security gateway.  The interface between
the FCIP Entity and the security gateway is private
and fails to conform to the security that will be
required of all FCIP implementations.

The above paragraph also applies to iSCSI (substitute iSCSI
for FCIP in all instances).  Let me also note that iSCSI's
ability to use a security gateway is not final at this
juncture.  The spectrum of security possibilities includes
things like SRP keying of ESP and IPsec transport mode that
would make external gateways difficult or impossible to use.

Those who care about being able to use security gateways
(or think that there's no need to support their use)
should speak up on the list, in London, and/or in Orange
County (I would expect the decision not to be made prior
to Orange County) and *EXPLAIN WHY* [technical rationale].

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------
 


From owner-ips@ece.cmu.edu  Fri Aug  3 06:10:49 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA11893
	for <ips-archive@odin.ietf.org>; Fri, 3 Aug 2001 06:10:49 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f739VK425916
	for ips-outgoing; Fri, 3 Aug 2001 05:31:20 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7329ve10174
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 22:09:57 -0400 (EDT)
Received: from postoffice.sarnoff.com ([127.0.0.1]) by
          postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
          SMTP id GHGZ8Q00.NDW for <ips@ece.cmu.edu>; Thu, 2 Aug 2001
          22:07:38 -0400 
Received: from nova.sarnoff.com ([130.33.8.27]) by
          postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
          ESMTP id GH5UTF00.7JP; Fri, 27 Jul 2001 21:58:27 -0400 
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
	by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id HAA08000;
	Tue, 24 Jul 2001 07:34:47 -0400 (EDT)
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA13461
	for ietf-123-outbound.05@ietf.org; Tue, 24 Jul 2001 07:15:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA12591
	for <all-ietf@loki.ietf.org>; Tue, 24 Jul 2001 06:29:07 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05829;
	Tue, 24 Jul 2001 06:29:06 -0400 (EDT)
Message-Id: <200107241029.GAA05829@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ips@ece.cmu.edu
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ips-iscsi-mib-02.txt
Date: Tue, 24 Jul 2001 06:29:06 -0400
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Storage Working Group of the IETF.

	Title		: Definitions of Managed Objects for iSCSI
	Author(s)	: M. Bakke et al.	
        Filename	: draft-ietf-ips-iscsi-mib-02.txt
	Pages		: 54
	Date		: 23-Jul-01
	
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in TCP/IP based internets

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-mib-02.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ips-iscsi-mib-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ips-iscsi-mib-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010723140346.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ips-iscsi-mib-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ips-iscsi-mib-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010723140346.I-D@ietf.org>

--OtherAccess--

--NextPart--



From owner-ips@ece.cmu.edu  Fri Aug  3 06:11:13 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA11913
	for <ips-archive@odin.ietf.org>; Fri, 3 Aug 2001 06:11:13 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f739V3m25892
	for ips-outgoing; Fri, 3 Aug 2001 05:31:03 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f738sie24352
	for <ips@ece.cmu.edu>; Fri, 3 Aug 2001 04:54:44 -0400 (EDT)
Received: from postoffice.sarnoff.com ([127.0.0.1]) by
          postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
          SMTP id GHHFCP00.KQJ for <ips@ece.cmu.edu>; Fri, 3 Aug 2001
          03:55:37 -0400 
Received: from nova.sarnoff.com ([130.33.8.27]) by
          postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
          ESMTP id GH5PIY00.UCW; Fri, 27 Jul 2001 20:04:10 -0400 
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
	by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id IAA25799;
	Wed, 25 Jul 2001 08:01:03 -0400 (EDT)
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA26299
	for ietf-123-outbound.05@ietf.org; Wed, 25 Jul 2001 07:35:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA25413
	for <all-ietf@loki.ietf.org>; Wed, 25 Jul 2001 06:31:53 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07322;
	Wed, 25 Jul 2001 06:31:52 -0400 (EDT)
Message-Id: <200107251031.GAA07322@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ips@ece.cmu.edu
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ips-iscsi-slp-01.txt
Date: Wed, 25 Jul 2001 06:31:51 -0400
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Storage Working Group of the IETF.

	Title		: Finding iSCSI Targets and Name Servers Using SLP
	Author(s)	: M. Bakke et al.
	Filename	: draft-ietf-ips-iscsi-slp-01.txt
	Pages		: 17
	Date		: 24-Jul-01
	
The iSCSI protocol provides a way for hosts to access SCSI devices
over an IP network.  This document defines the use of the Service
Location Protocol (SLP) by iSCSI hosts, devices, and name services,
along with the SLP service type templates that describe the services   they provide.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-slp-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ips-iscsi-slp-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ips-iscsi-slp-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010724132056.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ips-iscsi-slp-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ips-iscsi-slp-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010724132056.I-D@ietf.org>

--OtherAccess--

--NextPart--



From owner-ips@ece.cmu.edu  Fri Aug  3 06:11:15 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA11924
	for <ips-archive@odin.ietf.org>; Fri, 3 Aug 2001 06:11:15 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f739GZ225245
	for ips-outgoing; Fri, 3 Aug 2001 05:16:35 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f71MPXe18160
	for <ips@ece.cmu.edu>; Wed, 1 Aug 2001 18:25:33 -0400 (EDT)
Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35])
	by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id PAA24753;
	Wed, 1 Aug 2001 15:25:20 -0700 (PDT)
Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19)
	id <N5DRBW03>; Wed, 1 Aug 2001 15:25:19 -0700
Message-ID: <FFD40DB4943CD411876500508BAD027902993710@sj5-ex2.brocade.com>
From: Robert Snively <rsnively@Brocade.COM>
To: "'Black_David@emc.com'" <Black_David@emc.com>,
        Robert Snively
	 <rsnively@Brocade.COM>, ips@ece.cmu.edu
Subject: RE: Security Gateways
Date: Wed, 1 Aug 2001 15:25:16 -0700 
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

David,

I believe this is really a very difficult question, not
susceptible to a simple SHALL/SHALL NOT response.  
The technology absolutely allows and encourages
security edge devices and absolutely allows devices using
TCP and other protocols to exploit those edge devices or
not as the system administrator requires.  The marketplace
absolutely demands those capabilities.  A significant percentage
of the internet economy is based on separately supplied security.
I understand that the IETF
has no interest in devices that are solely for closed
environments, but the marketplace does not demand that
a device have security built in to qualify for compliance with a
protocol.  The marketplace does demand that
security be possible and available for a device.  

That is what we have been proposing.

By definition, "man in the middle" attacks are impossible
for a security edge device, since the only place that the
"man in the middle" can be placed is in the encrypted path.
The physically secured path has no possibility of an
entry point for such an attack.  

I can understand why the IESG would push back on this
question, but I would expect that they also believe that
an FCIP device without optional security implemented
is still an FCIP device and is compliant with the FCIP RFC. 
This should be true whether the TCP path is based on IP,
HIPPI, IB, a proprietary backplane or any other transport 
that supports TCP. With an edge security device installed 
in front of it, it is also a
secure FCIP device, just like the end-point of a 
virtual private network is a secure device. 

That is what we would like the RFC to say.

Bob

-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Wednesday, August 01, 2001 10:13 AM
To: rsnively@brocade.com; ips@ece.cmu.edu
Subject: RE: Security Gateways


Bob,

You've made a good case for "optional to use", but not
"optional to implement".  The basic reason is that there
is no way to ensure that vendors and/or users will
restrict the use of an implementation that does not
include security to situations where "paths of a
storage environment are physically secured and have 
no requirement for additional security mechanisms".
Hence security needs to be present so that it
can be used when FCIP is deployed in an environment
that requires security.  Further, the IETF has no
interest in specification of protocols that are
*solely* for use in the sort of closed environment
that you describe, and the IPS WG charter contains
explicit words to that effect.

Therefore, the basic FCIP security mechanisms MUST be
implemented, but usage MAY be negotiated.  At the moment,
"basic security mechanisms" means authentication and
cryptographic integrity.  Confidentiality can currently
be optional to implement, but I think it's a very good
idea to specify the basic confidentiality mechanism
(*if* confidentiality of any form is implemented, *then*
<XXX> MUST be implemented).  The design and specification
of any negotiation mechanism must resist man-in-the-middle
attacks on negotiation that would result in turning off
security where that was not the intended outcome - such
an approach can include restrictions on implementation
behavior (e.g., if "no authentication" is not acceptable,
do not offer or accept it during negotiation).

If the FCIP draft is sent to the IESG without requiring
implementation of the basic security mechanisms, it will
be returned to the WG with instructions to correct
that shortcoming, along with some choice words from the
ADs wondering how the WG chairs could have overlooked
something like this.  As a result, an FCIP draft that
does not require implementation of the basic security
mechanisms will not be Last Called in the WG until that
requirement is added.

Sorry to be blunt, but there is no flexibility on whether
the basic security mechanisms are mandatory to implement;
they will be mandatory to implement, period.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


> -----Original Message-----
> From: Robert Snively [mailto:rsnively@brocade.com]
> Sent: Wednesday, August 01, 2001 12:08 PM
> To: 'Black_David@emc.com'; ips@ece.cmu.edu
> Subject: RE: Security Gateways
> 
> 
> Dear David,
> 
> I would like to address the rather serious question you have
> raised here about both architectural layering and market
> requirements.  After considerable thought, based on the
> explanations below, I have concluded that the FCIP RFC should
> specify that security is optional to implement and optional to use.
> 
> 1)  Concerning architectural layering:
> 
> It is clear that the problems of security are well understood
> within IETF. Numerous solutions have been proposed and
> many of those have become standard implementations.  The most
> successful of those (as an example, IPSec) have used the
> principles of architectural layering very well.  IPSec
> provides a secure mechanism for transporting any IP-based
> protocol if the protocol requires such security.  However,
> the overlaying protocols (as an example, TCP) have no requirement
> to actually make use of IPSec, and in fact have no particular
> requirement to make use of IP.  This is as it should be.
> Each layer is implemented independently of the other.  The
> services that each layer implements depend on the market
> requirements for the environment.  By that logic, it is 
> unnecessary for FCIP to specify any security mechanism at all, 
> since so many security mechanisms are available.  However,
> FCIP has provided the additional guidance that, if security
> in a TCP environment is used, it shall be provided at a layer
> below the TCP interface.  In particular, it recommends the
> use of IPSec for TCP/IP environments (and will recommend the
> appropriate IPSec options).  This additional guidance has nothing
> to do with the architecture or definition of FCIP and is 
> merely a recommendation that should improve interoperability.
> 
> 2)  Concerning market requirements:
> 
> A very high percentage of storage environments today manage
> their configurations very carefully.  Such careful management is
> necessary to guarantee redundant paths for proper availability,
> to provide sufficient paths to provide the required 
> performance, and to
> guarantee known paths to improve reparability and consistency
> of behavior.  As a side effect, a very high percentage of
> the paths of a storage environment are physically secured and have
> no requirement for additional security mechanisms.  At present,
> the only paths that are using security are those very few paths
> that leave one physically secure environment to transport data to
> another physically secure environment.  Those few paths 
> almost universally
> use security mechanisms at a lower level (as an example, a virtual
> private network) to achieve their goals.  As a first guess, such
> paths are well under 1% of the storage paths being used today.
> 
> I do not believe that this paradigm will change significantly over
> the next several years, although of course the percentage of paths
> requiring transport security may rise over 1%.  The requirements for
> storage performance and the desire to maintain the storage devices
> and many of their primary processors in a physically secure
> environment will assure similar configurations.
> 
> In this environment, the market will demand low cost and high
> performance for the great majority of interconnects and will demand
> security for a relatively low percentage of interconnects.  
> 
> What this implies for technologies like FCIP is that security
> be available as a separate option, outside the primary FCIP
> definition.  While still allowing the integration of security
> inside an FCIP unit, the IETF draft for FCIP  must also allow security
> to be provided either not at all or by an outside mechanism.  
> The most common outside mechanism would be a gateway box of some sort.
> In many cases, the gateway box will be a secure router placed on the
> external link and servicing a large number of locally attached
> unsecured FCIP boxes.
> 
> CONCLUSIONS:
> 
> The FCIP draft should continue to specify a security mechanism,
> with IPSec being the appropriate candidate, to guarantee 
> interoperability
> when security is provided.  The FCIP draft should be modified to
> indicate that security is optional to implement and optional to use.
> In addition, it should explicitly indicate that external gateway
> boxes are allowed implementation mechanisms for security.
> 
> As a side question, note that management of storage area networks
> and FCIP boxes is a separate question and is outside the scope of
> the FCIP draft.  Both Fibre Channel and Ethernet management paths
> have security appropriate to the particular management mechanism.
> As an example, web-based management mechanisms use web-based
> security tools. 
> 
> Bob Snively                        e-mail:    rsnively@brocade.com
> Brocade Communications Systems     phone:  408 487 8135
> 1745 Technology Drive
> San Jose, CA 95110
> 
> 
> 
> -----Original Message-----
> From: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Tuesday, July 24, 2001 7:11 PM
> To: ips@ece.cmu.edu
> Subject: Security Gateways
> 
> 
> The following issue was hidden in my long set of
> comments on the -03 version of FCIP:
> 
> > > Delete 12 b).  If an FCIP entity is operating with an external
> > > security gateway, only the interface on the public side of the
> > > gateway is compliant with this specification.  The interface
> > > between the FCIP entity and the gateway is not compliant because
> > > it is lacking required security features - the FCIP entity
> > > *includes* the security gateway in this structure.
> > 
> > Please post this as a separate issue because several of the
> > FCIP Authors believe it is appropriate for FCIP and I cannot
> > represent their opinions.
> 
> The issue is not whether it's "appropriate".  The issue
> is that if an implementation uses an FCIP Entity plus
> an external security gateway, the only interface that
> conforms to the forthcoming RFC is the public/external
> interface on the security gateway.  The interface between
> the FCIP Entity and the security gateway is private
> and fails to conform to the security that will be
> required of all FCIP implementations.
> 
> The above paragraph also applies to iSCSI (substitute iSCSI
> for FCIP in all instances).  Let me also note that iSCSI's
> ability to use a security gateway is not final at this
> juncture.  The spectrum of security possibilities includes
> things like SRP keying of ESP and IPsec transport mode that
> would make external gateways difficult or impossible to use.
> 
> Those who care about being able to use security gateways
> (or think that there's no need to support their use)
> should speak up on the list, in London, and/or in Orange
> County (I would expect the decision not to be made prior
> to Orange County) and *EXPLAIN WHY* [technical rationale].
> 
> Thanks,
> --David
> 
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------
>  
> 


From owner-ips@ece.cmu.edu  Fri Aug  3 06:11:18 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA11936
	for <ips-archive@odin.ietf.org>; Fri, 3 Aug 2001 06:11:18 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f739UhL25870
	for ips-outgoing; Fri, 3 Aug 2001 05:30:43 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f738sie24344
	for <ips@ece.cmu.edu>; Fri, 3 Aug 2001 04:54:44 -0400 (EDT)
Received: from postoffice.sarnoff.com ([127.0.0.1]) by
          postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
          SMTP id GHHF4J00.NQC for <ips@ece.cmu.edu>; Fri, 3 Aug 2001
          03:50:43 -0400 
Received: from nova.sarnoff.com ([130.33.8.27]) by
          postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
          ESMTP id GH5D0K00.S1Q; Fri, 27 Jul 2001 15:33:56 -0400 
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
	by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id JAA01333;
	Fri, 27 Jul 2001 09:53:00 -0400 (EDT)
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA14865
	for ietf-123-outbound.05@ietf.org; Fri, 27 Jul 2001 09:35:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA12899
	for <all-ietf@loki.ietf.org>; Fri, 27 Jul 2001 07:08:08 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06726;
	Fri, 27 Jul 2001 07:08:01 -0400 (EDT)
Message-Id: <200107271108.HAA06726@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ips@ece.cmu.edu
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ips-iscsi-name-disc-02.txt
Date: Fri, 27 Jul 2001 07:08:00 -0400
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Storage Working Group of the IETF.

	Title		: iSCSI Naming and Discovery Requirements
	Author(s)	: M. Bakke et al.
	Filename	: draft-ietf-ips-iscsi-name-disc-02.txt
	Pages		: 22
	Date		: 26-Jul-01
	
This document describes iSCSI [7] naming and discovery details. This  
document complements the iSCSI Protocol draft. Flexibility is the key  
guiding principle behind this document. That is, an  
effort has been made to satisfy the needs of both small isolated  
environments, as well as large environments requiring secure/scalable  
solutions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-name-disc-02.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ips-iscsi-name-disc-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ips-iscsi-name-disc-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010726170641.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ips-iscsi-name-disc-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ips-iscsi-name-disc-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010726170641.I-D@ietf.org>

--OtherAccess--

--NextPart--



From owner-ips@ece.cmu.edu  Fri Aug  3 06:11:21 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA11947
	for <ips-archive@odin.ietf.org>; Fri, 3 Aug 2001 06:11:20 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f739Uvi25880
	for ips-outgoing; Fri, 3 Aug 2001 05:30:57 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f738sje24359
	for <ips@ece.cmu.edu>; Fri, 3 Aug 2001 04:54:45 -0400 (EDT)
Received: from postoffice.sarnoff.com ([127.0.0.1]) by
          postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
          SMTP id GHHFHL00.VQP for <ips@ece.cmu.edu>; Fri, 3 Aug 2001
          03:58:33 -0400 
Received: from nova.sarnoff.com ([130.33.8.27]) by
          postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
          ESMTP id GH5UTG00.AJ5; Fri, 27 Jul 2001 21:58:28 -0400 
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
	by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id HAA08330;
	Tue, 24 Jul 2001 07:44:23 -0400 (EDT)
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA13645
	for ietf-123-outbound.05@ietf.org; Tue, 24 Jul 2001 07:25:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA12598
	for <all-ietf@loki.ietf.org>; Tue, 24 Jul 2001 06:29:13 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05842;
	Tue, 24 Jul 2001 06:29:13 -0400 (EDT)
Message-Id: <200107241029.GAA05842@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ips@ece.cmu.edu
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ips-iscsi-07.txt
Date: Tue, 24 Jul 2001 06:29:13 -0400
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Storage Working Group of the IETF.

	Title		: iSCSI
	Author(s)	: J. Satran et al.
	Filename	: draft-ietf-ips-iscsi-07.txt
	Pages		: 187
	Date		: 23-Jul-01
	
The Small Computer Systems Interface (SCSI) is a popular family of 
protocols for communicating with I/O devices, especially storage 
devices.  This memo describes a transport protocol for SCSI that 
operates on top of TCP.  The iSCSI protocol aims to be fully 
compliant with the requirements laid out in the SCSI Architecture 
Model - 2 [SAM2] document.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-07.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ips-iscsi-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ips-iscsi-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010723140355.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ips-iscsi-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ips-iscsi-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010723140355.I-D@ietf.org>

--OtherAccess--

--NextPart--



From owner-ips@ece.cmu.edu  Fri Aug  3 06:12:42 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA11978
	for <ips-archive@odin.ietf.org>; Fri, 3 Aug 2001 06:12:42 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f739Hsl25328
	for ips-outgoing; Fri, 3 Aug 2001 05:17:54 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail07a.vwh1.net (mail07a.vwh1.net [209.238.9.57])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f720mpe24031
	for <ips@ece.cmu.edu>; Wed, 1 Aug 2001 20:48:51 -0400 (EDT)
Received: from www.platys.com (208.55.89.7)
	by mail07a.vwh1.net (RS ver 1.0.60s) with SMTP id 030975930;
	Wed,  1 Aug 2001 20:48:29 -0400 (EDT)
From: "Dev - Platys" <deva@platys.com>
To: "Elliott, Robert" <Robert.Elliott@compaq.com>, <ips@ece.cmu.edu>
Subject: RE: iSCSI: draft 7: iSCSI response and SCSI sense data
Date: Wed, 1 Aug 2001 17:52:41 -0700
Message-ID: <NFBBKBDFJCDMGCBKJLCJKELHFCAA.deva@platys.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <78AF3C342AEAEF4BA33B35A8A15668C6019E2006@cceexc17.americas.cpqcorp.net>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
X-Loop-Detect: 1
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Robert,

I agree with you on this.  

---
Forcing the iSCSI layer to fill in those fields seems to break the 
layering model.

I suggest removing the CHECK CONDITION status and additional sense 
code linkage and leave the SCSI status undefined if the iSCSI 
response is nonzero.

iSCSI draft 7 section 2.4.3 includes a table relating the iSCSI 
response codes to various CHECK CONDITION status additional 
sense codes:

------

Thanks

Deva
Platys Technologies

  "0x01 Target Failure
    ASC=0x44 ASCQ=0x00 INTERNAL TARGET FAILURE
  0x02 Delivery Subsystem Failure 
    ASC=0x47 ASCQ=0x03 INFORMATION UNIT CRC ERROR DETECTED
  0x03 Unsolicited data rejected
    ASC=0x49 ASCQ=0x00 INVALID MESSAGE ERROR
  0x04 Not enough unsolicited [data]
    ASC=0x49 ASCQ=0x00 INVALID MESSAGE ERROR
  0x05 SNACK rejected [Command in progress]
    ASC=0x47 ASCQ=0x03 INFORMATION UNIT CRC ERROR DETECTED

  As listed above, each defined response code MUST be used (under the 
  conditions described in the 'Reason' field), only when the 
  corresponding SCSI CHECK CONDITION is signaled, to convey additional 
  protocol service information.  A SCSI CHECK CONDITION with the ASC 
  and ASCQ values as tabulated MUST be signaled by iSCSI targets for 
  all the instances in this document referring to usage of one of the 
  above defined response codes."
 
No other SCSI protocol does this. iSCSI seems to be granting the 
SCSI-level status a priority over the iSCSI-level response data.  
I think the other protocols treat the response data as more 
important; if the response data indicates a problem, the SCSI layer 
is considered broken and the SCSI status is undefined.  

Forcing the iSCSI layer to fill in those fields seems to break the 
layering model.

I suggest removing the CHECK CONDITION status and additional sense 
code linkage and leave the SCSI status undefined if the iSCSI 
response is nonzero.

This is compatible with SAM-2, which only requires status be returned
when the service response is TASK COMPLETE (SAM-2 revision 18
section 5.3.1):
  "Status shall be sent from the logical unit to the application 
   client whenever a command ends with a service response of 
   TASK COMPLETE or LINKED COMMAND COMPLETE."

Furthermore, SAM-2 requires that status be ignored when the service
response indicates an error (SAM-2 revision 18 section 5.1):
  "Status: A one-byte field containing command completion status 
  (see 5.3). If the command ends with a service response of 
  SERVICE DELIVERY OR TARGET FAILURE, the application client 
  shall consider this parameter to be undefined."

I think iSCSI's current wording may violate this rule.
---
Rob Elliott, Compaq Server Storage
Robert.Elliott@compaq.com


From owner-ips@ece.cmu.edu  Fri Aug  3 06:14:15 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA12013
	for <ips-archive@odin.ietf.org>; Fri, 3 Aug 2001 06:14:14 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7398SW24886
	for ips-outgoing; Fri, 3 Aug 2001 05:08:28 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from ext1.pirus.com ([4.36.58.197])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6VJPe323711
	for <ips@ece.cmu.edu>; Tue, 31 Jul 2001 15:25:40 -0400 (EDT)
Message-Id: <200107311925.f6VJPe323711@ece.cmu.edu>
Received: by ext1.pirus.com with Internet Mail Service (5.5.2650.21)
	id <PJ7C823Y>; Tue, 31 Jul 2001 15:26:59 -0400
From: "Merhar, Milan" <mmerhar@pirus.com>
To: "'Sanjeev Bhagat (TRIPACE/Zoetermeer)'" <sbhagat@tripace.com>
Cc: ips@ece.cmu.edu
Subject: RE: Iscsi: Fault tolerance
Date: Tue, 31 Jul 2001 15:26:49 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Sanjeev, 

I think that your clients will actually be accessing a file system 
your server has created on the raw volume accessed by iSCSI.  They do so 
by using a network file protocol - in the case of Microsoft products,
probably CIFS, connecting to the server which then in turn does 
block mode accesses to the iSCSI volume.

So, if the server goes away, the clients can no longer reach 
the files stored on the iSCSI device.  Of course, unlike 
a server with a direct-attached drive, in the situation you 
describe another server could step into the place of the first one, 
mounting the iSCSI volume and again offering shared file access to 
those clients. (In other words, you've got a NAS server accessing 
its storage over a SAN - an IP SAN.)

Depending on how the server "went away", there may be some startup 
transients bringing its replacement online, as the file system is 
verified, cleaned up, etc.  The transition is also not transparent
to the clients, as they will need to reconnect to this new server, 
with its different IP address, as well.

Hope this helps.

	- milan


Milan Merhar, Chief Scientist, Pirus Networks

> -----Original Message-----
> From: Sanjeev Bhagat (TRIPACE/Zoetermeer) [mailto:sbhagat@tripace.com]
> Sent: Tuesday, July 31, 2001 2:18 PM
> To: 'Julian Satran'; ips@ece.cmu.edu
> Subject: RE: Iscsi: Fault tolerance
> 
> 
> Julian and all!!
> 
> The server connects to the iscsi target (Say just a disk) 
> with the help of
> an iSCSI initiator driver installed on the server. The NT 
> server thus shows
> an extra physical disk present on the server. The sys admin 
> then assigns the
> permission to other clients/users to share this target. The 
> clients can then
> access this this disk (iscsi target) or any sharable 
> directory on this disk
> (iscsi target)present on the server by connecting to the network.
> 
> Hope it is clear by now!! If it is not then please provide me 
> your contact
> number and I will try to explain you better.
> 
> I am sorry if there is any ambiguity but i cant find better words to
> explain.
> 
> Sanjeev
> 
> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Tuesday, July 31, 2001 6:35 PM
> To: ips@ece.cmu.edu
> Subject: Re: Iscsi: Fault tolerance
> 
> 
> 
> How exactly will the clients use the initiator on the server?
> 
> Julo
> 
> "Sanjeev Bhagat (TRIPACE/Zoetermeer)" <sbhagat@tripace.com> 
> on 31-07-2001
> 18:57:41
> 
> Please respond to "Sanjeev Bhagat (TRIPACE/Zoetermeer)"
>       <sbhagat@tripace.com>
> 
> To:   "'IPS Reflector'" <ips@ece.cmu.edu>
> cc:
> Subject:  Iscsi: Fault tolerance
> 
> 
> 
> 
> Hi
> 
> Consider a case where the clients of a Windows NT server are 
> accessing the
> iSCSI target with iSCSI initiator driver installed  on the Windows NT
> server
> to access a ISCSI target on NET. So all the clients on this Windows NT
> server can share the iSCSI target of this server. In case the 
> server goes
> down , will the clients still be able to access the iSCSI Target??
> 
> I hope I have put my question peoperly. In case not then 
> please feel free
> to
> call me at +31 624685051
> 
> 
> Sincerely,
> 
> Sanjeev Bhagat
> 
> Tripace Europe
> 
> 
>  - att1.htm
> 
> 


From owner-ips@ece.cmu.edu  Fri Aug  3 06:14:31 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA12024
	for <ips-archive@odin.ietf.org>; Fri, 3 Aug 2001 06:14:30 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f739iHp26413
	for ips-outgoing; Fri, 3 Aug 2001 05:44:17 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from ns.strahm.net (sub18-42.member.dsl-only.net [63.105.18.42])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f6VE2X304675
	for <ips@ece.cmu.edu>; Tue, 31 Jul 2001 10:02:34 -0400 (EDT)
Received: (qmail 24043 invoked by uid 500); 31 Jul 2001 12:32:43 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
  by localhost with SMTP; 31 Jul 2001 12:32:43 -0000
Date: Tue, 31 Jul 2001 05:32:43 -0700 (PDT)
From: Bill Strahm <bill@strahm.net>
To: Sharan Basappa <sharan@ctd.hcltech.com>
cc: "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
Subject: Re: can i discuss infiniband here
In-Reply-To: <219446B9B371D511A353000244192476190D19@DEVI>
Message-ID: <Pine.LNX.4.10.10107310531260.24040-100000@homegate.strahm.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Depending on what you are wanting to discuss, however there is an IPoverIB
working group that has a mailing list at 
listserv@mailbag.intel.com
subscribe ipoverib

We are discussing IP encapsulation and IB specific MIBs there.

Bill

On Tue, 31 Jul 2001, Sharan Basappa wrote:

> Just wanted to know if infiniband can be discussed in this forum.
> Sharan
> 


From owner-ips@ece.cmu.edu  Fri Aug  3 06:14:48 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA12037
	for <ips-archive@odin.ietf.org>; Fri, 3 Aug 2001 06:14:48 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f739V8M25899
	for ips-outgoing; Fri, 3 Aug 2001 05:31:08 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f738sje24356
	for <ips@ece.cmu.edu>; Fri, 3 Aug 2001 04:54:45 -0400 (EDT)
Received: from postoffice.sarnoff.com ([127.0.0.1]) by
          postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
          SMTP id GHHFHK00.RQD for <ips@ece.cmu.edu>; Fri, 3 Aug 2001
          03:58:32 -0400 
Received: from nova.sarnoff.com ([130.33.8.27]) by
          postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
          ESMTP id GH5UTF00.7JP; Fri, 27 Jul 2001 21:58:27 -0400 
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
	by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id HAA08000;
	Tue, 24 Jul 2001 07:34:47 -0400 (EDT)
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA13461
	for ietf-123-outbound.05@ietf.org; Tue, 24 Jul 2001 07:15:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA12591
	for <all-ietf@loki.ietf.org>; Tue, 24 Jul 2001 06:29:07 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05829;
	Tue, 24 Jul 2001 06:29:06 -0400 (EDT)
Message-Id: <200107241029.GAA05829@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ips@ece.cmu.edu
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ips-iscsi-mib-02.txt
Date: Tue, 24 Jul 2001 06:29:06 -0400
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Storage Working Group of the IETF.

	Title		: Definitions of Managed Objects for iSCSI
	Author(s)	: M. Bakke et al.	
        Filename	: draft-ietf-ips-iscsi-mib-02.txt
	Pages		: 54
	Date		: 23-Jul-01
	
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in TCP/IP based internets

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-mib-02.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ips-iscsi-mib-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ips-iscsi-mib-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010723140346.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ips-iscsi-mib-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ips-iscsi-mib-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010723140346.I-D@ietf.org>

--OtherAccess--

--NextPart--



From owner-ips@ece.cmu.edu  Fri Aug  3 06:15:16 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA12059
	for <ips-archive@odin.ietf.org>; Fri, 3 Aug 2001 06:15:16 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f739JnP25409
	for ips-outgoing; Fri, 3 Aug 2001 05:19:49 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mx01-a.netapp.com (mx01-a.netapp.com [198.95.226.53])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f724lSe03172
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 00:47:28 -0400 (EDT)
Received: from frejya.corp.netapp.com (frejya.corp.netapp.com [10.10.20.91])
	by mx01-a.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f724lLX26532;
	Wed, 1 Aug 2001 21:47:21 -0700 (PDT)
Received: from tooting-fe.eng.netapp.com (localhost [127.0.0.1])
	by frejya.corp.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f724lLE22020;
	Wed, 1 Aug 2001 21:47:21 -0700 (PDT)
Received: (from beepy@localhost)
	by tooting-fe.eng.netapp.com (8.8.8+Sun/8.8.8) id VAA02871;
	Wed, 1 Aug 2001 21:47:20 -0700 (PDT)
From: Brian Pawlowski <beepy@netapp.com>
Message-Id: <200108020447.VAA02871@tooting-fe.eng.netapp.com>
Subject: Re: Security Gateways
In-Reply-To: <200108020206.f7226He27045@ece.cmu.edu> from Jim McKinney at "Aug 1, 1 10:06:17 pm"
To: jmck+@ece.cmu.edu (Jim McKinney)
Date: Wed, 1 Aug 2001 21:47:20 -0700 (PDT)
Cc: ips@ece.cmu.edu
X-Mailer: ELM [version 2.4ME++ PL40 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

> 2)  Concerning market requirements:
> 
> A very high percentage of storage environments today manage
> their configurations very carefully.  Such careful management is
> necessary to guarantee redundant paths for proper availability,
> to provide sufficient paths to provide the required performance, and to
> guarantee known paths to improve reparability and consistency
> of behavior.  As a side effect, a very high percentage of
> the paths of a storage environment are physically secured and have
> no requirement for additional security mechanisms.  

I've often mused that storage environments today based on FC are
physically secure as an artifact of the severe deployment restrictions
that the technology itself supports.

Replacing FC deployments with TCP/IP-based networks blows these
assumptions.

After years in the insecure wilderness within NFS, and the inability
to count on strong security from all vendors removing a motivation
to even invest in it (it was optional), the movement in NFS Version 4
to strong security was a key component of the evolution wrought since
it was handed to the IETF.

I look back on our lack of commitment to providing interoperable,
manadatory to implement (optional to enable) strong security as being
one of the greatest failures in NFS - that is finally being corrected.

It is certainly sobering when your PC on your desktop provides stronger
security guarantees in a simple network when it accesses data on some
server (CIFS) than you are guaranteed (through mandatory to implement)
in your enterprise class storage network. 

beepy


From owner-ips@ece.cmu.edu  Fri Aug  3 06:16:15 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA12079
	for <ips-archive@odin.ietf.org>; Fri, 3 Aug 2001 06:16:15 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f739W1b25958
	for ips-outgoing; Fri, 3 Aug 2001 05:32:01 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7329ue10165
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 22:09:56 -0400 (EDT)
Received: from postoffice.sarnoff.com ([127.0.0.1]) by
          postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
          SMTP id GHGYU300.9DL for <ips@ece.cmu.edu>; Thu, 2 Aug 2001
          21:58:51 -0400 
Received: from nova.sarnoff.com ([130.33.8.27]) by
          postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
          ESMTP id GH5OXW00.HBB; Fri, 27 Jul 2001 19:51:32 -0400 
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
	by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id IAA25807;
	Wed, 25 Jul 2001 08:01:32 -0400 (EDT)
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA26191
	for ietf-123-outbound.05@ietf.org; Wed, 25 Jul 2001 07:25:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA25405
	for <all-ietf@loki.ietf.org>; Wed, 25 Jul 2001 06:31:46 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07301;
	Wed, 25 Jul 2001 06:31:45 -0400 (EDT)
Message-Id: <200107251031.GAA07301@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ips@ece.cmu.edu
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ips-fcovertcpip-04.txt
Date: Wed, 25 Jul 2001 06:31:44 -0400
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Storage Working Group of the IETF.

	Title		: Fibre Channel Over TCP/IP (FCIP)
	Author(s)	: M. Rajagopal, R. Bhagwat et al.
	Filename	: draft-ietf-ips-fcovertcpip-04.txt
	Pages		: 42
	Date		: 24-Jul-01
	
Fibre Channel Over TCP/IP (FCIP) describes mechanisms that allow the
interconnection of islands of Fibre Channel storage area networks
over IP-based networks to form a unified storage area network in a
single Fibre Channel fabric. FCIP relies on IP-based network
services to provide the connectivity between the storage area
network islands over local area networks, metropolitan area
networks, or wide area networks.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ips-fcovertcpip-04.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ips-fcovertcpip-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ips-fcovertcpip-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010724132046.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ips-fcovertcpip-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ips-fcovertcpip-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010724132046.I-D@ietf.org>

--OtherAccess--

--NextPart--



From owner-ips@ece.cmu.edu  Fri Aug  3 07:00:19 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA12058
	for <ips-archive@odin.ietf.org>; Fri, 3 Aug 2001 06:15:16 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f739VDA25906
	for ips-outgoing; Fri, 3 Aug 2001 05:31:13 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f738sie24348
	for <ips@ece.cmu.edu>; Fri, 3 Aug 2001 04:54:44 -0400 (EDT)
Received: from postoffice.sarnoff.com ([127.0.0.1]) by
          postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
          SMTP id GHHF9F00.HQI for <ips@ece.cmu.edu>; Fri, 3 Aug 2001
          03:53:39 -0400 
Received: from nova.sarnoff.com ([130.33.8.27]) by
          postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
          ESMTP id GH5OXW00.HBB; Fri, 27 Jul 2001 19:51:32 -0400 
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
	by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id IAA25807;
	Wed, 25 Jul 2001 08:01:32 -0400 (EDT)
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA26191
	for ietf-123-outbound.05@ietf.org; Wed, 25 Jul 2001 07:25:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA25405
	for <all-ietf@loki.ietf.org>; Wed, 25 Jul 2001 06:31:46 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07301;
	Wed, 25 Jul 2001 06:31:45 -0400 (EDT)
Message-Id: <200107251031.GAA07301@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ips@ece.cmu.edu
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ips-fcovertcpip-04.txt
Date: Wed, 25 Jul 2001 06:31:44 -0400
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Storage Working Group of the IETF.

	Title		: Fibre Channel Over TCP/IP (FCIP)
	Author(s)	: M. Rajagopal, R. Bhagwat et al.
	Filename	: draft-ietf-ips-fcovertcpip-04.txt
	Pages		: 42
	Date		: 24-Jul-01
	
Fibre Channel Over TCP/IP (FCIP) describes mechanisms that allow the
interconnection of islands of Fibre Channel storage area networks
over IP-based networks to form a unified storage area network in a
single Fibre Channel fabric. FCIP relies on IP-based network
services to provide the connectivity between the storage area
network islands over local area networks, metropolitan area
networks, or wide area networks.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ips-fcovertcpip-04.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ips-fcovertcpip-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ips-fcovertcpip-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010724132046.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ips-fcovertcpip-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ips-fcovertcpip-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010724132046.I-D@ietf.org>

--OtherAccess--

--NextPart--



From owner-ips@ece.cmu.edu  Fri Aug  3 10:58:49 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17513
	for <ips-archive@odin.ietf.org>; Fri, 3 Aug 2001 10:58:48 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f73DYkA15511
	for ips-outgoing; Fri, 3 Aug 2001 09:34:46 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from emulex.emulex.com (emulex.emulex.com [138.239.112.1])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f73DYge15496
	for <ips@ece.cmu.edu>; Fri, 3 Aug 2001 09:34:43 -0400 (EDT)
Received: from nsboston.ma.emulex.com (nsboston.ma.emulex.com [172.16.12.10])
	by emulex.emulex.com (8.9.1a/8.9.1) with ESMTP id GAA18340;
	Fri, 3 Aug 2001 06:34:46 -0700 (PDT)
Received: from xbl.ad.emulex.com (xbl.ma.emulex.com [172.16.12.11])
	by nsboston.ma.emulex.com (8.9.1a/8.9.1) with ESMTP id JAA08936;
	Fri, 3 Aug 2001 09:34:32 -0400 (EDT)
Received: by xbl.ad.emulex.com with Internet Mail Service (5.5.2653.19)
	id <QFN82LVB>; Fri, 3 Aug 2001 09:35:22 -0400
Message-ID: <3356669BBE90C448AD4645C843E2BF280A0420@xbl.ad.emulex.com>
From: "Williams, Jim" <Jim.Williams@emulex.com>
To: "'Black_David@emc.com'" <Black_David@emc.com>, bill@strahm.net,
        ips@ece.cmu.edu
Subject: RE: saag whyenc draft (was RE: Security Gateways)
Date: Fri, 3 Aug 2001 09:35:12 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

> 
> 
> -----Original Message-----
> From: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Thursday, August 02, 2001 7:11 PM
> To: bill@strahm.net; ips@ece.cmu.edu
> Subject: saag whyenc draft (was RE: Security Gateways)
> 
> 
> 
> > I also want to be careful about products that are multi
> > gigabit products, but to be "standards compliant" include a software
> > encryption module that runs at 12 Mbit/Sec and is completely useless.  I
> > would rather have that product without security, so that I KNOW that the
> > security isn't there...
> 
> OTOH, this argument may have some merit, as I would definitely expect
> to see things like this sort of brain-damaged software encryption module
> if confidentiality becomes a "MUST implement".  Let me be clear that
> this applies only to confidentiality -- a small amount of thought about
> the consequences of impersonation and a script kiddie's TCP hijack attack
> leads to the conclusion that authentication and cryptographic integrity
> have to be "MUST implement" for iSCSI, FCIP, and iFCP.
> 
> Let us know the results of your discussion.
> 
> Thanks,  --David

I think with regards to both confidentiality and authentication (IPSec
authentication, not login authentication) one can expect three types
of implementations.

1.  Products that claim full RFC compliance in big letters with a 
    small foot note stating that an external gateway is required
    for compliance with the security section of the RFC.

2.  Products that claim full RFC compliance but drop to 1% normal
    throughput whenever security is enabled, and whose customers
    will buy an external gateway anyway when they want security.

3.  Products that can run security at full speed but which are
    not competative in terms of cost/performance with 1 and 2.

I don't have a problem with any of these, but I think it's critically
important that the security protocol for iSCSI doesn't preclude
options 1 and 2.  In terms of actual deployment, I suspect these
will be the most common.  A requirement for keying IPSec in
a way that is not compatable with existing security gateways
would be a serious setback to general acceptance of iSCSI, and
could potentially result in the emergence of a de facto standard
(no security) which diverges from the RFC standard (manditory 
security).  I don't think diverging standards are in anyone's
best interest, especially if there are practical ways to 
aviod it.




From owner-ips@ece.cmu.edu  Fri Aug  3 11:12:02 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17847
	for <ips-archive@odin.ietf.org>; Fri, 3 Aug 2001 11:12:02 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f73DNuW14986
	for ips-outgoing; Fri, 3 Aug 2001 09:23:56 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f73DNqe14981
	for <ips@ece.cmu.edu>; Fri, 3 Aug 2001 09:23:52 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id PAA280554
	for <ips@ece.cmu.edu>; Fri, 3 Aug 2001 15:23:44 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f73DNd4119122
	for <ips@ece.cmu.edu>; Fri, 3 Aug 2001 15:23:44 +0200
Importance: Normal
Subject: Re: iSCSI: SendTargets in login or FFP?
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF9B523DDD.768C7D36-ONC2256A9D.0049DA5C@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Fri, 3 Aug 2001 16:27:32 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 03/08/2001 16:23:43
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Yes - There is probably a need for FFP and SendTargets falls in this
category.

Julo

"Robert D. Russell" <rdr@mars.iol.unh.edu> on 02-08-2001 20:49:08

Please respond to "Robert D. Russell" <rdr@mars.iol.unh.edu>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   ips@ece.cmu.edu
Subject:  Re: iSCSI: SendTargets in login or FFP?




Julian:

In order to try to organize information about the key parameters,
I developed the attached ASCII text file which characterizes each
key from draft 7 according to 4 attributes:

1.  what type of key it is, which determines in which login phase
    it can be used.
2.  when the key can be negotiated.
3.  who can send the key.
4.  the scope of application of the key's information.

The values of these attributes were drawn from Appendixes A and D.
The only new information added (i.e., information not in draft 7)
is the characterization of keys into 3 types - security, operational,
and informational, where the new category "informational"
applies to keys, such as TargetAddress, TargetName, InitiatorName,
etc. which can be sent in either the security or operational
subphases of login, and which simply provide information rather
than negotiate values.

There is still a question with regard to the SendTargets key
-- many of the recent postings regarding the use of SendTargets for
discovery sessions indicates that people expect this key to be used
only in Full Feature Phase.  Quoting from Mark Bakke's e-mail of
24-July:

> "Anyway, SendTargets is always done in full feature phase, and
> never during the login phase."

and later in the same message:

> No.  The point of doing SendTarget in full feature phase is that the
> initiators must first go through their normal authentication;
> SendTargets responses will often be based on the initiator's identity.

Is this limitation correct?  Or does this limitation apply only for
discovery sessions?

The draft currently characterizes SendTargets as ALL, which
does not imply this limitation.

If SendTargets is so limited, it would be the only key that could not
be used somewhere during login.  To cover this case in the attached table
I have added the category FFP to the 3 existing categories IO, LO,
and ALL.  Draft 7 would have to be modified to reflect this.

If this limitation is not correct, the category FPP
disappears and the ALL category would continue to apply to SendTargets
(and targest can expect to receive SendTargets during login).

Thanks,

Bob Russell
InterOperability Lab
University of New Hampshire
rdr@iol.unh.edu
603-862-3774



On Tue, 24 Jul 2001, Julian Satran wrote:

> Eddy,
>
> SendTargets can be used in both discovery session and normal session.
> Would you please clarify when you think this restriction should apply?
>
> Julo
>
> "Eddy Quicksall" <EQuicksall@mediaone.net> on 24-07-2001 04:15:56
>
> Please respond to "Eddy Quicksall" <EQuicksall@mediaone.net>
>
> To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> cc:
> Subject:  iSCSI: SendTargets in login or FFP?
>
>
>
>
> The spec says:
>
>   An initiator can log into this default target [iSCSI]
>   name, and use a command called "SendTargets" to retrieve a list of
>   iSCSI targets that exist at that address
>
> I assume this means the SendTargets would be used in Full Feature Phase
...
> the initiator would login using TargetName=iSCSI. That would get into FFP
> and then the initiator would use SendTargets= to get the list of targets.
> Then, login again with the appropriate target.
>
> The spec says:
>
>   In full feature phase the initiator may send SCSI
>   commands and data to the various LUs on the target by wrapping them
>   in iSCSI PDUs that go over the established iSCSI session.
>
> That means the target has to do something if a CDB is received to the
iSCSI
> canonical target. The spec doesn't give any suggestions here. I am
assuming
> the target would give a reject PDU with a reason of "Protocol Error"
(code
> 5).
>
> Do you agree that this is what should happen?
>
> We shouldn't require that the target enter FFP when it would not be valid
> to
> send a CDB. I think SendTargets should be done only at LO or IO time and
> that iSCSI should not get you into FFP. That would simplify coding.
>
>
> Eddy_Quicksall@iVivity.com
>
>
>
>

 - keys.txt





From owner-ips@ece.cmu.edu  Fri Aug  3 13:12:42 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21839
	for <ips-archive@odin.ietf.org>; Fri, 3 Aug 2001 13:12:42 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f73FVmY21620
	for ips-outgoing; Fri, 3 Aug 2001 11:31:48 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from bbnrel4.net.external.hp.com (bbnrel4.net.external.hp.com [155.208.254.68])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f73FVje21610
	for <ips@ece.cmu.edu>; Fri, 3 Aug 2001 11:31:45 -0400 (EDT)
Received: from quasit.br.itc.hp.com (quasit.br.itc.hp.com [15.145.8.135])
	by bbnrel4.net.external.hp.com (Postfix) with ESMTP
	id E0B372899E; Fri,  3 Aug 2001 17:31:32 +0200 (METDST)
Received: from loddon.br.itc.hp.com (loddon.br.itc.hp.com [15.145.8.166])
	by quasit.br.itc.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id QAA20659;
	Fri, 3 Aug 2001 16:31:29 +0100 (BST)
Received: from 15.145.8.166 by loddon.br.itc.hp.com (InterScan E-Mail VirusWall NT); Fri, 03 Aug 2001 16:31:29 +0100 (GMT Daylight Time)
Received: by loddon.br.itc.hp.com with Internet Mail Service (5.5.2653.19)
	id <PPJNKBZ5>; Fri, 3 Aug 2001 16:31:29 +0100
Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC101E7A7FD@dickens.bri.hp.com>
From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <matthew_burbridge@hp.com>
To: "'Robert D. Russell'" <rdr@mars.iol.unh.edu>,
        Julian Satran <Julian_Satran@il.ibm.com>
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: SendTargets in login or FFP?
Date: Fri, 3 Aug 2001 16:31:24 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Hi Robert,

In your attachment, you have stated that FMarker (and its dependencies) are
per connection.  I believe this was the case in 0.6 but in 0.7 it is now on
the LO connection and therefore is it not per session or am I missing
something here?

Cheers

Matthew Burbridge
Senior Development Engineer
NIS-Bristol
Hewlett Packard
Telnet: 312 7010
E-mail: matthewb@bri.hp.com
 

-----Original Message-----
From: Robert D. Russell [mailto:rdr@mars.iol.unh.edu]
Sent: Thursday, August 02, 2001 6:49 PM
To: Julian Satran
Cc: ips@ece.cmu.edu
Subject: Re: iSCSI: SendTargets in login or FFP?


Julian:

In order to try to organize information about the key parameters,
I developed the attached ASCII text file which characterizes each
key from draft 7 according to 4 attributes:

1.  what type of key it is, which determines in which login phase
    it can be used.
2.  when the key can be negotiated.
3.  who can send the key.
4.  the scope of application of the key's information.

The values of these attributes were drawn from Appendixes A and D.
The only new information added (i.e., information not in draft 7)
is the characterization of keys into 3 types - security, operational,
and informational, where the new category "informational"
applies to keys, such as TargetAddress, TargetName, InitiatorName,
etc. which can be sent in either the security or operational
subphases of login, and which simply provide information rather
than negotiate values.

There is still a question with regard to the SendTargets key
-- many of the recent postings regarding the use of SendTargets for
discovery sessions indicates that people expect this key to be used
only in Full Feature Phase.  Quoting from Mark Bakke's e-mail of
24-July:

> "Anyway, SendTargets is always done in full feature phase, and
> never during the login phase."

and later in the same message:

> No.  The point of doing SendTarget in full feature phase is that the
> initiators must first go through their normal authentication;
> SendTargets responses will often be based on the initiator's identity.

Is this limitation correct?  Or does this limitation apply only for
discovery sessions?

The draft currently characterizes SendTargets as ALL, which
does not imply this limitation.

If SendTargets is so limited, it would be the only key that could not
be used somewhere during login.  To cover this case in the attached table
I have added the category FFP to the 3 existing categories IO, LO,
and ALL.  Draft 7 would have to be modified to reflect this.

If this limitation is not correct, the category FPP
disappears and the ALL category would continue to apply to SendTargets
(and targest can expect to receive SendTargets during login).

Thanks,

Bob Russell
InterOperability Lab
University of New Hampshire
rdr@iol.unh.edu
603-862-3774



On Tue, 24 Jul 2001, Julian Satran wrote:

> Eddy,
> 
> SendTargets can be used in both discovery session and normal session.
> Would you please clarify when you think this restriction should apply?
> 
> Julo
> 
> "Eddy Quicksall" <EQuicksall@mediaone.net> on 24-07-2001 04:15:56
> 
> Please respond to "Eddy Quicksall" <EQuicksall@mediaone.net>
> 
> To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> cc:
> Subject:  iSCSI: SendTargets in login or FFP?
> 
> 
> 
> 
> The spec says:
> 
>   An initiator can log into this default target [iSCSI]
>   name, and use a command called "SendTargets" to retrieve a list of
>   iSCSI targets that exist at that address
> 
> I assume this means the SendTargets would be used in Full Feature Phase
...
> the initiator would login using TargetName=iSCSI. That would get into FFP
> and then the initiator would use SendTargets= to get the list of targets.
> Then, login again with the appropriate target.
> 
> The spec says:
> 
>   In full feature phase the initiator may send SCSI
>   commands and data to the various LUs on the target by wrapping them
>   in iSCSI PDUs that go over the established iSCSI session.
> 
> That means the target has to do something if a CDB is received to the
iSCSI
> canonical target. The spec doesn't give any suggestions here. I am
assuming
> the target would give a reject PDU with a reason of "Protocol Error" (code
> 5).
> 
> Do you agree that this is what should happen?
> 
> We shouldn't require that the target enter FFP when it would not be valid
> to
> send a CDB. I think SendTargets should be done only at LO or IO time and
> that iSCSI should not get you into FFP. That would simplify coding.
> 
> 
> Eddy_Quicksall@iVivity.com
> 
> 
> 
> 


From owner-ips@ece.cmu.edu  Fri Aug  3 13:27:34 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22249
	for <ips-archive@odin.ietf.org>; Fri, 3 Aug 2001 13:27:34 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f73GQw424476
	for ips-outgoing; Fri, 3 Aug 2001 12:26:58 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from iol.unh.edu (mars.iol.unh.edu [132.177.121.222])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f73GQue24471
	for <ips@ece.cmu.edu>; Fri, 3 Aug 2001 12:26:56 -0400 (EDT)
Received: from localhost (rdr@localhost)
	by iol.unh.edu (8.9.3/8.9.3) with ESMTP id MAA13565;
	Fri, 3 Aug 2001 12:26:49 -0400 (EDT)
Date: Fri, 3 Aug 2001 12:26:49 -0400
From: "Robert D. Russell" <rdr@mars.iol.unh.edu>
To: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <matthew_burbridge@hp.com>
cc: Julian Satran <Julian_Satran@il.ibm.com>, ips@ece.cmu.edu
Subject: RE: iSCSI: SendTargets in login or FFP?
In-Reply-To: <0B9A57FF1D57D411B47500D0B73E5CC101E7A7FD@dickens.bri.hp.com>
Message-ID: <Pine.SGI.4.20.0108031221180.13176-100000@mars.iol.unh.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Matthew:

Interesting -- in draft 0.6 the label was IO, but it has been
changed to LO in draft 0.7.  However, other parts of draft 0.7 still
clearly indicate this is a per-connection parameter.  See for example,
the description in Appendix C page 155 which says in the 3rd paragraph:

"The use of markers is negotiable.  The initiator and target MAY
indicate their readiness to receive and/or send markers during login
separately for each connection."

Furthermore, the definition of keys 19 (FMarker), 20 (RFMarkInt),
21 (SFMarkInt) all contain the explicit statement:

"This is a connection specific parameter."

Therefore, I would conclude that the change of IO in version 0.6 to
LO in version 0.7 is a typo, and should revert back to IO for these
3 keys.

Julian, is this correct?

Thanks,

Bob


On Fri, 3 Aug 2001, BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) wrote:

> Hi Robert,
> 
> In your attachment, you have stated that FMarker (and its dependencies) are
> per connection.  I believe this was the case in 0.6 but in 0.7 it is now on
> the LO connection and therefore is it not per session or am I missing
> something here?
> 
> Cheers
> 
> Matthew Burbridge
> Senior Development Engineer
> NIS-Bristol
> Hewlett Packard
> Telnet: 312 7010
> E-mail: matthewb@bri.hp.com
>  
> 
> -----Original Message-----
> From: Robert D. Russell [mailto:rdr@mars.iol.unh.edu]
> Sent: Thursday, August 02, 2001 6:49 PM
> To: Julian Satran
> Cc: ips@ece.cmu.edu
> Subject: Re: iSCSI: SendTargets in login or FFP?
> 
> 
> Julian:
> 
> In order to try to organize information about the key parameters,
> I developed the attached ASCII text file which characterizes each
> key from draft 7 according to 4 attributes:
> 
> 1.  what type of key it is, which determines in which login phase
>     it can be used.
> 2.  when the key can be negotiated.
> 3.  who can send the key.
> 4.  the scope of application of the key's information.
> 
> The values of these attributes were drawn from Appendixes A and D.
> The only new information added (i.e., information not in draft 7)
> is the characterization of keys into 3 types - security, operational,
> and informational, where the new category "informational"
> applies to keys, such as TargetAddress, TargetName, InitiatorName,
> etc. which can be sent in either the security or operational
> subphases of login, and which simply provide information rather
> than negotiate values.
> 
> There is still a question with regard to the SendTargets key
> -- many of the recent postings regarding the use of SendTargets for
> discovery sessions indicates that people expect this key to be used
> only in Full Feature Phase.  Quoting from Mark Bakke's e-mail of
> 24-July:
> 
> > "Anyway, SendTargets is always done in full feature phase, and
> > never during the login phase."
> 
> and later in the same message:
> 
> > No.  The point of doing SendTarget in full feature phase is that the
> > initiators must first go through their normal authentication;
> > SendTargets responses will often be based on the initiator's identity.
> 
> Is this limitation correct?  Or does this limitation apply only for
> discovery sessions?
> 
> The draft currently characterizes SendTargets as ALL, which
> does not imply this limitation.
> 
> If SendTargets is so limited, it would be the only key that could not
> be used somewhere during login.  To cover this case in the attached table
> I have added the category FFP to the 3 existing categories IO, LO,
> and ALL.  Draft 7 would have to be modified to reflect this.
> 
> If this limitation is not correct, the category FPP
> disappears and the ALL category would continue to apply to SendTargets
> (and targest can expect to receive SendTargets during login).
> 
> Thanks,
> 
> Bob Russell
> InterOperability Lab
> University of New Hampshire
> rdr@iol.unh.edu
> 603-862-3774
> 
> 
> 
> On Tue, 24 Jul 2001, Julian Satran wrote:
> 
> > Eddy,
> > 
> > SendTargets can be used in both discovery session and normal session.
> > Would you please clarify when you think this restriction should apply?
> > 
> > Julo
> > 
> > "Eddy Quicksall" <EQuicksall@mediaone.net> on 24-07-2001 04:15:56
> > 
> > Please respond to "Eddy Quicksall" <EQuicksall@mediaone.net>
> > 
> > To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> > cc:
> > Subject:  iSCSI: SendTargets in login or FFP?
> > 
> > 
> > 
> > 
> > The spec says:
> > 
> >   An initiator can log into this default target [iSCSI]
> >   name, and use a command called "SendTargets" to retrieve a list of
> >   iSCSI targets that exist at that address
> > 
> > I assume this means the SendTargets would be used in Full Feature Phase
> ...
> > the initiator would login using TargetName=iSCSI. That would get into FFP
> > and then the initiator would use SendTargets= to get the list of targets.
> > Then, login again with the appropriate target.
> > 
> > The spec says:
> > 
> >   In full feature phase the initiator may send SCSI
> >   commands and data to the various LUs on the target by wrapping them
> >   in iSCSI PDUs that go over the established iSCSI session.
> > 
> > That means the target has to do something if a CDB is received to the
> iSCSI
> > canonical target. The spec doesn't give any suggestions here. I am
> assuming
> > the target would give a reject PDU with a reason of "Protocol Error" (code
> > 5).
> > 
> > Do you agree that this is what should happen?
> > 
> > We shouldn't require that the target enter FFP when it would not be valid
> > to
> > send a CDB. I think SendTargets should be done only at LO or IO time and
> > that iSCSI should not get you into FFP. That would simplify coding.
> > 
> > 
> > Eddy_Quicksall@iVivity.com
> > 
> > 
> > 
> > 
> 



From owner-ips@ece.cmu.edu  Fri Aug  3 14:17:35 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23384
	for <ips-archive@odin.ietf.org>; Fri, 3 Aug 2001 14:17:34 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f73Gxwr26048
	for ips-outgoing; Fri, 3 Aug 2001 12:59:58 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e33.bld.us.ibm.com (e33.co.us.ibm.com [32.97.110.131])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f73Gxve26043
	for <ips@ece.cmu.edu>; Fri, 3 Aug 2001 12:59:57 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e33.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA41654;
	Fri, 3 Aug 2001 11:57:52 -0500
Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f73GxsX182076;
	Fri, 3 Aug 2001 10:59:55 -0600
X-Priority: 1 (High)
Importance: Normal
Subject: RE: Iscsi: Fault tolerance
To: "Merhar, Milan" <mmerhar@pirus.com>
Cc: "'Sanjeev Bhagat (TRIPACE/Zoetermeer)'" <sbhagat@tripace.com>,
        ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OF4B733DA7.EA5CB4D3-ON88256A9D.005C0C46@boulder.ibm.com>
From: "John Hufferd" <hufferd@us.ibm.com>
Date: Fri, 3 Aug 2001 09:59:04 -0700
X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.6 |December 14, 2000) at
 08/03/2001 10:59:54 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


What Milan says is probable, however, let me address it in a slightly
different way.

There are Servers, Today, that share their Data on a FC SAN.  They have
either a Shared File System or use something like "SANergy" to share out
the files.  In the case of a shared file system, each surviving member of
the Cluster can continue to access the Disks.  In the case of SANergy, the
other members can continue until the extent list needs to be updated.

These are solutions that are in use today, in FC SAN environments.  If you
are talking about general clients scattered around a campus that need
sharing, they will best be handled by a Filer (as Milan said).

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com


"Merhar, Milan" <mmerhar@pirus.com>@ece.cmu.edu on 07/31/2001 12:26:49 PM

Sent by:  owner-ips@ece.cmu.edu


To:   "'Sanjeev Bhagat (TRIPACE/Zoetermeer)'" <sbhagat@tripace.com>
cc:   ips@ece.cmu.edu
Subject:  RE: Iscsi: Fault tolerance



Sanjeev,

I think that your clients will actually be accessing a file system
your server has created on the raw volume accessed by iSCSI.  They do so
by using a network file protocol - in the case of Microsoft products,
probably CIFS, connecting to the server which then in turn does
block mode accesses to the iSCSI volume.

So, if the server goes away, the clients can no longer reach
the files stored on the iSCSI device.  Of course, unlike
a server with a direct-attached drive, in the situation you
describe another server could step into the place of the first one,
mounting the iSCSI volume and again offering shared file access to
those clients. (In other words, you've got a NAS server accessing
its storage over a SAN - an IP SAN.)

Depending on how the server "went away", there may be some startup
transients bringing its replacement online, as the file system is
verified, cleaned up, etc.  The transition is also not transparent
to the clients, as they will need to reconnect to this new server,
with its different IP address, as well.

Hope this helps.

     - milan


Milan Merhar, Chief Scientist, Pirus Networks

> -----Original Message-----
> From: Sanjeev Bhagat (TRIPACE/Zoetermeer) [mailto:sbhagat@tripace.com]
> Sent: Tuesday, July 31, 2001 2:18 PM
> To: 'Julian Satran'; ips@ece.cmu.edu
> Subject: RE: Iscsi: Fault tolerance
>
>
> Julian and all!!
>
> The server connects to the iscsi target (Say just a disk)
> with the help of
> an iSCSI initiator driver installed on the server. The NT
> server thus shows
> an extra physical disk present on the server. The sys admin
> then assigns the
> permission to other clients/users to share this target. The
> clients can then
> access this this disk (iscsi target) or any sharable
> directory on this disk
> (iscsi target)present on the server by connecting to the network.
>
> Hope it is clear by now!! If it is not then please provide me
> your contact
> number and I will try to explain you better.
>
> I am sorry if there is any ambiguity but i cant find better words to
> explain.
>
> Sanjeev
>
> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Tuesday, July 31, 2001 6:35 PM
> To: ips@ece.cmu.edu
> Subject: Re: Iscsi: Fault tolerance
>
>
>
> How exactly will the clients use the initiator on the server?
>
> Julo
>
> "Sanjeev Bhagat (TRIPACE/Zoetermeer)" <sbhagat@tripace.com>
> on 31-07-2001
> 18:57:41
>
> Please respond to "Sanjeev Bhagat (TRIPACE/Zoetermeer)"
>       <sbhagat@tripace.com>
>
> To:   "'IPS Reflector'" <ips@ece.cmu.edu>
> cc:
> Subject:  Iscsi: Fault tolerance
>
>
>
>
> Hi
>
> Consider a case where the clients of a Windows NT server are
> accessing the
> iSCSI target with iSCSI initiator driver installed  on the Windows NT
> server
> to access a ISCSI target on NET. So all the clients on this Windows NT
> server can share the iSCSI target of this server. In case the
> server goes
> down , will the clients still be able to access the iSCSI Target??
>
> I hope I have put my question peoperly. In case not then
> please feel free
> to
> call me at +31 624685051
>
>
> Sincerely,
>
> Sanjeev Bhagat
>
> Tripace Europe
>
>
>  - att1.htm
>
>





From owner-ips@ece.cmu.edu  Fri Aug  3 16:06:36 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25890
	for <ips-archive@odin.ietf.org>; Fri, 3 Aug 2001 16:06:36 -0400 (EDT)
From: owner-ips@ece.cmu.edu
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f73Itg402027
	for ips-outgoing; Fri, 3 Aug 2001 14:55:42 -0400 (EDT)
Date: Fri, 3 Aug 2001 14:55:42 -0400 (EDT)
Message-Id: <200108031855.f73Itg402027@ece.cmu.edu>
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f

Thanks for adding that, John. These "direct" file sharing 
solutions are powerful tools, but not often seen in 
general use at present. The ones that I'm familiar with 
run over FC SANs, although there is no reason why they 
wouldn't run very nicely over iSCSI.
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

In your application, the box that had been a "file server" 
now becomes a "metadata server" and "lock manager".  Once 
the clients are presented with the list of blocks comprising 
a file (and the write lock, if they're doing writes), they 
can go off and fetch the actual data from the iSCSI volume 
themselves.

A failed metadata server behaves pretty much like a 
failed file server in terms of bringing a spare online, doing 
file system recovery, etc, except that clients already 
having been granted file access can continue accessing 
those blocks (and only those blocks) during the outage.

As for client support, a special driver is needed on each client, 
to handle the split metadata/direct access operations.

- milan

> -----Original Message-----
> From: John Hufferd [mailto:hufferd@us.ibm.com]
> Sent: Friday, August 03, 2001 12:59 PM
> To: Merhar, Milan
> Cc: 'Sanjeev Bhagat (TRIPACE/Zoetermeer)'; ips@ece.cmu.edu
> Subject: RE: Iscsi: Fault tolerance
> 
> 
> 
> What Milan says is probable, however, let me address it in a slightly
> different way.
> 
> There are Servers, Today, that share their Data on a FC SAN.  
> They have
> either a Shared File System or use something like "SANergy" 
> to share out
> the files.  In the case of a shared file system, each 
> surviving member of
> the Cluster can continue to access the Disks.  In the case of 
> SANergy, the
> other members can continue until the extent list needs to be updated.
> 
> These are solutions that are in use today, in FC SAN 
> environments.  If you
> are talking about general clients scattered around a campus that need
> sharing, they will best be handled by a Filer (as Milan said).
> 
> .
> .
> .
> John L. Hufferd
> Senior Technical Staff Member (STSM)
> IBM/SSG San Jose Ca
> Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
> Home Office (408) 997-6136
> Internet address: hufferd@us.ibm.com
> 
> 
> "Merhar, Milan" <mmerhar@pirus.com>@ece.cmu.edu on 07/31/2001 
> 12:26:49 PM
> 
> Sent by:  owner-ips@ece.cmu.edu
> 
> 
> To:   "'Sanjeev Bhagat (TRIPACE/Zoetermeer)'" <sbhagat@tripace.com>
> cc:   ips@ece.cmu.edu
> Subject:  RE: Iscsi: Fault tolerance
> 
> 
> 
> Sanjeev,
> 
> I think that your clients will actually be accessing a file system
> your server has created on the raw volume accessed by iSCSI.  
> They do so
> by using a network file protocol - in the case of Microsoft products,
> probably CIFS, connecting to the server which then in turn does
> block mode accesses to the iSCSI volume.
> 
> So, if the server goes away, the clients can no longer reach
> the files stored on the iSCSI device.  Of course, unlike
> a server with a direct-attached drive, in the situation you
> describe another server could step into the place of the first one,
> mounting the iSCSI volume and again offering shared file access to
> those clients. (In other words, you've got a NAS server accessing
> its storage over a SAN - an IP SAN.)
> 
> Depending on how the server "went away", there may be some startup
> transients bringing its replacement online, as the file system is
> verified, cleaned up, etc.  The transition is also not transparent
> to the clients, as they will need to reconnect to this new server,
> with its different IP address, as well.
> 
> Hope this helps.
> 
>      - milan
> 
> 
> Milan Merhar, Chief Scientist, Pirus Networks
> 
> > -----Original Message-----
> > From: Sanjeev Bhagat (TRIPACE/Zoetermeer) 
> [mailto:sbhagat@tripace.com]
> > Sent: Tuesday, July 31, 2001 2:18 PM
> > To: 'Julian Satran'; ips@ece.cmu.edu
> > Subject: RE: Iscsi: Fault tolerance
> >
> >
> > Julian and all!!
> >
> > The server connects to the iscsi target (Say just a disk)
> > with the help of
> > an iSCSI initiator driver installed on the server. The NT
> > server thus shows
> > an extra physical disk present on the server. The sys admin
> > then assigns the
> > permission to other clients/users to share this target. The
> > clients can then
> > access this this disk (iscsi target) or any sharable
> > directory on this disk
> > (iscsi target)present on the server by connecting to the network.
> >
> > Hope it is clear by now!! If it is not then please provide me
> > your contact
> > number and I will try to explain you better.
> >
> > I am sorry if there is any ambiguity but i cant find better words to
> > explain.
> >
> > Sanjeev
> >
> > -----Original Message-----
> > From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > Sent: Tuesday, July 31, 2001 6:35 PM
> > To: ips@ece.cmu.edu
> > Subject: Re: Iscsi: Fault tolerance
> >
> >
> >
> > How exactly will the clients use the initiator on the server?
> >
> > Julo
> >
> > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" <sbhagat@tripace.com>
> > on 31-07-2001
> > 18:57:41
> >
> > Please respond to "Sanjeev Bhagat (TRIPACE/Zoetermeer)"
> >       <sbhagat@tripace.com>
> >
> > To:   "'IPS Reflector'" <ips@ece.cmu.edu>
> > cc:
> > Subject:  Iscsi: Fault tolerance
> >
> >
> >
> >
> > Hi
> >
> > Consider a case where the clients of a Windows NT server are
> > accessing the
> > iSCSI target with iSCSI initiator driver installed  on the 
> Windows NT
> > server
> > to access a ISCSI target on NET. So all the clients on this 
> Windows NT
> > server can share the iSCSI target of this server. In case the
> > server goes
> > down , will the clients still be able to access the iSCSI Target??
> >
> > I hope I have put my question peoperly. In case not then
> > please feel free
> > to
> > call me at +31 624685051
> >
> >
> > Sincerely,
> >
> > Sanjeev Bhagat
> >
> > Tripace Europe
> >
> >
> >  - att1.htm
> >
> >
> 
> 
> 



From owner-ips@ece.cmu.edu  Fri Aug  3 16:08:16 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25934
	for <ips-archive@odin.ietf.org>; Fri, 3 Aug 2001 16:08:16 -0400 (EDT)
From: owner-ips@ece.cmu.edu
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f73Iuht02059
	for ips-outgoing; Fri, 3 Aug 2001 14:56:43 -0400 (EDT)
Date: Fri, 3 Aug 2001 14:56:43 -0400 (EDT)
Message-Id: <200108031856.f73Iuht02059@ece.cmu.edu>
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f

> Bernard Aboba wrote:
> 
> Integrity protection via new MACs such as UMAC is *not* 
> expensive. This is
> a myth. See http://www.cs.ucdavis.edu/~rogaway/umac/perf00.html 
>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Bernard,

Thanks for the pointer to some current research in this area.

That paper gave cycles/byte numbers for their algorithm, on 
a Pentium III and PowerPC.  For now, I'll comment on the PPC 
numbers, because that family is available as an embeddable core
that can be integrated into hardware, while the Pentium III is not. 
For 1500-byte messages, it looks like UMAC will take between 
2.7 and 3.7 CPU clocks per byte (estimates, as no numbers 
were given for the full UMAC function on PPC).  

That indicates that I'd have to run my core at 600-800 Mhz 
to handle a single full duplex Gigabit Ethernet port, assuming
I have the packets in memory that's fast enough to not stall the 
CPU, and that there's some way of getting packets into and out 
of that memory without interfering with the CPU.

I grant you that is "do-able," and it certainly is less expensive 
than HMAC-SHA1, but I wouldn't call it "cheap."  At least for 
some portion of the audience here, "cheap" may be measured by how 
many thousands of gates the implementation adds to the existing 
data path logic, and "fast" by how many gate delays were 
introduced into that path. 

So, I guess that puts me in agreement with Jim William's 
comments; security protocols MUST be supported, and 
supported in the context of a single standard, 
not a "de jure" standard and a "de facto" alternative.
And, if that means the standard must embrace non-monolithic 
"system level" compliance, then let's figure out how to 
do that properly, rather than declaring it illegal and hoping 
it will go away.

- milan






From owner-ips@ece.cmu.edu  Fri Aug  3 17:07:31 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29234
	for <ips-archive@odin.ietf.org>; Fri, 3 Aug 2001 17:07:31 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f73JYCm03872
	for ips-outgoing; Fri, 3 Aug 2001 15:34:12 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from va2mc.ummailbox.net (va2mc.ummailbox.net [64.210.247.23])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f73JYAe03864
	for <ips@ece.cmu.edu>; Fri, 3 Aug 2001 15:34:10 -0400 (EDT)
Received: from hqmailweb.COMMSTOR.Crossroads.com (HQMailWeb.Crossroads.com [63.237.99.250:25])
	by va2mc.ummailbox.net with ESMTP id D0803-1533-077000;
	Fri, 3 Aug 2001 19:33:57 GMT
Received: from HQMAILNODE1.COMMSTOR.Crossroads.com ([10.5.1.42]) by hqmailweb.COMMSTOR.Crossroads.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 3 Aug 2001 14:33:56 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: Review of the 07 draft
Date: Fri, 3 Aug 2001 14:33:56 -0500
Message-ID: <CFD808D1D39ACB47ABFF586D484CC52E261E4B@HQMAILNODE1.COMMSTOR.Crossroads.com>
Thread-Topic: Review of the 07 draft
Thread-Index: AcEcUzwkrwfPElacSaa//kEPa4YzYA==
From: "Robert Griswold" <rgriswold@Crossroads.com>
To: <Julian_Satran@il.ibm.com>
Cc: "Bill Moody" <bmoody@Crossroads.com>, <ips@ece.cmu.edu>
X-OriginalArrivalTime: 03 Aug 2001 19:33:56.0338 (UTC) FILETIME=[3C587D20:01C11C53]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f73JYAe03865
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit

Julian:

First, great work on this initiative and please forgive my huge email.  

We have undertaken a review of the 07 version, and even though
Crossroads will be at the meetings in London, we thought it would be
prudent to post these observations on the current specification.  If we
have completely misread the document, or have missed resolutions that
have come across the reflector, we apologize up front.  I have also sent
you some editorial only comments for your review.

++++++++++

Section 1.2.2.1 (and others):
The third paragraph up from the bottom of page 19 refers to the action
that a target should take when receiving commands outside of a range,
that are not correctly marked as immediate, with the right flags set.
The question is in regards to the MUST instruction on "silently ignore".
Assuming the I_T nexus is established, the devices are communicating and
the target receives what could only correctly be termed a protocol error
from the initiator it has established communication with, why would the
target not respond with an error back?  If in fact the error is
transport related, and the initiator really did send the correct PDU,
then the target being mute on the reception of the this command leaves
the initiator guessing.  There are other points in the specification
where the target is instructed to "silently ignore."  

Section 1.2.2.2:
The fifth paragraph indicates that a "large difference" between StatSN
and ExpStatSN may indicate a problem, but the number required by the
specification as the maximum before an initiator must take action is 2.1
Billion!  This seems like a very big number, and most implementers would
want to take action long before this limit was reached.  What is the
thinking behind this number?  Is there something we aren't
understanding?

Section 1.2.5:
On page 25, the second full paragraph indicates that the definition of
the use of target tags is not specifically specified by the protocol.
While we see possible uses for Target Transfer Tags, we would like to
understand if the author's feel that limiting the interpretation of its
use to that described in 2.17.4 would be helpful.  Clearly this 32-bit
field plays little role in the overall usefulness iSCSI command
protocol, so someone must have felt that it would have been a great idea
to have this in the specification.  Can that be described?

Section 1.2.6
This section covers the topic of connection termination, which is also
covered in the discussion of the Logout command in section 2.14.  There
seems to be some mingling of the concept of TCP logout with the concepts
around termination of a communication channel for storage protocols.
The concept of sending a logout, then waiting for the receiving end to
do some clean-up, flushing, and or additional communication seems odd to
the command.  The Logout directive should require no further
communication, and should put neither initiator nor target into the
state of expecting any such communication.  We would like to see the
Logout command (not the request for a logout) be free of any
expectations once sent, or received.  It seems logical that since the
initiator is the responsible party for sending this command (we would
also like to begin some discussion on a target only Logout command, like
SRP is working on now) that it would have done all of the required
cleanup and preparation before issuing the command.  Implementation of
target code to make decisions on what outstanding commands it should or
shouldn't give some credence to before breaking the connection seems out
of place. 

Section 1.2.7
On page 28, in the fourth to last paragraph in this section, there is a
description on how a target can assume an iSCSI Initiator Name, as
learned through authentication.  This is a confusing paragraph, and we
cannot determine if it is implying that the target should use the
initiator name it has been given through some service, or that it was
authorized to use by an initiator that discovered its iSCSI functions.
Can this paragraph be further expanded to clarify how the name was
determined?

Section 1.2.9.1
The last paragraph on this section has as 42 words in it's first
sentence, with the word "message" being used six times.  Suggested
rewording:
"Relying solely on the "message length" information from the iSCSI
message header may make it impossible to find iSCSI message boundaries
in subsequent TCP segments; due to the loss of a TCP segment containing
the iSCSI message length."

Section 1.2.9.2
The second full paragraph's last two sentences have odd wording.
Suggested rewording:
"In practice, though, iSCSI is not expected to handle infinitely long
streams; stream addressing will wrap around at 2**32-1."

The first sentence of the next paragraph is difficult to interpret.
Suggested rewording:
"This model assumes that the iSCSI layer will deliver complete PDUs to
underlying layers in single (atomic) operations."
You may also want to consider adding words that explain the reasoning
behind this assumption, as some who don't care about those layers may
not understand why it would be a reasonable assumption.

The rest of this section uses the word MUST a few times in the
description of actions or implementation assumptions.  While the use of
the word MUST may make complete sense to the topic, and the points they
are being applied to, it seems out of place for an optional layer of the
model.  If the Synch and Steering layer is truly optional, then how can
the specification make claims to what MUST happen?

Section 1.5.3
The second paragraph on page 39 uses the term nexuses, but does not
clearly build the relationship that the ISID rule is attempting to
explain.  Can the level (I_T, I_T_L, I_T_L_x) of nexus be identified
that is being referred to here, to help clarify the ISID rule mentioned
in the previous paragraph?

Section 2.2.2
The definition of the AHS (see below, 2.2.3.1) seems to be covered as a
global PDU property, but only op-code 0x01 (SCSI Command) seems to make
use of it.  Since the AHS seems to be only needed to encapsulate an
extended CDB, then why define its possible existence for all PDUs?  Can
the AHS be used in other commands?

Section 2.2.2.4
This section defines the behavior of non-specific fields in op-code use,
but not completely.  One portion of the field is explained (P/F bit),
but the use of the rest of the field is left to the reader to find in
the other op-codes.  Would it make more sense to pull the definition of
the P/F bit out of this section, then simply tell the reader that the
other bits are defined in the op-code specific sections?  Maybe tabulate
the P/F usage in this section, to the op-code specific use?

Section 2.2.2.7
The second sentence of this paragraph defines that the LUN field can be
used for "some other purpose."  While there may be a good reason for
overloading this field, we would like to see some more information on
the nature of this use.  What about inserting "opcode-specific" in from
of the word "purpose".

Section 2.2.3.1
The inclusion of a bit that identifies if the CDB is extended should not
live in an optional header.  Expecting that all implementations would
correctly code the use of an optional header to return critical data
that should be identified with the required portion of the CDB seems out
of place.  We would suggest that the use of a reserved bit or a bit in a
reserved byte be used, from the BHS, be used to identify an extended
CDB.  Putting the spillover of the CDB into the AHS (section 2.3.6) is
not an issue, but flagging if there is spillover should not be in the
AHS.

Section 2.4.3
This section has seen a lot of discussion, and we agree with the
position that Rob Elliot and David Black took on the disassociation of
the iSCSI responses from the ASC/ASCQ SCSI status codes.  While the
discussion of ACA and it's relationship to iSCSI may not be resolved
quickly, there needs to be a way to avoid polluting the expectation of
the SAM status to the devices with the iSCSI response codes.

Section 2.5.1
This section seems to build on the work done in FCP for out of CDB
delivery of task management.  But the behavior of a target on receipt of
a Target Cold Reset should be similar to that of a Logout (assuming
behavior as explained above in comments on section 1.2.6), where the
target returns as little information as possible, and does not attempt
to clean-up or respond upon reception of the command.  Also, this is the
only section in the document where the term MIB is used, and since
management of iSCSI is outside of the scope of this document, we would
prefer to see the last sentence in the paragraph on Target Cold Reset
removed.

Section 2.8
While the section on Bookmarks is brand new, and will probably go
through more definition, the double definition of this field should be
removed.  If it stays as Bookmark, and it is optional, then it is not
reserved.

Section 2.8.5
This section allows (in the first paragraph) large binary items to be
encoded as hex or decimal.  This discussion is ongoing now, and we
believe the encoding should be hex.

The third to last sentence in this section alludes to the ability to use
key=value pairs to perform active operations.  Since iSCSI active
operations are interpreted by us as related to SCSI operations, what is
being said here?  Does this mean that an initiator could perform
mode-parameter or task management operations inside of Text Messages?
If so, then more definition of this behavior is needed.

Section 2.9.5
The second paragraph attempts to instruct the reader to order response
key=value pairs in the same order they were received, but provides
little direction on why, or what possible consequences would be if it
were not done in that order.  Why is this sentence needed, except for
instruction on best practices?

Section 2.10.1
The instructions to targets on supporting multiple connections run up
against the minimum requirement of targets to support only one
connection.  If this section is a better reason to require at least two
connections at a minimum, then the specification should call that the
minimum.  If initiators are going to expect to be able to use this
command, but targets that only support one connection would refuse it,
than what good is this instruction going to be?  Would a target designer
who develops an iSCSI target create the ability to open two connections
to support only this situation, and not expand the interface to run two
connections in Full Feature Mode?

Section 2.12.4
If the limit of reflected data is 4096 bytes, then the instruction to
the initiator should not be "avoid sending", it should be "MUST NOT"
send more than 4096 bytes.  Is there a reason why the initiator would
want to send more than those number of bytes?

Section 2.14
This section was discussed above in relationship to section 1.2.6.  The
Logout command should be simple and immediate, with no further work
needed by the target then the clearing of internal buffers, and the
reporting on the next Login (CHECK CONDITION) that the Logout was
performed. 

Section 2.16
The last sentence in this section seems at odds with good error
detection for targets, and at odds with section 2.19.1.  If a SNACK
received has and error, whether or not it was a miss-directed PDU, or a
transit error, why would a target just silently ignore it?  Should it
use the SNACK Rejected code of the Reject response, or at least tell the
initiator something?  Besides, the use of the word "must" seems
inconsistent with what this sentence is trying to say.  If there is a
good reason for a target to ignore this, then it should be mentioned,
and the directive should be "MUST" if the expectations of the initiator
are set that way.

Section 2.16.1
The last paragraph of this section is confusing.  We cannot determine
how it should be rewritten, since the intent is not clear.  Why would
the target issue a message requesting Logout simply because it cannot
process as SNACK that is optional anyway?  How does the initiator know
if the target supports in-connection or out-of-connection recovery with
regards to what the target does after discarding the SNACK?

Section 2.17.3
What is the purpose of the last sentence on page 87?  It seems to
indicate that there is a good reason (besides the obvious) why the
Desired Data Length should not be zero, but falls short of explaining,
or directing the reader with a "MUST," or "SHOULD."

Section 2.17.4
This topic was discussed above in section 1.2.5.  

Section 3
We would like to see the explanation in this section clarified with
regards to the use of mode parameter changes for SCSI settings, versus
iSCSI settings.  Suggested rewording for the first sentence of the
second paragraph:
"The mode parameters for iSCSI behavior cannot be set by SCSI mode-set
but can be retrieved by SCSI mode-sense commands."
Suggested additional wording:
"SCSI mode parameters (non-iSCSI specific) cannot be set or retrieved
from within iSCSI mode page commands."  -  Or something like that.

Section 4.2
Under the key SecurityContextComplete=yes, there is a description of
what the party sending this key should do, finishing with the phrase
"until the handshake is complete."  What is the scenario for avoiding a
lock condition in this handshake?  Should the party use some standard
timeout? Where is this defined?

Section 7
The second paragraph in this section defines an assumption of the
specification.  Potential manufacturers of iSCSI targets will want to
know under what circumstances will the saving of sense and status
information differ than those already done for FC or SCSI operation;
specifically with regards to iSCSI Logout and iSCSI task management
commands.  Can this paragraph have more details added?

Section 7.1c
This description of the use of the Retry bit seems to put the onus of
interpretation of the Retry bit on the target for command replay.  Is it
at all possible for a Replay request to get issued, within the scope of
an initiator delaying its acknowledgement, such that the command
actually did get completed, but the Retry bit was set too soon?  Would
one assume that an initiator just avoids doing something like this?  

Section 7.6
This section uses the term "ULP timeout", but there is no definition or
reference to where it can be found.

Section 7.9
By recommending (in the first paragraph) that a connection be tested in
HA environments with iSCSI NOP-ping command, aren't the authors
recommending that designers use bandwidth consuming methods for
determining this?  If you assume a multiple path connection (fabric) for
such iSCSI implementations, then couldn't a bunch of initiators
potentially flood the fabric with such commands to "recognize a failing
connection?"

Section 7.11.1 and 7.11.2
Specifically, what time-outs are being referred to here?  The time a
target or initiator should or might wait for acknowledgement from the
other node that error recovery is being attempted?

Section 7.11.3
This section seems to not agree with the methods for completing a Logout
command as discussed earlier.  Item number (2) in this section indicates
that the initiator should treat the reception of an Asynchronous Message
requesting a Logout command to that of a TCP failure, yet the target is
instructed (section 2.14) to treat the reception of a Logout command as
an opportunity to complete any commands "it deems necessary."  Again,
the need for a Target Logout and Initiator Logout seems apparent.

Thanks,
Bob

Robert Griswold
Technologist
Crossroads Systems, Inc.
512-928-7272



From owner-ips@ece.cmu.edu  Fri Aug  3 17:09:54 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29261
	for <ips-archive@odin.ietf.org>; Fri, 3 Aug 2001 17:09:54 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f73Jqwv04876
	for ips-outgoing; Fri, 3 Aug 2001 15:52:58 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f73Jque04871
	for <ips@ece.cmu.edu>; Fri, 3 Aug 2001 15:52:57 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA102930;
	Fri, 3 Aug 2001 15:50:33 -0400
Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f73Jq2X14418;
	Fri, 3 Aug 2001 13:52:03 -0600
Importance: Normal
Subject: RE: Iscsi: Fault tolerance
To: "Merhar, Milan" <mmerhar@pirus.com>
Cc: "Merhar, Milan" <mmerhar@pirus.com>,
        "'Sanjeev Bhagat (TRIPACE/Zoetermeer)'" <sbhagat@tripace.com>,
        ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OF891F9067.84736BD3-ON88256A9D.006D0AA8@boulder.ibm.com>
From: "John Hufferd" <hufferd@us.ibm.com>
Date: Fri, 3 Aug 2001 12:51:12 -0700
X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.6 |December 14, 2000) at
 08/03/2001 01:52:02 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Correct.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com


"Merhar, Milan" <mmerhar@Pirus.com> on 08/03/2001 10:58:34 AM

To:   John Hufferd/San Jose/IBM@IBMUS, "Merhar, Milan" <mmerhar@Pirus.com>
cc:   "'Sanjeev Bhagat (TRIPACE/Zoetermeer)'" <sbhagat@tripace.com>,
      ips@ece.cmu.edu
Subject:  RE: Iscsi: Fault tolerance



Thanks for adding that, John. These "direct" file sharing
solutions are powerful tools, but not often seen in
general use at present. The ones that I'm familiar with
run over FC SANs, although there is no reason why they
wouldn't run very nicely over iSCSI.

In your application, the box that had been a "file server"
now becomes a "metadata server" and "lock manager".  Once
the clients are presented with the list of blocks comprising
a file (and the write lock, if they're doing writes), they
can go off and fetch the actual data from the iSCSI volume
themselves.

A failed metadata server behaves pretty much like a
failed file server in terms of bringing a spare online, doing
file system recovery, etc, except that clients already
having been granted file access can continue accessing
those blocks (and only those blocks) during the outage.

As for client support, a special driver is needed on each client,
to handle the split metadata/direct access operations.

- milan

> -----Original Message-----
> From: John Hufferd [mailto:hufferd@us.ibm.com]
> Sent: Friday, August 03, 2001 12:59 PM
> To: Merhar, Milan
> Cc: 'Sanjeev Bhagat (TRIPACE/Zoetermeer)'; ips@ece.cmu.edu
> Subject: RE: Iscsi: Fault tolerance
>
>
>
> What Milan says is probable, however, let me address it in a slightly
> different way.
>
> There are Servers, Today, that share their Data on a FC SAN.
> They have
> either a Shared File System or use something like "SANergy"
> to share out
> the files.  In the case of a shared file system, each
> surviving member of
> the Cluster can continue to access the Disks.  In the case of
> SANergy, the
> other members can continue until the extent list needs to be updated.
>
> These are solutions that are in use today, in FC SAN
> environments.  If you
> are talking about general clients scattered around a campus that need
> sharing, they will best be handled by a Filer (as Milan said).
>
> .
> .
> .
> John L. Hufferd
> Senior Technical Staff Member (STSM)
> IBM/SSG San Jose Ca
> Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
> Home Office (408) 997-6136
> Internet address: hufferd@us.ibm.com
>
>
> "Merhar, Milan" <mmerhar@pirus.com>@ece.cmu.edu on 07/31/2001
> 12:26:49 PM
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   "'Sanjeev Bhagat (TRIPACE/Zoetermeer)'" <sbhagat@tripace.com>
> cc:   ips@ece.cmu.edu
> Subject:  RE: Iscsi: Fault tolerance
>
>
>
> Sanjeev,
>
> I think that your clients will actually be accessing a file system
> your server has created on the raw volume accessed by iSCSI.
> They do so
> by using a network file protocol - in the case of Microsoft products,
> probably CIFS, connecting to the server which then in turn does
> block mode accesses to the iSCSI volume.
>
> So, if the server goes away, the clients can no longer reach
> the files stored on the iSCSI device.  Of course, unlike
> a server with a direct-attached drive, in the situation you
> describe another server could step into the place of the first one,
> mounting the iSCSI volume and again offering shared file access to
> those clients. (In other words, you've got a NAS server accessing
> its storage over a SAN - an IP SAN.)
>
> Depending on how the server "went away", there may be some startup
> transients bringing its replacement online, as the file system is
> verified, cleaned up, etc.  The transition is also not transparent
> to the clients, as they will need to reconnect to this new server,
> with its different IP address, as well.
>
> Hope this helps.
>
>      - milan
>
>
> Milan Merhar, Chief Scientist, Pirus Networks
>
> > -----Original Message-----
> > From: Sanjeev Bhagat (TRIPACE/Zoetermeer)
> [mailto:sbhagat@tripace.com]
> > Sent: Tuesday, July 31, 2001 2:18 PM
> > To: 'Julian Satran'; ips@ece.cmu.edu
> > Subject: RE: Iscsi: Fault tolerance
> >
> >
> > Julian and all!!
> >
> > The server connects to the iscsi target (Say just a disk)
> > with the help of
> > an iSCSI initiator driver installed on the server. The NT
> > server thus shows
> > an extra physical disk present on the server. The sys admin
> > then assigns the
> > permission to other clients/users to share this target. The
> > clients can then
> > access this this disk (iscsi target) or any sharable
> > directory on this disk
> > (iscsi target)present on the server by connecting to the network.
> >
> > Hope it is clear by now!! If it is not then please provide me
> > your contact
> > number and I will try to explain you better.
> >
> > I am sorry if there is any ambiguity but i cant find better words to
> > explain.
> >
> > Sanjeev
> >
> > -----Original Message-----
> > From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > Sent: Tuesday, July 31, 2001 6:35 PM
> > To: ips@ece.cmu.edu
> > Subject: Re: Iscsi: Fault tolerance
> >
> >
> >
> > How exactly will the clients use the initiator on the server?
> >
> > Julo
> >
> > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" <sbhagat@tripace.com>
> > on 31-07-2001
> > 18:57:41
> >
> > Please respond to "Sanjeev Bhagat (TRIPACE/Zoetermeer)"
> >       <sbhagat@tripace.com>
> >
> > To:   "'IPS Reflector'" <ips@ece.cmu.edu>
> > cc:
> > Subject:  Iscsi: Fault tolerance
> >
> >
> >
> >
> > Hi
> >
> > Consider a case where the clients of a Windows NT server are
> > accessing the
> > iSCSI target with iSCSI initiator driver installed  on the
> Windows NT
> > server
> > to access a ISCSI target on NET. So all the clients on this
> Windows NT
> > server can share the iSCSI target of this server. In case the
> > server goes
> > down , will the clients still be able to access the iSCSI Target??
> >
> > I hope I have put my question peoperly. In case not then
> > please feel free
> > to
> > call me at +31 624685051
> >
> >
> > Sincerely,
> >
> > Sanjeev Bhagat
> >
> > Tripace Europe
> >
> >
> >  - att1.htm
> >
> >
>
>
>





From owner-ips@ece.cmu.edu  Fri Aug  3 18:52:18 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00398
	for <ips-archive@odin.ietf.org>; Fri, 3 Aug 2001 18:52:18 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f73LRSs09796
	for ips-outgoing; Fri, 3 Aug 2001 17:27:28 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f73LRQe09790
	for <ips@ece.cmu.edu>; Fri, 3 Aug 2001 17:27:26 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA99158;
	Fri, 3 Aug 2001 17:24:54 -0400
Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f73LQmX272270;
	Fri, 3 Aug 2001 15:26:48 -0600
Importance: Normal
Subject: Re: Review of the 07 draft
To: "Robert Griswold" <rgriswold@Crossroads.com>
Cc: ips@ece.cmu.edu
From: "Jim Hafner" <hafner@almaden.ibm.com>
Date: Fri, 3 Aug 2001 14:26:47 -0700
Message-ID: <OF4052726A.3C7AF210-ON88256A9D.0074339D@boulder.ibm.com>
X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.6 |December 14, 2000) at
 08/03/2001 02:26:48 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Bob,

Nice job!  I have a couple of things I want to remark on.

You wrote:

>Section 1.2.7
>On page 28, in the fourth to last paragraph in this section, there is a
>description on how a target can assume an iSCSI Initiator Name, as
>learned through authentication.  This is a confusing paragraph, and we
>cannot determine if it is implying that the target should use the
>initiator name it has been given through some service, or that it was
>authorized to use by an initiator that discovered its iSCSI functions.
>Can this paragraph be further expanded to clarify how the name was
>determined?

In my opinion (as I stated in an earlier note), I think this whole
paragraph, and any other text related to third-party stuff should be
deleted from the draft, not expanded on.  This is a complex issue with many
different points of view and differing interpretation of requirements, from
application and management requirements, to simplicit/complexity of the
protocols involved with lots of security sprinkled in.  I would like this
dropped from the current draft and addressed at a later time (if necessary
-- and I'm not convinced that it is, at least at the level of the iSCSI
protocol).

You also wrote:
>Section 1.5.3
>The second paragraph on page 39 uses the term nexuses, but does not
>clearly build the relationship that the ISID rule is attempting to
>explain.  Can the level (I_T, I_T_L, I_T_L_x) of nexus be identified
>that is being referred to here, to help clarify the ISID rule mentioned
>in the previous paragraph?

This text is mine.  What this is referring to is just the I_T part of the
nexus (as that is the only part that iSCSI is involved in).  The text does
say "between the same two SCSI initiator and SCSI target ports".  I had
hoped that was clearly refering to the I_T.

And...
>The third to last sentence in this section alludes to the ability to use
>key=value pairs to perform active operations.  Since iSCSI active
>operations are interpreted by us as related to SCSI operations, what is
>being said here?  Does this mean that an initiator could perform
>mode-parameter or task management operations inside of Text Messages?
>If so, then more definition of this behavior is needed.

Well, in fact, the draft is supposed to say that MODE_SELECT for the
transport-specific mode page will NOT be done via SCSI, only via Text
commands.  I read that as saying that from the SCSI layer, all fields in
these pages are "unchangeable" (even though they can change in the iSCSI
layer).  Of course, the draft doesn't say whether MODE PARAMETERS HAVE
CHANGED unit attentions get thrown up at the SCSI layer when this happens
at the iSCSI layer.... You later have a clarifying question (Section 3) on
this as well.

Regards,
Jim Hafner





From owner-ips@ece.cmu.edu  Fri Aug  3 21:23:03 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02001
	for <ips-archive@odin.ietf.org>; Fri, 3 Aug 2001 21:23:02 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f740F1916183
	for ips-outgoing; Fri, 3 Aug 2001 20:15:01 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from clyde.stargateip.com ([209.237.5.66])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f740Ewe16174
	for <ips@ece.cmu.edu>; Fri, 3 Aug 2001 20:14:58 -0400 (EDT)
Received: from bluestar (dhcp-101.stargateip.com [10.10.5.101])
	by clyde.stargateip.com (8.9.1/8.9.1) with SMTP id RAA15374;
	Fri, 3 Aug 2001 17:09:00 -0700 (PDT)
Reply-To: <deva@stargateip.com>
From: "Dev" <deva@stargateip.com>
To: "Jim Hafner" <hafner@almaden.ibm.com>,
        "Robert Griswold" <rgriswold@Crossroads.com>
Cc: <ips@ece.cmu.edu>
Subject: RE: Review of the 07 draft
Date: Fri, 3 Aug 2001 17:18:45 -0700
Message-ID: <NFBBKBDFJCDMGCBKJLCJEEMJFCAA.deva@stargateip.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
In-Reply-To: <OF4052726A.3C7AF210-ON88256A9D.0074339D@boulder.ibm.com>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Jim,

You wrote:
>Of course, the draft doesn't say whether MODE PARAMETERS HAVE
>CHANGED unit attentions get thrown up at the SCSI layer when this happens
>at the iSCSI layer.... You later have a clarifying question (Section 3) on
>this as well.

Yes it is necessary to return  unit attentions for Mode parameter changes
(changed through SCSI command).
it is within the domain of SCSI, not iSCSI . However a note on
implementation in the iSCSI spec that
discusses the mode parameters will be good.

Thanks

Deva
Platys communications



From owner-ips@ece.cmu.edu  Sat Aug  4 02:46:36 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22883
	for <ips-archive@odin.ietf.org>; Sat, 4 Aug 2001 02:46:36 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f745pIR26958
	for ips-outgoing; Sat, 4 Aug 2001 01:51:18 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from internaut.com ([64.38.134.99])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f745pGe26953
	for <ips@ece.cmu.edu>; Sat, 4 Aug 2001 01:51:16 -0400 (EDT)
Received: from localhost (aboba@localhost)
	by internaut.com (8.9.3/8.9.3) with ESMTP id WAA95657;
	Fri, 3 Aug 2001 22:41:16 -0700 (PDT)
	(envelope-from aboba@internaut.com)
Date: Fri, 3 Aug 2001 22:41:16 -0700 (PDT)
From: Bernard Aboba <aboba@internaut.com>
To: Black_David@emc.com
cc: bill@strahm.net, wdixon@microsoft.com, ips@ece.cmu.edu
Subject: Re: saag whyenc draft (was RE: Security Gateways)
In-Reply-To: <277DD60FB639D511AC0400B0D068B71ECAD567@CORPMX14>
Message-ID: <Pine.BSF.4.21.0108032211370.95634-100000@internaut.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

> Are you prepared to argue that data requiring
> confidentiality will never or almost never be sent via iSCSI or
> FCIP?  That is the line of reasoning that this draft leads to.

It's worth keeping in mind that Encrypting File Systems are now widely
supported. So in practice, the data may already be encrypted, and it might
be argued that in such a case, IPsec confidentiality is redundant. 

> OTOH, this argument may have some merit, as I would definitely expect
> to see things like this sort of brain-damaged software encryption module
> if confidentiality becomes a "MUST implement".  

Unfortunately, such a software encryption module would not be
"brain-damaged." Such performance is typical of 3DES implemented in
software on Pentium class processors in the 200 - 300 Mhz range (and
equivalent RISC processors). Software AES implementations will do
almost an order of magnitude better. but that's still a far cry from 1+
Gbps. At those speeds hardware acceleration will be required. 

Ultimately, the credibility of mandating confidentiality depends on the
demonstration that the service can actually be provided at the required
line rates. I expect that we will be able to lay out the evidence by the
Interim Meeting. 

> this applies only to confidentiality -- a small amount of thought about
> the consequences of impersonation and a script kiddie's TCP hijack attack
> leads to the conclusion that authentication and cryptographic integrity
> have to be "MUST implement" for iSCSI, FCIP, and iFCP.
> 

Yup. 

> The paper indicated that PowerPC clock speeds of 600-800 Mhz would be
> required in order for UMAC to handle 1 Gbps line rate...

I agree that it might be challenging to implement a software MAC on an
iSCSI target running at 1+ Gbps line rate. But this is more credible
for an iSCSI initiator running on a new PC with say, 1.7 Ghz clock rate. 
At 1 Gbps, UMAC-4/8 would consume 262.5 Million cycles/second, or
15% of CPU. 

By the interim meeting, we hope to have some presentations on the
performance achievable via hardware acceleration. I'd
note that software MAC algorithms are not necessarily the fastest
algorithms to implement in hardware. So the 2-3 cycles/byte of UMAC
on PowerPC should not be considered the best that can be done, just an
indication of how far we've come from HMAC-SHA1. 





From owner-ips@ece.cmu.edu  Sat Aug  4 02:51:02 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22911
	for <ips-archive@odin.ietf.org>; Sat, 4 Aug 2001 02:51:02 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7469Sv27487
	for ips-outgoing; Sat, 4 Aug 2001 02:09:28 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7469Qe27482
	for <ips@ece.cmu.edu>; Sat, 4 Aug 2001 02:09:26 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id IAA76556
	for <ips@ece.cmu.edu>; Sat, 4 Aug 2001 08:09:20 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7469Jr92404
	for <ips@ece.cmu.edu>; Sat, 4 Aug 2001 08:09:19 +0200
Importance: Normal
Subject: RE: iSCSI: SendTargets in login or FFP?
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFB7BDE54F.8A67F9AF-ONC2256A9E.0022281B@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Sat, 4 Aug 2001 09:15:23 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 04/08/2001 09:09:18
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Matthew,

That is an (editorial) mistake. They are still IO.  But this whole area
might change - look for the framing report in London.

Julo

"BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <matthew_burbridge@hp.com> on
03-08-2001 18:31:24

Please respond to "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)"
      <matthew_burbridge@hp.com>

To:   "'Robert D. Russell'" <rdr@mars.iol.unh.edu>, Julian
      Satran/Haifa/IBM@IBMIL
cc:   ips@ece.cmu.edu
Subject:  RE: iSCSI: SendTargets in login or FFP?



Hi Robert,

In your attachment, you have stated that FMarker (and its dependencies) are
per connection.  I believe this was the case in 0.6 but in 0.7 it is now on
the LO connection and therefore is it not per session or am I missing
something here?

Cheers

Matthew Burbridge
Senior Development Engineer
NIS-Bristol
Hewlett Packard
Telnet: 312 7010
E-mail: matthewb@bri.hp.com


-----Original Message-----
From: Robert D. Russell [mailto:rdr@mars.iol.unh.edu]
Sent: Thursday, August 02, 2001 6:49 PM
To: Julian Satran
Cc: ips@ece.cmu.edu
Subject: Re: iSCSI: SendTargets in login or FFP?


Julian:

In order to try to organize information about the key parameters,
I developed the attached ASCII text file which characterizes each
key from draft 7 according to 4 attributes:

1.  what type of key it is, which determines in which login phase
    it can be used.
2.  when the key can be negotiated.
3.  who can send the key.
4.  the scope of application of the key's information.

The values of these attributes were drawn from Appendixes A and D.
The only new information added (i.e., information not in draft 7)
is the characterization of keys into 3 types - security, operational,
and informational, where the new category "informational"
applies to keys, such as TargetAddress, TargetName, InitiatorName,
etc. which can be sent in either the security or operational
subphases of login, and which simply provide information rather
than negotiate values.

There is still a question with regard to the SendTargets key
-- many of the recent postings regarding the use of SendTargets for
discovery sessions indicates that people expect this key to be used
only in Full Feature Phase.  Quoting from Mark Bakke's e-mail of
24-July:

> "Anyway, SendTargets is always done in full feature phase, and
> never during the login phase."

and later in the same message:

> No.  The point of doing SendTarget in full feature phase is that the
> initiators must first go through their normal authentication;
> SendTargets responses will often be based on the initiator's identity.

Is this limitation correct?  Or does this limitation apply only for
discovery sessions?

The draft currently characterizes SendTargets as ALL, which
does not imply this limitation.

If SendTargets is so limited, it would be the only key that could not
be used somewhere during login.  To cover this case in the attached table
I have added the category FFP to the 3 existing categories IO, LO,
and ALL.  Draft 7 would have to be modified to reflect this.

If this limitation is not correct, the category FPP
disappears and the ALL category would continue to apply to SendTargets
(and targest can expect to receive SendTargets during login).

Thanks,

Bob Russell
InterOperability Lab
University of New Hampshire
rdr@iol.unh.edu
603-862-3774



On Tue, 24 Jul 2001, Julian Satran wrote:

> Eddy,
>
> SendTargets can be used in both discovery session and normal session.
> Would you please clarify when you think this restriction should apply?
>
> Julo
>
> "Eddy Quicksall" <EQuicksall@mediaone.net> on 24-07-2001 04:15:56
>
> Please respond to "Eddy Quicksall" <EQuicksall@mediaone.net>
>
> To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> cc:
> Subject:  iSCSI: SendTargets in login or FFP?
>
>
>
>
> The spec says:
>
>   An initiator can log into this default target [iSCSI]
>   name, and use a command called "SendTargets" to retrieve a list of
>   iSCSI targets that exist at that address
>
> I assume this means the SendTargets would be used in Full Feature Phase
...
> the initiator would login using TargetName=iSCSI. That would get into FFP
> and then the initiator would use SendTargets= to get the list of targets.
> Then, login again with the appropriate target.
>
> The spec says:
>
>   In full feature phase the initiator may send SCSI
>   commands and data to the various LUs on the target by wrapping them
>   in iSCSI PDUs that go over the established iSCSI session.
>
> That means the target has to do something if a CDB is received to the
iSCSI
> canonical target. The spec doesn't give any suggestions here. I am
assuming
> the target would give a reject PDU with a reason of "Protocol Error"
(code
> 5).
>
> Do you agree that this is what should happen?
>
> We shouldn't require that the target enter FFP when it would not be valid
> to
> send a CDB. I think SendTargets should be done only at LO or IO time and
> that iSCSI should not get you into FFP. That would simplify coding.
>
>
> Eddy_Quicksall@iVivity.com
>
>
>
>





From owner-ips@ece.cmu.edu  Sat Aug  4 16:42:53 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00659
	for <ips-archive@odin.ietf.org>; Sat, 4 Aug 2001 16:42:52 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f74JkEA03501
	for ips-outgoing; Sat, 4 Aug 2001 15:46:14 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from elmo.ece.cmu.edu (ELMO.ECE.CMU.EDU [128.2.136.21])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f73It6e01968
	for <ips@ece.cmu.edu>; Fri, 3 Aug 2001 14:55:06 -0400 (EDT)
Date: Fri, 3 Aug 2001 14:55:06 -0400 (EDT)
Message-Id: <200108031855.f73It6e01968@ece.cmu.edu>
From: Jim McKinney <jmck+@ece.cmu.edu>
X-Mailer: BatIMail version 3.2
To: ips@ece.cmu.edu
Subject: RE: Security Gateways
References: <200108031742.f73Hgqa28223@ece.cmu.edu>
Mime-Version: 1.0 (generated by tm-edit 1.5)
Content-Type: text/plain; charset=US-ASCII
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Approved: sskm1

> Bernard Aboba wrote:
> 
> Integrity protection via new MACs such as UMAC is *not* 
> expensive. This is
> a myth. See http://www.cs.ucdavis.edu/~rogaway/umac/perf00.html 
>

Bernard,

Thanks for the pointer to some current research in this area.

That paper gave cycles/byte numbers for their algorithm, on 
a Pentium III and PowerPC.  For now, I'll comment on the PPC 
numbers, because that family is available as an embeddable core
that can be integrated into hardware, while the Pentium III is not. 
For 1500-byte messages, it looks like UMAC will take between 
2.7 and 3.7 CPU clocks per byte (estimates, as no numbers 
were given for the full UMAC function on PPC).  

That indicates that I'd have to run my core at 600-800 Mhz 
to handle a single full duplex Gigabit Ethernet port, assuming
I have the packets in memory that's fast enough to not stall the 
CPU, and that there's some way of getting packets into and out 
of that memory without interfering with the CPU.

I grant you that is "do-able," and it certainly is less expensive 
than HMAC-SHA1, but I wouldn't call it "cheap."  At least for 
some portion of the audience here, "cheap" may be measured by how 
many thousands of gates the implementation adds to the existing 
data path logic, and "fast" by how many gate delays were 
introduced into that path. 

So, I guess that puts me in agreement with Jim William's 
comments; security protocols MUST be supported, and 
supported in the context of a single standard, 
not a "de jure" standard and a "de facto" alternative.
And, if that means the standard must embrace non-monolithic 
"system level" compliance, then let's figure out how to 
do that properly, rather than declaring it illegal and hoping 
it will go away.

- milan




From owner-ips@ece.cmu.edu  Sat Aug  4 16:43:43 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00674
	for <ips-archive@odin.ietf.org>; Sat, 4 Aug 2001 16:43:42 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f74JjJA03457
	for ips-outgoing; Sat, 4 Aug 2001 15:45:19 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from ext1.pirus.com ([4.36.58.197])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f73Hgoe28219
	for <ips@ece.cmu.edu>; Fri, 3 Aug 2001 13:42:50 -0400 (EDT)
Message-Id: <200108031742.f73Hgoe28219@ece.cmu.edu>
Received: by ext1.pirus.com with Internet Mail Service (5.5.2650.21)
	id <PJ7C8NXS>; Fri, 3 Aug 2001 13:44:16 -0400
From: "Merhar, Milan" <mmerhar@pirus.com>
To: "'Bernard Aboba'" <aboba@internaut.com>,
        "'Williams, Jim'"
	 <Jim.Williams@emulex.com>
Cc: Black_David@emc.com, rsnively@Brocade.COM, ips@ece.cmu.edu
Subject: RE: Security Gateways
Date: Fri, 3 Aug 2001 13:44:07 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

> Bernard Aboba wrote:
> 
> Integrity protection via new MACs such as UMAC is *not* 
> expensive. This is
> a myth. See http://www.cs.ucdavis.edu/~rogaway/umac/perf00.html 
>

Bernard,

Thanks for the pointer to some current research in this area.

That paper gave cycles/byte numbers for their algorithm, on 
a Pentium III and PowerPC.  For now, I'll comment on the PPC 
numbers, because that family is available as an embeddable core
that can be integrated into hardware, while the Pentium III is not. 
For 1500-byte messages, it looks like UMAC will take between 
2.7 and 3.7 CPU clocks per byte (estimates, as no numbers 
were given for the full UMAC function on PPC).  

That indicates that I'd have to run my core at 600-800 Mhz 
to handle a single full duplex Gigabit Ethernet port, assuming
I have the packets in memory that's fast enough to not stall the 
CPU, and that there's some way of getting packets into and out 
of that memory without interfering with the CPU.

I grant you that is "do-able," and it certainly is less expensive 
than HMAC-SHA1, but I wouldn't call it "cheap."  At least for 
some portion of the audience here, "cheap" may be measured by how 
many thousands of gates the implementation adds to the existing 
data path logic, and "fast" by how many gate delays were 
introduced into that path. 

So, I guess that puts me in agreement with Jim William's 
comments; security protocols MUST be supported, and 
supported in the context of a single standard, 
not a "de jure" standard and a "de facto" alternative.
And, if that means the standard must embrace non-monolithic 
"system level" compliance, then let's figure out how to 
do that properly, rather than declaring it illegal and hoping 
it will go away.

- milan



From owner-ips@ece.cmu.edu  Sat Aug  4 16:50:12 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00743
	for <ips-archive@odin.ietf.org>; Sat, 4 Aug 2001 16:50:11 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f74JjZY03468
	for ips-outgoing; Sat, 4 Aug 2001 15:45:35 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from ext1.pirus.com ([4.36.58.197])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f73HvKe28995
	for <ips@ece.cmu.edu>; Fri, 3 Aug 2001 13:57:20 -0400 (EDT)
Message-Id: <200108031757.f73HvKe28995@ece.cmu.edu>
Received: by ext1.pirus.com with Internet Mail Service (5.5.2650.21)
	id <PJ7C8NX6>; Fri, 3 Aug 2001 13:58:46 -0400
From: "Merhar, Milan" <mmerhar@pirus.com>
To: "'John Hufferd'" <hufferd@us.ibm.com>,
        "Merhar, Milan"
	 <mmerhar@pirus.com>
Cc: "'Sanjeev Bhagat (TRIPACE/Zoetermeer)'" <sbhagat@tripace.com>,
        ips@ece.cmu.edu
Subject: RE: Iscsi: Fault tolerance
Date: Fri, 3 Aug 2001 13:58:34 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Thanks for adding that, John. These "direct" file sharing 
solutions are powerful tools, but not often seen in 
general use at present. The ones that I'm familiar with 
run over FC SANs, although there is no reason why they 
wouldn't run very nicely over iSCSI.

In your application, the box that had been a "file server" 
now becomes a "metadata server" and "lock manager".  Once 
the clients are presented with the list of blocks comprising 
a file (and the write lock, if they're doing writes), they 
can go off and fetch the actual data from the iSCSI volume 
themselves.

A failed metadata server behaves pretty much like a 
failed file server in terms of bringing a spare online, doing 
file system recovery, etc, except that clients already 
having been granted file access can continue accessing 
those blocks (and only those blocks) during the outage.

As for client support, a special driver is needed on each client, 
to handle the split metadata/direct access operations.

- milan

> -----Original Message-----
> From: John Hufferd [mailto:hufferd@us.ibm.com]
> Sent: Friday, August 03, 2001 12:59 PM
> To: Merhar, Milan
> Cc: 'Sanjeev Bhagat (TRIPACE/Zoetermeer)'; ips@ece.cmu.edu
> Subject: RE: Iscsi: Fault tolerance
> 
> 
> 
> What Milan says is probable, however, let me address it in a slightly
> different way.
> 
> There are Servers, Today, that share their Data on a FC SAN.  
> They have
> either a Shared File System or use something like "SANergy" 
> to share out
> the files.  In the case of a shared file system, each 
> surviving member of
> the Cluster can continue to access the Disks.  In the case of 
> SANergy, the
> other members can continue until the extent list needs to be updated.
> 
> These are solutions that are in use today, in FC SAN 
> environments.  If you
> are talking about general clients scattered around a campus that need
> sharing, they will best be handled by a Filer (as Milan said).
> 
> .
> .
> .
> John L. Hufferd
> Senior Technical Staff Member (STSM)
> IBM/SSG San Jose Ca
> Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
> Home Office (408) 997-6136
> Internet address: hufferd@us.ibm.com
> 
> 
> "Merhar, Milan" <mmerhar@pirus.com>@ece.cmu.edu on 07/31/2001 
> 12:26:49 PM
> 
> Sent by:  owner-ips@ece.cmu.edu
> 
> 
> To:   "'Sanjeev Bhagat (TRIPACE/Zoetermeer)'" <sbhagat@tripace.com>
> cc:   ips@ece.cmu.edu
> Subject:  RE: Iscsi: Fault tolerance
> 
> 
> 
> Sanjeev,
> 
> I think that your clients will actually be accessing a file system
> your server has created on the raw volume accessed by iSCSI.  
> They do so
> by using a network file protocol - in the case of Microsoft products,
> probably CIFS, connecting to the server which then in turn does
> block mode accesses to the iSCSI volume.
> 
> So, if the server goes away, the clients can no longer reach
> the files stored on the iSCSI device.  Of course, unlike
> a server with a direct-attached drive, in the situation you
> describe another server could step into the place of the first one,
> mounting the iSCSI volume and again offering shared file access to
> those clients. (In other words, you've got a NAS server accessing
> its storage over a SAN - an IP SAN.)
> 
> Depending on how the server "went away", there may be some startup
> transients bringing its replacement online, as the file system is
> verified, cleaned up, etc.  The transition is also not transparent
> to the clients, as they will need to reconnect to this new server,
> with its different IP address, as well.
> 
> Hope this helps.
> 
>      - milan
> 
> 
> Milan Merhar, Chief Scientist, Pirus Networks
> 
> > -----Original Message-----
> > From: Sanjeev Bhagat (TRIPACE/Zoetermeer) 
> [mailto:sbhagat@tripace.com]
> > Sent: Tuesday, July 31, 2001 2:18 PM
> > To: 'Julian Satran'; ips@ece.cmu.edu
> > Subject: RE: Iscsi: Fault tolerance
> >
> >
> > Julian and all!!
> >
> > The server connects to the iscsi target (Say just a disk)
> > with the help of
> > an iSCSI initiator driver installed on the server. The NT
> > server thus shows
> > an extra physical disk present on the server. The sys admin
> > then assigns the
> > permission to other clients/users to share this target. The
> > clients can then
> > access this this disk (iscsi target) or any sharable
> > directory on this disk
> > (iscsi target)present on the server by connecting to the network.
> >
> > Hope it is clear by now!! If it is not then please provide me
> > your contact
> > number and I will try to explain you better.
> >
> > I am sorry if there is any ambiguity but i cant find better words to
> > explain.
> >
> > Sanjeev
> >
> > -----Original Message-----
> > From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > Sent: Tuesday, July 31, 2001 6:35 PM
> > To: ips@ece.cmu.edu
> > Subject: Re: Iscsi: Fault tolerance
> >
> >
> >
> > How exactly will the clients use the initiator on the server?
> >
> > Julo
> >
> > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" <sbhagat@tripace.com>
> > on 31-07-2001
> > 18:57:41
> >
> > Please respond to "Sanjeev Bhagat (TRIPACE/Zoetermeer)"
> >       <sbhagat@tripace.com>
> >
> > To:   "'IPS Reflector'" <ips@ece.cmu.edu>
> > cc:
> > Subject:  Iscsi: Fault tolerance
> >
> >
> >
> >
> > Hi
> >
> > Consider a case where the clients of a Windows NT server are
> > accessing the
> > iSCSI target with iSCSI initiator driver installed  on the 
> Windows NT
> > server
> > to access a ISCSI target on NET. So all the clients on this 
> Windows NT
> > server can share the iSCSI target of this server. In case the
> > server goes
> > down , will the clients still be able to access the iSCSI Target??
> >
> > I hope I have put my question peoperly. In case not then
> > please feel free
> > to
> > call me at +31 624685051
> >
> >
> > Sincerely,
> >
> > Sanjeev Bhagat
> >
> > Tripace Europe
> >
> >
> >  - att1.htm
> >
> >
> 
> 
> 


From owner-ips@ece.cmu.edu  Sun Aug  5 11:55:16 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15220
	for <ips-archive@odin.ietf.org>; Sun, 5 Aug 2001 11:55:15 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f75EtI117777
	for ips-outgoing; Sun, 5 Aug 2001 10:55:18 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f75Erte17713
	for <ips@ece.cmu.edu>; Sun, 5 Aug 2001 10:53:55 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id QAA356784;
	Sun, 5 Aug 2001 16:52:28 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f75EqHA221724;
	Sun, 5 Aug 2001 16:52:22 +0200
Importance: Normal
Subject: Re: Review of the 07 draft
To: "Robert Griswold" <rgriswold@crossroads.com>
Cc: "Bill Moody" <bmoody@crossroads.com>, <ips@ece.cmu.edu>
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF25946100.9081046E-ONC2256A9F.002DE79F@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Sun, 5 Aug 2001 17:52:01 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 05/08/2001 17:52:27
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Robert,

Thanks for you kind opening and for taking the time to read it.
Comments in text.

Julo

"Robert Griswold" <rgriswold@crossroads.com> on 03-08-2001 22:33:56

Please respond to "Robert Griswold" <rgriswold@crossroads.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   "Bill Moody" <bmoody@crossroads.com>, <ips@ece.cmu.edu>
Subject:  Review of the 07 draft



Julian:

First, great work on this initiative and please forgive my huge email.

We have undertaken a review of the 07 version, and even though
Crossroads will be at the meetings in London, we thought it would be
prudent to post these observations on the current specification.  If we
have completely misread the document, or have missed resolutions that
have come across the reflector, we apologize up front.  I have also sent
you some editorial only comments for your review.

++++++++++

Section 1.2.2.1 (and others):
The third paragraph up from the bottom of page 19 refers to the action
that a target should take when receiving commands outside of a range,
that are not correctly marked as immediate, with the right flags set.
The question is in regards to the MUST instruction on "silently ignore".
Assuming the I_T nexus is established, the devices are communicating and
the target receives what could only correctly be termed a protocol error
from the initiator it has established communication with, why would the
target not respond with an error back?  If in fact the error is
transport related, and the initiator really did send the correct PDU,
then the target being mute on the reception of the this command leaves
the initiator guessing.  There are other points in the specification
where the target is instructed to "silently ignore."

+++ This point has a long history remains of which you can find in the mail
archives.  I and several other authors where inclined to "silently discard"
whatever can't be repaired (e.g., bugs in the initiator, delayed packets or
packets arriving late) and explicitly reject only what can be repaired.
Debugging ease can be achieved by other means (event logs etc.). However
many of our colleagues on the list wanted error rejects to be explicit
whenever it is feasible and that is what you have now except for the cases
in which discards are due to a "legitimate packet" arriving late (e.g.,
from a previous transmission attempt that is already recovered).
Discards are also better in preventing DOS attacks by stream replay++++

Section 1.2.2.2:
The fifth paragraph indicates that a "large difference" between StatSN
and ExpStatSN may indicate a problem, but the number required by the
specification as the maximum before an initiator must take action is 2.1
Billion!  This seems like a very big number, and most implementers would
want to take action long before this limit was reached.  What is the
thinking behind this number?  Is there something we aren't
understanding?

+++ That is very much dependent on implementation and infrastructure (round
trip delay). We assumed that at several hundreds you will start to worry :
-)) +++


Section 1.2.5:
On page 25, the second full paragraph indicates that the definition of
the use of target tags is not specifically specified by the protocol.
While we see possible uses for Target Transfer Tags, we would like to
understand if the author's feel that limiting the interpretation of its
use to that described in 2.17.4 would be helpful.  Clearly this 32-bit
field plays little role in the overall usefulness iSCSI command
protocol, so someone must have felt that it would have been a great idea
to have this in the specification.  Can that be described?

+++ We envisioned TTTs to be used by the target to identify parts of the
data stream that arrive in response of an R2T. Additionally they identify
NOP-Outs that are sent in response to a polling Nop-IN and in general when
valid indicate that the target expects something and identify the response
(link it to the "cause") for the target. We mentioned that the protocol
does not care about the value mainly to stress that, unlike ITT, the
protocol has no uniqueness requirement for them and whenever they appear
the LUN is also present and can serve as an additional differentiator.
++++

Section 1.2.6
This section covers the topic of connection termination, which is also
covered in the discussion of the Logout command in section 2.14.  There
seems to be some mingling of the concept of TCP logout with the concepts
around termination of a communication channel for storage protocols.
The concept of sending a logout, then waiting for the receiving end to
do some clean-up, flushing, and or additional communication seems odd to
the command.  The Logout directive should require no further
communication, and should put neither initiator nor target into the
state of expecting any such communication.  We would like to see the
Logout command (not the request for a logout) be free of any
expectations once sent, or received.  It seems logical that since the
initiator is the responsible party for sending this command (we would
also like to begin some discussion on a target only Logout command, like
SRP is working on now) that it would have done all of the required
cleanup and preparation before issuing the command.  Implementation of
target code to make decisions on what outstanding commands it should or
shouldn't give some credence to before breaking the connection seems out
of place.

+++ Logout has also history. We started without a logout but realized soon
that we will need a synchronized logout to enable command allegiance change
for recovery (that is possible only after logout). Besides it is a simple
and painless way to do a clean shutdown of a connection. As for a target
only logout that is what the Asynch Message does (after some timeouts)
Please keep in mind that there is also a fine interplay between logout and
recovery and that both initiator and target may decide to start some
recovery action+++

Section 1.2.7
On page 28, in the fourth to last paragraph in this section, there is a
description on how a target can assume an iSCSI Initiator Name, as
learned through authentication.  This is a confusing paragraph, and we
cannot determine if it is implying that the target should use the
initiator name it has been given through some service, or that it was
authorized to use by an initiator that discovered its iSCSI functions.
Can this paragraph be further expanded to clarify how the name was
determined?

+++ This is getting thrown out (it is already) considering that T10 has
gone a long way to expand the addressing of third party command source and
destinatiantion +++

Section 1.2.9.1
The last paragraph on this section has as 42 words in it's first
sentence, with the word "message" being used six times.  Suggested
rewording:
"Relying solely on the "message length" information from the iSCSI
message header may make it impossible to find iSCSI message boundaries
in subsequent TCP segments; due to the loss of a TCP segment containing
the iSCSI message length."

++ OK +++

Section 1.2.9.2
The second full paragraph's last two sentences have odd wording.
Suggested rewording:
"In practice, though, iSCSI is not expected to handle infinitely long
streams; stream addressing will wrap around at 2**32-1."


+++ OK +++

The first sentence of the next paragraph is difficult to interpret.
Suggested rewording:
"This model assumes that the iSCSI layer will deliver complete PDUs to
underlying layers in single (atomic) operations."
You may also want to consider adding words that explain the reasoning
behind this assumption, as some who don't care about those layers may
not understand why it would be a reasonable assumption.


+++ I've made it:

This model assumes that the iSCSI layer will deliver complete PDUs to
underlying layers in single (atomic) operations.  The underlying layer doe
not need to examine the stream content to discover the PDU boundaries.

But please note that this whole sectionmight go away :-)

++++

The rest of this section uses the word MUST a few times in the
description of actions or implementation assumptions.  While the use of
the word MUST may make complete sense to the topic, and the points they
are being applied to, it seems out of place for an optional layer of the
model.  If the Synch and Steering layer is truly optional, then how can
the specification make claims to what MUST happen?

+++ it says that IF you doit that MUST be the way to do it ++++

Section 1.5.3
The second paragraph on page 39 uses the term nexuses, but does not
clearly build the relationship that the ISID rule is attempting to
explain.  Can the level (I_T, I_T_L, I_T_L_x) of nexus be identified
that is being referred to here, to help clarify the ISID rule mentioned
in the previous paragraph?
+++ I_T - will fix the text +++

Section 2.2.2
The definition of the AHS (see below, 2.2.3.1) seems to be covered as a
global PDU property, but only op-code 0x01 (SCSI Command) seems to make
use of it.  Since the AHS seems to be only needed to encapsulate an
extended CDB, then why define its possible existence for all PDUs?  Can
the AHS be used in other commands?
+++ There is another one - BiDirectional command fields. +++

Section 2.2.2.4
This section defines the behavior of non-specific fields in op-code use,
but not completely.  One portion of the field is explained (P/F bit),
but the use of the rest of the field is left to the reader to find in
the other op-codes.  Would it make more sense to pull the definition of
the P/F bit out of this section, then simply tell the reader that the
other bits are defined in the op-code specific sections?  Maybe tabulate
the P/F usage in this section, to the op-code specific use?

+++ Good point I'll remove the P/F text - it appears wherever it is used.
+++

Section 2.2.2.7
The second sentence of this paragraph defines that the LUN field can be
used for "some other purpose."  While there may be a good reason for
overloading this field, we would like to see some more information on
the nature of this use.  What about inserting "opcode-specific" in from
of the word "purpose".

+++ I've changed it to:

1.1.1.1   LUN

   Some opcodes operate on a specific Logical Unit. The Logical Unit Number
   (LUN) field identifies which Logical Unit.  If the opcode does not
   relate to a Logical Unit, this field either is ignored or may be used in
   an opcode specific way.  The LUN field is 64-bits and it is to be
   formatted in accordance with [SAM2].

 ++++

Section 2.2.3.1
The inclusion of a bit that identifies if the CDB is extended should not
live in an optional header.  Expecting that all implementations would
correctly code the use of an optional header to return critical data
that should be identified with the required portion of the CDB seems out
of place.  We would suggest that the use of a reserved bit or a bit in a
reserved byte be used, from the BHS, be used to identify an extended
CDB.  Putting the spillover of the CDB into the AHS (section 2.3.6) is
not an issue, but flagging if there is spillover should not be in the
AHS.

+++ That must be a "misreading" - We are talking about a coded field one of
the values is Extended CDB. The whole code is the AHSType.  And if you have
an extended CDB this header is not optional - it is the way to code the
extended CDB (no other way is decribed)
++++

Section 2.4.3
This section has seen a lot of discussion, and we agree with the
position that Rob Elliot and David Black took on the disassociation of
the iSCSI responses from the ASC/ASCQ SCSI status codes.  While the
discussion of ACA and it's relationship to iSCSI may not be resolved
quickly, there needs to be a way to avoid polluting the expectation of
the SAM status to the devices with the iSCSI response codes.

+++ It is going to change. We have to find also a good code (ASC/ASQ) for
Insufficient immediate data
++++

Section 2.5.1
This section seems to build on the work done in FCP for out of CDB
delivery of task management.  But the behavior of a target on receipt of
a Target Cold Reset should be similar to that of a Logout (assuming
behavior as explained above in comments on section 1.2.6), where the
target returns as little information as possible, and does not attempt
to clean-up or respond upon reception of the command.  Also, this is the
only section in the document where the term MIB is used, and since
management of iSCSI is outside of the scope of this document, we would
prefer to see the last sentence in the paragraph on Target Cold Reset
removed.

+++ I can refer to some "opaque" management structure instead of MIB
As for not  returning anything this is acceptable for Target Cold Reset -
where the TCP connections are teared down but not for those that leave the
connections
standing +++

Section 2.8
While the section on Bookmarks is brand new, and will probably go
through more definition, the double definition of this field should be
removed.  If it stays as Bookmark, and it is optional, then it is not
reserved.

+++ The Bookmark field is a bookmark if the B bit is 1 else it is reserved
+++

Section 2.8.5
This section allows (in the first paragraph) large binary items to be
encoded as hex or decimal.  This discussion is ongoing now, and we
believe the encoding should be hex.

+++ We think that hex will be the preferred encoding used but sometimes
people will copy decimal numbers. Once you have to have a decimal
conversion routine it makes little sense to force hexadecimal only by
dictate
+++

The third to last sentence in this section alludes to the ability to use
key=value pairs to perform active operations.  Since iSCSI active
operations are interpreted by us as related to SCSI operations, what is
being said here?  Does this mean that an initiator could perform
mode-parameter or task management operations inside of Text Messages?
If so, then more definition of this behavior is needed.

+++ I will change it to "long lasting operations" and those can be vendor
specific +++

Section 2.9.5
The second paragraph attempts to instruct the reader to order response
key=value pairs in the same order they were received, but provides
little direction on why, or what possible consequences would be if it
were not done in that order.  Why is this sentence needed, except for
instruction on best practices?

+++ It is not a MUST but it was thought by many (with some vehemence) as
helping matching.  IMHO it has no meaning and would suggest removing it.
+++

Section 2.10.1
The instructions to targets on supporting multiple connections run up
against the minimum requirement of targets to support only one
connection.  If this section is a better reason to require at least two
connections at a minimum, then the specification should call that the
minimum.  If initiators are going to expect to be able to use this
command, but targets that only support one connection would refuse it,
than what good is this instruction going to be?  Would a target designer
who develops an iSCSI target create the ability to open two connections
to support only this situation, and not expand the interface to run two
connections in Full Feature Mode?

+++ The text only says that if you are going to support connection recovery
you should be able to support opening a second connection in order to clean
the first connection and close it. It also explicitly says that you don't
have to support 2 connections in full feature phase. And even on 2 TCP
connections it is just a recommendation - using IP-over-pidgeons can be an
good alternative for forcing a TCP connection to close. On a more serious
note the second TCP connection can be on the same physical connection.
+++

Section 2.12.4
If the limit of reflected data is 4096 bytes, then the instruction to
the initiator should not be "avoid sending", it should be "MUST NOT"
send more than 4096 bytes.  Is there a reason why the initiator would
want to send more than those number of bytes?

+++ The implications of saying MUST NOT would be that the target has to
check and to reject with a format error. We don't want this do we? +++

Section 2.14
This section was discussed above in relationship to section 1.2.6.  The
Logout command should be simple and immediate, with no further work
needed by the target then the clearing of internal buffers, and the
reporting on the next Login (CHECK CONDITION) that the Logout was
performed.

+++ the answer is the same as before +++

Section 2.16
The last sentence in this section seems at odds with good error
detection for targets, and at odds with section 2.19.1.  If a SNACK
received has and error, whether or not it was a miss-directed PDU, or a
transit error, why would a target just silently ignore it?  Should it
use the SNACK Rejected code of the Reject response, or at least tell the
initiator something?  Besides, the use of the word "must" seems
inconsistent with what this sentence is trying to say.  If there is a
good reason for a target to ignore this, then it should be mentioned,
and the directive should be "MUST" if the expectations of the initiator
are set that way.

+++ A SNACK that is not supported is answered either by an Asynch Message
asking logout - for failover - or total silence - in which case we assume
SCSI will timeout and do its thing (abort, reissue the command or whatever
neded.
There no need to answer. A badly formed SNACK is rejected as any othe badly
formed PDU (although even this is perceived by some as excessive when it
does not help the initiator take repair action).
++++

Section 2.16.1
The last paragraph of this section is confusing.  We cannot determine
how it should be rewritten, since the intent is not clear.  Why would
the target issue a message requesting Logout simply because it cannot
process as SNACK that is optional anyway?  How does the initiator know
if the target supports in-connection or out-of-connection recovery with
regards to what the target does after discarding the SNACK?
+++ The target should request logout if it supports connection recovery but
not
data snack +++

Section 2.17.3
What is the purpose of the last sentence on page 87?  It seems to
indicate that there is a good reason (besides the obvious) why the
Desired Data Length should not be zero, but falls short of explaining,
or directing the reader with a "MUST," or "SHOULD."

+++ the reason is in 2.17.1 the number of R2Ts in a command should be less
than x'ffffffff'
+++

Section 2.17.4
This topic was discussed above in section 1.2.5.

+++ I hope the answer was adequate +++

Section 3
We would like to see the explanation in this section clarified with
regards to the use of mode parameter changes for SCSI settings, versus
iSCSI settings.  Suggested rewording for the first sentence of the
second paragraph:
"The mode parameters for iSCSI behavior cannot be set by SCSI mode-set
but can be retrieved by SCSI mode-sense commands."
Suggested additional wording:
"SCSI mode parameters (non-iSCSI specific) cannot be set or retrieved
from within iSCSI mode page commands."  -  Or something like that.
+++ OK +++
Section 4.2
Under the key SecurityContextComplete=yes, there is a description of
what the party sending this key should do, finishing with the phrase
"until the handshake is complete."  What is the scenario for avoiding a
lock condition in this handshake?  Should the party use some standard
timeout? Where is this defined?

+++ I think we can leave this to be implementation dependent. If I would
have to chose a "way out" would say limited number of text exchanges rather
than a timeout.  ++++

Section 7
The second paragraph in this section defines an assumption of the
specification.  Potential manufacturers of iSCSI targets will want to
know under what circumstances will the saving of sense and status
information differ than those already done for FC or SCSI operation;
specifically with regards to iSCSI Logout and iSCSI task management
commands.  Can this paragraph have more details added?

+++ The status and sense are saved for command recovery while the status is
not acknowledged. Te recovery may involve status only, or some lost data
(detected) when status arrived) or the whole command replay. Details are
... I think we have now more than 50 pages of detail +++

Section 7.1c
This description of the use of the Retry bit seems to put the onus of
interpretation of the Retry bit on the target for command replay.  Is it
at all possible for a Replay request to get issued, within the scope of
an initiator delaying its acknowledgement, such that the command
actually did get completed, but the Retry bit was set too soon?  Would
one assume that an initiator just avoids doing something like this?

+++ I will come back to this later. +++

Section 7.6
This section uses the term "ULP timeout", but there is no definition or
reference to where it can be found.

+++ It is not defined here - it is assumed that when we let SCSI commands
dry out (drop data packets, status etc.) the SCSI drivers will recover
after a timeout and do some cleanup +++

Section 7.9
By recommending (in the first paragraph) that a connection be tested in
HA environments with iSCSI NOP-ping command, aren't the authors
recommending that designers use bandwidth consuming methods for
determining this?  If you assume a multiple path connection (fabric) for
such iSCSI implementations, then couldn't a bunch of initiators
potentially flood the fabric with such commands to "recognize a failing
connection?"

+++ We don't think that a a NOP once a second or once 100ms is a bandwidth
consuming event.  +++

Section 7.11.1 and 7.11.2
Specifically, what time-outs are being referred to here?  The time a
target or initiator should or might wait for acknowledgement from the
other node that error recovery is being attempted?

+++ Yes and the values are fabric and device dependent +++

Section 7.11.3
This section seems to not agree with the methods for completing a Logout
command as discussed earlier.  Item number (2) in this section indicates
that the initiator should treat the reception of an Asynchronous Message
requesting a Logout command to that of a TCP failure, yet the target is
instructed (section 2.14) to treat the reception of a Logout command as
an opportunity to complete any commands "it deems necessary."  Again,
the need for a Target Logout and Initiator Logout seems apparent.

+++ Item 2 says only that the recovery procedure - if the parties are
capable
and willing to do within session recovery - should be initiated (like on a
complete TCP failure).  +++

Thanks,
Bob

Robert Griswold
Technologist
Crossroads Systems, Inc.
512-928-7272






From owner-ips@ece.cmu.edu  Sun Aug  5 11:57:41 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15257
	for <ips-archive@odin.ietf.org>; Sun, 5 Aug 2001 11:57:40 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f75FUDa18893
	for ips-outgoing; Sun, 5 Aug 2001 11:30:13 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f75FUAe18885;
	Sun, 5 Aug 2001 11:30:10 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id RAA133644;
	Sun, 5 Aug 2001 17:30:04 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f75FU3D06844;
	Sun, 5 Aug 2001 17:30:04 +0200
Importance: Normal
Subject: RE: Security Gateways
To: Jim McKinney <jmck+@ece.cmu.edu>
Cc: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF4363ACE9.DF3574F2-ONC2256A9F.0054E1D0@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Sun, 5 Aug 2001 18:29:46 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 05/08/2001 18:30:03
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Did somebody attempt to design specialized hardware to do UMAC?

Julo

Jim McKinney <jmck+@ece.cmu.edu>@ece.cmu.edu on 03-08-2001 21:55:06

Please respond to Jim McKinney <jmck+@ece.cmu.edu>

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: Security Gateways




Approved: sskm1

> Bernard Aboba wrote:
>
> Integrity protection via new MACs such as UMAC is *not*
> expensive. This is
> a myth. See http://www.cs.ucdavis.edu/~rogaway/umac/perf00.html
>

Bernard,

Thanks for the pointer to some current research in this area.

That paper gave cycles/byte numbers for their algorithm, on
a Pentium III and PowerPC.  For now, I'll comment on the PPC
numbers, because that family is available as an embeddable core
that can be integrated into hardware, while the Pentium III is not.
For 1500-byte messages, it looks like UMAC will take between
2.7 and 3.7 CPU clocks per byte (estimates, as no numbers
were given for the full UMAC function on PPC).

That indicates that I'd have to run my core at 600-800 Mhz
to handle a single full duplex Gigabit Ethernet port, assuming
I have the packets in memory that's fast enough to not stall the
CPU, and that there's some way of getting packets into and out
of that memory without interfering with the CPU.

I grant you that is "do-able," and it certainly is less expensive
than HMAC-SHA1, but I wouldn't call it "cheap."  At least for
some portion of the audience here, "cheap" may be measured by how
many thousands of gates the implementation adds to the existing
data path logic, and "fast" by how many gate delays were
introduced into that path.

So, I guess that puts me in agreement with Jim William's
comments; security protocols MUST be supported, and
supported in the context of a single standard,
not a "de jure" standard and a "de facto" alternative.
And, if that means the standard must embrace non-monolithic
"system level" compliance, then let's figure out how to
do that properly, rather than declaring it illegal and hoping
it will go away.

- milan







From owner-ips@ece.cmu.edu  Sun Aug  5 12:53:58 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15231
	for <ips-archive@odin.ietf.org>; Sun, 5 Aug 2001 11:55:57 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f75FMLj18633
	for ips-outgoing; Sun, 5 Aug 2001 11:22:21 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f75FMKe18627
	for <ips@ece.cmu.edu>; Sun, 5 Aug 2001 11:22:20 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id RAA236348
	for <ips@ece.cmu.edu>; Sun, 5 Aug 2001 17:22:12 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f75FMCA153850
	for <ips@ece.cmu.edu>; Sun, 5 Aug 2001 17:22:13 +0200
Importance: Normal
Subject: RE: Review of the 07 draft
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF40D6D634.B81361EF-ONC2256A9F.00530E57@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Sun, 5 Aug 2001 18:21:56 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 05/08/2001 18:22:12
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


I've added a statement saying:

The iSCSI specific parameter change with text mode commands MUST be
performed following the SCSI rules as stated by [SAM2] and [SPC].

Julo

"Dev" <deva@stargateip.com>@ece.cmu.edu on 04-08-2001 03:18:45

Please respond to <deva@stargateip.com>

Sent by:  owner-ips@ece.cmu.edu


To:   Jim Hafner/Almaden/IBM@IBMUS, "Robert Griswold"
      <rgriswold@Crossroads.com>
cc:   <ips@ece.cmu.edu>
Subject:  RE: Review of the 07 draft



Jim,

You wrote:
>Of course, the draft doesn't say whether MODE PARAMETERS HAVE
>CHANGED unit attentions get thrown up at the SCSI layer when this happens
>at the iSCSI layer.... You later have a clarifying question (Section 3) on
>this as well.

Yes it is necessary to return  unit attentions for Mode parameter changes
(changed through SCSI command).
it is within the domain of SCSI, not iSCSI . However a note on
implementation in the iSCSI spec that
discusses the mode parameters will be good.

Thanks

Deva
Platys communications






From owner-ips@ece.cmu.edu  Sun Aug  5 14:30:35 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17544
	for <ips-archive@odin.ietf.org>; Sun, 5 Aug 2001 14:30:34 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f75HaMr23041
	for ips-outgoing; Sun, 5 Aug 2001 13:36:22 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from zcamail05.zca.compaq.com (zcamail05.zca.compaq.com [161.114.32.105])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f75HaLe23035
	for <ips@ece.cmu.edu>; Sun, 5 Aug 2001 13:36:21 -0400 (EDT)
Received: by zcamail05.zca.compaq.com (Postfix, from userid 12345)
	id EE0A1D8E; Sun,  5 Aug 2001 10:40:08 -0700 (PDT)
Received: from exchou-gh02.cca.cpqcorp.net (exchou-gh02.cca.cpqcorp.net [16.110.248.202])
	by zcamail05.zca.compaq.com (Postfix) with ESMTP id B2E95C81
	for <ips@ece.cmu.edu>; Sun,  5 Aug 2001 10:40:08 -0700 (PDT)
Received: by exchou-gh02.cca.cpqcorp.net with Internet Mail Service (5.5.2652.78)
	id <QKRJAVCH>; Sun, 5 Aug 2001 12:36:14 -0500
Message-ID: <78AF3C342AEAEF4BA33B35A8A15668C6019E2010@cceexc17.americas.cpqcorp.net>
From: "Elliott, Robert" <Robert.Elliott@compaq.com>
To: "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
Subject: iSCSI: draft 7: Abort Task and RefCmdSN
Date: Sun, 5 Aug 2001 12:36:10 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

The Task Management [function] Command PDU includes two fields
currently only used by the ABORT TASK function:

2.5.2 Referenced Task Tag  
  Initiator Task Tag of the task to be aborted - for abort task 
 
2.5.3 RefCmdSN [Referenced command sequence number]
  For abort-task the task CmdSN to enable task removal. If RefCmdSN is 
  is lower that ExpCmdSN or higher than MaxCmdSN the target will ignore 
  RefCmdSN.

Both fields identify the task to be aborted.  The Referenced Task
Tag field sits at the SCSI level and matches the SAM-2 function
call description (SAM-2 revision 18):
6.2 ABORT TASK
  Function call:
    Service Response = ABORT TASK (IN (I_T_L_Q Nexus) )

The RefCmdSN field sits at the iSCSI level.

I suggest removing one of these fields.  Having two ways to
specify the same thing just raises the question of what to do
when the values don't agree.  If that happens, should the 
target:
send back a Reject PDU
abort both tasks
abort the task indicated by the Referenced Task Tag
abort the task indicated by the RefCmdSN
abort one of the tasks but also report an error
do any of the above

Since task management functions in general may rely on the
SCSI tag (although Abort Task is the only current user of it), 
I suggest keeping that flag and dropping the iSCSI field.

--
Robert.Elliott@compaq.com
Compaq Computer Server Storage


From owner-ips@ece.cmu.edu  Sun Aug  5 15:32:07 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19096
	for <ips-archive@odin.ietf.org>; Sun, 5 Aug 2001 15:32:07 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f75Ib9P24924
	for ips-outgoing; Sun, 5 Aug 2001 14:37:09 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f75Ib7e24920
	for <ips@ece.cmu.edu>; Sun, 5 Aug 2001 14:37:07 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id UAA145584
	for <ips@ece.cmu.edu>; Sun, 5 Aug 2001 20:37:01 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f75Ib0D29156
	for <ips@ece.cmu.edu>; Sun, 5 Aug 2001 20:37:00 +0200
Importance: Normal
Subject: Re: iSCSI: draft 7: Abort Task and RefCmdSN
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF013FA49E.166DE5E8-ONC2256A9F.006493A4@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Sun, 5 Aug 2001 21:36:44 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 05/08/2001 21:37:00
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Robert,

This is related to the fact that the abort command can arrive before the
command to be aborted if sent on a different connection (or the command has
been dropped due to some error). As such RefCmdSN indicates where the
command would have been in the command queue.  If they don't agree the
target should not abbort. And the main criteria for finding a task is the
Initiator Task Tag.
I've changed the wording to:

1.1.1     RefCmdSN

   For abort-task the task CmdSN to enable task removal. If RefCmdSN does
   not match the CmdSN of the command to be aborted at the target
The abort action MUST not be performed and the response MUST be function
rejected.

Julo



"Elliott, Robert" <Robert.Elliott@compaq.com>@ece.cmu.edu on 05-08-2001
20:36:10

Please respond to "Elliott, Robert" <Robert.Elliott@compaq.com>

Sent by:  owner-ips@ece.cmu.edu


To:   "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
cc:
Subject:  iSCSI: draft 7: Abort Task and RefCmdSN



The Task Management [function] Command PDU includes two fields
currently only used by the ABORT TASK function:

2.5.2 Referenced Task Tag
  Initiator Task Tag of the task to be aborted - for abort task

2.5.3 RefCmdSN [Referenced command sequence number]
  For abort-task the task CmdSN to enable task removal. If RefCmdSN is
  is lower that ExpCmdSN or higher than MaxCmdSN the target will ignore
  RefCmdSN.

Both fields identify the task to be aborted.  The Referenced Task
Tag field sits at the SCSI level and matches the SAM-2 function
call description (SAM-2 revision 18):
6.2 ABORT TASK
  Function call:
    Service Response = ABORT TASK (IN (I_T_L_Q Nexus) )

The RefCmdSN field sits at the iSCSI level.

I suggest removing one of these fields.  Having two ways to
specify the same thing just raises the question of what to do
when the values don't agree.  If that happens, should the
target:
send back a Reject PDU
abort both tasks
abort the task indicated by the Referenced Task Tag
abort the task indicated by the RefCmdSN
abort one of the tasks but also report an error
do any of the above

Since task management functions in general may rely on the
SCSI tag (although Abort Task is the only current user of it),
I suggest keeping that flag and dropping the iSCSI field.

--
Robert.Elliott@compaq.com
Compaq Computer Server Storage





From owner-ips@ece.cmu.edu  Sun Aug  5 16:51:52 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20968
	for <ips-archive@odin.ietf.org>; Sun, 5 Aug 2001 16:51:52 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f75JpYN27256
	for ips-outgoing; Sun, 5 Aug 2001 15:51:34 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from med.corp.rhapsodynetworks.com (64-160-62-201.rhapsodynetworks.com [64.160.62.201] (may be forged))
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f74NbQe10989
	for <ips@ece.cmu.edu>; Sat, 4 Aug 2001 19:37:37 -0400 (EDT)
Received: by med.corp.rhapsodynetworks.com with Internet Mail Service (5.5.2653.19)
	id <NXFDFMLA>; Sat, 4 Aug 2001 16:37:15 -0700
Message-ID: <45BEF1D68145D51186C100B0D0AABE6503D611@med.corp.rhapsodynetworks.com>
From: Venkat Rangan <vrangan@rhapsodynetworks.com>
To: "'Merhar, Milan'" <mmerhar@pirus.com>,
        "'Bernard Aboba'"
	 <aboba@internaut.com>,
        "'Williams, Jim'" <Jim.Williams@emulex.com>
Cc: Black_David@emc.com, rsnively@Brocade.COM, ips@ece.cmu.edu
Subject: RE: Security Gateways
Date: Sat, 4 Aug 2001 16:37:08 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Milan,

Rather than run the algorithm on a PPC core, you can get a native core as
listed here. When integrated into a Xilinx Virtex FPGA (XCV400-6) it gives
3Gbps processing for DES. AES is usually an order of magnitude faster, and
if you convert FPGA to ASIC, you may be looking at 2x to 4x improvement.

http://www.free-ip.com/DES

Venkat Rangan
Rhapsody Networks Inc.
http://www.rhapsodynetworks.com


-----Original Message-----
From: Merhar, Milan [mailto:mmerhar@pirus.com]
Sent: Friday, August 03, 2001 10:44 AM
To: 'Bernard Aboba'; 'Williams, Jim'
Cc: Black_David@emc.com; rsnively@Brocade.COM; ips@ece.cmu.edu
Subject: RE: Security Gateways


> Bernard Aboba wrote:
> 
> Integrity protection via new MACs such as UMAC is *not* 
> expensive. This is
> a myth. See http://www.cs.ucdavis.edu/~rogaway/umac/perf00.html 
>

Bernard,

Thanks for the pointer to some current research in this area.

That paper gave cycles/byte numbers for their algorithm, on 
a Pentium III and PowerPC.  For now, I'll comment on the PPC 
numbers, because that family is available as an embeddable core
that can be integrated into hardware, while the Pentium III is not. 
For 1500-byte messages, it looks like UMAC will take between 
2.7 and 3.7 CPU clocks per byte (estimates, as no numbers 
were given for the full UMAC function on PPC).  

That indicates that I'd have to run my core at 600-800 Mhz 
to handle a single full duplex Gigabit Ethernet port, assuming
I have the packets in memory that's fast enough to not stall the 
CPU, and that there's some way of getting packets into and out 
of that memory without interfering with the CPU.

I grant you that is "do-able," and it certainly is less expensive 
than HMAC-SHA1, but I wouldn't call it "cheap."  At least for 
some portion of the audience here, "cheap" may be measured by how 
many thousands of gates the implementation adds to the existing 
data path logic, and "fast" by how many gate delays were 
introduced into that path. 

So, I guess that puts me in agreement with Jim William's 
comments; security protocols MUST be supported, and 
supported in the context of a single standard, 
not a "de jure" standard and a "de facto" alternative.
And, if that means the standard must embrace non-monolithic 
"system level" compliance, then let's figure out how to 
do that properly, rather than declaring it illegal and hoping 
it will go away.

- milan


From owner-ips@ece.cmu.edu  Mon Aug  6 04:14:25 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19141
	for <ips-archive@odin.ietf.org>; Mon, 6 Aug 2001 04:14:25 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f767f3s19019
	for ips-outgoing; Mon, 6 Aug 2001 03:41:03 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f767f1e19015
	for <ips@ece.cmu.edu>; Mon, 6 Aug 2001 03:41:02 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id JAA301862
	for <ips@ece.cmu.edu>; Mon, 6 Aug 2001 09:40:53 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f767erx126370
	for <ips@ece.cmu.edu>; Mon, 6 Aug 2001 09:40:53 +0200
Importance: Normal
Subject: RE: iSCSI: draft 7: Abort Task and RefCmdSN
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF95614718.CB0F5850-ONC2256AA0.0029D5F7@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Mon, 6 Aug 2001 10:40:37 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 06/08/2001 10:40:52
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Sorry David - Since 06 this is not true anymore as they carry their own
CmdSN for the purpose you mentioned (even when immediate) - but although
this is good for clear task set it is not good enough for singles for which
we still need both.

Julo

Black_David@emc.com@ece.cmu.edu on 06-08-2001 10:14:43

Please respond to Black_David@emc.com

Sent by:  owner-ips@ece.cmu.edu


To:   Robert.Elliott@compaq.com, ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: draft 7: Abort Task and RefCmdSN



ABORT TASK SET and CLEAR TASK SET also need the RefCmdSN to
indicate where in the stream of commands they were issued.
Julian - you probably need to revise your revised text to
take this into account.

--David

> -----Original Message-----
> From: Elliott, Robert [mailto:Robert.Elliott@compaq.com]
> Sent: Sunday, August 05, 2001 1:36 PM
> To: 'ips@ece.cmu.edu'
> Subject: iSCSI: draft 7: Abort Task and RefCmdSN
>
>
> The Task Management [function] Command PDU includes two fields
> currently only used by the ABORT TASK function:
>
> 2.5.2 Referenced Task Tag
>   Initiator Task Tag of the task to be aborted - for abort task
>
> 2.5.3 RefCmdSN [Referenced command sequence number]
>   For abort-task the task CmdSN to enable task removal. If
> RefCmdSN is
>   is lower that ExpCmdSN or higher than MaxCmdSN the target
> will ignore
>   RefCmdSN.
>
> Both fields identify the task to be aborted.  The Referenced Task
> Tag field sits at the SCSI level and matches the SAM-2 function
> call description (SAM-2 revision 18):
> 6.2 ABORT TASK
>   Function call:
>     Service Response = ABORT TASK (IN (I_T_L_Q Nexus) )
>
> The RefCmdSN field sits at the iSCSI level.
>
> I suggest removing one of these fields.  Having two ways to
> specify the same thing just raises the question of what to do
> when the values don't agree.  If that happens, should the
> target:
> send back a Reject PDU
> abort both tasks
> abort the task indicated by the Referenced Task Tag
> abort the task indicated by the RefCmdSN
> abort one of the tasks but also report an error
> do any of the above
>
> Since task management functions in general may rely on the
> SCSI tag (although Abort Task is the only current user of it),
> I suggest keeping that flag and dropping the iSCSI field.
>
> --
> Robert.Elliott@compaq.com
> Compaq Computer Server Storage
>





From owner-ips@ece.cmu.edu  Mon Aug  6 04:17:18 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19235
	for <ips-archive@odin.ietf.org>; Mon, 6 Aug 2001 04:17:18 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f767JvD18375
	for ips-outgoing; Mon, 6 Aug 2001 03:19:57 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f767Jue18369
	for <ips@ece.cmu.edu>; Mon, 6 Aug 2001 03:19:56 -0400 (EDT)
Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <3W0TTSRQ>; Mon, 6 Aug 2001 03:19:50 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD57A@CORPMX14>
From: Black_David@emc.com
To: Robert.Elliott@compaq.com, ips@ece.cmu.edu
Subject: RE: iSCSI: draft 7: Abort Task and RefCmdSN
Date: Mon, 6 Aug 2001 03:14:43 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

ABORT TASK SET and CLEAR TASK SET also need the RefCmdSN to
indicate where in the stream of commands they were issued.
Julian - you probably need to revise your revised text to
take this into account.

--David

> -----Original Message-----
> From: Elliott, Robert [mailto:Robert.Elliott@compaq.com]
> Sent: Sunday, August 05, 2001 1:36 PM
> To: 'ips@ece.cmu.edu'
> Subject: iSCSI: draft 7: Abort Task and RefCmdSN
> 
> 
> The Task Management [function] Command PDU includes two fields
> currently only used by the ABORT TASK function:
> 
> 2.5.2 Referenced Task Tag  
>   Initiator Task Tag of the task to be aborted - for abort task 
>  
> 2.5.3 RefCmdSN [Referenced command sequence number]
>   For abort-task the task CmdSN to enable task removal. If 
> RefCmdSN is 
>   is lower that ExpCmdSN or higher than MaxCmdSN the target 
> will ignore 
>   RefCmdSN.
> 
> Both fields identify the task to be aborted.  The Referenced Task
> Tag field sits at the SCSI level and matches the SAM-2 function
> call description (SAM-2 revision 18):
> 6.2 ABORT TASK
>   Function call:
>     Service Response = ABORT TASK (IN (I_T_L_Q Nexus) )
> 
> The RefCmdSN field sits at the iSCSI level.
> 
> I suggest removing one of these fields.  Having two ways to
> specify the same thing just raises the question of what to do
> when the values don't agree.  If that happens, should the 
> target:
> send back a Reject PDU
> abort both tasks
> abort the task indicated by the Referenced Task Tag
> abort the task indicated by the RefCmdSN
> abort one of the tasks but also report an error
> do any of the above
> 
> Since task management functions in general may rely on the
> SCSI tag (although Abort Task is the only current user of it), 
> I suggest keeping that flag and dropping the iSCSI field.
> 
> --
> Robert.Elliott@compaq.com
> Compaq Computer Server Storage
> 


From owner-ips@ece.cmu.edu  Mon Aug  6 05:45:15 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20525
	for <ips-archive@odin.ietf.org>; Mon, 6 Aug 2001 05:45:15 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f768boL20691
	for ips-outgoing; Mon, 6 Aug 2001 04:37:50 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from relay2.bt.net (relay2.bt.net [194.72.6.62])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f768bne20687
	for <ips@ece.cmu.edu>; Mon, 6 Aug 2001 04:37:49 -0400 (EDT)
Received: from [217.33.138.159] (helo=cs.uchicago.edu)
	by relay2.bt.net with esmtp (Exim 3.15 #1)
	id 15TftP-0007ZU-00
	for ips@ece.cmu.edu; Mon, 06 Aug 2001 09:37:43 +0100
To: ips@ece.cmu.edu
Subject: Re: Security Gateways 
In-Reply-To: Message from Venkat Rangan <vrangan@rhapsodynetworks.com> 
   of "Sat, 04 Aug 2001 16:37:08 PDT." <45BEF1D68145D51186C100B0D0AABE6503D611@med.corp.rhapsodynetworks.com> 
References: <45BEF1D68145D51186C100B0D0AABE6503D611@med.corp.rhapsodynetworks.com> 
Date: Mon, 06 Aug 2001 04:37:37 -0400
From: Stephen Bailey <steph@cs.uchicago.edu>
Message-Id: <E15TftP-0007ZU-00@relay2.bt.net>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Venkat,

> it gives 3Gbps processing for DES

Thanks for the link.

Forgive my potential ignorance, but I'm not sure this number is
meaningful.  They say it would be problematic to adapt their fast mode
implementation to CBC, which is what IPSec requires.  The slow mode
variant, which they say is easily adaptable to CBE runs at 130
Mbits/s.  Furthermore, they admit that they don't even have a story on
fast 3DES/CBC, which what I thought was de rigeur these days.

Hopefully, somebody will correct any of misunderstanding I might have
in this regard.

Thanks,
  Steph


From owner-ips@ece.cmu.edu  Mon Aug  6 11:44:33 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26023
	for <ips-archive@odin.ietf.org>; Mon, 6 Aug 2001 11:44:33 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f76DxeA12009
	for ips-outgoing; Mon, 6 Aug 2001 09:59:40 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from c007.snv.cp.net (c007-h011.c007.snv.cp.net [209.228.33.217])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f76Dxde12005
	for <ips@ece.cmu.edu>; Mon, 6 Aug 2001 09:59:39 -0400 (EDT)
Received: (cpmta 5836 invoked from network); 6 Aug 2001 06:59:29 -0700
Received: from host217-33-146-233.ietf.ignite.net (HELO littlejoy) (217.33.146.233)
  by smtp.telocity.com (209.228.33.217) with SMTP; 6 Aug 2001 06:59:29 -0700
X-Sent: 6 Aug 2001 13:59:29 GMT
From: "Douglas Otis" <dotis@sanlight.net>
To: "Ips" <ips@ece.cmu.edu>
Subject: [iSCSI] Resolution of management commands and multiple head of queue commands.
Date: Mon, 6 Aug 2001 06:57:42 -0700
Message-ID: <NEBBJGDMMLHHCIKHGBEJAEBLCKAA.dotis@sanlight.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

All,

iSCSI version .7 is a significant improvement.  Two areas that prompted a
draft still seem unresolved.  Section 8.1 mentions a potential problem
without addressing at least a suggested means of handling these situations.
There are management commands that can not resolve with connection
allegiance alone.  On another point, with no assurance or direct
confirmation of Immediate Delivery Commands (IDC) and the potential for only
a single command resource being allocated by the target, one must wonder how
these commands are to be handled in practice.  Preventing more than a single
command to be sent as IDC would be one solution as there is assurance there
will be resources for only a single command.  If this were to be adopted as
the method of handling these IDC commands, then such a flag could serve to
allow an exception to the command window limit and avoid creating an
overlaid command sequence count that then only serves to befuddle
acknowledgement.  If multiple IDC commands need to be sent, then either
waiting for acknowledgement or sending these commands consecutively where
acknowledgement would indicate quickly status of these commands without the
initiator pondering their status at a point in time where speed of
resolution is important.

Doug



From owner-ips@ece.cmu.edu  Mon Aug  6 11:55:28 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26234
	for <ips-archive@odin.ietf.org>; Mon, 6 Aug 2001 11:55:27 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f76F2Uc15419
	for ips-outgoing; Mon, 6 Aug 2001 11:02:30 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f76F2Te15414
	for <ips@ece.cmu.edu>; Mon, 6 Aug 2001 11:02:29 -0400 (EDT)
Received: by zmamail03.zma.compaq.com (Postfix, from userid 12345)
	id E2A9DA0E8; Mon,  6 Aug 2001 11:02:19 -0400 (EDT)
Received: from exchou-gh02.cca.cpqcorp.net (exchou-gh02.cca.cpqcorp.net [16.110.248.202])
	by zmamail03.zma.compaq.com (Postfix) with ESMTP id B368899B0
	for <ips@ece.cmu.edu>; Mon,  6 Aug 2001 11:02:19 -0400 (EDT)
Received: by exchou-gh02.cca.cpqcorp.net with Internet Mail Service (5.5.2652.78)
	id <QLD2G82H>; Mon, 6 Aug 2001 10:02:18 -0500
Message-ID: <78AF3C342AEAEF4BA33B35A8A15668C6019E2012@cceexc17.americas.cpqcorp.net>
From: "Elliott, Robert" <Robert.Elliott@compaq.com>
To: "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
Subject: iSCSI: draft 7: Final bit in Data PDUs
Date: Mon, 6 Aug 2001 10:02:10 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

iSCSI draft 7 section 2.7.1 describes when the (F) Final bit is 
set in the Data-out and Data-in PDUs:

  For outgoing data, this bit is 1 for the last PDU of unsolicited
  data  or the last PDU of a sequence answering a R2T. 
         
  For incoming data, this bit is 1 for the last input (read) data
  PDU of a sequence.  

It needs to define how this works for bidirectional commands.
Is the F bit set to one on both the last Data-out PDU and the last
Data-in PDU?  Or is it set to one only on the last Data PDU, 
whatever direction it may be?

--
Robert.Elliott@compaq.com
Compaq Computer Server Storage


From owner-ips@ece.cmu.edu  Mon Aug  6 14:49:25 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29382
	for <ips-archive@odin.ietf.org>; Mon, 6 Aug 2001 14:49:24 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f76HlIZ24120
	for ips-outgoing; Mon, 6 Aug 2001 13:47:18 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f76HlFe24107
	for <ips@ece.cmu.edu>; Mon, 6 Aug 2001 13:47:16 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id TAA267332
	for <ips@ece.cmu.edu>; Mon, 6 Aug 2001 19:47:09 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f76Hl8x171804
	for <ips@ece.cmu.edu>; Mon, 6 Aug 2001 19:47:08 +0200
Importance: Normal
Subject: Re: iSCSI: draft 7: Final bit in Data PDUs
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF139DDEC3.83689B82-ONC2256AA0.005CFB5C@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Mon, 6 Aug 2001 19:57:27 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 06/08/2001 20:47:08
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Elliot,

I have no clue how those commands are going to work.
Can you help?
I assume that the F bit will have to be there at both ends?

Julo

"Elliott, Robert" <Robert.Elliott@compaq.com>@ece.cmu.edu on 06-08-2001
18:02:10

Please respond to "Elliott, Robert" <Robert.Elliott@compaq.com>

Sent by:  owner-ips@ece.cmu.edu


To:   "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
cc:
Subject:  iSCSI: draft 7: Final bit in Data PDUs



iSCSI draft 7 section 2.7.1 describes when the (F) Final bit is
set in the Data-out and Data-in PDUs:

  For outgoing data, this bit is 1 for the last PDU of unsolicited
  data  or the last PDU of a sequence answering a R2T.

  For incoming data, this bit is 1 for the last input (read) data
  PDU of a sequence.

It needs to define how this works for bidirectional commands.
Is the F bit set to one on both the last Data-out PDU and the last
Data-in PDU?  Or is it set to one only on the last Data PDU,
whatever direction it may be?

--
Robert.Elliott@compaq.com
Compaq Computer Server Storage





From owner-ips@ece.cmu.edu  Mon Aug  6 14:50:10 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29429
	for <ips-archive@odin.ietf.org>; Mon, 6 Aug 2001 14:50:10 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f76HlLa24121
	for ips-outgoing; Mon, 6 Aug 2001 13:47:21 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f76HlFe24108
	for <ips@ece.cmu.edu>; Mon, 6 Aug 2001 13:47:16 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id TAA268304
	for <ips@ece.cmu.edu>; Mon, 6 Aug 2001 19:47:09 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f76Hl8W17038
	for <ips@ece.cmu.edu>; Mon, 6 Aug 2001 19:47:08 +0200
Importance: Normal
Subject: Re: [iSCSI] Resolution of management commands and multiple head of queue
 commands.
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF1AB57C09.13854438-ONC2256AA0.005CB2A5@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Mon, 6 Aug 2001 19:53:56 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 06/08/2001 20:47:08
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Immediate commands don't just get discarded - they are rejected.

Julo

"Douglas Otis" <dotis@sanlight.net>@ece.cmu.edu on 06-08-2001 16:57:42

Please respond to "Douglas Otis" <dotis@sanlight.net>

Sent by:  owner-ips@ece.cmu.edu


To:   "Ips" <ips@ece.cmu.edu>
cc:
Subject:  [iSCSI] Resolution of management commands and multiple head of
      queue commands.



All,

iSCSI version .7 is a significant improvement.  Two areas that prompted a
draft still seem unresolved.  Section 8.1 mentions a potential problem
without addressing at least a suggested means of handling these situations.
There are management commands that can not resolve with connection
allegiance alone.  On another point, with no assurance or direct
confirmation of Immediate Delivery Commands (IDC) and the potential for
only
a single command resource being allocated by the target, one must wonder
how
these commands are to be handled in practice.  Preventing more than a
single
command to be sent as IDC would be one solution as there is assurance there
will be resources for only a single command.  If this were to be adopted as
the method of handling these IDC commands, then such a flag could serve to
allow an exception to the command window limit and avoid creating an
overlaid command sequence count that then only serves to befuddle
acknowledgement.  If multiple IDC commands need to be sent, then either
waiting for acknowledgement or sending these commands consecutively where
acknowledgement would indicate quickly status of these commands without the
initiator pondering their status at a point in time where speed of
resolution is important.

Doug






From owner-ips@ece.cmu.edu  Mon Aug  6 14:51:36 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29448
	for <ips-archive@odin.ietf.org>; Mon, 6 Aug 2001 14:51:35 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f76IG7X25631
	for ips-outgoing; Mon, 6 Aug 2001 14:16:07 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from emulex.emulex.com (emulex.emulex.com [138.239.112.1])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f76IG5e25625
	for <ips@ece.cmu.edu>; Mon, 6 Aug 2001 14:16:05 -0400 (EDT)
Received: from nsboston.ma.emulex.com (nsboston.ma.emulex.com [172.16.12.10])
	by emulex.emulex.com (8.9.1a/8.9.1) with ESMTP id LAA25364;
	Mon, 6 Aug 2001 11:16:10 -0700 (PDT)
Received: from 7h16a (gn14-140.ma.emulex.com [172.16.14.140])
	by nsboston.ma.emulex.com (8.9.1a/8.9.1) with SMTP id OAA11671;
	Mon, 6 Aug 2001 14:15:54 -0400 (EDT)
Reply-To: <Alex.Nicolson@emulex.com>
From: "Nicolson, Alex" <Alex.Nicolson@emulex.com>
To: "Julian Satran" <Julian_Satran@il.ibm.com>, <ips@ece.cmu.edu>
Subject: RE: iSCSI: draft 7: Abort Task and RefCmdSN
Date: Mon, 6 Aug 2001 14:16:28 -0400
Message-ID: <002f01c11ea3$e9231ea0$8c0e10ac@7h16a.ma.emulex.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700
In-Reply-To: <OF013FA49E.166DE5E8-ONC2256A9F.006493A4@telaviv.ibm.com>
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Julo,

I must be misunderstanding something. I thought that Task Management
commands were to be executed as if they had arrived in sequence based on
their CmdSN.

        "Task management commands must be executed
        as if all the commands having a CmdSN lower or equal to the task
        management CmdSN have been received by the target (i.e., have to be
        executed as if received for ordered delivery even when marked for
        immediate delivery)."

Why wouldn't that be the case with Abort Task?

Alex.Nicolson@emulex.com


> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Julian Satran
> Sent: Sunday, August 05, 2001 2:37 PM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI: draft 7: Abort Task and RefCmdSN
>
>
> Robert,
>
> This is related to the fact that the abort command can arrive before the
> command to be aborted if sent on a different connection (or the
> command has
> been dropped due to some error). As such RefCmdSN indicates where the
> command would have been in the command queue.  If they don't agree the
> target should not abbort. And the main criteria for finding a task is the
> Initiator Task Tag.
> I've changed the wording to:
>
> 1.1.1     RefCmdSN
>
>    For abort-task the task CmdSN to enable task removal. If RefCmdSN does
>    not match the CmdSN of the command to be aborted at the target
> The abort action MUST not be performed and the response MUST be function
> rejected.
>
> Julo
>
>
>
> "Elliott, Robert" <Robert.Elliott@compaq.com>@ece.cmu.edu on 05-08-2001
> 20:36:10
>
> Please respond to "Elliott, Robert" <Robert.Elliott@compaq.com>
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
> cc:
> Subject:  iSCSI: draft 7: Abort Task and RefCmdSN
>
>
>
> The Task Management [function] Command PDU includes two fields
> currently only used by the ABORT TASK function:
>
> 2.5.2 Referenced Task Tag
>   Initiator Task Tag of the task to be aborted - for abort task
>
> 2.5.3 RefCmdSN [Referenced command sequence number]
>   For abort-task the task CmdSN to enable task removal. If RefCmdSN is
>   is lower that ExpCmdSN or higher than MaxCmdSN the target will ignore
>   RefCmdSN.
>
> Both fields identify the task to be aborted.  The Referenced Task
> Tag field sits at the SCSI level and matches the SAM-2 function
> call description (SAM-2 revision 18):
> 6.2 ABORT TASK
>   Function call:
>     Service Response = ABORT TASK (IN (I_T_L_Q Nexus) )
>
> The RefCmdSN field sits at the iSCSI level.
>
> I suggest removing one of these fields.  Having two ways to
> specify the same thing just raises the question of what to do
> when the values don't agree.  If that happens, should the
> target:
> send back a Reject PDU
> abort both tasks
> abort the task indicated by the Referenced Task Tag
> abort the task indicated by the RefCmdSN
> abort one of the tasks but also report an error
> do any of the above
>
> Since task management functions in general may rely on the
> SCSI tag (although Abort Task is the only current user of it),
> I suggest keeping that flag and dropping the iSCSI field.
>
> --
> Robert.Elliott@compaq.com
> Compaq Computer Server Storage
>
>
>



From owner-ips@ece.cmu.edu  Mon Aug  6 15:53:24 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00413
	for <ips-archive@odin.ietf.org>; Mon, 6 Aug 2001 15:53:24 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f76Ijte27298
	for ips-outgoing; Mon, 6 Aug 2001 14:45:55 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from c007.snv.cp.net (c007-h000.c007.snv.cp.net [209.228.33.206])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f76Ijre27294
	for <ips@ece.cmu.edu>; Mon, 6 Aug 2001 14:45:53 -0400 (EDT)
Received: (cpmta 27072 invoked from network); 6 Aug 2001 11:45:37 -0700
Received: from host217-33-141-49.ietf.ignite.net (HELO littlejoy) (217.33.141.49)
  by smtp.telocity.com (209.228.33.206) with SMTP; 6 Aug 2001 11:45:37 -0700
X-Sent: 6 Aug 2001 18:45:37 GMT
From: "Douglas Otis" <dotis@sanlight.net>
To: "Julian Satran" <Julian_Satran@il.ibm.com>, <ips@ece.cmu.edu>
Subject: RE: [iSCSI] Resolution of management commands and multiple head of queue commands.
Date: Mon, 6 Aug 2001 11:43:50 -0700
Message-ID: <NEBBJGDMMLHHCIKHGBEJGEBOCKAA.dotis@sanlight.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: <OF1AB57C09.13854438-ONC2256AA0.005CB2A5@telaviv.ibm.com>
Importance: Normal
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Julian,

The reject response requires the entire PDU header be returned.  That would
then require resources to store these headers for such a response.  If there
are resources to store this command, that then begs the question how many
must be stored even if only to reject?  Do you have any insight as how a
multi-connection task set resolve state with independent status
serialization?

Doug

> Immediate commands don't just get discarded - they are rejected.
>
> Julo
>
> "Douglas Otis" <dotis@sanlight.net>@ece.cmu.edu on 06-08-2001 16:57:42
>
> Please respond to "Douglas Otis" <dotis@sanlight.net>
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   "Ips" <ips@ece.cmu.edu>
> cc:
> Subject:  [iSCSI] Resolution of management commands and multiple head of
>       queue commands.
>
>
>
> All,
>
> iSCSI version .7 is a significant improvement.  Two areas that prompted a
> draft still seem unresolved.  Section 8.1 mentions a potential problem
> without addressing at least a suggested means of handling these
> situations.
> There are management commands that can not resolve with connection
> allegiance alone.  On another point, with no assurance or direct
> confirmation of Immediate Delivery Commands (IDC) and the potential for
> only
> a single command resource being allocated by the target, one must wonder
> how
> these commands are to be handled in practice.  Preventing more than a
> single
> command to be sent as IDC would be one solution as there is
> assurance there
> will be resources for only a single command.  If this were to be
> adopted as
> the method of handling these IDC commands, then such a flag could serve to
> allow an exception to the command window limit and avoid creating an
> overlaid command sequence count that then only serves to befuddle
> acknowledgement.  If multiple IDC commands need to be sent, then either
> waiting for acknowledgement or sending these commands consecutively where
> acknowledgement would indicate quickly status of these commands
> without the
> initiator pondering their status at a point in time where speed of
> resolution is important.
>
> Doug
>
>
>
>
>



From owner-ips@ece.cmu.edu  Mon Aug  6 15:56:54 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00460
	for <ips-archive@odin.ietf.org>; Mon, 6 Aug 2001 15:56:54 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f76JMpX29403
	for ips-outgoing; Mon, 6 Aug 2001 15:22:51 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from hotmail.com (oe53.law11.hotmail.com [64.4.16.46])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f76JMne29398
	for <ips@ece.cmu.edu>; Mon, 6 Aug 2001 15:22:49 -0400 (EDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 6 Aug 2001 12:22:39 -0700
X-Originating-IP: [66.31.75.202]
From: "Eddy Quicksall" <ESQuicksall@hotmail.com>
To: "Elliott, Robert" <Robert.Elliott@compaq.com>, <ips@ece.cmu.edu>
References: <78AF3C342AEAEF4BA33B35A8A15668C6014D6915@cceexc17.americas.cpqcorp.net>
Subject: Re: iSCSI: draft 7: iSCSI response and SCSI sense data
Date: Mon, 6 Aug 2001 15:22:42 -0400
MIME-Version: 1.0
Content-Type: text/plain;	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Message-ID: <OE537fIZHO1g4dNCxLY00001bfb@hotmail.com>
X-OriginalArrivalTime: 06 Aug 2001 19:22:39.0904 (UTC) FILETIME=[28661A00:01C11EAD]
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Then what was the purpose of giving them separate fields and eliminating the
S bit?

Eddy

----- Original Message -----
From: "Elliott, Robert" <Robert.Elliott@compaq.com>
To: <ips@ece.cmu.edu>
Sent: Thursday, August 02, 2001 6:04 PM
Subject: RE: iSCSI: draft 7: iSCSI response and SCSI sense data


> My view:
> If a non-zero response code is present, the Status field is undefined
> and the response data contains all information about the error (fed
> from the iSCSI layer).
>
> If the target is capable of reporting a Status, then the response
> field is zero and the sense data contains all information about the
> error (fed from the SCSI layer, which might communicate with the
> iSCSI layer internally to figure out some of the information).
>
> ---
> Rob Elliott, Compaq Server Storage
> Robert.Elliott@compaq.com
>
>
>
> > -----Original Message-----
> > From: Robert Snively [mailto:rsnively@brocade.com]
> > Sent: Thursday, August 02, 2001 4:39 PM
> > To: 'cbm@rose.hp.com'; Elliott, Robert
> > Cc: 'ips@ece.cmu.edu'
> > Subject: RE: iSCSI: draft 7: iSCSI response and SCSI sense data
> >
> >
> > I am not sure that complete removal of the response codes
> > is the best approach.  There are some things
> > that SCSI devices can know nothing about, and only TCP links
> > can know about.  There are other things that iSCSI state machines
> > know about that logical units do not know about (usually software
> > generated inconsistencies in the protocol procedures).  These are
> > natural candidates for response codes.  Note that vendor
> > specific is a synonym for non-interoperable and also for
> > undesirable.  It is far better to reserve anything like that,
> > since the behavior in the presence of a vendor specific value
> > is not defined.  While it is clear that may response codes should
> > move over to CHECK CONDITIONS, I think that there are
> > still some protocol related response codes that will be required.
> >
> > Bob
> >
> > -----Original Message-----
> > From: Mallikarjun C. [mailto:cbm@rose.hp.com]
> > Sent: Wednesday, August 01, 2001 9:06 PM
> > To: Elliott, Robert
> > Cc: 'ips@ece.cmu.edu'
> > Subject: Re: iSCSI: draft 7: iSCSI response and SCSI sense data
> >
> >
> > Robert and all,
> >
> > As the one who suggested that wording into the draft, let me
> > add some comments. (Please see
> > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg05089.html
> > for my initial proposal.)
> >
> > > I suggest removing the CHECK CONDITION status and additional sense
> > > code linkage and leave the SCSI status undefined if the iSCSI
> > > response is nonzero.
> >
> > I agree, as Steph already alluded to in a separate email, the ideal
> > solution appears to:
> >           a) drop the response code *definitions* (ie. leave
> >              room for vendor-unique codes) altogether, and
> >           b) continue to specify the right SCSI CHECK CONDITION
> >              (ASC, ASCQ) values for the iSCSI error events (such
> >              as digest failures).
> >
> > As I said in the earlier referenced message "mandate a standard
> > SCSI CHECK CONDITION on these errors with the current response codes
> > acting as detailed descriptions.".  But you bring up a good point
> > that this "detailed descriptions" may be violating SAM-2's
> > expectations.
> >
> > > Forcing the iSCSI layer to fill in those fields seems to break the
> > > layering model.
> >
> > I disagree.  If the affected SCSI task can be reliably ascertained
> > by the target, it appears highly desirable to report the status
> > using a SCSI CHECK CONDITION.  Target iSCSI layer has to internally
> > terminate the pre-instantiated SCSI task anyway informing its SCSI
> > layer of the fact.  Besides, there are precedents in FCP-2 for similar
> > cases where the task is identifiable.
> >
> > Regards.
> > --
> > Mallikarjun
> >
> > Mallikarjun Chadalapaka
> > Networked Storage Architecture
> > Network Storage Solutions Organization
> > MS 5668 Hewlett-Packard, Roseville.
> > cbm@rose.hp.com
> >
> > "Elliott, Robert" wrote:
> > >
> > > iSCSI draft 7 section 2.4.3 includes a table relating the iSCSI
> > > response codes to various CHECK CONDITION status additional
> > > sense codes:
> > >
> > >   "0x01 Target Failure
> > >     ASC=0x44 ASCQ=0x00 INTERNAL TARGET FAILURE
> > >   0x02 Delivery Subsystem Failure
> > >     ASC=0x47 ASCQ=0x03 INFORMATION UNIT CRC ERROR DETECTED
> > >   0x03 Unsolicited data rejected
> > >     ASC=0x49 ASCQ=0x00 INVALID MESSAGE ERROR
> > >   0x04 Not enough unsolicited [data]
> > >     ASC=0x49 ASCQ=0x00 INVALID MESSAGE ERROR
> > >   0x05 SNACK rejected [Command in progress]
> > >     ASC=0x47 ASCQ=0x03 INFORMATION UNIT CRC ERROR DETECTED
> > >
> > >   As listed above, each defined response code MUST be used
> > (under the
> > >   conditions described in the 'Reason' field), only when the
> > >   corresponding SCSI CHECK CONDITION is signaled, to convey
> > additional
> > >   protocol service information.  A SCSI CHECK CONDITION with the ASC
> > >   and ASCQ values as tabulated MUST be signaled by iSCSI targets for
> > >   all the instances in this document referring to usage of
> > one of the
> > >   above defined response codes."
> > >
> > > No other SCSI protocol does this. iSCSI seems to be granting the
> > > SCSI-level status a priority over the iSCSI-level response data.
> > > I think the other protocols treat the response data as more
> > > important; if the response data indicates a problem, the SCSI layer
> > > is considered broken and the SCSI status is undefined.
> > >
> > > Forcing the iSCSI layer to fill in those fields seems to break the
> > > layering model.
> > >
> > > I suggest removing the CHECK CONDITION status and additional sense
> > > code linkage and leave the SCSI status undefined if the iSCSI
> > > response is nonzero.
> > >
> > > This is compatible with SAM-2, which only requires status
> > be returned
> > > when the service response is TASK COMPLETE (SAM-2 revision 18
> > > section 5.3.1):
> > >   "Status shall be sent from the logical unit to the application
> > >    client whenever a command ends with a service response of
> > >    TASK COMPLETE or LINKED COMMAND COMPLETE."
> > >
> > > Furthermore, SAM-2 requires that status be ignored when the service
> > > response indicates an error (SAM-2 revision 18 section 5.1):
> > >   "Status: A one-byte field containing command completion status
> > >   (see 5.3). If the command ends with a service response of
> > >   SERVICE DELIVERY OR TARGET FAILURE, the application client
> > >   shall consider this parameter to be undefined."
> > >
> > > I think iSCSI's current wording may violate this rule.
> > > ---
> > > Rob Elliott, Compaq Server Storage
> > > Robert.Elliott@compaq.com
> >
>


From owner-ips@ece.cmu.edu  Mon Aug  6 15:57:52 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00475
	for <ips-archive@odin.ietf.org>; Mon, 6 Aug 2001 15:57:52 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f76JNJP29425
	for ips-outgoing; Mon, 6 Aug 2001 15:23:19 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from c007.snv.cp.net (c007-h011.c007.snv.cp.net [209.228.33.217])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f76JNIe29420
	for <ips@ece.cmu.edu>; Mon, 6 Aug 2001 15:23:18 -0400 (EDT)
Received: (cpmta 1436 invoked from network); 6 Aug 2001 12:21:57 -0700
Received: from host217-33-141-49.ietf.ignite.net (HELO littlejoy) (217.33.141.49)
  by smtp.telocity.com (209.228.33.217) with SMTP; 6 Aug 2001 12:21:57 -0700
X-Sent: 6 Aug 2001 19:21:57 GMT
From: "Douglas Otis" <dotis@sanlight.net>
To: "Julian Satran" <Julian_Satran@il.ibm.com>, <ips@ece.cmu.edu>
Subject: RE: [iSCSI] Resolution of management commands and multiple head of queue commands.
Date: Mon, 6 Aug 2001 12:20:10 -0700
Message-ID: <NEBBJGDMMLHHCIKHGBEJGEBPCKAA.dotis@sanlight.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <OF1AB57C09.13854438-ONC2256AA0.005CB2A5@telaviv.ibm.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

As a follow on:

iSCSI .7

RE: Immediate Delivery

        "Please note that the number of commands used for immediate delivery
        is not limited and their delivery to execution is not acknowledged
        through the numbering scheme.  Immediate commands can be rejected by
        the iSCSI target due to lack of resources. An iSCSI target MUST be
        able to handle at least one immediate task management command and
one
        immediate non-task-management iSCSI request per connection at any
        time."

RE: Reject

        "It may happen that a target receives a PDU with a format error
(e.g.,
        inconsistent fields etc.) or a digest error (e.g., invalid payload
or
        header). The target returns the header (not including digest) of the
        PDU in error as the data of the response."

Unlike any other command, Immediate Delivery Commands are not regulated by
the Target.  It is clear however that even to reject these commands, there
needs to be resources.  If there is resouces, then there is not a problem,
if there is not resouces, then the logic seems broken.

Doug

> Immediate commands don't just get discarded - they are rejected.
>
> Julo
>
> "Douglas Otis" <dotis@sanlight.net>@ece.cmu.edu on 06-08-2001 16:57:42
>
> Please respond to "Douglas Otis" <dotis@sanlight.net>
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   "Ips" <ips@ece.cmu.edu>
> cc:
> Subject:  [iSCSI] Resolution of management commands and multiple head of
>       queue commands.
>
>
>
> All,
>
> iSCSI version .7 is a significant improvement.  Two areas that prompted a
> draft still seem unresolved.  Section 8.1 mentions a potential problem
> without addressing at least a suggested means of handling these
> situations.
> There are management commands that can not resolve with connection
> allegiance alone.  On another point, with no assurance or direct
> confirmation of Immediate Delivery Commands (IDC) and the potential for
> only
> a single command resource being allocated by the target, one must wonder
> how
> these commands are to be handled in practice.  Preventing more than a
> single
> command to be sent as IDC would be one solution as there is
> assurance there
> will be resources for only a single command.  If this were to be
> adopted as
> the method of handling these IDC commands, then such a flag could serve to
> allow an exception to the command window limit and avoid creating an
> overlaid command sequence count that then only serves to befuddle
> acknowledgement.  If multiple IDC commands need to be sent, then either
> waiting for acknowledgement or sending these commands consecutively where
> acknowledgement would indicate quickly status of these commands
> without the
> initiator pondering their status at a point in time where speed of
> resolution is important.
>
> Doug
>
>
>
>
>



From owner-ips@ece.cmu.edu  Mon Aug  6 16:59:41 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01666
	for <ips-archive@odin.ietf.org>; Mon, 6 Aug 2001 16:59:41 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f76Jhs700601
	for ips-outgoing; Mon, 6 Aug 2001 15:43:54 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f76Jhqe00594
	for <ips@ece.cmu.edu>; Mon, 6 Aug 2001 15:43:52 -0400 (EDT)
Received: by ATLOPS with Internet Mail Service (5.5.2448.0)
	id <QMJCNB1H>; Mon, 6 Aug 2001 15:43:45 -0400
Message-ID: <25369470B6F0D41194820002B328BDD20266F3@ATLOPS>
From: Sanjay Goyal <sanjay_goyal@ivivity.com>
To: "Ips (E-mail)" <ips@ece.cmu.edu>
Cc: Sanjay Goyal <sanjay_goyal@ivivity.com>
Subject: AHSLength 
Date: Mon, 6 Aug 2001 15:43:44 -0400 
X-MS-TNEF-Correlator: <25369470B6F0D41194820002B328BDD20266F3@ATLOPS>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C11EB0.1A671488"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C11EB0.1A671488
Content-Type: text/plain;
	charset="iso-8859-1"

Hi
 as per 2.2.3.2 in iSCSI draft version 7.0
  AHSLength is length in bytes of the AHS 
        excluding AHSType and AHSLength (not including padding).
   It doesnot mention any thing about byte-3 in 1st (32-bit)WORD (address
0).
 
 if we look at the example for BI-DI the AHSLength is 5 which includes the
byte-3 in 1st WORD 
       whereas
 if we look at the example for Extended CDB the AHSLength is CDB-16, it
seems as if the byte-3 of 1st WORD is not counted in AHSLength. The reason
for length to be CDB-16, I assume is because the BHS has first 16 bytes of
the CDB.

I am not clear on whether we will include byte-3 of 1st WORD in the
AHSLength or not.

Regards
Sanjay Goyal

------_=_NextPart_000_01C11EB0.1A671488
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64

eJ8+Ii4TAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQWAAwAOAAAA0QcIAAYADwArACwAAQBNAQEggAMADgAAANEHCAAG
AA8AKwAsAAEATQEBCYABACEAAABERDQ1N0M2QTY1OEFENTExOTRCMzAwMDJCMzI4QkREMgAgBwEE
gAEACwAAAEFIU0xlbmd0aCAAXgMBDYAEAAIAAAACAAIAAQOQBgCEBwAAMAAAAAMACVkBAAAAAwDe
P69vAAADADYAAAAAAAMAW4AIIAYAAAAAAMAAAAAAAABGAAAAAFKFAAB9bgEAHgBcgAggBgAAAAAA
wAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAAOS4wAAsAhYAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAA
AAAAAwAOgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALABCACCAGAAAAAADAAAAAAAAARgAA
AAADhQAAAAAAAAsAEYAIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwA3gAggBgAAAAAAwAAA
AAAAAEYAAAAAEIUAAAAAAAADADiACCAGAAAAAADAAAAAAAAARgAAAAARhQAAAAAAAAMAPoAIIAYA
AAAAAMAAAAAAAABGAAAAABiFAAAAAAAAAgEJEAEAAABcAgAAWAIAAPMDAABMWkZ1GGKHwQMACgBy
Y3BnMTI14jIDQ3RleAVBAQMB9/8KgAKkA+QHEwKAD/MAUARWPwhVB7IRJQ5RAwECAGNo4QrAc2V0
MgYABsMRJfYzBEYTtzASLBEzCO8J97Y7GB8OMDURIgxgYwBQMwsJAWQzNhZQC6YgSKcAoAqxCoAg
YQQgcBKB1DIuHfAzHgAgC4AeYABTQ1NJIGRyYTkBgCB2BJAAkAIgIDeOLgFAHSQQwEhTTAnw2Gd0
aB5gBCBsINUDoIxieQ6wBCBvZiAhAL5lIIIK4yBSI3QOwGMKQMpkC4BnIIJUeR2wHXDEbmQgiShu
bwVAC4BLJBYKsGQkQikuIxdJ+QVAZG8HkCYCB4ACMB+i/QBweSKBJFIBoAhgBUAiAiQtMx5iMXMF
QCgzADItYml0KVdPvFJEJeAm8RggBBEwJ1czHRUGkCB3IrAXsG9rzx1wBUAikg7AYW0LUCKwwwIQ
BcBCSS1EHuAilf0gyDUtoCmAE9AmNQeRIpLfKjwrkyMbMPAEkGUdgC0fey4vBbFFDtAJ8AEAJTBD
DERCL783Yi0xNiznHmAFQBQQZW0EIB2BNQG/MekiYTLHITEmAgWgdQIwxzdBHnEgly4gVCKhNFLn
H7EvIiFldG8h8CKwOMZzHuAdgHN1B4AhIj8AY+xhdRQQIoNCIuET4AQg/GZpFAAFQDkAIfw3cSdl
+x0UP7FtO8QhYArBH7E0Ie8ikQXANTED8GwDIDFVOm8/O3IDoDe8BbEmAUNLUmVOZwsRNIUGEWph
KVBHLG95B0AdFH1MIB4AcAABAAAAJwAAAGlTQ1NJOiBkcmFmdCA3OiBGaW5hbCBiaXQgaW4gRGF0
YSBQRFVzAAACAXEAAQAAABsAAAABwR6QVshqfETEimUR1ZSzAAKzKL3SAAXYUoAAAwAmAAAAAAAD
AC4AAAAAAAsAAgABAAAAHgBCEAEAAABJAAAAPDc4QUYzQzM0MkFFQUVGNEJBMzNCMzVBOEExNTY2
OEM2MDE5RTIwMTJAY2NlZXhjMTcuYW1lcmljYXMuY3BxY29ycC5uZXQ+AAAAAAMA/T/kBAAAQAA5
AEAzTxqwHsEBAwDxPwkEAAAeADFAAQAAAAgAAABTQU5KQVlHAAMAGkAAAAAAHgAwQAEAAAAIAAAA
U0FOSkFZRwADABlAAAAAAAMAgBD/////CwDyEAEAAAACAUcAAQAAAC0AAABjPVVTO2E9IDtwPUlW
SVZJVFk7bD1BVExPUFMtMDEwODA2MTk0MzQ0Wi0zNAAAAAACAfk/AQAAAEoAAAAAAAAA3KdAyMBC
EBq0uQgAKy/hggEAAAAAAAAAL089SVZJVklUWS9PVT1BVExPUFMvQ049UkVDSVBJRU5UUy9DTj1T
QU5KQVlHAAAAHgD4PwEAAAANAAAAU2FuamF5IEdveWFsAAAAAB4AOEABAAAACAAAAFNBTkpBWUcA
AgH7PwEAAABKAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAAAAAAAC9PPUlWSVZJVFkvT1U9QVRM
T1BTL0NOPVJFQ0lQSUVOVFMvQ049U0FOSkFZRwAAAB4A+j8BAAAADQAAAFNhbmpheSBHb3lhbAAA
AAAeADlAAQAAAAgAAABTQU5KQVlHAEAABzCq2kwasB7BAUAACDCIFGcasB7BAR4APQABAAAAAQAA
AAAAAAAeAB0OAQAAAAsAAABBSFNMZW5ndGggAAAeADUQAQAAADAAAAA8MjUzNjk0NzBCNkYwRDQx
MTk0ODIwMDAyQjMyOEJERDIwMjY2RjNAQVRMT1BTPgALACkAAAAAAAsAIwAAAAAAAwAGENPnUhQD
AAcQCgIAAAMAEBAAAAAAAwAREAAAAAAeAAgQAQAAAGUAAABISUFTUEVSMjIzMklOSVNDU0lEUkFG
VFZFUlNJT043MEFIU0xFTkdUSElTTEVOR1RISU5CWVRFU09GVEhFQUhTRVhDTFVESU5HQUhTVFlQ
RUFOREFIU0xFTkdUSChOT1RJTkNMAAAAAAIBfwABAAAAMAAAADwyNTM2OTQ3MEI2RjBENDExOTQ4
MjAwMDJCMzI4QkREMjAyNjZGM0BBVExPUFM+ANqb

------_=_NextPart_000_01C11EB0.1A671488--


From owner-ips@ece.cmu.edu  Mon Aug  6 16:59:43 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01677
	for <ips-archive@odin.ietf.org>; Mon, 6 Aug 2001 16:59:42 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f76KLfS02743
	for ips-outgoing; Mon, 6 Aug 2001 16:21:41 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f76KLde02734
	for <ips@ece.cmu.edu>; Mon, 6 Aug 2001 16:21:40 -0400 (EDT)
Received: by ATLOPS with Internet Mail Service (5.5.2448.0)
	id <QMJCNB1W>; Mon, 6 Aug 2001 16:21:34 -0400
Message-ID: <25369470B6F0D41194820002B328BDD20266F4@ATLOPS>
From: Sanjay Goyal <sanjay_goyal@ivivity.com>
To: Sanjay Goyal <sanjay_goyal@ivivity.com>,
        "'Ips (E-mail)'"
	 <ips@ece.cmu.edu>
Subject: F bit for SCSI command PDU
Date: Mon, 6 Aug 2001 16:21:33 -0400 
X-MS-TNEF-Correlator: <25369470B6F0D41194820002B328BDD20266F4@ATLOPS>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C11EB5.62ADC034"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C11EB5.62ADC034
Content-Type: text/plain;
	charset="iso-8859-1"

Hi
 as per description for b7, F-bit in 2.3.1 in iSCSI draft version 7.0
 
my interpretation is that for Write SCSI Command PDUs if we are sending just
the command without any data, we should set the F-bit to 1, is this correct,
please clarify.
   
Regards
Sanjay Goyal

------_=_NextPart_000_01C11EB5.62ADC034
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64

eJ8+IiMUAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQWAAwAOAAAA0QcIAAYAEAAVACEAAQAtAQEggAMADgAAANEHCAAG
ABAAFQAhAAEALQEBCYABACEAAABERDQ2N0M2QTY1OEFENTExOTRCMzAwMDJCMzI4QkREMgAhBwEE
gAEAGwAAAEYgYml0IGZvciBTQ1NJIGNvbW1hbmQgUERVAGYIAQ2ABAACAAAAAgACAAEDkAYAnAYA
AC8AAAADADYAAAAAAAMAW4AIIAYAAAAAAMAAAAAAAABGAAAAAFKFAAB9bgEAHgBcgAggBgAAAAAA
wAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAAOS4wAAsAhYAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAA
AAAAAwAOgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALABCACCAGAAAAAADAAAAAAAAARgAA
AAADhQAAAAAAAAsAEYAIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwA3gAggBgAAAAAAwAAA
AAAAAEYAAAAAEIUAAAAAAAADADiACCAGAAAAAADAAAAAAAAARgAAAAARhQAAAAAAAAMAPoAIIAYA
AAAAAMAAAAAAAABGAAAAABiFAAAAAAAAAgEJEAEAAACEAQAAgAEAADICAABMWkZ1j0Q3xwMACgBy
Y3BnMTI14jIDQ3RleAVBAQMB9/8KgAKkA+QHEwKAD/MAUARWPwhVB7IRJQ5RAwECAGNo4QrAc2V0
MgYABsMRJfYzBEYTtzASLBEzCO8J97Y7GB8OMDURIgxgYwBQMwsJAWQzNhZQC6YgSKcAoAqxCoAg
YQQgcBKB6wEABPRpAiAgAhAFwAGwwCwgRi1iaQVAC4BAIDIuMy4xH4JpkFNDU0kd4HJhAYCcIHYE
kACQHoE3LgFAMx0kHRRteR+BDrBycM8YIAGQHmMEACB0E+AFQH0eslcFEA6wBgAgcghQbcEDgWQg
UERVBCAGkPwgdySwCsAksBQQJXALgOBnIGp1cwVAI+AksP8FoCVEA/Aj4AhgBUAAcCKgWmQjUGEf
ECYhcyhRbA8lgBQRJ1MfNHRvIDGfHxAjsyOxBaEYIGN0HxA9C1BlHYAngQtgBoF5LkcdFS2AHRRS
ZWcLEXMTHRQGEWphIqBHb3kLB0AdFH0wEB4AcAABAAAAJwAAAGlTQ1NJOiBkcmFmdCA3OiBGaW5h
bCBiaXQgaW4gRGF0YSBQRFVzAAACAXEAAQAAACAAAAABwR6QVshqfETEimUR1ZSzAAKzKL3SAAXY
UoAAA1TPUAMAJgAAAAAAAwAuAAAAAAALAAIAAQAAAAMACVkBAAAAHgBCEAEAAAAwAAAAPDI1MzY5
NDcwQjZGMEQ0MTE5NDgyMDAwMkIzMjhCREQyMDI2NkYzQEFUTE9QUz4AAwDeP69vAABAADkAkF6f
YrUewQEDAPE/CQQAAB4AMUABAAAACAAAAFNBTkpBWUcAAwAaQAAAAAAeADBAAQAAAAgAAABTQU5K
QVlHAAMAGUAAAAAAAwD9P+QEAAADAIAQ/////wIBRwABAAAALQAAAGM9VVM7YT0gO3A9SVZJVklU
WTtsPUFUTE9QUy0wMTA4MDYyMDIxMzNaLTM5AAAAAAIB+T8BAAAASgAAAAAAAADcp0DIwEIQGrS5
CAArL+GCAQAAAAAAAAAvTz1JVklWSVRZL09VPUFUTE9QUy9DTj1SRUNJUElFTlRTL0NOPVNBTkpB
WUcAAAAeAPg/AQAAAA0AAABTYW5qYXkgR295YWwAAAAAHgA4QAEAAAAIAAAAU0FOSkFZRwACAfs/
AQAAAEoAAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAAL089SVZJVklUWS9PVT1BVExPUFMv
Q049UkVDSVBJRU5UUy9DTj1TQU5KQVlHAAAAHgD6PwEAAAANAAAAU2FuamF5IEdveWFsAAAAAB4A
OUABAAAACAAAAFNBTkpBWUcAQAAHMEy93gO1HsEBQAAIMDTArWK1HsEBHgA9AAEAAAABAAAAAAAA
AB4AHQ4BAAAAGwAAAEYgYml0IGZvciBTQ1NJIGNvbW1hbmQgUERVAAAeADUQAQAAADAAAAA8MjUz
Njk0NzBCNkYwRDQxMTk0ODIwMDAyQjMyOEJERDIwMjY2RjRAQVRMT1BTPgALACkAAAAAAAsAIwAA
AAAAAwAGEFZASyoDAAcQ0wAAAAMAEBAAAAAAAwAREAAAAAAeAAgQAQAAAGUAAABISUFTUEVSREVT
Q1JJUFRJT05GT1JCNyxGLUJJVElOMjMxSU5JU0NTSURSQUZUVkVSU0lPTjcwTVlJTlRFUlBSRVRB
VElPTklTVEhBVEZPUldSSVRFU0NTSUNPTU1BTkRQRFVTAAAAAAIBfwABAAAAMAAAADwyNTM2OTQ3
MEI2RjBENDExOTQ4MjAwMDJCMzI4QkREMjAyNjZGNEBBVExPUFM+AJ5P

------_=_NextPart_000_01C11EB5.62ADC034--


From owner-ips@ece.cmu.edu  Mon Aug  6 17:20:51 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02047
	for <ips-archive@odin.ietf.org>; Mon, 6 Aug 2001 17:20:50 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f76KdQA03627
	for ips-outgoing; Mon, 6 Aug 2001 16:39:26 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f76KdOe03622
	for <ips@ece.cmu.edu>; Mon, 6 Aug 2001 16:39:25 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id WAA225898
	for <ips@ece.cmu.edu>; Mon, 6 Aug 2001 22:39:18 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f76KdHx141218
	for <ips@ece.cmu.edu>; Mon, 6 Aug 2001 22:39:18 +0200
Importance: Normal
Subject: Re: F bit for SCSI command PDU
To: Sanjay Goyal <sanjay_goyal@ivivity.com>
Cc: Sanjay Goyal <sanjay_goyal@ivivity.com>,
        "'Ips (E-mail)'" <ips@ece.cmu.edu>
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF2C83FDEC.B74A29FB-ONC2256AA0.00716A43@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Mon, 6 Aug 2001 23:39:02 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 06/08/2001 23:39:17
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

yes - julo

Sanjay Goyal <sanjay_goyal@ivivity.com>@ece.cmu.edu on 06-08-2001 23:21:33

Please respond to Sanjay Goyal <sanjay_goyal@ivivity.com>

Sent by:  owner-ips@ece.cmu.edu


To:   Sanjay Goyal <sanjay_goyal@ivivity.com>, "'Ips (E-mail)'"
      <ips@ece.cmu.edu>
cc:
Subject:  F bit for SCSI command PDU



Hi
 as per description for b7, F-bit in 2.3.1 in iSCSI draft version 7.0

my interpretation is that for Write SCSI Command PDUs if we are sending
just
the command without any data, we should set the F-bit to 1, is this
correct,
please clarify.

Regards
Sanjay Goyal

 - C.DTF





From owner-ips@ece.cmu.edu  Mon Aug  6 17:32:45 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02324
	for <ips-archive@odin.ietf.org>; Mon, 6 Aug 2001 17:32:44 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f76KnrA04175
	for ips-outgoing; Mon, 6 Aug 2001 16:49:53 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from aexchgmid.aebsinternal.com ([156.46.187.18])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f76Knpe04170
	for <ips@ece.cmu.edu>; Mon, 6 Aug 2001 16:49:51 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: remove
Date: Mon, 6 Aug 2001 15:48:29 -0500
Message-ID: <2DF94E7DE745C3449BCF1BBC71E6BAAC1D9729@aexchgmid.aebsinternal.com>
Thread-Topic: iSCSI: draft 7: iSCSI response and SCSI sense data
Thread-Index: AcEetOJyMpg9ynbnQPSD1gIMkdnxqAABD5mg
From: "Tim Arland" <tim.arland@aebs.com>
To: "Eddy Quicksall" <ESQuicksall@hotmail.com>,
        "Elliott, Robert" <Robert.Elliott@compaq.com>, <ips@ece.cmu.edu>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f76Knqe04171
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit



-----Original Message-----
From: Eddy Quicksall [mailto:ESQuicksall@hotmail.com]
Sent: Monday, August 06, 2001 2:23 PM
To: Elliott, Robert; ips@ece.cmu.edu
Subject: Re: iSCSI: draft 7: iSCSI response and SCSI sense data


Then what was the purpose of giving them separate fields and eliminating
the
S bit?

Eddy

----- Original Message -----
From: "Elliott, Robert" <Robert.Elliott@compaq.com>
To: <ips@ece.cmu.edu>
Sent: Thursday, August 02, 2001 6:04 PM
Subject: RE: iSCSI: draft 7: iSCSI response and SCSI sense data


> My view:
> If a non-zero response code is present, the Status field is undefined
> and the response data contains all information about the error (fed
> from the iSCSI layer).
>
> If the target is capable of reporting a Status, then the response
> field is zero and the sense data contains all information about the
> error (fed from the SCSI layer, which might communicate with the
> iSCSI layer internally to figure out some of the information).
>
> ---
> Rob Elliott, Compaq Server Storage
> Robert.Elliott@compaq.com
>
>
>
> > -----Original Message-----
> > From: Robert Snively [mailto:rsnively@brocade.com]
> > Sent: Thursday, August 02, 2001 4:39 PM
> > To: 'cbm@rose.hp.com'; Elliott, Robert
> > Cc: 'ips@ece.cmu.edu'
> > Subject: RE: iSCSI: draft 7: iSCSI response and SCSI sense data
> >
> >
> > I am not sure that complete removal of the response codes
> > is the best approach.  There are some things
> > that SCSI devices can know nothing about, and only TCP links
> > can know about.  There are other things that iSCSI state machines
> > know about that logical units do not know about (usually software
> > generated inconsistencies in the protocol procedures).  These are
> > natural candidates for response codes.  Note that vendor
> > specific is a synonym for non-interoperable and also for
> > undesirable.  It is far better to reserve anything like that,
> > since the behavior in the presence of a vendor specific value
> > is not defined.  While it is clear that may response codes should
> > move over to CHECK CONDITIONS, I think that there are
> > still some protocol related response codes that will be required.
> >
> > Bob
> >
> > -----Original Message-----
> > From: Mallikarjun C. [mailto:cbm@rose.hp.com]
> > Sent: Wednesday, August 01, 2001 9:06 PM
> > To: Elliott, Robert
> > Cc: 'ips@ece.cmu.edu'
> > Subject: Re: iSCSI: draft 7: iSCSI response and SCSI sense data
> >
> >
> > Robert and all,
> >
> > As the one who suggested that wording into the draft, let me
> > add some comments. (Please see
> > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg05089.html
> > for my initial proposal.)
> >
> > > I suggest removing the CHECK CONDITION status and additional sense
> > > code linkage and leave the SCSI status undefined if the iSCSI
> > > response is nonzero.
> >
> > I agree, as Steph already alluded to in a separate email, the ideal
> > solution appears to:
> >           a) drop the response code *definitions* (ie. leave
> >              room for vendor-unique codes) altogether, and
> >           b) continue to specify the right SCSI CHECK CONDITION
> >              (ASC, ASCQ) values for the iSCSI error events (such
> >              as digest failures).
> >
> > As I said in the earlier referenced message "mandate a standard
> > SCSI CHECK CONDITION on these errors with the current response codes
> > acting as detailed descriptions.".  But you bring up a good point
> > that this "detailed descriptions" may be violating SAM-2's
> > expectations.
> >
> > > Forcing the iSCSI layer to fill in those fields seems to break the
> > > layering model.
> >
> > I disagree.  If the affected SCSI task can be reliably ascertained
> > by the target, it appears highly desirable to report the status
> > using a SCSI CHECK CONDITION.  Target iSCSI layer has to internally
> > terminate the pre-instantiated SCSI task anyway informing its SCSI
> > layer of the fact.  Besides, there are precedents in FCP-2 for
similar
> > cases where the task is identifiable.
> >
> > Regards.
> > --
> > Mallikarjun
> >
> > Mallikarjun Chadalapaka
> > Networked Storage Architecture
> > Network Storage Solutions Organization
> > MS 5668 Hewlett-Packard, Roseville.
> > cbm@rose.hp.com
> >
> > "Elliott, Robert" wrote:
> > >
> > > iSCSI draft 7 section 2.4.3 includes a table relating the iSCSI
> > > response codes to various CHECK CONDITION status additional
> > > sense codes:
> > >
> > >   "0x01 Target Failure
> > >     ASC=0x44 ASCQ=0x00 INTERNAL TARGET FAILURE
> > >   0x02 Delivery Subsystem Failure
> > >     ASC=0x47 ASCQ=0x03 INFORMATION UNIT CRC ERROR DETECTED
> > >   0x03 Unsolicited data rejected
> > >     ASC=0x49 ASCQ=0x00 INVALID MESSAGE ERROR
> > >   0x04 Not enough unsolicited [data]
> > >     ASC=0x49 ASCQ=0x00 INVALID MESSAGE ERROR
> > >   0x05 SNACK rejected [Command in progress]
> > >     ASC=0x47 ASCQ=0x03 INFORMATION UNIT CRC ERROR DETECTED
> > >
> > >   As listed above, each defined response code MUST be used
> > (under the
> > >   conditions described in the 'Reason' field), only when the
> > >   corresponding SCSI CHECK CONDITION is signaled, to convey
> > additional
> > >   protocol service information.  A SCSI CHECK CONDITION with the
ASC
> > >   and ASCQ values as tabulated MUST be signaled by iSCSI targets
for
> > >   all the instances in this document referring to usage of
> > one of the
> > >   above defined response codes."
> > >
> > > No other SCSI protocol does this. iSCSI seems to be granting the
> > > SCSI-level status a priority over the iSCSI-level response data.
> > > I think the other protocols treat the response data as more
> > > important; if the response data indicates a problem, the SCSI
layer
> > > is considered broken and the SCSI status is undefined.
> > >
> > > Forcing the iSCSI layer to fill in those fields seems to break the
> > > layering model.
> > >
> > > I suggest removing the CHECK CONDITION status and additional sense
> > > code linkage and leave the SCSI status undefined if the iSCSI
> > > response is nonzero.
> > >
> > > This is compatible with SAM-2, which only requires status
> > be returned
> > > when the service response is TASK COMPLETE (SAM-2 revision 18
> > > section 5.3.1):
> > >   "Status shall be sent from the logical unit to the application
> > >    client whenever a command ends with a service response of
> > >    TASK COMPLETE or LINKED COMMAND COMPLETE."
> > >
> > > Furthermore, SAM-2 requires that status be ignored when the
service
> > > response indicates an error (SAM-2 revision 18 section 5.1):
> > >   "Status: A one-byte field containing command completion status
> > >   (see 5.3). If the command ends with a service response of
> > >   SERVICE DELIVERY OR TARGET FAILURE, the application client
> > >   shall consider this parameter to be undefined."
> > >
> > > I think iSCSI's current wording may violate this rule.
> > > ---
> > > Rob Elliott, Compaq Server Storage
> > > Robert.Elliott@compaq.com
> >
>


From owner-ips@ece.cmu.edu  Mon Aug  6 17:35:02 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02369
	for <ips-archive@odin.ietf.org>; Mon, 6 Aug 2001 17:35:02 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f76KYAd03330
	for ips-outgoing; Mon, 6 Aug 2001 16:34:10 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f76KY8e03320
	for <ips@ece.cmu.edu>; Mon, 6 Aug 2001 16:34:08 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id WAA293286
	for <ips@ece.cmu.edu>; Mon, 6 Aug 2001 22:34:01 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f76KY0W65498
	for <ips@ece.cmu.edu>; Mon, 6 Aug 2001 22:34:01 +0200
Importance: Normal
Subject: RE: iSCSI: draft 7: Abort Task and RefCmdSN
To: <Alex.Nicolson@emulex.com>
Cc: <ips@ece.cmu.edu>
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF2D07FE7B.8F08D662-ONC2256AA0.006FB0B3@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Mon, 6 Aug 2001 23:21:13 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 06/08/2001 23:34:01
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Alex,

That is correct but has no relevance if you want to abbort one specific
task.

Julo

"Nicolson, Alex" <Alex.Nicolson@emulex.com> on 06-08-2001 21:16:28

Please respond to <Alex.Nicolson@emulex.com>

To:   Julian Satran/Haifa/IBM@IBMIL, <ips@ece.cmu.edu>
cc:
Subject:  RE: iSCSI: draft 7: Abort Task and RefCmdSN



Julo,

I must be misunderstanding something. I thought that Task Management
commands were to be executed as if they had arrived in sequence based on
their CmdSN.

        "Task management commands must be executed
        as if all the commands having a CmdSN lower or equal to the task
        management CmdSN have been received by the target (i.e., have to be
        executed as if received for ordered delivery even when marked for
        immediate delivery)."

Why wouldn't that be the case with Abort Task?

Alex.Nicolson@emulex.com


> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Julian Satran
> Sent: Sunday, August 05, 2001 2:37 PM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI: draft 7: Abort Task and RefCmdSN
>
>
> Robert,
>
> This is related to the fact that the abort command can arrive before the
> command to be aborted if sent on a different connection (or the
> command has
> been dropped due to some error). As such RefCmdSN indicates where the
> command would have been in the command queue.  If they don't agree the
> target should not abbort. And the main criteria for finding a task is the
> Initiator Task Tag.
> I've changed the wording to:
>
> 1.1.1     RefCmdSN
>
>    For abort-task the task CmdSN to enable task removal. If RefCmdSN does
>    not match the CmdSN of the command to be aborted at the target
> The abort action MUST not be performed and the response MUST be function
> rejected.
>
> Julo
>
>
>
> "Elliott, Robert" <Robert.Elliott@compaq.com>@ece.cmu.edu on 05-08-2001
> 20:36:10
>
> Please respond to "Elliott, Robert" <Robert.Elliott@compaq.com>
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
> cc:
> Subject:  iSCSI: draft 7: Abort Task and RefCmdSN
>
>
>
> The Task Management [function] Command PDU includes two fields
> currently only used by the ABORT TASK function:
>
> 2.5.2 Referenced Task Tag
>   Initiator Task Tag of the task to be aborted - for abort task
>
> 2.5.3 RefCmdSN [Referenced command sequence number]
>   For abort-task the task CmdSN to enable task removal. If RefCmdSN is
>   is lower that ExpCmdSN or higher than MaxCmdSN the target will ignore
>   RefCmdSN.
>
> Both fields identify the task to be aborted.  The Referenced Task
> Tag field sits at the SCSI level and matches the SAM-2 function
> call description (SAM-2 revision 18):
> 6.2 ABORT TASK
>   Function call:
>     Service Response = ABORT TASK (IN (I_T_L_Q Nexus) )
>
> The RefCmdSN field sits at the iSCSI level.
>
> I suggest removing one of these fields.  Having two ways to
> specify the same thing just raises the question of what to do
> when the values don't agree.  If that happens, should the
> target:
> send back a Reject PDU
> abort both tasks
> abort the task indicated by the Referenced Task Tag
> abort the task indicated by the RefCmdSN
> abort one of the tasks but also report an error
> do any of the above
>
> Since task management functions in general may rely on the
> SCSI tag (although Abort Task is the only current user of it),
> I suggest keeping that flag and dropping the iSCSI field.
>
> --
> Robert.Elliott@compaq.com
> Compaq Computer Server Storage
>
>
>






From owner-ips@ece.cmu.edu  Mon Aug  6 17:35:07 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02386
	for <ips-archive@odin.ietf.org>; Mon, 6 Aug 2001 17:35:07 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f76KYG503342
	for ips-outgoing; Mon, 6 Aug 2001 16:34:16 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f76KYDe03336
	for <ips@ece.cmu.edu>; Mon, 6 Aug 2001 16:34:13 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id WAA104546;
	Mon, 6 Aug 2001 22:34:02 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f76KY1x86648;
	Mon, 6 Aug 2001 22:34:01 +0200
Importance: Normal
Subject: Re: iSCSI: draft 7: iSCSI response and SCSI sense data
To: "Eddy Quicksall" <ESQuicksall@hotmail.com>
Cc: "Elliott, Robert" <Robert.Elliott@compaq.com>, <ips@ece.cmu.edu>
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFDA87C1B9.F9378D30-ONC2256AA0.00705C20@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Mon, 6 Aug 2001 23:27:47 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 06/08/2001 23:34:01
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


That will change - Julo

"Eddy Quicksall" <ESQuicksall@hotmail.com>@ece.cmu.edu on 06-08-2001
22:22:42

Please respond to "Eddy Quicksall" <ESQuicksall@hotmail.com>

Sent by:  owner-ips@ece.cmu.edu


To:   "Elliott, Robert" <Robert.Elliott@compaq.com>, <ips@ece.cmu.edu>
cc:
Subject:  Re: iSCSI: draft 7: iSCSI response and SCSI sense data



Then what was the purpose of giving them separate fields and eliminating
the
S bit?

Eddy

----- Original Message -----
From: "Elliott, Robert" <Robert.Elliott@compaq.com>
To: <ips@ece.cmu.edu>
Sent: Thursday, August 02, 2001 6:04 PM
Subject: RE: iSCSI: draft 7: iSCSI response and SCSI sense data


> My view:
> If a non-zero response code is present, the Status field is undefined
> and the response data contains all information about the error (fed
> from the iSCSI layer).
>
> If the target is capable of reporting a Status, then the response
> field is zero and the sense data contains all information about the
> error (fed from the SCSI layer, which might communicate with the
> iSCSI layer internally to figure out some of the information).
>
> ---
> Rob Elliott, Compaq Server Storage
> Robert.Elliott@compaq.com
>
>
>
> > -----Original Message-----
> > From: Robert Snively [mailto:rsnively@brocade.com]
> > Sent: Thursday, August 02, 2001 4:39 PM
> > To: 'cbm@rose.hp.com'; Elliott, Robert
> > Cc: 'ips@ece.cmu.edu'
> > Subject: RE: iSCSI: draft 7: iSCSI response and SCSI sense data
> >
> >
> > I am not sure that complete removal of the response codes
> > is the best approach.  There are some things
> > that SCSI devices can know nothing about, and only TCP links
> > can know about.  There are other things that iSCSI state machines
> > know about that logical units do not know about (usually software
> > generated inconsistencies in the protocol procedures).  These are
> > natural candidates for response codes.  Note that vendor
> > specific is a synonym for non-interoperable and also for
> > undesirable.  It is far better to reserve anything like that,
> > since the behavior in the presence of a vendor specific value
> > is not defined.  While it is clear that may response codes should
> > move over to CHECK CONDITIONS, I think that there are
> > still some protocol related response codes that will be required.
> >
> > Bob
> >
> > -----Original Message-----
> > From: Mallikarjun C. [mailto:cbm@rose.hp.com]
> > Sent: Wednesday, August 01, 2001 9:06 PM
> > To: Elliott, Robert
> > Cc: 'ips@ece.cmu.edu'
> > Subject: Re: iSCSI: draft 7: iSCSI response and SCSI sense data
> >
> >
> > Robert and all,
> >
> > As the one who suggested that wording into the draft, let me
> > add some comments. (Please see
> > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg05089.html
> > for my initial proposal.)
> >
> > > I suggest removing the CHECK CONDITION status and additional sense
> > > code linkage and leave the SCSI status undefined if the iSCSI
> > > response is nonzero.
> >
> > I agree, as Steph already alluded to in a separate email, the ideal
> > solution appears to:
> >           a) drop the response code *definitions* (ie. leave
> >              room for vendor-unique codes) altogether, and
> >           b) continue to specify the right SCSI CHECK CONDITION
> >              (ASC, ASCQ) values for the iSCSI error events (such
> >              as digest failures).
> >
> > As I said in the earlier referenced message "mandate a standard
> > SCSI CHECK CONDITION on these errors with the current response codes
> > acting as detailed descriptions.".  But you bring up a good point
> > that this "detailed descriptions" may be violating SAM-2's
> > expectations.
> >
> > > Forcing the iSCSI layer to fill in those fields seems to break the
> > > layering model.
> >
> > I disagree.  If the affected SCSI task can be reliably ascertained
> > by the target, it appears highly desirable to report the status
> > using a SCSI CHECK CONDITION.  Target iSCSI layer has to internally
> > terminate the pre-instantiated SCSI task anyway informing its SCSI
> > layer of the fact.  Besides, there are precedents in FCP-2 for similar
> > cases where the task is identifiable.
> >
> > Regards.
> > --
> > Mallikarjun
> >
> > Mallikarjun Chadalapaka
> > Networked Storage Architecture
> > Network Storage Solutions Organization
> > MS 5668 Hewlett-Packard, Roseville.
> > cbm@rose.hp.com
> >
> > "Elliott, Robert" wrote:
> > >
> > > iSCSI draft 7 section 2.4.3 includes a table relating the iSCSI
> > > response codes to various CHECK CONDITION status additional
> > > sense codes:
> > >
> > >   "0x01 Target Failure
> > >     ASC=0x44 ASCQ=0x00 INTERNAL TARGET FAILURE
> > >   0x02 Delivery Subsystem Failure
> > >     ASC=0x47 ASCQ=0x03 INFORMATION UNIT CRC ERROR DETECTED
> > >   0x03 Unsolicited data rejected
> > >     ASC=0x49 ASCQ=0x00 INVALID MESSAGE ERROR
> > >   0x04 Not enough unsolicited [data]
> > >     ASC=0x49 ASCQ=0x00 INVALID MESSAGE ERROR
> > >   0x05 SNACK rejected [Command in progress]
> > >     ASC=0x47 ASCQ=0x03 INFORMATION UNIT CRC ERROR DETECTED
> > >
> > >   As listed above, each defined response code MUST be used
> > (under the
> > >   conditions described in the 'Reason' field), only when the
> > >   corresponding SCSI CHECK CONDITION is signaled, to convey
> > additional
> > >   protocol service information.  A SCSI CHECK CONDITION with the ASC
> > >   and ASCQ values as tabulated MUST be signaled by iSCSI targets for
> > >   all the instances in this document referring to usage of
> > one of the
> > >   above defined response codes."
> > >
> > > No other SCSI protocol does this. iSCSI seems to be granting the
> > > SCSI-level status a priority over the iSCSI-level response data.
> > > I think the other protocols treat the response data as more
> > > important; if the response data indicates a problem, the SCSI layer
> > > is considered broken and the SCSI status is undefined.
> > >
> > > Forcing the iSCSI layer to fill in those fields seems to break the
> > > layering model.
> > >
> > > I suggest removing the CHECK CONDITION status and additional sense
> > > code linkage and leave the SCSI status undefined if the iSCSI
> > > response is nonzero.
> > >
> > > This is compatible with SAM-2, which only requires status
> > be returned
> > > when the service response is TASK COMPLETE (SAM-2 revision 18
> > > section 5.3.1):
> > >   "Status shall be sent from the logical unit to the application
> > >    client whenever a command ends with a service response of
> > >    TASK COMPLETE or LINKED COMMAND COMPLETE."
> > >
> > > Furthermore, SAM-2 requires that status be ignored when the service
> > > response indicates an error (SAM-2 revision 18 section 5.1):
> > >   "Status: A one-byte field containing command completion status
> > >   (see 5.3). If the command ends with a service response of
> > >   SERVICE DELIVERY OR TARGET FAILURE, the application client
> > >   shall consider this parameter to be undefined."
> > >
> > > I think iSCSI's current wording may violate this rule.
> > > ---
> > > Rob Elliott, Compaq Server Storage
> > > Robert.Elliott@compaq.com
> >
>





From owner-ips@ece.cmu.edu  Mon Aug  6 17:39:35 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02453
	for <ips-archive@odin.ietf.org>; Mon, 6 Aug 2001 17:39:35 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f76KY9Y03328
	for ips-outgoing; Mon, 6 Aug 2001 16:34:09 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f76KY7e03318
	for <ips@ece.cmu.edu>; Mon, 6 Aug 2001 16:34:07 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id WAA104544
	for <ips@ece.cmu.edu>; Mon, 6 Aug 2001 22:34:00 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f76KY0W65496
	for <ips@ece.cmu.edu>; Mon, 6 Aug 2001 22:34:00 +0200
Importance: Normal
Subject: iSCSI London-IETF-foils
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF8B74ADF8.2A7606E7-ONC2256AA0.006F73AB@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Mon, 6 Aug 2001 23:18:33 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 06/08/2001 23:34:00
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

My foils are on my site.

Julo



From owner-ips@ece.cmu.edu  Mon Aug  6 18:18:02 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03256
	for <ips-archive@odin.ietf.org>; Mon, 6 Aug 2001 18:18:02 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f76LC4X05266
	for ips-outgoing; Mon, 6 Aug 2001 17:12:04 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from relay3.bt.net (relay3.bt.net [194.72.6.50])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f76LC3e05262
	for <ips@ece.cmu.edu>; Mon, 6 Aug 2001 17:12:03 -0400 (EDT)
Received: from [217.33.138.159] (helo=cs.uchicago.edu)
	by relay3.bt.net with esmtp (Exim 3.22 #1)
	id 15TrfJ-0006Kw-00
	for ips@ece.cmu.edu; Mon, 06 Aug 2001 22:11:57 +0100
To: ips@ece.cmu.edu
Subject: iSCSI: Updated proposed iSCSI framing draft requirements
Date: Mon, 06 Aug 2001 17:11:52 -0400
From: Stephen Bailey <steph@cs.uchicago.edu>
Message-Id: <E15TrfJ-0006Kw-00@relay3.bt.net>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

All,

The updated proposed requirements for iSCSI framing modes (modes are
described in draft-ietf-tsvwg-tcp-ulp-frame-00.txt) are:

 o iSCSI receivers SHALL implement one of:
   - No framing
   - PDU alignment and no framing
   - Markers, PDU alignment and no framing
 o iSCSI senders SHALL implement one of:
   - PDU alignment and no framing
   - Markers and no framing
 o iSCSI senders SHOULD implement:
   - PDU alignment and no framing

Please review and comment.

Sorry for the mixup.

Thanks,
  Steph


From owner-ips@ece.cmu.edu  Mon Aug  6 23:50:25 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09062
	for <ips-archive@odin.ietf.org>; Mon, 6 Aug 2001 23:50:24 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f772kWo20651
	for ips-outgoing; Mon, 6 Aug 2001 22:46:32 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from hotmail.com (oe67.law8.hotmail.com [216.33.240.202])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f76Kgke03844
	for <ips@ece.cmu.edu>; Mon, 6 Aug 2001 16:42:46 -0400 (EDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 6 Aug 2001 13:42:40 -0700
X-Originating-IP: [64.174.149.250]
From: "Satish Menon" <satish_s_menon@hotmail.com>
To: <ips@ece.cmu.edu>
Date: Mon, 6 Aug 2001 13:44:05 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;	boundary="----=_NextPart_000_0067_01C11E7D.DC2126F0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Message-ID: <OE678Bi89QtpfTYSl1q00006d36@hotmail.com>
X-OriginalArrivalTime: 06 Aug 2001 20:42:40.0411 (UTC) FILETIME=[55B956B0:01C11EB8]
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0067_01C11E7D.DC2126F0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Does anyone know how many end-to-end credits a typical HBA (N-port) =
issues per exchange? For a long distance link over FCIP, clearly this =
number needs to be large. If not, then the link utilization will be =
extremely poor. For e.g. a 200ms RTT link at 1 Gbps assuming 1 exchange =
through it, it will need 10,000 credits to keep the link fully utilized. =
Using a different number of exchanges say 2000, the number of credits =
per exchange drop to 5.

------=_NextPart_000_0067_01C11E7D.DC2126F0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2><FONT =
face=3DArial=20
size=3D2>Does anyone know how many end-to-end credits a typical HBA =
(N-port)=20
issues per exchange? For a long distance link over FCIP, clearly this =
number=20
needs to be large. If not, then the link utilization will be extremely=20
poor.&nbsp;For e.g. a 200ms RTT link at 1 Gbps assuming 1 exchange =
through it,=20
it will need 10,000 credits to keep the link fully utilized. Using a =
different=20
number of exchanges say 2000, the number of credits per exchange drop to =

5.</FONT></FONT></FONT></DIV></FONT></DIV></BODY></HTML>

------=_NextPart_000_0067_01C11E7D.DC2126F0--


From owner-ips@ece.cmu.edu  Tue Aug  7 02:52:31 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26784
	for <ips-archive@odin.ietf.org>; Tue, 7 Aug 2001 02:52:31 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f775jU127070
	for ips-outgoing; Tue, 7 Aug 2001 01:45:30 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f775jOe27062
	for <ips@ece.cmu.edu>; Tue, 7 Aug 2001 01:45:24 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id HAA231336
	for <ips@ece.cmu.edu>; Tue, 7 Aug 2001 07:45:17 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f775jGW60738
	for <ips@ece.cmu.edu>; Tue, 7 Aug 2001 07:45:16 +0200
Importance: Normal
Subject: Re: AHSLength
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF080A1F57.DD444F58-ONC2256AA1.00196A56@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Tue, 7 Aug 2001 07:40:45 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 07/08/2001 08:45:16
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Sanjay,

You are right - there is a mistake in the extended CDB - the length field
should read "CDBLength - 15".

Julo

Sanjay Goyal <sanjay_goyal@ivivity.com>@ece.cmu.edu on 06-08-2001 22:43:44

Please respond to Sanjay Goyal <sanjay_goyal@ivivity.com>

Sent by:  owner-ips@ece.cmu.edu


To:   "Ips (E-mail)" <ips@ece.cmu.edu>
cc:   Sanjay Goyal <sanjay_goyal@ivivity.com>
Subject:  AHSLength



Hi
 as per 2.2.3.2 in iSCSI draft version 7.0
  AHSLength is length in bytes of the AHS
        excluding AHSType and AHSLength (not including padding).
   It doesnot mention any thing about byte-3 in 1st (32-bit)WORD (address
0).

 if we look at the example for BI-DI the AHSLength is 5 which includes the
byte-3 in 1st WORD
       whereas
 if we look at the example for Extended CDB the AHSLength is CDB-16, it
seems as if the byte-3 of 1st WORD is not counted in AHSLength. The reason
for length to be CDB-16, I assume is because the BHS has first 16 bytes of
the CDB.

I am not clear on whether we will include byte-3 of 1st WORD in the
AHSLength or not.

Regards
Sanjay Goyal







From owner-ips@ece.cmu.edu  Tue Aug  7 02:52:38 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26795
	for <ips-archive@odin.ietf.org>; Tue, 7 Aug 2001 02:52:38 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7768LC27852
	for ips-outgoing; Tue, 7 Aug 2001 02:08:21 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7768Je27847
	for <ips@ece.cmu.edu>; Tue, 7 Aug 2001 02:08:19 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id IAA183696
	for <ips@ece.cmu.edu>; Tue, 7 Aug 2001 08:08:12 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7768BW26784
	for <ips@ece.cmu.edu>; Tue, 7 Aug 2001 08:08:11 +0200
Importance: Normal
Subject: Re:
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF33E62F3C.E216BC19-ONC2256AA1.00210AD4@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Tue, 7 Aug 2001 09:01:46 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 07/08/2001 09:08:11
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f7768Ke27849
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit


How did you come to this number?  What did you assume for the exchange
length?

Julo

"Satish Menon" <satish_s_menon@hotmail.com>@ece.cmu.edu on 06-08-2001
23:44:05

Please respond to "Satish Menon" <satish_s_menon@hotmail.com>

Sent by:  owner-ips@ece.cmu.edu


To:   <ips@ece.cmu.edu>
cc:
Subject:





Does anyone know how many end-to-end credits a typical HBA (N-port)  issues
per exchange? For a long distance link over FCIP, clearly this number
needs to be large. If not, then the link utilization will be extremely
poor. For e.g. a 200ms RTT link at 1 Gbps assuming 1 exchange through it,
it will need 10,000 credits to keep the link fully utilized. Using a
different  number of exchanges say 2000, the number of credits per exchange
drop to  5.





From owner-ips@ece.cmu.edu  Tue Aug  7 02:52:39 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26806
	for <ips-archive@odin.ietf.org>; Tue, 7 Aug 2001 02:52:39 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f775rUb27341
	for ips-outgoing; Tue, 7 Aug 2001 01:53:30 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f775rOe27335
	for <ips@ece.cmu.edu>; Tue, 7 Aug 2001 01:53:25 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id HAA134240
	for <ips@ece.cmu.edu>; Tue, 7 Aug 2001 07:53:11 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f775rAD187094
	for <ips@ece.cmu.edu>; Tue, 7 Aug 2001 07:53:11 +0200
Importance: Normal
Subject: Re: remove
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF71441C79.64D44F22-ONC2256AA1.00203D23@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Tue, 7 Aug 2001 08:52:55 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 07/08/2001 08:53:10
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

An additional qualifier (iSCSI) for bad status.  Julo

"Tim Arland" <tim.arland@aebs.com>@ece.cmu.edu on 06-08-2001 23:48:29

Please respond to "Tim Arland" <tim.arland@aebs.com>

Sent by:  owner-ips@ece.cmu.edu


To:   "Eddy Quicksall" <ESQuicksall@hotmail.com>, "Elliott, Robert"
      <Robert.Elliott@compaq.com>, <ips@ece.cmu.edu>
cc:
Subject:  remove





-----Original Message-----
From: Eddy Quicksall [mailto:ESQuicksall@hotmail.com]
Sent: Monday, August 06, 2001 2:23 PM
To: Elliott, Robert; ips@ece.cmu.edu
Subject: Re: iSCSI: draft 7: iSCSI response and SCSI sense data


Then what was the purpose of giving them separate fields and eliminating
the
S bit?

Eddy

----- Original Message -----
From: "Elliott, Robert" <Robert.Elliott@compaq.com>
To: <ips@ece.cmu.edu>
Sent: Thursday, August 02, 2001 6:04 PM
Subject: RE: iSCSI: draft 7: iSCSI response and SCSI sense data


> My view:
> If a non-zero response code is present, the Status field is undefined
> and the response data contains all information about the error (fed
> from the iSCSI layer).
>
> If the target is capable of reporting a Status, then the response
> field is zero and the sense data contains all information about the
> error (fed from the SCSI layer, which might communicate with the
> iSCSI layer internally to figure out some of the information).
>
> ---
> Rob Elliott, Compaq Server Storage
> Robert.Elliott@compaq.com
>
>
>
> > -----Original Message-----
> > From: Robert Snively [mailto:rsnively@brocade.com]
> > Sent: Thursday, August 02, 2001 4:39 PM
> > To: 'cbm@rose.hp.com'; Elliott, Robert
> > Cc: 'ips@ece.cmu.edu'
> > Subject: RE: iSCSI: draft 7: iSCSI response and SCSI sense data
> >
> >
> > I am not sure that complete removal of the response codes
> > is the best approach.  There are some things
> > that SCSI devices can know nothing about, and only TCP links
> > can know about.  There are other things that iSCSI state machines
> > know about that logical units do not know about (usually software
> > generated inconsistencies in the protocol procedures).  These are
> > natural candidates for response codes.  Note that vendor
> > specific is a synonym for non-interoperable and also for
> > undesirable.  It is far better to reserve anything like that,
> > since the behavior in the presence of a vendor specific value
> > is not defined.  While it is clear that may response codes should
> > move over to CHECK CONDITIONS, I think that there are
> > still some protocol related response codes that will be required.
> >
> > Bob
> >
> > -----Original Message-----
> > From: Mallikarjun C. [mailto:cbm@rose.hp.com]
> > Sent: Wednesday, August 01, 2001 9:06 PM
> > To: Elliott, Robert
> > Cc: 'ips@ece.cmu.edu'
> > Subject: Re: iSCSI: draft 7: iSCSI response and SCSI sense data
> >
> >
> > Robert and all,
> >
> > As the one who suggested that wording into the draft, let me
> > add some comments. (Please see
> > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg05089.html
> > for my initial proposal.)
> >
> > > I suggest removing the CHECK CONDITION status and additional sense
> > > code linkage and leave the SCSI status undefined if the iSCSI
> > > response is nonzero.
> >
> > I agree, as Steph already alluded to in a separate email, the ideal
> > solution appears to:
> >           a) drop the response code *definitions* (ie. leave
> >              room for vendor-unique codes) altogether, and
> >           b) continue to specify the right SCSI CHECK CONDITION
> >              (ASC, ASCQ) values for the iSCSI error events (such
> >              as digest failures).
> >
> > As I said in the earlier referenced message "mandate a standard
> > SCSI CHECK CONDITION on these errors with the current response codes
> > acting as detailed descriptions.".  But you bring up a good point
> > that this "detailed descriptions" may be violating SAM-2's
> > expectations.
> >
> > > Forcing the iSCSI layer to fill in those fields seems to break the
> > > layering model.
> >
> > I disagree.  If the affected SCSI task can be reliably ascertained
> > by the target, it appears highly desirable to report the status
> > using a SCSI CHECK CONDITION.  Target iSCSI layer has to internally
> > terminate the pre-instantiated SCSI task anyway informing its SCSI
> > layer of the fact.  Besides, there are precedents in FCP-2 for
similar
> > cases where the task is identifiable.
> >
> > Regards.
> > --
> > Mallikarjun
> >
> > Mallikarjun Chadalapaka
> > Networked Storage Architecture
> > Network Storage Solutions Organization
> > MS 5668 Hewlett-Packard, Roseville.
> > cbm@rose.hp.com
> >
> > "Elliott, Robert" wrote:
> > >
> > > iSCSI draft 7 section 2.4.3 includes a table relating the iSCSI
> > > response codes to various CHECK CONDITION status additional
> > > sense codes:
> > >
> > >   "0x01 Target Failure
> > >     ASC=0x44 ASCQ=0x00 INTERNAL TARGET FAILURE
> > >   0x02 Delivery Subsystem Failure
> > >     ASC=0x47 ASCQ=0x03 INFORMATION UNIT CRC ERROR DETECTED
> > >   0x03 Unsolicited data rejected
> > >     ASC=0x49 ASCQ=0x00 INVALID MESSAGE ERROR
> > >   0x04 Not enough unsolicited [data]
> > >     ASC=0x49 ASCQ=0x00 INVALID MESSAGE ERROR
> > >   0x05 SNACK rejected [Command in progress]
> > >     ASC=0x47 ASCQ=0x03 INFORMATION UNIT CRC ERROR DETECTED
> > >
> > >   As listed above, each defined response code MUST be used
> > (under the
> > >   conditions described in the 'Reason' field), only when the
> > >   corresponding SCSI CHECK CONDITION is signaled, to convey
> > additional
> > >   protocol service information.  A SCSI CHECK CONDITION with the
ASC
> > >   and ASCQ values as tabulated MUST be signaled by iSCSI targets
for
> > >   all the instances in this document referring to usage of
> > one of the
> > >   above defined response codes."
> > >
> > > No other SCSI protocol does this. iSCSI seems to be granting the
> > > SCSI-level status a priority over the iSCSI-level response data.
> > > I think the other protocols treat the response data as more
> > > important; if the response data indicates a problem, the SCSI
layer
> > > is considered broken and the SCSI status is undefined.
> > >
> > > Forcing the iSCSI layer to fill in those fields seems to break the
> > > layering model.
> > >
> > > I suggest removing the CHECK CONDITION status and additional sense
> > > code linkage and leave the SCSI status undefined if the iSCSI
> > > response is nonzero.
> > >
> > > This is compatible with SAM-2, which only requires status
> > be returned
> > > when the service response is TASK COMPLETE (SAM-2 revision 18
> > > section 5.3.1):
> > >   "Status shall be sent from the logical unit to the application
> > >    client whenever a command ends with a service response of
> > >    TASK COMPLETE or LINKED COMMAND COMPLETE."
> > >
> > > Furthermore, SAM-2 requires that status be ignored when the
service
> > > response indicates an error (SAM-2 revision 18 section 5.1):
> > >   "Status: A one-byte field containing command completion status
> > >   (see 5.3). If the command ends with a service response of
> > >   SERVICE DELIVERY OR TARGET FAILURE, the application client
> > >   shall consider this parameter to be undefined."
> > >
> > > I think iSCSI's current wording may violate this rule.
> > > ---
> > > Rob Elliott, Compaq Server Storage
> > > Robert.Elliott@compaq.com
> >
>





From owner-ips@ece.cmu.edu  Tue Aug  7 04:23:22 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27562
	for <ips-archive@odin.ietf.org>; Tue, 7 Aug 2001 04:23:22 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f777IF500074
	for ips-outgoing; Tue, 7 Aug 2001 03:18:15 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from ariel.nishansystems.com (smtp.nishansystems.com [216.217.36.162])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f777IEe00069
	for <ips@ece.cmu.edu>; Tue, 7 Aug 2001 03:18:14 -0400 (EDT)
Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19)
	id <351LHX1V>; Tue, 7 Aug 2001 00:18:08 -0700
Message-ID: <B300BD9620BCD411A366009027C21D9B5BADD2@ariel.nishansystems.com>
From: Joshua Tseng <jtseng@NishanSystems.com>
To: "'Williams, Jim'" <Jim.Williams@emulex.com>,
        "'Black_David@emc.com'"
	 <Black_David@emc.com>, ips@ece.cmu.edu
Subject: RE: saag whyenc draft (was RE: Security Gateways)
Date: Tue, 7 Aug 2001 00:18:04 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

I would like to second Jim's remarks below, and would like to see some
or all of his text included in the iSCSI document.  I think
this is a reasonable approach which would address most concerns on
all sides.

Much has been said to deride today's firewall-based security
architecture ("hard on the outside, chewy on the inside...").
But the fact is that we know what the strengths and weaknesses
of this architecture are.  And despite all the touted advantages
of the pure end-to-end security model, do we have any experience
with it? I think not.

One immediate consequence I can think of is that iSCSI devices will
not be able to leverage the services of a security gateway, unless you
have distributed the encryption keys for your iSCSI session to that
firewall.  And contrary to the negative things said about them,
security gateways are, and IMO will continue to be, an important
component to any enterprise's security infrastructure for the forseeable
future.  They are a bottleneck for all traffic entering the network,
making it much easier for the administrator to monitor security threats
to that network, since he only has to monitor his few security gateways,
instead of each of his 1000's of hosts.

And if iSCSI devices cannot leverage the services of a security firewall
because all of their traffic is encrypted, what that means is that they
will each be individually responsible for fending off DOS attacks.  
Anyone can spoof IPSec packets.  From what I understand, the work on
IPSec NAT will not fix this since the NAT boundary is stateless, and
will not authenticate the IPSec.  For some administrators, especially
storage administrators, I believe they would be quite uncomfortable
about this.

I would propose that security gateways will be particularly important
for iSCSI, even if they are equipped with end-to-end security.  iSCSI
should not be compared to WAP, telnet, or even NFS.  Sure, in some cases
iSCSI will be deployed on workstations, and the user will be able to
complain to the administrator if they their system suddenly halts under
the load of a SMURF attack.  But in other environments, I can envision
farms of 100's, perhaps 1000's of iSCSI disk drives and servers, all
managed by a small team of a few administrators. In this situation,
centrally managed security gateways that are fully empowered to filter
and protect will be important.  I would be uncomfortable allowing direct
IP connectivity to the public network for each of these devices, even if
all traffic is IPSec encrypted. My solution would be to hide these devices
behind a security gateway network proxy, turn off the end-to-end security,
and use the security gateway's IPSec.

Josh

> 
> I think with regards to both confidentiality and authentication (IPSec
> authentication, not login authentication) one can expect three types
> of implementations.
> 
> 1.  Products that claim full RFC compliance in big letters with a 
>     small foot note stating that an external gateway is required
>     for compliance with the security section of the RFC.
> 
> 2.  Products that claim full RFC compliance but drop to 1% normal
>     throughput whenever security is enabled, and whose customers
>     will buy an external gateway anyway when they want security.
> 
> 3.  Products that can run security at full speed but which are
>     not competative in terms of cost/performance with 1 and 2.
> 
> I don't have a problem with any of these, but I think it's critically
> important that the security protocol for iSCSI doesn't preclude
> options 1 and 2.  In terms of actual deployment, I suspect these
> will be the most common.  A requirement for keying IPSec in
> a way that is not compatable with existing security gateways
> would be a serious setback to general acceptance of iSCSI, and
> could potentially result in the emergence of a de facto standard
> (no security) which diverges from the RFC standard (manditory 
> security).  I don't think diverging standards are in anyone's
> best interest, especially if there are practical ways to 
> aviod it.
> 
> 


From owner-ips@ece.cmu.edu  Tue Aug  7 06:13:40 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29178
	for <ips-archive@odin.ietf.org>; Tue, 7 Aug 2001 06:13:40 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f778woi03302
	for ips-outgoing; Tue, 7 Aug 2001 04:58:50 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from relay2.bt.net (relay2.bt.net [194.72.6.62])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f778wne03298
	for <ips@ece.cmu.edu>; Tue, 7 Aug 2001 04:58:49 -0400 (EDT)
Received: from [217.33.138.159] (helo=cs.uchicago.edu)
	by relay2.bt.net with esmtp (Exim 3.15 #1)
	id 15U2hH-0003N4-00
	for ips@ece.cmu.edu; Tue, 07 Aug 2001 09:58:43 +0100
To: ips@ece.cmu.edu
Subject: Re: iSCSI: Updated proposed iSCSI framing draft requirements 
In-Reply-To: Message from Stephen Bailey <steph@cs.uchicago.edu> 
   of "Mon, 06 Aug 2001 17:11:52 EDT."
Date: Tue, 07 Aug 2001 04:58:33 -0400
From: Stephen Bailey <steph@cs.uchicago.edu>
Message-Id: <E15U2hH-0003N4-00@relay2.bt.net>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

All,

Based upon comments at the iSCSI meeting, David Black has asked the
framing team to prepare a somewhat more complete statement of
requirements with justification for consensus consideration.

Therefore, please ignore my previous message.  A more expansive
version will be forthcoming shortly.

Thanks,
  Steph


From owner-ips@ece.cmu.edu  Tue Aug  7 10:40:06 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05084
	for <ips-archive@odin.ietf.org>; Tue, 7 Aug 2001 10:40:06 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f77DDsw22845
	for ips-outgoing; Tue, 7 Aug 2001 09:13:54 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from ns.maryville.com (ns.maryville.com [12.34.165.10])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f77DDqe22839
	for <ips@ece.cmu.edu>; Tue, 7 Aug 2001 09:13:53 -0400 (EDT)
Received: from mtmail.maryville.com by ns.maryville.com
          via smtpd (for ECE.CMU.EDU [128.2.136.200]) with SMTP; 7 Aug 2001 13:13:52 UT
Received: by MTMAIL with Internet Mail Service (5.5.2653.19)
	id <NGXN802X>; Tue, 7 Aug 2001 08:13:51 -0500
Message-ID: <5189E4627FC5D411AC9E0020941203380118E6A5@MTMAIL>
From: Bryan Jones <bryan.jones@maryville.com>
To: "'Eddy Quicksall '" <ESQuicksall@hotmail.com>,
        "'Elliott, Robert '"
	 <Robert.Elliott@compaq.com>,
        "'ips@ece.cmu.edu '" <ips@ece.cmu.edu>
Subject: remove
Date: Tue, 7 Aug 2001 08:13:45 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

remove


From owner-ips@ece.cmu.edu  Tue Aug  7 10:47:02 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05342
	for <ips-archive@odin.ietf.org>; Tue, 7 Aug 2001 10:47:02 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f77Dllw24436
	for ips-outgoing; Tue, 7 Aug 2001 09:47:47 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail4.tor.primus.ca (mx-backup.primus.ca [216.254.136.135])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f77Dlje24432
	for <ips@ece.cmu.edu>; Tue, 7 Aug 2001 09:47:46 -0400 (EDT)
Received: from dsl-216-254-190-10.tor.primus.ca ([216.254.190.10] helo=perfisan4)
	by mail4.tor.primus.ca with smtp (Exim 2.11 #1)
	id 15U7Cd-0002ZS-07; Tue, 7 Aug 2001 09:47:23 -0400
Reply-To: <tnguyen@perfisans.com>
From: "Trang Nguyen" <tnguyen@perfisans.com>
To: "Julian Satran" <Julian_Satran@il.ibm.com>, <ips@ece.cmu.edu>
Subject: RE: iSCSI London-IETF-foils
Date: Tue, 7 Aug 2001 09:50:16 -0400
Message-ID: <BNEALKHNNHCOIGPENKKMAEOOCAAA.tnguyen@perfisans.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
In-Reply-To: <OF8B74ADF8.2A7606E7-ONC2256AA0.006F73AB@telaviv.ibm.com>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Julo,

Could you please tell us your site address?

Thanks,

Trang 


-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Julian Satran
Sent: August 6, 2001 4:19 PM
To: ips@ece.cmu.edu
Subject: iSCSI London-IETF-foils


My foils are on my site.

Julo



From owner-ips@ece.cmu.edu  Tue Aug  7 11:26:01 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06209
	for <ips-archive@odin.ietf.org>; Tue, 7 Aug 2001 11:26:00 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f77E0FB25011
	for ips-outgoing; Tue, 7 Aug 2001 10:00:15 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f77E0De25003
	for <ips@ece.cmu.edu>; Tue, 7 Aug 2001 10:00:13 -0400 (EDT)
Received: by ATLOPS with Internet Mail Service (5.5.2448.0)
	id <QMJCNBKC>; Tue, 7 Aug 2001 10:00:08 -0400
Message-ID: <25369470B6F0D41194820002B328BDD20266FB@ATLOPS>
From: Sanjay Goyal <sanjay_goyal@ivivity.com>
To: "Ips (E-mail)" <ips@ece.cmu.edu>
Cc: Sanjay Goyal <sanjay_goyal@ivivity.com>
Subject: Task Management Response
Date: Tue, 7 Aug 2001 10:00:07 -0400 
X-MS-TNEF-Correlator: <25369470B6F0D41194820002B328BDD20266FB@ATLOPS>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C11F49.43B07FDE"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C11F49.43B07FDE
Content-Type: text/plain;
	charset="iso-8859-1"

Hi
 iSCSI draft 7.0
 2.6 Task Management Response
   description does include everything but      <Target cold reset>, why
was it left out is not clear to me as there is no difference between
warm and cold reset behaviour as an target.

 2.5 Task Management Command
   LUN is optional for this PDU
              why it is mandatory for
    Task Management Response.


Regards
Sanjay Goyal

------_=_NextPart_000_01C11F49.43B07FDE
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64

eJ8+IgkOAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQkABAACAAAAAAAAAAEIAAUABAAAAAAAAAAAAAEFgAMADgAAANEH
CAAHAAoAAAAHAAIA+gABIIADAA4AAADRBwgABwAKAAAABwACAPoAAQmAAQAhAAAAREM0QjdDNkE2
NThBRDUxMTk0QjMwMDAyQjMyOEJERDIALAcBBIABABkAAABUYXNrIE1hbmFnZW1lbnQgUmVzcG9u
c2UAHwkBDYAEAAIAAAACAAIAAQOQBgCUBgAAMAAAAAMANgAAAAAAAwBbgAggBgAAAAAAwAAAAAAA
AEYAAAAAUoUAAH1uAQAeAFyACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAQAAAA5LjAACwCF
gAggBgAAAAAAwAAAAAAAAEYAAAAABoUAAAAAAAADAA6ACCAGAAAAAADAAAAAAAAARgAAAAABhQAA
AAAAAAsAEIAIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAACwARgAggBgAAAAAAwAAAAAAAAEYA
AAAADoUAAAAAAAADADeACCAGAAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAMAOIAIIAYAAAAAAMAA
AAAAAABGAAAAABGFAAAAAAAAAwA+gAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAACAQkQAQAA
AMABAAC8AQAA0QIAAExaRnXt7DD1AwAKAHJjcGcxMjXiMgNDdGV4BUEBAwH3/wqAAqQD5AcTAoAP
8wBQBFY/CFUHshElDlEDAQIAY2jhCsBzZXQyBgAGwxEl9jMERhO3MBIsETMI7wn3tjsYHw4wNREi
DGBjAFAzCwkBZDM2FlALpiBIBwCgCrEKgCBpU0NTIEkgZHJhAYAgNwYuAUAdJDIuNiBUGGFzawXQ
AHBhZ2XvB4ACMAfwB5BwAiAUEB0VtyEAAQAE9GkCIB3QbweRjQuAYwpAAQAgZXYEkAh5dGgLgGcg
YnXrBUAjozwfIHIfsAVAF5EMZCAYIBQRPiwgd3RoeR0Udx8wHXAFQGwdAXEgCGAFQAQAIG5vRyRh
JlAKwXRvIAeAIH8l8SMQBJAioCbjHdAGkGbXKGEiUCKgYhQgdwnhJYb0cm0oAG4ksCSIKaET4H52
IbAIcCgCA5EBkCQyLtsdFB53NR8fCFBtA4ELMdEgxUxVTibSbyGTB0AeIAIQJ5EjIAQgUERVvyCn
MmklUSYSJuEvcmEnsP8i8DEyMggfLyA1LSsdFCAgmmcLEXMdFAYRamEzYFhHb3kHQB0UfToAHgBw
AAEAAAATAAAAVGFzayBNbmdtbnQgUnNwc25zAAACAXEAAQAAABsAAAABwR8/9S9qfEtaimUR1ZSz
AAKzKL3SAAJGpKAAAwAmAAAAAAADAC4AAAAAAAsAAgABAAAACwAXDAAAAAADAF1AAAAAAAMACVkB
AAAAAwDeP69vAABAADkA4EqdQ0kfwQEDAPE/CQQAAB4AMUABAAAACAAAAFNBTkpBWUcAAwAaQAAA
AAAeADBAAQAAAAgAAABTQU5KQVlHAAMAGUAAAAAAAwD9P+QEAAADAIAQ/////wIBRwABAAAALgAA
AGM9VVM7YT0gO3A9SVZJVklUWTtsPUFUTE9QUy0wMTA4MDcxNDAwMDdaLTEwNQAAAAIB+T8BAAAA
SgAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAAAAAAvTz1JVklWSVRZL09VPUFUTE9QUy9DTj1S
RUNJUElFTlRTL0NOPVNBTkpBWUcAAAAeAPg/AQAAAA0AAABTYW5qYXkgR295YWwAAAAAHgA4QAEA
AAAIAAAAU0FOSkFZRwACAfs/AQAAAEoAAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAAL089
SVZJVklUWS9PVT1BVExPUFMvQ049UkVDSVBJRU5UUy9DTj1TQU5KQVlHAAAAHgD6PwEAAAANAAAA
U2FuamF5IEdveWFsAAAAAB4AOUABAAAACAAAAFNBTkpBWUcAQAAHMBjFDwZJH8EBQAAIMN5/sENJ
H8EBHgA9AAEAAAABAAAAAAAAAB4AHQ4BAAAAGQAAAFRhc2sgTWFuYWdlbWVudCBSZXNwb25zZQAA
AAAeADUQAQAAADAAAAA8MjUzNjk0NzBCNkYwRDQxMTk0ODIwMDAyQjMyOEJERDIwMjY2RkJAQVRM
T1BTPgALACkAAAAAAAsAIwAAAAAAAwAGEFNK1XoDAAcQHwEAAAMAEBAAAAAAAwAREAAAAAAeAAgQ
AQAAAGUAAABISUlTQ1NJRFJBRlQ3MDI2VEFTS01BTkFHRU1FTlRSRVNQT05TRURFU0NSSVBUSU9O
RE9FU0lOQ0xVREVFVkVSWVRISU5HQlVUPFRBUkdFVENPTERSRVNFVCxXSFlXQVNJVExFAAAAAAIB
fwABAAAAMAAAADwyNTM2OTQ3MEI2RjBENDExOTQ4MjAwMDJCMzI4QkREMjAyNjZGQkBBVExPUFM+
AGVP

------_=_NextPart_000_01C11F49.43B07FDE--


From owner-ips@ece.cmu.edu  Tue Aug  7 13:22:56 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08674
	for <ips-archive@odin.ietf.org>; Tue, 7 Aug 2001 13:22:56 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f77FoI501421
	for ips-outgoing; Tue, 7 Aug 2001 11:50:18 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f77FoFe01416
	for <ips@ece.cmu.edu>; Tue, 7 Aug 2001 11:50:15 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id RAA246496
	for <ips@ece.cmu.edu>; Tue, 7 Aug 2001 17:50:04 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f77Fo4p45532
	for <ips@ece.cmu.edu>; Tue, 7 Aug 2001 17:50:04 +0200
Importance: Normal
Subject: Re: iSCSI: StatSn
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF43524F72.90B60869-ONC2256AA1.0056CD03@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Tue, 7 Aug 2001 18:49:48 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 07/08/2001 18:50:04
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Rishab,

Status is does not have any ordering requirement hence the numbering is per
connection and is done only to enable bulk acknowledgement (not ordering).

Julo

Rishabh Srivastav <rishabh_srivastav@yahoo.com> on 07-08-2001 15:42:06

Please respond to Rishabh Srivastav <rishabh_srivastav@yahoo.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:
Subject:  iSCSI: StatSn



Julo,
one more question : why is statSN per connection and
not per session ? can't there be a one-to-one
correspondance between cmdSN and statSN, since there
is one status response per command ?

thanks,
rishabh

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/





From owner-ips@ece.cmu.edu  Tue Aug  7 14:12:46 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10009
	for <ips-archive@odin.ietf.org>; Tue, 7 Aug 2001 14:12:46 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f77HPLJ06863
	for ips-outgoing; Tue, 7 Aug 2001 13:25:21 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f77HPKe06858
	for <ips@ece.cmu.edu>; Tue, 7 Aug 2001 13:25:20 -0400 (EDT)
Received: by zmamail03.zma.compaq.com (Postfix, from userid 12345)
	id 012709A40; Tue,  7 Aug 2001 13:25:14 -0400 (EDT)
Received: from exchou-gh02.cca.cpqcorp.net (exchou-gh02.cca.cpqcorp.net [16.110.248.202])
	by zmamail03.zma.compaq.com (Postfix) with ESMTP id C6531BFEB
	for <ips@ece.cmu.edu>; Tue,  7 Aug 2001 13:25:14 -0400 (EDT)
Received: by exchou-gh02.cca.cpqcorp.net with Internet Mail Service (5.5.2652.78)
	id <QLD2K6G0>; Tue, 7 Aug 2001 12:25:14 -0500
Message-ID: <78AF3C342AEAEF4BA33B35A8A15668C6014D693C@cceexc17.americas.cpqcorp.net>
From: "Elliott, Robert" <Robert.Elliott@compaq.com>
To: ips@ece.cmu.edu
Subject: RE: iSCSI: draft 7: Final bit in Data PDUs
Date: Tue, 7 Aug 2001 12:25:13 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

I think an F bit per direction would be most useful.

Bidirectional command background:  the target chooses what order to run the
reads and writes.  It can start with either, and switch from one to the
other as often as it wishes.  These are all legal:

1.  read all data, write all data
2.  write all data, read all data
3.  read some, write some, read some, ...
4.  write some, read some, ...

There are two independent data pointers active, one per stream.  EMDP
applies to both.

--
Robert.Elliott@compaq.com
Compaq Computer Server Storage


-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Monday, August 06, 2001 5:57 PM
To: ips@ece.cmu.edu
Subject: Re: iSCSI: draft 7: Final bit in Data PDUs


Elliot,

I have no clue how those commands are going to work.
Can you help?
I assume that the F bit will have to be there at both ends?

Julo

"Elliott, Robert" <Robert.Elliott@compaq.com>@ece.cmu.edu on 06-08-2001
18:02:10

Please respond to "Elliott, Robert" <Robert.Elliott@compaq.com>

Sent by:  owner-ips@ece.cmu.edu


To:   "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
cc:
Subject:  iSCSI: draft 7: Final bit in Data PDUs



iSCSI draft 7 section 2.7.1 describes when the (F) Final bit is
set in the Data-out and Data-in PDUs:

  For outgoing data, this bit is 1 for the last PDU of unsolicited
  data  or the last PDU of a sequence answering a R2T.

  For incoming data, this bit is 1 for the last input (read) data
  PDU of a sequence.

It needs to define how this works for bidirectional commands.
Is the F bit set to one on both the last Data-out PDU and the last
Data-in PDU?  Or is it set to one only on the last Data PDU,
whatever direction it may be?

--
Robert.Elliott@compaq.com
Compaq Computer Server Storage




From owner-ips@ece.cmu.edu  Tue Aug  7 14:18:12 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10130
	for <ips-archive@odin.ietf.org>; Tue, 7 Aug 2001 14:18:12 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f77GtHm05094
	for ips-outgoing; Tue, 7 Aug 2001 12:55:17 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e34.bld.us.ibm.com (e34.co.us.ibm.com [32.97.110.132])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f77GtFe05086
	for <ips@ece.cmu.edu>; Tue, 7 Aug 2001 12:55:15 -0400 (EDT)
Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.99.140.22])
	by e34.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA76304
	for <ips@ece.cmu.edu>; Tue, 7 Aug 2001 12:53:09 -0400
Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49])
	by westrelay01.boulder.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f77GtD834518
	for <ips@ece.cmu.edu>; Tue, 7 Aug 2001 10:55:13 -0600
X-Priority: 1 (High)
Importance: Normal
Subject: iSCSI: Support Alias in the protocol 
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OFA1290378.108271AC-ON88256AA1.005ADB47@boulder.ibm.com>
From: "John Hufferd" <hufferd@us.ibm.com>
Date: Tue, 7 Aug 2001 09:51:38 -0700
X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.6 |December 14, 2000) at
 08/07/2001 10:55:13 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Today at the 51st meeting of the IETF, I presented an issue that came out
of the Naming and Discovery Team.

That was that some members of the team did not understand why we needed to
have an Alias field, which is in the base protocol today, since it was
technically not needed.   The position I presented to the group was that
the Naming and Discovery Team did not have consensus, since many of us felt
that having a Human oriented "Tagging" function was useful, and a small
item which would be useful for Administrators especially when EUI names are
used.

One person, at the meeting today, stated that it might not be of extreme
importance on large Networks with sophisticated Management tools, but it
was very useful in small to medium environments, where the Management tools
were slim.  And at least one person stated that since it was not required,
it should not be in the protocol.

As the conversations when on, it was pointed out by the area director,
Scott  Bradner, that SLP used a similar Text field in its protocol, so
there was clearly a president.

In any event, we could not reach consensus at the meeting, so I was asked
to bring the issue to the List.  (So here it is!)

Please state your positions so that David can call a consensus.



.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com



From owner-ips@ece.cmu.edu  Tue Aug  7 15:11:27 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11302
	for <ips-archive@odin.ietf.org>; Tue, 7 Aug 2001 15:11:26 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f77HlvH08132
	for ips-outgoing; Tue, 7 Aug 2001 13:47:57 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f77Hlue08128
	for <ips@ece.cmu.edu>; Tue, 7 Aug 2001 13:47:56 -0400 (EDT)
Received: by zmamail03.zma.compaq.com (Postfix, from userid 12345)
	id 8A4BBC008; Tue,  7 Aug 2001 13:47:50 -0400 (EDT)
Received: from exchou-gh02.cca.cpqcorp.net (exchou-gh02.cca.cpqcorp.net [16.110.248.202])
	by zmamail03.zma.compaq.com (Postfix) with ESMTP id 1929BC307
	for <ips@ece.cmu.edu>; Tue,  7 Aug 2001 13:47:50 -0400 (EDT)
Received: by exchou-gh02.cca.cpqcorp.net with Internet Mail Service (5.5.2652.78)
	id <QLD2K8T3>; Tue, 7 Aug 2001 12:47:49 -0500
Message-ID: <78AF3C342AEAEF4BA33B35A8A15668C6019E2014@cceexc17.americas.cpqcorp.net>
From: "Elliott, Robert" <Robert.Elliott@compaq.com>
To: "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
Subject: iSCSI: draft 7: remove S bit and Status field from the Data-in PD
	U?
Date: Tue, 7 Aug 2001 12:47:44 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

At the IETF IPS WG meeting, removing the immediate data from the
Command PDU was discussed as a possible simplification.

A similar simplification would be to remove the S bit and Status
field from the Data-in PDU.  These let Status be returned in the
Data-in PDU rather than in a separate Response PDU.  The target
can send the last Data-in PDU and the Response PDU back-to-back; 
there's not much wire overhead sending 48 more bytes.  The 
initiator always has to handle separate Response PDUs, so this 
eliminates a special case and collects all status and residual 
handling in one place.

--
Robert.Elliott@compaq.com
Compaq Computer Server Storage




From owner-ips@ece.cmu.edu  Tue Aug  7 15:55:41 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11888
	for <ips-archive@odin.ietf.org>; Tue, 7 Aug 2001 15:55:40 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f77IbwE11184
	for ips-outgoing; Tue, 7 Aug 2001 14:37:58 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from clyde.stargateip.com ([209.237.5.66])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f77Ibue11176
	for <ips@ece.cmu.edu>; Tue, 7 Aug 2001 14:37:56 -0400 (EDT)
Received: from bluestar (dhcp-101.stargateip.com [10.10.5.101])
	by clyde.stargateip.com (8.9.1/8.9.1) with SMTP id LAA18214;
	Tue, 7 Aug 2001 11:32:08 -0700 (PDT)
Reply-To: <deva@stargateip.com>
From: "Dev" <deva@stargateip.com>
To: "Julian Satran" <Julian_Satran@il.ibm.com>, <ips@ece.cmu.edu>
Cc: <hafner@almaden.ibm.com>
Subject: RE: Review of the 07 draft
Date: Tue, 7 Aug 2001 11:42:06 -0700
Message-ID: <NFBBKBDFJCDMGCBKJLCJAENOFCAA.deva@stargateip.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
In-Reply-To: <OF40D6D634.B81361EF-ONC2256A9F.00530E57@telaviv.ibm.com>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


Julian,

I suggest that,
"The iSCSI specific parameter change with text mode commands are initiator
specific and
MUST be performed following the SCSI rules as stated by [SAM2] and [SPC]."

Because, the iSCSI mode parameter changes are implemented per initiator,
there is no need to
raise unit attention for other initiators should the mode parameters change.
The above change
explicitly states that the mode changes are effected per initiator.

Jim, are you fine with this and address the concern you raise ?

Thanks

Deva
Platys communications


-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Julian Satran
Sent: Sunday, August 05, 2001 8:22 AM
To: ips@ece.cmu.edu
Subject: RE: Review of the 07 draft



I've added a statement saying:

The iSCSI specific parameter change with text mode commands MUST be
performed following the SCSI rules as stated by [SAM2] and [SPC].

Julo

"Dev" <deva@stargateip.com>@ece.cmu.edu on 04-08-2001 03:18:45

Please respond to <deva@stargateip.com>

Sent by:  owner-ips@ece.cmu.edu


To:   Jim Hafner/Almaden/IBM@IBMUS, "Robert Griswold"
      <rgriswold@Crossroads.com>
cc:   <ips@ece.cmu.edu>
Subject:  RE: Review of the 07 draft



Jim,

You wrote:
>Of course, the draft doesn't say whether MODE PARAMETERS HAVE
>CHANGED unit attentions get thrown up at the SCSI layer when this happens
>at the iSCSI layer.... You later have a clarifying question (Section 3) on
>this as well.

Yes it is necessary to return  unit attentions for Mode parameter changes
(changed through SCSI command).
it is within the domain of SCSI, not iSCSI . However a note on
implementation in the iSCSI spec that
discusses the mode parameters will be good.

Thanks

Deva
Platys communications






From owner-ips@ece.cmu.edu  Tue Aug  7 17:21:44 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12701
	for <ips-archive@odin.ietf.org>; Tue, 7 Aug 2001 17:21:44 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f77JdoO14715
	for ips-outgoing; Tue, 7 Aug 2001 15:39:50 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f77Jdme14707
	for <ips@ece.cmu.edu>; Tue, 7 Aug 2001 15:39:48 -0400 (EDT)
Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77])
	by msgbas2.cos.agilent.com (Postfix) with ESMTP
	id 3BF8760E; Tue,  7 Aug 2001 13:39:46 -0600 (MDT)
Received: from acropora.rose.agilent.com (acropora.rose.agilent.com [130.30.179.5])
	by msgrel1.cos.agilent.com (Postfix) with ESMTP
	id 46D1C2C6; Tue,  7 Aug 2001 13:39:47 -0600 (MDT)
Received: (from dbs@localhost)
	by acropora.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) id MAA20593;
	Tue, 7 Aug 2001 12:38:56 -0700 (PDT)
From: Dave Sheehy <dbs@acropora.rose.agilent.com>
Message-Id: <200108071938.MAA20593@acropora.rose.agilent.com>
Subject: Re: iSCSI: draft 7: remove S bit and Status field from the Data-in PD
To: Robert.Elliott@compaq.com
Date: Tue, 07 Aug 2001 12:38:55 PDT
Cc: ips@ece.cmu.edu (IETF IP SAN Reflector)
In-Reply-To: <78AF3C342AEAEF4BA33B35A8A15668C6019E2014@cceexc17.americas.cpqcorp.net>; from "Elliott, Robert" at Aug 7, 101 11:40 am
X-Mailer: Elm [revision: 212.4]
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


> At the IETF IPS WG meeting, removing the immediate data from the
> Command PDU was discussed as a possible simplification.

What are you trying to simplify? Is it the case where both immediate and
unsolicited PDUs are allowed in the same command? In that case I would 
recommend making the two mutually exclusive as the preferred simplification. 
Separate unsolicited data PDUs are far more onerous than immediate data (for 
the target). If you really want to simplify things then eliminate unsolicited
data PDUs and keep immediate data!

Dave Sheehy



From owner-ips@ece.cmu.edu  Tue Aug  7 17:28:33 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12756
	for <ips-archive@odin.ietf.org>; Tue, 7 Aug 2001 17:28:32 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f77JPqe13971
	for ips-outgoing; Tue, 7 Aug 2001 15:25:52 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from aegis.indstorage.com (www.diigroup.com [208.132.17.2] (may be forged))
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f77JPoe13966
	for <ips@ece.cmu.edu>; Tue, 7 Aug 2001 15:25:50 -0400 (EDT)
Received: from markb2k ([192.168.1.101])
	by aegis.indstorage.com (8.11.0/8.11.0) with SMTP id f77JIBf02181;
	Tue, 7 Aug 2001 13:18:11 -0600
Reply-To: <markb@indstorage.com>
From: "Mark Bradley" <markb@indstorage.com>
To: "John Hufferd" <hufferd@us.ibm.com>, <ips@ece.cmu.edu>
Subject: RE: iSCSI: Support Alias in the protocol 
Date: Tue, 7 Aug 2001 13:26:38 -0600
Message-ID: <PIELJFAMKOIKGPDIGIJEMEICCCAA.markb@indstorage.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
In-Reply-To: <OFA1290378.108271AC-ON88256AA1.005ADB47@boulder.ibm.com>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

I support an Alias field.  I agree it is useful in many scenarios.

I'm not sure about having a president, however, and am not sure 
why we would discuss politics here.  :{)
  --  markb

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
John Hufferd
Sent: Tuesday, August 07, 2001 10:52 AM
To: ips@ece.cmu.edu
Subject: iSCSI: Support Alias in the protocol 


Today at the 51st meeting of the IETF, I presented an issue that came out
of the Naming and Discovery Team.

That was that some members of the team did not understand why we needed to
have an Alias field, which is in the base protocol today, since it was
technically not needed.   The position I presented to the group was that
the Naming and Discovery Team did not have consensus, since many of us felt
that having a Human oriented "Tagging" function was useful, and a small
item which would be useful for Administrators especially when EUI names are
used.

One person, at the meeting today, stated that it might not be of extreme
importance on large Networks with sophisticated Management tools, but it
was very useful in small to medium environments, where the Management tools
were slim.  And at least one person stated that since it was not required,
it should not be in the protocol.

As the conversations when on, it was pointed out by the area director,
Scott  Bradner, that SLP used a similar Text field in its protocol, so
there was clearly a president.

In any event, we could not reach consensus at the meeting, so I was asked
to bring the issue to the List.  (So here it is!)

Please state your positions so that David can call a consensus.



.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com



From owner-ips@ece.cmu.edu  Tue Aug  7 19:43:58 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14477
	for <ips-archive@odin.ietf.org>; Tue, 7 Aug 2001 19:43:58 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f77MDjb23390
	for ips-outgoing; Tue, 7 Aug 2001 18:13:45 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from ariel.nishansystems.com (smtp.nishansystems.com [216.217.36.162])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f77MDhe23383
	for <ips@ece.cmu.edu>; Tue, 7 Aug 2001 18:13:43 -0400 (EDT)
Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19)
	id <351LHXPA>; Tue, 7 Aug 2001 15:04:14 -0700
Message-ID: <B300BD9620BCD411A366009027C21D9B51A1BC@ariel.nishansystems.com>
From: Kevin Gibbons <kgibbons@NishanSystems.com>
To: "'John Hufferd'" <hufferd@us.ibm.com>, ips@ece.cmu.edu
Subject: RE: iSCSI: Support Alias in the protocol 
Date: Tue, 7 Aug 2001 15:04:08 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

I support the Alias field.  I can see value in being able to assign a user
readable name to a storage device that is not required to be unique or
adhere to a specific format.

Regards, Kevin

-----Original Message-----
From: John Hufferd [mailto:hufferd@us.ibm.com]
Sent: Tuesday, August 07, 2001 9:52 AM
To: ips@ece.cmu.edu
Subject: iSCSI: Support Alias in the protocol 


Today at the 51st meeting of the IETF, I presented an issue that came out
of the Naming and Discovery Team.

That was that some members of the team did not understand why we needed to
have an Alias field, which is in the base protocol today, since it was
technically not needed.   The position I presented to the group was that
the Naming and Discovery Team did not have consensus, since many of us felt
that having a Human oriented "Tagging" function was useful, and a small
item which would be useful for Administrators especially when EUI names are
used.

One person, at the meeting today, stated that it might not be of extreme
importance on large Networks with sophisticated Management tools, but it
was very useful in small to medium environments, where the Management tools
were slim.  And at least one person stated that since it was not required,
it should not be in the protocol.

As the conversations when on, it was pointed out by the area director,
Scott  Bradner, that SLP used a similar Text field in its protocol, so
there was clearly a president.

In any event, we could not reach consensus at the meeting, so I was asked
to bring the issue to the List.  (So here it is!)

Please state your positions so that David can call a consensus.



.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com


From owner-ips@ece.cmu.edu  Tue Aug  7 22:19:28 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16746
	for <ips-archive@odin.ietf.org>; Tue, 7 Aug 2001 22:19:27 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f781M1J01193
	for ips-outgoing; Tue, 7 Aug 2001 21:22:01 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from lucy.trebia.com ([65.192.191.151])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f781Lxe01188
	for <ips@ece.cmu.edu>; Tue, 7 Aug 2001 21:21:59 -0400 (EDT)
Received: from trebia.com (TREBIA-JWS [65.192.191.186]) by lucy.trebia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id QASG4P7F; Tue, 7 Aug 2001 21:26:13 -0400
Message-ID: <3B709481.94AB5907@trebia.com>
Date: Tue, 07 Aug 2001 21:23:13 -0400
From: James Smart <james.smart@trebia.com>
Reply-To: james.smart@trebia.com
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ips@ece.cmu.edu
Subject: Re: iSCSI: Support Alias in the protocol
References: <OFA1290378.108271AC-ON88256AA1.005ADB47@boulder.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

I support the notion of an Alias. This is a feature that I've seen many FC SAN
configurations use. This feature is extremely high on many SAN administrators
lists.

-- James Smart


John Hufferd wrote:

> Today at the 51st meeting of the IETF, I presented an issue that came out
> of the Naming and Discovery Team.
>
> That was that some members of the team did not understand why we needed to
> have an Alias field, which is in the base protocol today, since it was
> technically not needed.   The position I presented to the group was that
> the Naming and Discovery Team did not have consensus, since many of us felt
> that having a Human oriented "Tagging" function was useful, and a small
> item which would be useful for Administrators especially when EUI names are
> used.
>
> One person, at the meeting today, stated that it might not be of extreme
> importance on large Networks with sophisticated Management tools, but it
> was very useful in small to medium environments, where the Management tools
> were slim.  And at least one person stated that since it was not required,
> it should not be in the protocol.
>
> As the conversations when on, it was pointed out by the area director,
> Scott  Bradner, that SLP used a similar Text field in its protocol, so
> there was clearly a president.
>
> In any event, we could not reach consensus at the meeting, so I was asked
> to bring the issue to the List.  (So here it is!)
>
> Please state your positions so that David can call a consensus.
>
> .
> .
> .
> John L. Hufferd
> Senior Technical Staff Member (STSM)
> IBM/SSG San Jose Ca
> Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
> Home Office (408) 997-6136
> Internet address: hufferd@us.ibm.com



From owner-ips@ece.cmu.edu  Wed Aug  8 00:20:28 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19132
	for <ips-archive@odin.ietf.org>; Wed, 8 Aug 2001 00:20:28 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f783HOv05722
	for ips-outgoing; Tue, 7 Aug 2001 23:17:24 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from localhost.localdomain (client124091.atl.mediaone.net [24.31.124.91])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f783HMe05717
	for <ips@ece.cmu.edu>; Tue, 7 Aug 2001 23:17:22 -0400 (EDT)
Received: (from marck@localhost)
	by localhost.localdomain (8.11.2/8.11.2) id f783HEn02074;
	Tue, 7 Aug 2001 23:17:14 -0400
X-Authentication-Warning: localhost.localdomain: marck set sender to marc_karasek@ivivity.com using -f
Subject: ethereal
From: Marc Karasek <marc_karasek@ivivity.com>
To: ips iscsi <ips@ece.cmu.edu>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Evolution/0.12.99 (Preview Release)
Date: 07 Aug 2001 23:17:13 -0400
Message-Id: <997240634.2051.0.camel@localhost.localdomain>
Mime-Version: 1.0
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Has anyone taken the job to update ethereal for drfat 7 yet? 
-- 
/*************************
Marc Karasek
Sr. Firmware Engineer
iVivity Inc.
marc_karasek@ivivity.com
(770) 986-8925
(770) 986-8926 Fax
*************************/


From owner-ips@ece.cmu.edu  Wed Aug  8 04:01:16 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07733
	for <ips-archive@odin.ietf.org>; Wed, 8 Aug 2001 04:01:16 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f786l3d13720
	for ips-outgoing; Wed, 8 Aug 2001 02:47:03 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from tele-post-20.mail.demon.net (tele-post-20.mail.demon.net [194.217.242.20])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f786l1e13715
	for <ips@ece.cmu.edu>; Wed, 8 Aug 2001 02:47:01 -0400 (EDT)
Received: from ordern.demon.co.uk ([158.152.10.215])
	by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2)
	id 15UN7L-0000sR-0K; Wed, 8 Aug 2001 06:46:59 +0000
Received: from localhost(rook.ordern.com[192.168.1.1]) (1079 bytes) by ordern.demon.co.uk
	via smtpd with P:esmtp/R:smart_host/T:smtp
	(sender: <markb@ordern.com>) 
	id <m15UN7L-000RSCC@ordern.demon.co.uk>
	for <ips@ece.cmu.edu>; Wed, 8 Aug 2001 07:46:59 +0100 (BST)
	(Smail-3.2.0.108 1999-Sep-19 #7 built 2000-Feb-18)
Date: Wed, 08 Aug 2001 07:46:58 +0100 (BST)
Message-Id: <20010808.074658.424244953.markb@ordern.com>
To: marc_karasek@ivivity.com
Cc: ips@ece.cmu.edu
Subject: Re: ethereal
From: Mark Burton <markb@ordern.com>
In-Reply-To: <997240634.2051.0.camel@localhost.localdomain>
References: <997240634.2051.0.camel@localhost.localdomain>
X-Mailer: Mew version 2.0 on XEmacs 21.4.4 (Artificial Intelligence)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


Hello Marc,

I haven't yet, but I do intend to do that sometime.

Cheers,

Mark

From: Marc Karasek <marc_karasek@ivivity.com>
Subject: ethereal
Date: 07 Aug 2001 23:17:13 -0400

> Has anyone taken the job to update ethereal for drfat 7 yet? 
> -- 
> /*************************
> Marc Karasek
> Sr. Firmware Engineer
> iVivity Inc.
> marc_karasek@ivivity.com
> (770) 986-8925
> (770) 986-8926 Fax
> *************************/


From owner-ips@ece.cmu.edu  Wed Aug  8 04:51:54 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08326
	for <ips-archive@odin.ietf.org>; Wed, 8 Aug 2001 04:51:49 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f787ZGZ15332
	for ips-outgoing; Wed, 8 Aug 2001 03:35:16 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f787Z9e15315
	for <ips@ece.cmu.edu>; Wed, 8 Aug 2001 03:35:09 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id JAA231132;
	Wed, 8 Aug 2001 09:34:51 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f787Yo860422;
	Wed, 8 Aug 2001 09:34:50 +0200
Importance: Normal
Subject: Re: your query
To: "Satish Menon" <satish_s_menon@hotmail.com>
Cc: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF303861EB.EC525345-ONC2256AA2.00295B34@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Wed, 8 Aug 2001 10:34:33 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 08/08/2001 10:34:50
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f787ZFe15329
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit

TCP works with some other structures. It is a sliding window protocol. And
yes for the links you mentioned the window has to be sizable. And the
number-of-SCSI commans/R2Ts/Data in flow has to be also large to fill the
pipe.

Julo

"Satish Menon" <satish_s_menon@hotmail.com> on 08-08-2001 00:55:41

Please respond to "Satish Menon" <satish_s_menon@hotmail.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:
Subject:  your query




Here is how the  calculation was done. Also, some folks told me that N-port
HBAs don't reserve  end-to-end credits by exchange, they just have a common
pool of
credits  for the entire HBA (around 16), so the calculations factor in
this
new
data point.

Assume a 1 Gbps link.
Assume a 2K FC  frame.

So it takes 16us to transmit a frame. For 200ms RTT, that means  that
200ms/
16us ~ 10,000 credits.

Case A. For a 1Gbps FCIP link with  100 N-port HBAs, each HBA needs to
advertise 100 credits (10,000/100) to  fully utilize the link. The
utilization with 16 credits/ HBA will be  16%.

Case B. For a 1 Gbps FCIP link with 5 N-port HBAs, each HBA needs  to
advertise 2,000 credits (10,000/5) to fully utilize the link.  The
utilization with 16 credits/ HBA will be 0.8%.

Case C. For a 10  Gbps FCIP link with 100 N-port HBAs, each HBA needs to
advertise 1,000  credits to fully utilize the link. The utilization with 16
credits/ HBA will  be 1.6%.

Case D. For a 10 Gbps FCIP link with 5 N-port HBAs, each HBA  needs to
advertise 20,000 credits to fully utilize the link. The utilization  with
16
credits/ HBA will be 0.08%.
------------

> -----  Original Message -----
>
> From: "Julian Satran" <Julian_Satran@il.ibm.com>
> To: <ips@ece.cmu.edu>
> Sent: Monday, August 06, 2001 11:01  PM
> Subject: Re:
>
>
> >
> > How did you  come to this number?  What did you assume for the exchange
> >  length?
> >
> > Julo
> >
> > "Satish Menon"  <satish_s_menon@hotmail.com>@ece.cmu.edu on 06-08-2001
> > 23:44:05
>  >
> > Please respond to "Satish Menon" <satish_s_menon@hotmail.com>
> >
> > Sent by:  owner-ips@ece.cmu.edu
> >
> >
> > To:   <ips@ece.cmu.edu>
> > cc:
> > Subject:
> >
>  >
> >
> >
> >
> > Does anyone know how  many end-to-end credits a typical HBA (N-port)
> issues
> > per  exchange? For a long distance link over FCIP, clearly this number
> >  needs to be large. If not, then the link utilization will be extremely
>  > poor. For e.g. a 200ms RTT link at 1 Gbps assuming 1 exchange  through
it,
> > it will need 10,000 credits to keep the link fully  utilized. Using a
> > different  number of exchanges say 2000, the  number of credits per
> exchange
> > drop to  5.
>  >
> >
> >
>






From owner-ips@ece.cmu.edu  Wed Aug  8 04:52:49 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08361
	for <ips-archive@odin.ietf.org>; Wed, 8 Aug 2001 04:52:49 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f78803k16134
	for ips-outgoing; Wed, 8 Aug 2001 04:00:03 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from relay2.bt.net (relay2.bt.net [194.72.6.62])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f78800e16129
	for <ips@ece.cmu.edu>; Wed, 8 Aug 2001 04:00:00 -0400 (EDT)
Received: from [217.33.138.194] (helo=cs.uchicago.edu)
	by relay2.bt.net with esmtp (Exim 3.15 #1)
	id 15UOFu-0006aI-00
	for ips@ece.cmu.edu; Wed, 08 Aug 2001 08:59:54 +0100
To: ips@ece.cmu.edu
Subject: Re: iSCSI: draft 7: remove S bit and Status field from the Data-in PD 
In-Reply-To: Message from Dave Sheehy <dbs@acropora.rose.agilent.com> 
   of "Tue, 07 Aug 2001 12:38:55 PDT." <200108071938.MAA20593@acropora.rose.agilent.com> 
References: <200108071938.MAA20593@acropora.rose.agilent.com> 
Date: Wed, 08 Aug 2001 03:59:47 -0400
From: Stephen Bailey <steph@cs.uchicago.edu>
Message-Id: <E15UOFu-0006aI-00@relay2.bt.net>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

> What are you trying to simplify?

Trying to simplify the receiver's data path by eliminating one of the
two possible ways in which unsolicited data could arrive.

Eliminating the unsolicited PDUs is the WRONG choice because if you
only have immediate data (data within the command PDU), you can must
either a) make the allowable size of the command PDU relatively
unbounded (to accomodate arbitrarily sized immediate data), which will
break either framing mode b) severely limit the amount of unsolicited
that can be sent, which makes unsolicited data useless.

So, unsolicited data should be carried in a similar, if not identical
way as regular data, tiled into multiple PDUs.

Steph


From owner-ips@ece.cmu.edu  Wed Aug  8 04:52:55 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08377
	for <ips-archive@odin.ietf.org>; Wed, 8 Aug 2001 04:52:55 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7881CI16203
	for ips-outgoing; Wed, 8 Aug 2001 04:01:12 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from relay2.bt.net (relay2.bt.net [194.72.6.62])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f78819e16192
	for <ips@ece.cmu.edu>; Wed, 8 Aug 2001 04:01:10 -0400 (EDT)
Received: from [217.33.138.194] (helo=cs.uchicago.edu)
	by relay2.bt.net with esmtp (Exim 3.15 #1)
	id 15UOH2-0006di-00
	for ips@ece.cmu.edu; Wed, 08 Aug 2001 09:01:04 +0100
To: ips@ece.cmu.edu
Subject: Re: iSCSI: Support Alias in the protocol 
In-Reply-To: Message from "John Hufferd" <hufferd@us.ibm.com> 
   of "Tue, 07 Aug 2001 09:51:38 PDT." <OFA1290378.108271AC-ON88256AA1.005ADB47@boulder.ibm.com> 
Date: Wed, 08 Aug 2001 04:00:57 -0400
From: Stephen Bailey <steph@cs.uchicago.edu>
Message-Id: <E15UOH2-0006di-00@relay2.bt.net>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

> Please state your positions so that David can call a consensus.

No surprise, I'm for the Alias.

Steph


From owner-ips@ece.cmu.edu  Wed Aug  8 05:39:15 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08987
	for <ips-archive@odin.ietf.org>; Wed, 8 Aug 2001 05:39:15 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f788LsF16910
	for ips-outgoing; Wed, 8 Aug 2001 04:21:54 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail.san.yahoo.com (mail.san.yahoo.com [209.132.1.30])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f788Lqe16906
	for <ips@ece.cmu.edu>; Wed, 8 Aug 2001 04:21:52 -0400 (EDT)
Received: from bursar.muttsnuts.com (217.33.138.58) by mail.san.yahoo.com (5.5.041.1)
        id 3B708C18000130DB for ips@ece.cmu.edu; Wed, 8 Aug 2001 01:20:39 -0700
Message-Id: <5.1.0.14.2.20010808092030.01cdd530@mail.muttsnuts.com>
X-Sender: markemuttsnuts@mail.muttsnuts.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 08 Aug 2001 09:21:17 +0100
To: ips@ece.cmu.edu
From: "Mark S. Edwards" <marke@muttsnuts.com>
Subject: Re: iSCSI: Support Alias in the protocol 
In-Reply-To: <E15UOH2-0006di-00@relay2.bt.net>
References: <Message from "John Hufferd" <hufferd@us.ibm.com>
 <OFA1290378.108271AC-ON88256AA1.005ADB47@boulder.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Aliases ...  Yes please !!!



From owner-ips@ece.cmu.edu  Wed Aug  8 05:42:35 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09047
	for <ips-archive@odin.ietf.org>; Wed, 8 Aug 2001 05:42:35 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f788SA617110
	for ips-outgoing; Wed, 8 Aug 2001 04:28:10 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from relay3.bt.net (relay3.bt.net [194.72.6.50])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f788S8e17105
	for <ips@ece.cmu.edu>; Wed, 8 Aug 2001 04:28:08 -0400 (EDT)
Received: from [217.33.138.194] (helo=cs.uchicago.edu)
	by relay3.bt.net with esmtp (Exim 3.22 #1)
	id 15UOh8-0007bX-00
	for ips@ece.cmu.edu; Wed, 08 Aug 2001 09:28:02 +0100
To: ips@ece.cmu.edu
Subject: Re: iSCSI: draft 7: remove S bit and Status field from the Data-in PD U? 
In-Reply-To: Message from "Elliott, Robert" <Robert.Elliott@compaq.com> 
   of "Tue, 07 Aug 2001 12:47:44 CDT." <78AF3C342AEAEF4BA33B35A8A15668C6019E2014@cceexc17.americas.cpqcorp.net> 
References: <78AF3C342AEAEF4BA33B35A8A15668C6019E2014@cceexc17.americas.cpqcorp.net> 
Date: Wed, 08 Aug 2001 04:27:55 -0400
From: Stephen Bailey <steph@cs.uchicago.edu>
Message-Id: <E15UOh8-0007bX-00@relay3.bt.net>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Robert,

> A similar simplification would be to remove the S bit and Status
> field from the Data-in PDU.

It wouldn't hurt my feelings if this happened.

However, there is a difference between these two simplifications.  The
good status optimization prevents the transmission of a PDU which is
~100% overhead.  Unsolicited data, by its nature, is to carry data, so
adding additional headers just leads you to the current header/data
overhead level.

That said, the ratio of data to status is going to be high no matter
what, so the overhead contribution of not optimizing good status is
probably neglible.  Furthermore, for hardware implementations, the
good status optimization is just an irritant.  Presumably that is why
FCP never bothered with it.

The traditional-sockets software-only implementations will have the
same argument against eliminating this optimization that they do
against removing Immediate data.  These optimizations permit them to
do half as many reads (2 instead of 4) in the optimized cases.
Personally, I would prefer not to give weight to unoptimized TCP
software solutions over hardware and optimized TCP software solutions.
Although most existing implementations are unoptimized TCP versions,
they should be considered prototypes (after all, version=0 until RFC
or death :^)

At an absolute minimum, I think we could remove the status field, and
assume that s=1 implies status=good.  There are no other SCSI statuses
that are worth optimizing.

Steph


From owner-ips@ece.cmu.edu  Wed Aug  8 08:04:49 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10704
	for <ips-archive@odin.ietf.org>; Wed, 8 Aug 2001 08:04:49 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f78Aak301865
	for ips-outgoing; Wed, 8 Aug 2001 06:36:46 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from thunk.org (THANK.THUNK.ORG [216.175.175.163])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f78Aahe01860
	for <ips@ece.cmu.edu>; Wed, 8 Aug 2001 06:36:43 -0400 (EDT)
Received: from host217-33-136-64.ietf.ignite.net ([217.33.136.64] helo=think.thunk.org)
	by thunk.org with asmtp (Exim 3.22 #1 (Debian))
	id 15UQbG-0005G2-00; Wed, 08 Aug 2001 06:30:06 -0400
Received: from tytso by think.thunk.org with local (Exim 3.22 #1 (Debian))
	id 15UQb8-0001z3-00; Wed, 08 Aug 2001 06:29:58 -0400
Date: Wed, 8 Aug 2001 06:29:58 -0400
From: Theodore Tso <tytso@mit.edu>
To: Joshua Tseng <jtseng@NishanSystems.com>
Cc: "'Williams, Jim'" <Jim.Williams@emulex.com>,
        "'Black_David@emc.com'" <Black_David@emc.com>, ips@ece.cmu.edu
Subject: Re: saag whyenc draft (was RE: Security Gateways)
Message-ID: <20010808062958.A7491@thunk.org>
References: <B300BD9620BCD411A366009027C21D9B5BADD2@ariel.nishansystems.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
In-Reply-To: <B300BD9620BCD411A366009027C21D9B5BADD2@ariel.nishansystems.com>; from jtseng@NishanSystems.com on Tue, Aug 07, 2001 at 12:18:04AM -0700
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

On Tue, Aug 07, 2001 at 12:18:04AM -0700, Joshua Tseng wrote:
> And despite all the touted advantages
> of the pure end-to-end security model, do we have any experience
> with it? I think not.

Actually, quite a few organizations have had a lot of experince with a
pure end-to-end security model.  Try just about any university, which
simply can't run with firewalls because every single professor has
collaborative research projects with so many folks at other
organizations that a firewall would be pointless (there'd be so many
holes in the firewalls that you might as well not bother).

> One immediate consequence I can think of is that iSCSI devices will
> not be able to leverage the services of a security gateway, unless you
> have distributed the encryption keys for your iSCSI session to that
> firewall.  And contrary to the negative things said about them,
> security gateways are, and IMO will continue to be, an important
> component to any enterprise's security infrastructure for the forseeable
> future.  They are a bottleneck for all traffic entering the network,
> making it much easier for the administrator to monitor security threats
> to that network, since he only has to monitor his few security gateways,
> instead of each of his 1000's of hosts.

... and when someone takes their infected Windows 2000 laptop back
behind the corporate firewall, viruses such as Code Red generally
rampage completely out of control, since people behind the firewall
get careless and assume that they don't need to worry about security
or applying the latest security patches or service packs behind the
firewall.

This has happened to at least three companies, according to reports
from IETF'ers.  One of them at last count hadn't been able to read
e-mail for the last 48+ hours because Code Red was disrupting the
internal network so badly that he wasn't able to get to his corporate
mail servers.

If you think that administrators only need to monitor the few security
gateways, in order to assure the security of the enterprise, you're
beeing hopelessly optimistic.

That being said, no one is saying that security firewalls should be
thrown out; first of all, by saying that security should be mandatory
to implement, it gives the choice of whether or not the encryption
should be turned on to the user.  Mantory to implement != manadatory
to use.  Secondly, defense in depth is important.  

Even behind my corporate firewall of my company, I maintain my
personal machines as if there were no firewall, and use encrypted
connections for everything.  This meant that after we got badly
attacked by hackers who were able to pierce the corporate firewalls, I
wasn't affected.  However the naive folks who assumed they didn't need
to worry about security because the firewall would protect them were
very badly affected indeed.

							- Ted



From owner-ips@ece.cmu.edu  Wed Aug  8 08:06:45 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10733
	for <ips-archive@odin.ietf.org>; Wed, 8 Aug 2001 08:06:45 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f78B4u102774
	for ips-outgoing; Wed, 8 Aug 2001 07:04:56 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f78B4qe02767
	for <ips@ece.cmu.edu>; Wed, 8 Aug 2001 07:04:52 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id NAA157810
	for <ips@ece.cmu.edu>; Wed, 8 Aug 2001 13:04:42 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f78B4fe219506
	for <ips@ece.cmu.edu>; Wed, 8 Aug 2001 13:04:41 +0200
Importance: Normal
Subject: RE: iSCSI: draft 7: Abort Task and RefCmdSN
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFFBA9C080.99DA59F2-ONC2256AA2.0036C5D4@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Wed, 8 Aug 2001 13:02:22 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 08/08/2001 14:04:41
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Correct - expect CmdSN should take a value of one more the last CmdSN (the
value that would have beein give to it would it not have been immediate).
And tere is bound bound to be a slight correction som simplify abbort task
in most of the cases comming in several days (nothing major only a
clarification and a recommended behaviour).

Julo

"Nicolson, Alex" <Alex.Nicolson@emulex.com> on 07-08-2001 16:28:42

Please respond to <Alex.Nicolson@emulex.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:
Subject:  RE: iSCSI: draft 7: Abort Task and RefCmdSN



Julo,

Thanks for having patience with me.

The way I understand the CmdSN for Task Management in the Rev 7 spec, it
looked that for all practical purposes, the CmdSn was going to have to be
set to the last value sent for it to properly handle all outstanding
commands, otherwise there would be lost Task Tags. I read it as there would
be no responses for any tasks greater than CmdSN, therefore CmdSN seems to
requires some not so arbitrary value. Is there something I should read more
carefully?

Alex



> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Tuesday, August 07, 2001 1:58 AM
> To: Alex.Nicolson@emulex.com
> Subject: RE: iSCSI: draft 7: Abort Task and RefCmdSN
>
>
> Alex
>
> CmdSN can take any value. CmdSN is meant mainly as a generalized
reference
> for where in the stream an immediate command was issue - or as a
> CmdSN when
> not immediate (even Abort Task does not have to be immediate).
>
> Julo
>
> "Nicolson, Alex" <Alex.Nicolson@emulex.com> on 07-08-2001 00:21:01
>
> Please respond to <Alex.Nicolson@emulex.com>
>
> To:   Julian Satran/Haifa/IBM@IBMIL
> cc:
> Subject:  RE: iSCSI: draft 7: Abort Task and RefCmdSN
>
>
>
> Julo,
>
> I'm sorry I am being so thick, I am quite confused. My understanding was
> that to Abort Task aborted the task based on the Referenced Task
> Tag. Is it
> now required that to abort a task both the CmdSn and Task Tag must be
used
> ID a particular Task? I'm not sure why both are required.
>
> I can understand that a Abort Task might arrive before the iSCSI SCSI PDU
> for that task to be aborted arrived, but can't the problem be detected
and
> manged by use of the CmdSN.
>
> (I guess I liked it better when the only purpose of CmdSn was for command
> ordering between the iSCSI and SCSI layer. :))
>
> Alex.NicolsoN@emulex.com
>
>
> > -----Original Message-----
> > From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > Sent: Monday, August 06, 2001 4:21 PM
> > To: Alex.Nicolson@emulex.com
> > Cc: ips@ece.cmu.edu
> > Subject: RE: iSCSI: draft 7: Abort Task and RefCmdSN
> >
> >
> >
> > Alex,
> >
> > That is correct but has no relevance if you want to abbort one specific
> > task.
> >
> > Julo
> >
> > "Nicolson, Alex" <Alex.Nicolson@emulex.com> on 06-08-2001 21:16:28
> >
> > Please respond to <Alex.Nicolson@emulex.com>
> >
> > To:   Julian Satran/Haifa/IBM@IBMIL, <ips@ece.cmu.edu>
> > cc:
> > Subject:  RE: iSCSI: draft 7: Abort Task and RefCmdSN
> >
> >
> >
> > Julo,
> >
> > I must be misunderstanding something. I thought that Task Management
> > commands were to be executed as if they had arrived in sequence based
on
> > their CmdSN.
> >
> >         "Task management commands must be executed
> >         as if all the commands having a CmdSN lower or equal to the
task
> >         management CmdSN have been received by the target (i.e.,
> > have to be
> >         executed as if received for ordered delivery even when
> marked for
> >         immediate delivery)."
> >
> > Why wouldn't that be the case with Abort Task?
> >
> > Alex.Nicolson@emulex.com
> >
> >
> > > -----Original Message-----
> > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf
Of
> > > Julian Satran
> > > Sent: Sunday, August 05, 2001 2:37 PM
> > > To: ips@ece.cmu.edu
> > > Subject: Re: iSCSI: draft 7: Abort Task and RefCmdSN
> > >
> > >
> > > Robert,
> > >
> > > This is related to the fact that the abort command can arrive before
> the
> > > command to be aborted if sent on a different connection (or the
> > > command has
> > > been dropped due to some error). As such RefCmdSN indicates where the
> > > command would have been in the command queue.  If they don't agree
the
> > > target should not abbort. And the main criteria for finding a
> > task is the
> > > Initiator Task Tag.
> > > I've changed the wording to:
> > >
> > > 1.1.1     RefCmdSN
> > >
> > >    For abort-task the task CmdSN to enable task removal. If
> > RefCmdSN does
> > >    not match the CmdSN of the command to be aborted at the target
> > > The abort action MUST not be performed and the response MUST be
> function
> > > rejected.
> > >
> > > Julo
> > >
> > >
> > >
> > > "Elliott, Robert" <Robert.Elliott@compaq.com>@ece.cmu.edu on
> 05-08-2001
> > > 20:36:10
> > >
> > > Please respond to "Elliott, Robert" <Robert.Elliott@compaq.com>
> > >
> > > Sent by:  owner-ips@ece.cmu.edu
> > >
> > >
> > > To:   "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
> > > cc:
> > > Subject:  iSCSI: draft 7: Abort Task and RefCmdSN
> > >
> > >
> > >
> > > The Task Management [function] Command PDU includes two fields
> > > currently only used by the ABORT TASK function:
> > >
> > > 2.5.2 Referenced Task Tag
> > >   Initiator Task Tag of the task to be aborted - for abort task
> > >
> > > 2.5.3 RefCmdSN [Referenced command sequence number]
> > >   For abort-task the task CmdSN to enable task removal. If RefCmdSN
is
> > >   is lower that ExpCmdSN or higher than MaxCmdSN the target
> will ignore
> > >   RefCmdSN.
> > >
> > > Both fields identify the task to be aborted.  The Referenced Task
> > > Tag field sits at the SCSI level and matches the SAM-2 function
> > > call description (SAM-2 revision 18):
> > > 6.2 ABORT TASK
> > >   Function call:
> > >     Service Response = ABORT TASK (IN (I_T_L_Q Nexus) )
> > >
> > > The RefCmdSN field sits at the iSCSI level.
> > >
> > > I suggest removing one of these fields.  Having two ways to
> > > specify the same thing just raises the question of what to do
> > > when the values don't agree.  If that happens, should the
> > > target:
> > > send back a Reject PDU
> > > abort both tasks
> > > abort the task indicated by the Referenced Task Tag
> > > abort the task indicated by the RefCmdSN
> > > abort one of the tasks but also report an error
> > > do any of the above
> > >
> > > Since task management functions in general may rely on the
> > > SCSI tag (although Abort Task is the only current user of it),
> > > I suggest keeping that flag and dropping the iSCSI field.
> > >
> > > --
> > > Robert.Elliott@compaq.com
> > > Compaq Computer Server Storage
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
>






From owner-ips@ece.cmu.edu  Wed Aug  8 08:07:40 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10746
	for <ips-archive@odin.ietf.org>; Wed, 8 Aug 2001 08:07:39 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f78B4re02769
	for ips-outgoing; Wed, 8 Aug 2001 07:04:53 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f78B4pe02760
	for <ips@ece.cmu.edu>; Wed, 8 Aug 2001 07:04:51 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id NAA303418
	for <ips@ece.cmu.edu>; Wed, 8 Aug 2001 13:04:43 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f78B4he219510
	for <ips@ece.cmu.edu>; Wed, 8 Aug 2001 13:04:43 +0200
Importance: Normal
Subject: Re: Task Management Response
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF281C689F.6F319FE1-ONC2256AA2.0038AAB4@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Wed, 8 Aug 2001 13:33:29 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 08/08/2001 14:04:42
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

On cold reset all TCP conections are also severed.

LUN is not required in response it is a mistake. I'll fix it.

Julo

Sanjay Goyal <sanjay_goyal@ivivity.com>@ece.cmu.edu on 07-08-2001 17:00:07

Please respond to Sanjay Goyal <sanjay_goyal@ivivity.com>

Sent by:  owner-ips@ece.cmu.edu


To:   "Ips (E-mail)" <ips@ece.cmu.edu>
cc:   Sanjay Goyal <sanjay_goyal@ivivity.com>
Subject:  Task Management Response



Hi
 iSCSI draft 7.0
 2.6 Task Management Response
   description does include everything but      <Target cold reset>, why
was it left out is not clear to me as there is no difference between
warm and cold reset behaviour as an target.

 2.5 Task Management Command
   LUN is optional for this PDU
              why it is mandatory for
    Task Management Response.


Regards
Sanjay Goyal







From owner-ips@ece.cmu.edu  Wed Aug  8 08:08:24 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10759
	for <ips-archive@odin.ietf.org>; Wed, 8 Aug 2001 08:08:24 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f78B4rB02768
	for ips-outgoing; Wed, 8 Aug 2001 07:04:53 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f78B4ne02758
	for <ips@ece.cmu.edu>; Wed, 8 Aug 2001 07:04:49 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id NAA31248
	for <ips@ece.cmu.edu>; Wed, 8 Aug 2001 13:04:41 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f78B4ee85662
	for <ips@ece.cmu.edu>; Wed, 8 Aug 2001 13:04:40 +0200
Importance: Normal
Subject: RE: iSCSI London-IETF-foils
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF942E844C.BCC8CCD1-ONC2256AA2.0033AB1D@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Wed, 8 Aug 2001 12:25:03 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 08/08/2001 14:04:40
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

http://www.haifa.il.ibm.com/satran/ips

"Trang Nguyen" <tnguyen@perfisans.com> on 07-08-2001 16:50:16

Please respond to <tnguyen@perfisans.com>

To:   Julian Satran/Haifa/IBM@IBMIL, <ips@ece.cmu.edu>
cc:
Subject:  RE: iSCSI London-IETF-foils



Hi Julo,

Could you please tell us your site address?

Thanks,

Trang


-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Julian Satran
Sent: August 6, 2001 4:19 PM
To: ips@ece.cmu.edu
Subject: iSCSI London-IETF-foils


My foils are on my site.

Julo






From owner-ips@ece.cmu.edu  Wed Aug  8 08:26:12 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11056
	for <ips-archive@odin.ietf.org>; Wed, 8 Aug 2001 08:26:12 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f78BQr803556
	for ips-outgoing; Wed, 8 Aug 2001 07:26:53 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f78BQoe03551
	for <ips@ece.cmu.edu>; Wed, 8 Aug 2001 07:26:51 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id NAA183232
	for <ips@ece.cmu.edu>; Wed, 8 Aug 2001 13:26:38 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f78BQb843804
	for <ips@ece.cmu.edu>; Wed, 8 Aug 2001 13:26:37 +0200
Importance: Normal
Subject: RE: iSCSI: draft 7: Final bit in Data PDUs
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF60CF467F.270AF79F-ONC2256AA2.003D8FFC@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Wed, 8 Aug 2001 14:26:22 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 08/08/2001 14:26:37
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Elliot,

Thanks .  Will change 2.7.1 to read:

1.1.1     F (Final) Bit

   For outgoing data, this bit is 1 for the last PDU of unsolicited data or
   the last PDU of a sequence answering a R2T.

   For incoming data, this bit is 1 for the last input (read) data PDU of a
   sequence.  Input can be split in several sequences each one having it's
   own F bit. Splitting in sequences does not affect DataSN counting on
   Data-IN PDUs but MAY be used as a "change direction" indication for
   Bidirectional operations that need such a change and/or end of
   recoverable sequences by targets with a limited replay buffer.

   For Bidirectional operations, the F bit is 1 both for the end of the
   input sequences as well as the end of the output sequences.

 Comments?

 Julo

"Elliott, Robert" <Robert.Elliott@compaq.com>@ece.cmu.edu on 07-08-2001
20:25:13

Please respond to "Elliott, Robert" <Robert.Elliott@compaq.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: draft 7: Final bit in Data PDUs



I think an F bit per direction would be most useful.

Bidirectional command background:  the target chooses what order to run the
reads and writes.  It can start with either, and switch from one to the
other as often as it wishes.  These are all legal:

1.  read all data, write all data
2.  write all data, read all data
3.  read some, write some, read some, ...
4.  write some, read some, ...

There are two independent data pointers active, one per stream.  EMDP
applies to both.

--
Robert.Elliott@compaq.com
Compaq Computer Server Storage


-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Monday, August 06, 2001 5:57 PM
To: ips@ece.cmu.edu
Subject: Re: iSCSI: draft 7: Final bit in Data PDUs


Elliot,

I have no clue how those commands are going to work.
Can you help?
I assume that the F bit will have to be there at both ends?

Julo

"Elliott, Robert" <Robert.Elliott@compaq.com>@ece.cmu.edu on 06-08-2001
18:02:10

Please respond to "Elliott, Robert" <Robert.Elliott@compaq.com>

Sent by:  owner-ips@ece.cmu.edu


To:   "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
cc:
Subject:  iSCSI: draft 7: Final bit in Data PDUs



iSCSI draft 7 section 2.7.1 describes when the (F) Final bit is
set in the Data-out and Data-in PDUs:

  For outgoing data, this bit is 1 for the last PDU of unsolicited
  data  or the last PDU of a sequence answering a R2T.

  For incoming data, this bit is 1 for the last input (read) data
  PDU of a sequence.

It needs to define how this works for bidirectional commands.
Is the F bit set to one on both the last Data-out PDU and the last
Data-in PDU?  Or is it set to one only on the last Data PDU,
whatever direction it may be?

--
Robert.Elliott@compaq.com
Compaq Computer Server Storage







From owner-ips@ece.cmu.edu  Wed Aug  8 09:36:40 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12319
	for <ips-archive@odin.ietf.org>; Wed, 8 Aug 2001 09:36:39 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f78C51S05062
	for ips-outgoing; Wed, 8 Aug 2001 08:05:01 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f78C4ve05057
	for <ips@ece.cmu.edu>; Wed, 8 Aug 2001 08:04:58 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id OAA21050
	for <ips@ece.cmu.edu>; Wed, 8 Aug 2001 14:04:42 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f78C4fe30364
	for <ips@ece.cmu.edu>; Wed, 8 Aug 2001 14:04:41 +0200
Importance: Normal
Subject: Re: iSCSI: draft 7: remove S bit and Status field from the Data-in PD
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF032F45D3.59C0047E-ONC2256AA2.00424646@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Wed, 8 Aug 2001 15:04:26 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 08/08/2001 15:04:41
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


That will negatively afftect receiver performance.  Julo

Stephen Bailey <steph@cs.uchicago.edu>@ece.cmu.edu on 08-08-2001 10:59:47

Please respond to Stephen Bailey <steph@cs.uchicago.edu>

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  Re: iSCSI: draft 7: remove S bit and Status field from the
      Data-in PD



> What are you trying to simplify?

Trying to simplify the receiver's data path by eliminating one of the
two possible ways in which unsolicited data could arrive.

Eliminating the unsolicited PDUs is the WRONG choice because if you
only have immediate data (data within the command PDU), you can must
either a) make the allowable size of the command PDU relatively
unbounded (to accomodate arbitrarily sized immediate data), which will
break either framing mode b) severely limit the amount of unsolicited
that can be sent, which makes unsolicited data useless.

So, unsolicited data should be carried in a similar, if not identical
way as regular data, tiled into multiple PDUs.

Steph





From owner-ips@ece.cmu.edu  Wed Aug  8 09:37:16 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12347
	for <ips-archive@odin.ietf.org>; Wed, 8 Aug 2001 09:37:16 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f78Ba8d03956
	for ips-outgoing; Wed, 8 Aug 2001 07:36:08 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f78Ba6e03952
	for <ips@ece.cmu.edu>; Wed, 8 Aug 2001 07:36:06 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id NAA247444
	for <ips@ece.cmu.edu>; Wed, 8 Aug 2001 13:35:59 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f78BZw888196
	for <ips@ece.cmu.edu>; Wed, 8 Aug 2001 13:35:58 +0200
Importance: Normal
Subject: Re: iSCSI: draft 7: remove S bit and Status field from the Data-in PD	U?
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFAD943866.BEDCCCC0-ONC2256AA2.003EE978@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Wed, 8 Aug 2001 14:35:43 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 08/08/2001 14:35:58
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Elliott,

That might be so for hardware inplementations. For software it means an
additional read and it may negatively affect performance for short
operations (like data base transactions).

The same is true for immediate writes. The simplification that was agreed
that we bring back to the list
was to eliminate 2 types of unsolicited data and return to only one king
being allowed in a command.

So here it is.  I personally think that the simplification is so minor that
it is not worth going through talking about it.

Comments?

Julo


"Elliott, Robert" <Robert.Elliott@compaq.com>@ece.cmu.edu on 07-08-2001
20:47:44

Please respond to "Elliott, Robert" <Robert.Elliott@compaq.com>

Sent by:  owner-ips@ece.cmu.edu


To:   "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
cc:
Subject:  iSCSI: draft 7: remove S bit and Status field from the Data-in PD
      U?



At the IETF IPS WG meeting, removing the immediate data from the
Command PDU was discussed as a possible simplification.

A similar simplification would be to remove the S bit and Status
field from the Data-in PDU.  These let Status be returned in the
Data-in PDU rather than in a separate Response PDU.  The target
can send the last Data-in PDU and the Response PDU back-to-back;
there's not much wire overhead sending 48 more bytes.  The
initiator always has to handle separate Response PDUs, so this
eliminates a special case and collects all status and residual
handling in one place.

--
Robert.Elliott@compaq.com
Compaq Computer Server Storage







From owner-ips@ece.cmu.edu  Wed Aug  8 11:13:53 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14642
	for <ips-archive@odin.ietf.org>; Wed, 8 Aug 2001 11:13:53 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f78DRLp08804
	for ips-outgoing; Wed, 8 Aug 2001 09:27:21 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from relay3.bt.net (relay3.bt.net [194.72.6.50])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f78DRJe08797
	for <ips@ece.cmu.edu>; Wed, 8 Aug 2001 09:27:19 -0400 (EDT)
Received: from [217.33.138.194] (helo=cs.uchicago.edu)
	by relay3.bt.net with esmtp (Exim 3.22 #1)
	id 15UTMf-0001Zw-00
	for ips@ece.cmu.edu; Wed, 08 Aug 2001 14:27:13 +0100
To: ips@ece.cmu.edu
Subject: Re: iSCSI: draft 7: remove S bit and Status field from the Data-in PD 
In-Reply-To: Message from "Julian Satran" <Julian_Satran@il.ibm.com> 
   of "Wed, 08 Aug 2001 15:04:26 +0300." <OF032F45D3.59C0047E-ONC2256AA2.00424646@telaviv.ibm.com> 
References: <OF032F45D3.59C0047E-ONC2256AA2.00424646@telaviv.ibm.com> 
Date: Wed, 08 Aug 2001 09:27:05 -0400
From: Stephen Bailey <steph@cs.uchicago.edu>
Message-Id: <E15UTMf-0001Zw-00@relay3.bt.net>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

> That will negatively afftect receiver performance.
                              ^ software
                                       ^s running on unmodified TCP layers

I even argue with the claim that it has to negatively affect the
performance running against an unmodified TCP layer.

In the worst possible case, where your receiver is implemented as a
user-mode program, AND, you implement it as:

  for (;;) {
    if ((c = read(f, bhs, sizeof(*bhs)) < 0) { /* error */ }
    restLen = bhs->ahsLen + bhs->dataLen;
    if ((c = read(f, rest, restLen) < 0) { /* error */ }
    /* process PDU */
    . . .
  }

or worse, with 3 reads() (or even 1 read()), YES, having an extra PDU
slows you down.

However, this is not a high performance way to implement the
protocol.  In other words, you're not really trying if you do this, so
we shouldn't improve the performance for implementations that aren't
trying.  The performance way to implement this is something like:

  for (;;) {
    if (outOfBufferOrJustWantToTryForMore()) {
      fillBuffer(b);  /* nonblocking read unless outOfBuffer */
    }
    bhs = readFromBuffer(b, sizeof(*bhs));
    restLen = bhs->ahsLen + bhs->dataLen;
    rest = readFromBuffer(b, restLen);
    /* process PDU */
  }

With a structure LIKE (I know the above structure is `buggy') this,
your `reads' are very lightweight.  Typically, you'll get an entire
TCP segment (or possibly more) per real read, and pulling an arbitrary
number of PDUs from that segment costs about the same as pulling a
single PDU from that segment.

Completely independently of whether we agglutinate control with data,
if `pull from socket' (typically system) calls are expensive,
performance will stink if you use the `get next data == pull from
socket' model.  If pull from socket calls are cheap, the agglutination
doesn't matter either.

Steph


From owner-ips@ece.cmu.edu  Wed Aug  8 12:45:06 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16871
	for <ips-archive@odin.ietf.org>; Wed, 8 Aug 2001 12:45:06 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f78FK0514857
	for ips-outgoing; Wed, 8 Aug 2001 11:20:00 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f78FJve14852
	for <ips@ece.cmu.edu>; Wed, 8 Aug 2001 11:19:58 -0400 (EDT)
Received: by ATLOPS with Internet Mail Service (5.5.2448.0)
	id <QMJCNBVX>; Wed, 8 Aug 2001 11:19:52 -0400
Message-ID: <25369470B6F0D41194820002B328BDD2116212@ATLOPS>
From: Sanjay Goyal <sanjay_goyal@ivivity.com>
To: "Ips (E-mail)" <ips@ece.cmu.edu>
Cc: Sanjay Goyal <sanjay_goyal@ivivity.com>
Subject: NOP-out,  NOP-in PDU
Date: Wed, 8 Aug 2001 11:19:43 -0400 
X-MS-TNEF-Correlator: <25369470B6F0D41194820002B328BDD2116212@ATLOPS>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C1201D.922F0A02"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C1201D.922F0A02
Content-Type: text/plain;
	charset="iso-8859-1"

Hi
 
 (2.12) 
For initiator to test the connection, it should set the P bit to ONE
     while
 (2.13.1)for target to test the connection, it should set the P bit to ZERO
 How does it know the connection is OK without any response back to it. As
only with P=1, initiator will response with NOP-out PDU.

 I dont quite follow it, please help me understand it.

Sanjay Goyal                                     
Asic Design Engg.                              
www.ivivity.com


------_=_NextPart_000_01C1201D.922F0A02
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64

eJ8+IjUPAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQkABAACAAAAAAAAAAEIAAUABAAAAAAAAAAAAAEFgAMADgAAANEH
CAAIAAsAEwArAAMANAEBIIADAA4AAADRBwgACAALABMANAADAD0BAQmAAQAhAAAAQjE1NzdDNkE2
NThBRDUxMTk0QjMwMDAyQjMyOEJERDIADgcBBIABABUAAABOT1Atb3V0LCAgTk9QLWluIFBEVQDY
BQENgAQAAgAAAAIAAgABA5AGALAGAAAwAAAAAwA2AAAAAAADAFuACCAGAAAAAADAAAAAAAAARgAA
AABShQAAfW4BAB4AXIAIIAYAAAAAAMAAAAAAAABGAAAAAFSFAAABAAAABAAAADkuMAALAIWACCAG
AAAAAADAAAAAAAAARgAAAAAGhQAAAAAAAAMADoAIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAA
CwAQgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAALABGACCAGAAAAAADAAAAAAAAARgAAAAAO
hQAAAAAAAAMAN4AIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwA4gAggBgAAAAAAwAAAAAAA
AEYAAAAAEYUAAAAAAAADAD6ACCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAAIBCRABAAAA2QEA
ANUBAAAhAwAATFpGdfGvf3ADAAoAcmNwZzEyNeIyA0N0ZXgFQQEDAff/CoACpAPkBxMCgA/zAFAE
Vj8IVQeyESUOUQMBAgBjaOEKwHNldDIGAAbDESX2MwRGE7cwEiwRMwjvCfe2OxgfDjA1ESIMYGMA
UDMLCQFkMzYWUAumIEgfAKAKsQqACuMdUSgyLjUOICkddUYFsQuAaXR9BzB0BbEfYB+QB5AFQHTI
aGUgBaBubgWQHzBNAiAsHvAFQHNoCGBsjmQhQBQgIBNQIGIhITEfoU9ORR0VI2J3aNUDEGUdiTMe
ECkCEB+BPQrAZyHSH78gzyHeWkUkUk8dFUhvB+Bkb/MHkScha24pkSYsHvAEIHxPSyOgHyAnYQVA
AHB58iAYIHNwAiAUECJQANB2ayWSHyAuEMAEIAIgbOcsgCviIjA9MScBHxcD8A5sAyAspy5zTk9Q
LWEsIlBEVS4dFB0VSeMpsQIwIHF1HyAmQAIQny/QKZEfICcAC1BlYS0BESYwbHAgB4AgdW5/BIEl
8ABwJ6AtsTGqBhFq4mEsgEdveQdAI2M3j084jR0ULfAN4CBEB5BpwmcDoEVuZ2ct0DsPiTjfCnc9
QC5pdj2BqHR5LgWgbTGqfT8AAAAAHgBwAAEAAAATAAAAMi4xMCBMb2dpbiBDb21tYW5kAAACAXEA
AQAAACAAAAABwR957ndqfFHrimUR1ZSzAAKzKL3SAAGgnHAAJz1ykAMAJgAAAAAAAwAuAAAAAAAL
AAIAAQAAAAsAFwwAAAAAAwBdQAAAAAADAAlZAQAAAAMA3j+vbwAAQAA5AHB1Ro0dIMEBAwDxPwkE
AAAeADFAAQAAAAgAAABTQU5KQVlHAAMAGkAAAAAAHgAwQAEAAAAIAAAAU0FOSkFZRwADABlAAAAA
AAMA/T/kBAAAAwCAEP////8CAUcAAQAAAC4AAABjPVVTO2E9IDtwPUlWSVZJVFk7bD1BVExPUFMt
MDEwODA4MTUxOTQzWi0yNzQAAAACAfk/AQAAAEoAAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAA
AAAAL089SVZJVklUWS9PVT1BVExPUFMvQ049UkVDSVBJRU5UUy9DTj1TQU5KQVlHAAAAHgD4PwEA
AAANAAAAU2FuamF5IEdveWFsAAAAAB4AOEABAAAACAAAAFNBTkpBWUcAAgH7PwEAAABKAAAAAAAA
ANynQMjAQhAatLkIACsv4YIBAAAAAAAAAC9PPUlWSVZJVFkvT1U9QVRMT1BTL0NOPVJFQ0lQSUVO
VFMvQ049U0FOSkFZRwAAAB4A+j8BAAAADQAAAFNhbmpheSBHb3lhbAAAAAAeADlAAQAAAAgAAABT
QU5KQVlHAEAABzB6rpBaHSDBAUAACDACCi+SHSDBAR4APQABAAAAAQAAAAAAAAAeAB0OAQAAABUA
AABOT1Atb3V0LCAgTk9QLWluIFBEVQAAAAAeADUQAQAAADAAAAA8MjUzNjk0NzBCNkYwRDQxMTk0
ODIwMDAyQjMyOEJERDIxMTYyMTJAQVRMT1BTPgALACkAAAAAAAsAIwAAAAAAAwAGEHoVzOADAAcQ
OAEAAAMAEBAAAAAAAwAREAAAAAAeAAgQAQAAAGUAAABISSgyMTIpRk9SSU5JVElBVE9SVE9URVNU
VEhFQ09OTkVDVElPTixJVFNIT1VMRFNFVFRIRVBCSVRUT09ORVdISUxFKDIxMzEpRk9SVEFSR0VU
VE9URVNUVEhFQ09OTkVDVElPAAAAAAIBfwABAAAAMAAAADwyNTM2OTQ3MEI2RjBENDExOTQ4MjAw
MDJCMzI4QkREMjExNjIxMkBBVExPUFM+ABRY

------_=_NextPart_000_01C1201D.922F0A02--


From owner-ips@ece.cmu.edu  Wed Aug  8 14:37:16 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18926
	for <ips-archive@odin.ietf.org>; Wed, 8 Aug 2001 14:37:16 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f78HVnw22415
	for ips-outgoing; Wed, 8 Aug 2001 13:31:49 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f78HVle22410
	for <ips@ece.cmu.edu>; Wed, 8 Aug 2001 13:31:47 -0400 (EDT)
Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <QQS06DQC>; Wed, 8 Aug 2001 13:31:41 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD583@CORPMX14>
From: Black_David@emc.com
To: jtseng@NishanSystems.com, ips@ece.cmu.edu
Subject: RE: saag whyenc draft (was RE: Security Gateways)
Date: Wed, 8 Aug 2001 13:26:25 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

> I would like to second Jim's remarks below, and would like to see some
> or all of his text included in the iSCSI document.  I think
> this is a reasonable approach which would address most concerns on
> all sides.

Not exactly.  The "asterisk" type of implementation (complies with
the security portion of the RFC only when a separately purchased
external gateway is present) have the potential to provide other
than end-to-end security because there's no way to control how
much network is between the iSCSI device and the gateway (e.g.,
suppose the gateway goofs and instead of talking to its peer
in the other city winds up talking to a gateway located a few
hops away in a metro POP).  At the moment, both automatic keying
proposals for iSCSI (SRP/ESP and some variant of IKE) are headed
in this direction by requiring modifications to current IPsec
firewalls in order to correctly implement the keying and/or
ESP processing.

The rest of Josh's message confuses "mandatory to implement" (which
iSCSI is being required to do) with "mandatory to use" (which is
not required, not even by the saag whyenc draft. After a long
exposition on the utility of corporate security gateways (mostly
correct, as they are in fact useful) Josh sums up by saying:

>  My solution would be to hide these devices
> behind a security gateway network proxy, turn off the end-to-end security,
> and use the security gateway's IPSec.

This is completely permissible, even under the saag whyenc draft (see its
discussion of "mandatory to implement" vs. "mandatory to use" in Section 7),
and is the obvious thing to do in the situation Josh is concerned about.

One other note is that to get denial of service prevention benefits for
iSCSI from a firewall, one probably needs iSCSI-specific inspection code
in the firewall.  Needless to say, this won't happen right away.

--David

p.s.  Jim's original text on types of implementations is below.


> > 
> > I think with regards to both confidentiality and 
> authentication (IPSec
> > authentication, not login authentication) one can expect three types
> > of implementations.
> > 
> > 1.  Products that claim full RFC compliance in big letters with a 
> >     small foot note stating that an external gateway is required
> >     for compliance with the security section of the RFC.
> > 
> > 2.  Products that claim full RFC compliance but drop to 1% normal
> >     throughput whenever security is enabled, and whose customers
> >     will buy an external gateway anyway when they want security.
> > 
> > 3.  Products that can run security at full speed but which are
> >     not competative in terms of cost/performance with 1 and 2.
> > 
> > I don't have a problem with any of these, but I think it's 
> critically
> > important that the security protocol for iSCSI doesn't preclude
> > options 1 and 2.  In terms of actual deployment, I suspect these
> > will be the most common.  A requirement for keying IPSec in
> > a way that is not compatable with existing security gateways
> > would be a serious setback to general acceptance of iSCSI, and
> > could potentially result in the emergence of a de facto standard
> > (no security) which diverges from the RFC standard (manditory 
> > security).  I don't think diverging standards are in anyone's
> > best interest, especially if there are practical ways to 
> > aviod it.
> > 
> > 
> 


From owner-ips@ece.cmu.edu  Wed Aug  8 14:47:07 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19098
	for <ips-archive@odin.ietf.org>; Wed, 8 Aug 2001 14:47:07 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f78ICBQ24691
	for ips-outgoing; Wed, 8 Aug 2001 14:12:11 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from web20209.mail.yahoo.com (web20209.mail.yahoo.com [216.136.226.64])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f78HLRe21820
	for <ips@ece.cmu.edu>; Wed, 8 Aug 2001 13:21:28 -0400 (EDT)
Message-ID: <20010808172127.78861.qmail@web20209.mail.yahoo.com>
Received: from [64.174.149.250] by web20209.mail.yahoo.com; Wed, 08 Aug 2001 10:21:26 PDT
Date: Wed, 8 Aug 2001 10:21:26 -0700 (PDT)
From: Jyothi Vaidyanathan <jyothi_vaidyanathan@yahoo.com>
Subject: FCIP link: Severe underutilization problem?
To: ips@ece.cmu.edu, satish_s_menon@hotmail.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Satish,

Has anybody else confirmed these calculations? I hope
they are wrong, because if they are correct they
severely limit the utility of the FCIP standard.

Regards,

Jyothi

Jyothi Vaidyanathan
Elmwood Semiconductors, Inc.
(401) 941-3910

--------------Original Message------------------

TCP works with some other structures. It is a sliding
window protocol. And
yes for the links you mentioned the window has to be
sizable. And the
number-of-SCSI commans/R2Ts/Data in flow has to be
also large to fill the
pipe.

Julo

"Satish Menon" <satish_s_menon@hotmail.com> on
08-08-2001 00:55:41

Please respond to "Satish Menon"
<satish_s_menon@hotmail.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:
Subject:  your query




Here is how the  calculation was done. Also, some
folks told me that N-port
HBAs don't reserve  end-to-end credits by exchange,
they just have a common
pool of
credits  for the entire HBA (around 16), so the
calculations factor in
this
new
data point.

Assume a 1 Gbps link.
Assume a 2K FC  frame.

So it takes 16us to transmit a frame. For 200ms RTT,
that means  that
200ms/
16us ~ 10,000 credits.

Case A. For a 1Gbps FCIP link with  100 N-port HBAs,
each HBA needs to
advertise 100 credits (10,000/100) to  fully utilize
the link. The
utilization with 16 credits/ HBA will be  16%.

Case B. For a 1 Gbps FCIP link with 5 N-port HBAs,
each HBA needs  to
advertise 2,000 credits (10,000/5) to fully utilize
the link.  The
utilization with 16 credits/ HBA will be 0.8%.

Case C. For a 10  Gbps FCIP link with 100 N-port HBAs,
each HBA needs to
advertise 1,000  credits to fully utilize the link.
The utilization with 16
credits/ HBA will  be 1.6%.

Case D. For a 10 Gbps FCIP link with 5 N-port HBAs,
each HBA  needs to
advertise 20,000 credits to fully utilize the link.
The utilization  with
16
credits/ HBA will be 0.08%.
------------

> -----  Original Message -----
>
> From: "Julian Satran" <Julian_Satran@il.ibm.com>
> To: <ips@ece.cmu.edu>
> Sent: Monday, August 06, 2001 11:01  PM
> Subject: Re:
>
>
> >
> > How did you  come to this number? What did you
assume for the exchange
> >  length?
> >
> > Julo
> >
> > "Satish Menon" 
<satish_s_menon@hotmail.com>@ece.cmu.edu on 06-08-2001
> > 23:44:05
>  >
> > Please respond to "Satish Menon"
<satish_s_menon@hotmail.com>
> >
> > Sent by: owner-ips@ece.cmu.edu
> >
> >
> > To: <ips@ece.cmu.edu>
> > cc:
> > Subject:
> >
>  >
> >
> >
> >
> > Does anyone know how  many end-to-end credits a
typical HBA (N-port)
> issues
> > per  exchange? For a long distance link over FCIP,
clearly this number
> >  needs to be large. If not, then the link
utilization will be extremely
>  > poor. For e.g. a 200ms RTT link at 1 Gbps
assuming 1 exchange  through
it,
> > it will need 10,000 credits to keep the link fully
 utilized. Using a
> > different number of exchanges say 2000, the 
number of credits per
> exchange
> > drop to 5.
>  >
> >
> >
>





__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/


From owner-ips@ece.cmu.edu  Wed Aug  8 15:16:02 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19655
	for <ips-archive@odin.ietf.org>; Wed, 8 Aug 2001 15:16:01 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f78IZJD26129
	for ips-outgoing; Wed, 8 Aug 2001 14:35:19 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from va2mc.ummailbox.net (va2mc.ummailbox.net [64.210.247.19])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f78IZHe26123
	for <ips@ece.cmu.edu>; Wed, 8 Aug 2001 14:35:17 -0400 (EDT)
Received: from hqmailweb.COMMSTOR.Crossroads.com (HQMailWeb.Crossroads.com [63.237.99.250:25])
	by va2mc.ummailbox.net with ESMTP id U0808-1434-27a100;
	Wed, 8 Aug 2001 18:34:57 GMT
Received: from HQMAILNODE1.COMMSTOR.Crossroads.com ([10.5.1.42]) by hqmailweb.COMMSTOR.Crossroads.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Wed, 8 Aug 2001 13:34:56 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
Subject: Reserved field definitions
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Wed, 8 Aug 2001 13:34:55 -0500
Message-ID: <CFD808D1D39ACB47ABFF586D484CC52E261E53@HQMAILNODE1.COMMSTOR.Crossroads.com>
Thread-Topic: Reserved field definitions
Thread-Index: AcEgONHkgw8wF6MjREiAiazcXFXINQ==
From: "Robert Griswold" <rgriswold@Crossroads.com>
To: "Julian Satran" <Julian_Satran@il.ibm.com>
Cc: <ips@ece.cmu.edu>
X-OriginalArrivalTime: 08 Aug 2001 18:34:56.0813 (UTC) FILETIME=[D2B095D0:01C12038]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f78IZHe26124
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit

Julian:

In review the use of Reserved fields in the iSCSI draft, there seem to
be some inconsistencies through the document, and the assumptions of
their use appear to be in conflict with SAM-2.  First, two quotes from
07 and SAM-2:

"2. iSCSI PDU Formats 
...  Any bits not defined MUST be set to zero. Any reserved fields and
values MUST be 0 unless specified otherwise. "

"3.3.8 reserved: A keyword referring to bits, bytes, words, fields and
code values that are set aside for future standardization. Their use and
interpretation may be specified by future extensions to this or other
standards. A reserved bit, byte, word or field shall be set to zero, or
in accordance with a future extension to this standard. Recipients are
not required to check reserved bits, bytes, words or fields for zero
values.  Receipt of reserved code values in defined fields shall be
reported as an error."

It appears that there are some conflicts with the usage of the
definition of reserved in the iSCSI document and the definitions coming
from T10, specifically how to handle garbage in reserved fields.  I
would suggest that a PDU format error in iSCSI is actually a PDU
received that has errors in any defined fields, but does not require a
reject if inconsistencies are found in reserved fields.  Also, the fact
that some reserved fields require zeros, while others require ones seems
odd, and will probably lead to more incompatibilities than the value of
having dissimilar reserved field use provides.  If there is previous art
that forces this difference than let's call that use of the field for
what it is, versus calling it reserved.  My understanding of TCP network
protocols is very weak, though, and there could be a really good reason
why this mapping is happening, so please whack me with the stupid stick
if necessary.

The following are cases where 07 has lapses in the use of reserved
fields:

Page 44, under AHSType, bits 0 and 3-59 are declared Reserved, but not
"must be 0".  But also strangely here, it seems that AHSType is an
eight-bit field, that has 64-bits worth of explanation.  Am I reading
something wrong here?

Page 45, byte 2 of word 0 of op-code 0x01 is declared Reserved, but no
requirement for zeros (aside from the directive in Section 2).

Page 49, bits 5 and 6 of Flags are declared as Reserved, but no
requirement for zeros.  Also, bit 7 is not even declared even though the
table above (pg 48) shows bit 7 as a 1.  Does this mean bit 7 falls into
the odd category of a reserved field that must be 1?

Page 49, bits 80-ff of Response are declared as "Reserved" for
Vendor-unique responses.  Now most developers would interpret this
correctly, but the use of the word reserved here could lead some into
thinking only 0's are allowed, or must be checked for 0's.

Page 51, both 2.4.7 and 2.4.8 declare that if the S field is 0, then the
two mentioned fields are reserved, but no requirement for zeros (aside
from the directive in Section 2).

Page 53, the definition of Reference Task Tag or Reserved shows that a
reserved (even though specified) field need not be 0 (aside from the
directive in Section 2).

Page 80, bytes 0 and 1 of word 8 show CID or Reserved, but no
requirement for zeros (aside from the directive in Section 2).

Page 84, definition of Bit S, says 'otherwise, it is reserved,' but no
requirement for zeros (aside from the directive in Section 2).

Thanks,
Bob

Robert Griswold
Technologist
Crossroads Systems, Inc.
512-928-7272



From owner-ips@ece.cmu.edu  Thu Aug  9 05:32:13 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18671
	for <ips-archive@odin.ietf.org>; Thu, 9 Aug 2001 05:32:13 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f798I3r29243
	for ips-outgoing; Thu, 9 Aug 2001 04:18:03 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from relay3.bt.net (relay3.bt.net [194.72.6.50])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f798I2e29239
	for <ips@ece.cmu.edu>; Thu, 9 Aug 2001 04:18:02 -0400 (EDT)
Received: from [217.33.138.194] (helo=cs.uchicago.edu)
	by relay3.bt.net with esmtp (Exim 3.22 #1)
	id 15Ul0u-0001yd-00
	for ips@ece.cmu.edu; Thu, 09 Aug 2001 09:17:56 +0100
To: ips@ece.cmu.edu
Subject: Re: FCIP link: Severe underutilization problem? 
In-Reply-To: Message from Jyothi Vaidyanathan <jyothi_vaidyanathan@yahoo.com> 
   of "Wed, 08 Aug 2001 10:21:26 PDT." <20010808172127.78861.qmail@web20209.mail.yahoo.com> 
References: <20010808172127.78861.qmail@web20209.mail.yahoo.com> 
Date: Thu, 09 Aug 2001 04:17:48 -0400
From: Stephen Bailey <steph@cs.uchicago.edu>
Message-Id: <E15Ul0u-0001yd-00@relay3.bt.net>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

> Has anybody else confirmed these calculations?

I don't think they are correct.

When you are within the FC network, credits are link-layer.  That
means, each LINK must have enough credits to satisfy only its
bandwidth * delay product.  You will not get a 200 MS delay on a
single FC link.  You will get a speed-of-light in a fibre (or twinax)
+ some small overhead type delay.

When you are in TCP, YES, you need enough buffering to cover the
bandwidth * delay of the entire TCP connection.  If THAT has a 200 MS
RTT and a bandwidth of 10 Gbits/s, you need 200 MB of buffering
(analogous to FC credits) in the FCIP gateways to `guarantee' it works
at line rate under ideal circumstances.  The FCP HBAs do not need 200
MB worth of BB credits.  For the HBA's first hop FC link, a number
like Tachyon's 4 BB credits is more than enough.

> And the number-of-SCSI commans/R2Ts/Data in flow has to be also
> large to fill the pipe.

Julian makes the vastly more important point here.  This applies no
matter WHAT the link technology.

Even if you have flow control buffering to saturate your links at 10
Gb/s * 200 MS, most file systems don't generate nearly enough
concurrent demand (e.g. 200 MB of total outstanding transfers AT ALL
TIMES in this case), to maintain performance at this bandwidth *
delay.

You can sing the aggregation song in this case, though.  Each client
may only generate O(10 MB) of concurrent demand, but if you have 20
clients, you could fully use your 10 Gb/s * 200 MS.

Even though present hosts may not be tuned for the next bandwidth *
delay step, that's never been a reason not to take the step.  The
single-stream performance of FCP @ > 10 km was pretty lackluster
initially on many platforms.  Make sure you appropriately calibrate
your initial expecations on FCIP.

Steph


From owner-ips@ece.cmu.edu  Thu Aug  9 07:29:41 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21011
	for <ips-archive@odin.ietf.org>; Thu, 9 Aug 2001 07:29:40 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f79ACZd13151
	for ips-outgoing; Thu, 9 Aug 2001 06:12:35 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f79ACXe13146
	for <ips@ece.cmu.edu>; Thu, 9 Aug 2001 06:12:34 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id MAA257530
	for <ips@ece.cmu.edu>; Thu, 9 Aug 2001 12:12:23 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f79ACMT112854
	for <ips@ece.cmu.edu>; Thu, 9 Aug 2001 12:12:23 +0200
Importance: Normal
Subject: Re: iSCSI: draft 7: Final bit in Data PDUs
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF241DBA3F.B0A1504A-ONC2256AA3.0037F498@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Thu, 9 Aug 2001 13:11:34 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 09/08/2001 13:12:22
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Yes. Julo

Rishabh Srivastav <rishabh_srivastav@yahoo.com> on 08-08-2001 20:48:40

Please respond to Rishabh Srivastav <rishabh_srivastav@yahoo.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:
Subject:  Re: iSCSI: draft 7: Final bit in Data PDUs



which means, there can even be a case of consecutive
sequences of Data-in PDUs,
with each sequence consisting of 1 PDU with F bit set.
is it so ?

-rishabh

Julian Satran wrote:

  Elliot,

  Thanks .  Will change 2.7.1 to read:

  1.1.1     F (Final) Bit

     For outgoing data, this bit is 1 for the last PDU
of unsolicited data or
     the last PDU of a sequence answering a R2T.

     For incoming data, this bit is 1 for the last
input (read) data PDU of a
     sequence.  Input can be split in several
sequences each one having it's
     own F bit. Splitting in sequences does not affect
DataSN counting on
     Data-IN PDUs but MAY be used as a "change
direction" indication for
     Bidirectional operations that need such a change
and/or end of
     recoverable sequences by targets with a limited
replay buffer.

     For Bidirectional operations, the F bit is 1 both
for the end of the
     input sequences as well as the end of the output
sequences.

   Comments?

   Julo

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/





From owner-ips@ece.cmu.edu  Thu Aug  9 12:00:12 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28471
	for <ips-archive@odin.ietf.org>; Thu, 9 Aug 2001 12:00:12 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f79F4Hi25077
	for ips-outgoing; Thu, 9 Aug 2001 11:04:17 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f79F4Ge25072
	for <ips@ece.cmu.edu>; Thu, 9 Aug 2001 11:04:16 -0400 (EDT)
Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA26238; Thu, 9 Aug 2001 11:04:03 -0400 (EDT)
Message-ID: <3B72A4E8.839D0D1E@cisco.com>
Date: Thu, 09 Aug 2001 09:57:44 -0500
From: Mark Bakke <mbakke@cisco.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686)
X-Accept-Language: en, de
MIME-Version: 1.0
To: Julian Satran <julian_satran@il.ibm.com>, IPS <ips@ece.cmu.edu>
Subject: iSCSI: DataOrder and DataDeliveryOrder
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


Julian-

Another possible dependency in the negotiated parameters.

Are DataOrder and DataDeliveryOrder independent?

Can we have DataOder=true and DataDeliverOrder=false?

If not, we could combine them into:

  DataOrder=<strict | sequence | none>

or something like that.

Any thoughts?

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054


From owner-ips@ece.cmu.edu  Thu Aug  9 12:01:50 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28610
	for <ips-archive@odin.ietf.org>; Thu, 9 Aug 2001 12:01:50 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f79FSSE29330
	for ips-outgoing; Thu, 9 Aug 2001 11:28:28 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from va2mc.ummailbox.net (va2mc.ummailbox.net [64.210.247.16])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f79FSQe29324
	for <ips@ece.cmu.edu>; Thu, 9 Aug 2001 11:28:26 -0400 (EDT)
Received: from hqmailweb.COMMSTOR.Crossroads.com (HQMailWeb.Crossroads.com [63.237.99.250:25])
	by va2mc.ummailbox.net with ESMTP id G0809-1127-652900;
	Thu, 9 Aug 2001 15:27:57 GMT
Received: from HQMAILNODE1.COMMSTOR.Crossroads.com ([10.5.1.42]) by hqmailweb.COMMSTOR.Crossroads.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 9 Aug 2001 10:27:56 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
Subject: RE: Review of the 07 draft
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Thu, 9 Aug 2001 10:27:56 -0500
Message-ID: <CFD808D1D39ACB47ABFF586D484CC52E261E4D@HQMAILNODE1.COMMSTOR.Crossroads.com>
Thread-Topic: Review of the 07 draft
Thread-Index: AcEd0YQEiMImcs8pRNC6GEp7VciaUwArrVcw
From: "Robert Griswold" <rgriswold@Crossroads.com>
To: "Julian Satran" <Julian_Satran@il.ibm.com>
Cc: "Bill Moody" <bmoody@Crossroads.com>, <ips@ece.cmu.edu>
X-OriginalArrivalTime: 09 Aug 2001 15:27:56.0618 (UTC) FILETIME=[DD5872A0:01C120E7]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f79FSQe29327
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit

Julian:

Thanks, responses in line...

Bob

Robert Griswold
Technologist
Crossroads Systems, Inc.
512-928-7272

From: 	Julian Satran [mailto:Julian_Satran@il.ibm.com] 
Sent:	Sunday, August 05, 2001 9:52 AM
To:	Robert Griswold
Subject:	Re: Review of the 07 draft


Robert,

Thanks for you kind opening and for taking the time to read it.
Comments in text.

Julo

"Robert Griswold" <rgriswold@crossroads.com> on 03-08-2001 22:33:56

To:   Julian Satran/Haifa/IBM@IBMIL
Subject:  Review of the 07 draft



Julian:

First, great work on this initiative and please forgive my huge email.

...

++++++++++

Section 1.2.2.1 (and others):
...

+++ This point has a long history remains of which you can find in the
mail
archives.  I and several other authors where inclined to "silently
discard"
whatever can't be repaired (e.g., bugs in the initiator, delayed packets
or
packets arriving late) and explicitly reject only what can be repaired.
Debugging ease can be achieved by other means (event logs etc.). However
many of our colleagues on the list wanted error rejects to be explicit
whenever it is feasible and that is what you have now except for the
cases
in which discards are due to a "legitimate packet" arriving late (e.g.,
from a previous transmission attempt that is already recovered).
Discards are also better in preventing DOS attacks by stream replay++++

[Bob Griswold]  Thanks, that is good clarification.  Again, while I
realize there may have been a lot of history on some of these comments,
having the evolution of the thinking helps.

Section 1.2.5:
...

+++ We envisioned TTTs to be used by the target to identify parts of the
data stream that arrive in response of an R2T. Additionally they
identify
NOP-Outs that are sent in response to a polling Nop-IN and in general
when
valid indicate that the target expects something and identify the
response
(link it to the "cause") for the target. We mentioned that the protocol
does not care about the value mainly to stress that, unlike ITT, the
protocol has no uniqueness requirement for them and whenever they appear
the LUN is also present and can serve as an additional differentiator.
++++

[Bob Griswold]  This will help in understanding what TTTs will be used
for.


Section 1.2.6
...

+++ Logout has also history. We started without a logout but realized
soon
that we will need a synchronized logout to enable command allegiance
change
for recovery (that is possible only after logout). Besides it is a
simple
and painless way to do a clean shutdown of a connection. As for a target
only logout that is what the Asynch Message does (after some timeouts)
Please keep in mind that there is also a fine interplay between logout
and
recovery and that both initiator and target may decide to start some
recovery action+++

[Bob Griswold]  I see the need for the logout to be as quick and as
clean as possible.  If one assumes the Initiator and Target have agreed
on some form of possible recovery scenario, then having the target spend
cycles trying to deliver some recovery information in response to a
Logout seems reasonable; but I am not confident divergent iSCSI
platforms could come to such an agreement, short of it being defined in
one of the iSCSI specifications.


Section 1.2.7
...

+++ This is getting thrown out (it is already) considering that T10 has
gone a long way to expand the addressing of third party command source
and
destinatiantion +++

[Bob Griswold]  This is good news...



This model assumes that the iSCSI layer will deliver complete PDUs to
underlying layers in single (atomic) operations.  The underlying layer
doe
not need to examine the stream content to discover the PDU boundaries.

But please note that this whole sectionmight go away :-)

[Bob Griswold]  OK.


++++

The rest of this section uses the word MUST a few times in the
description of actions or implementation assumptions.  While the use of
the word MUST may make complete sense to the topic, and the points they
are being applied to, it seems out of place for an optional layer of the
model.  If the Synch and Steering layer is truly optional, then how can
the specification make claims to what MUST happen?

+++ it says that IF you doit that MUST be the way to do it ++++

[Bob Griswold]  My main concern is over the ability to have this
specification define implementations of internal "sync and steering" for
different host implementations.  Certainly the IETF should define the
right method for on-the-wire communication between two systems that are
implementing such layers, wherever that communication may exist, but
internal implementations for iSCSI drivers, and how they handle these
"sync and steering" delivered PDUs seems out of place.  Assuming each OS
needs its separate driver base, separate assumptions and separate
legacies, there will be very little hope for having these PDUs
delivered, internally in divergent operating systems, in the exact same
manner.  Have I made these comments clearer, or just confused it more?


Section 2.2.2
The definition of the AHS (see below, 2.2.3.1) seems to be covered as a
global PDU property, but only op-code 0x01 (SCSI Command) seems to make
use of it.  Since the AHS seems to be only needed to encapsulate an
extended CDB, then why define its possible existence for all PDUs?  Can
the AHS be used in other commands?
+++ There is another one - BiDirectional command fields. +++

[Bob Griswold]  Sorry, emphases on the wrong point here, my fault.  The
use of the AHS is only for iSCSI PDU op-code 0x01, but is defined under
section 2.2 (granted, optional) as a part of the general iSCSI PDU
format.  Since the AHS is only used for a SCSI Command, should it be
defined only under this instance, or is there some future use of the AHS
envisioned?  This comment borderlines on just editorial, and for
education for me.

Section 2.2.2.7
...

+++ I've changed it to:

1.1.1.1   LUN

   Some opcodes operate on a specific Logical Unit. The Logical Unit
Number
   (LUN) field identifies which Logical Unit.  If the opcode does not
   relate to a Logical Unit, this field either is ignored or may be used
in
   an opcode specific way.  The LUN field is 64-bits and it is to be
   formatted in accordance with [SAM2].

 ++++

[Bob Griswold]  Great, that helps a lot.

Section 2.2.3.1
The inclusion of a bit that identifies if the CDB is extended should not
live in an optional header.  Expecting that all implementations would
correctly code the use of an optional header to return critical data
that should be identified with the required portion of the CDB seems out
of place.  We would suggest that the use of a reserved bit or a bit in a
reserved byte be used, from the BHS, be used to identify an extended
CDB.  Putting the spillover of the CDB into the AHS (section 2.3.6) is
not an issue, but flagging if there is spillover should not be in the
AHS.

+++ That must be a "misreading" - We are talking about a coded field one
of
the values is Extended CDB. The whole code is the AHSType.  And if you
have
an extended CDB this header is not optional - it is the way to code the
extended CDB (no other way is decribed)
++++

[Bob Griswold]  I am clear on the fact that the Extended CDB bit is in
the AHSType field; I am assuming that you are referring to section 2.3.6
when you say the header is not optional.  Can a developer assume that if
a SCSI Command PDU is received, and the TotalAHSLength has a correctly
formatted value, that there either must be an Extended CDB AHS, or
Bi-directional AHS present?  This may be sufficient to alert from inside
of the required header that the additional header exists.


Section 2.5.1
...

+++ I can refer to some "opaque" management structure instead of MIB

[Bob Griswold]  Sounds good.

As for not  returning anything this is acceptable for Target Cold Reset
-
where the TCP connections are teared down but not for those that leave
the
connections standing +++

[Bob Griswold]  I have reread this comment, but cannot understand what
you are saying.

Section 2.8.5
...

+++ We think that hex will be the preferred encoding used but sometimes
people will copy decimal numbers. Once you have to have a decimal
conversion routine it makes little sense to force hexadecimal only by
dictate
+++

[Bob Griswold]  Well, if you assume that someone somewhere will have to
do the conversion of decimal to hex, then the burden has to live
somewhere, right?  If the wire is going to be exposed to two different
encoding schemes, then how is a lowly target going to know if its
getting decimal or hex values?  Will there be some marker, key=value
system, or something that will allow the receiver of an ambiguous data
type to know what it is getting?

Section 2.9.5
..

+++ It is not a MUST but it was thought by many (with some vehemence) as
helping matching.  IMHO it has no meaning and would suggest removing it.
+++

[Bob Griswold]  Agreed, there is no reason the same folks couldn't drive
a great "best-practices" RFC, or some SNIA document that could be used
by the industry developers to make life easier.  The out-of-order
key=value issue will never go away, but keeping code efficient is always
good.

Section 2.10.1
...

+++ The text only says that if you are going to support connection
recovery
you should be able to support opening a second connection in order to
clean
the first connection and close it. It also explicitly says that you
don't
have to support 2 connections in full feature phase. And even on 2 TCP
connections it is just a recommendation - using IP-over-pidgeons can be
an
good alternative for forcing a TCP connection to close. On a more
serious
note the second TCP connection can be on the same physical connection.
+++

[Bob Griswold]  Thanks for the explanation, and the great visual.

Section 2.12.4
If the limit of reflected data is 4096 bytes, then the instruction to
the initiator should not be "avoid sending", it should be "MUST NOT"
send more than 4096 bytes.  Is there a reason why the initiator would
want to send more than those number of bytes?

+++ The implications of saying MUST NOT would be that the target has to
check and to reject with a format error. We don't want this do we? +++

[Bob Griswold]  Since the implications of ping data escape me (sorry,
just a storage guy so pinging is something I don't understand) I
probably need to defer this to the networking thinkers.  I just hate to
have language in a specification that allows the receiver of what should
be a field overrun to do whatever it sees fit.  Can you give a two
sentence explanation on what the target would do with ping data that is
truncated, and what the initiator would expect to see in such a case?


Section 2.16
The last sentence in this section seems at odds with good error
detection for targets, and at odds with section 2.19.1.  If a SNACK
received has and error, whether or not it was a miss-directed PDU, or a
transit error, why would a target just silently ignore it?  Should it
use the SNACK Rejected code of the Reject response, or at least tell the
initiator something?  Besides, the use of the word "must" seems
inconsistent with what this sentence is trying to say.  If there is a
good reason for a target to ignore this, then it should be mentioned,
and the directive should be "MUST" if the expectations of the initiator
are set that way.

+++ A SNACK that is not supported is answered either by an Asynch
Message
asking logout - for failover - or total silence - in which case we
assume
SCSI will timeout and do its thing (abort, reissue the command or
whatever
neded.
There no need to answer. A badly formed SNACK is rejected as any othe
badly
formed PDU (although even this is perceived by some as excessive when it
does not help the initiator take repair action).
++++

[Bob Griswold]  Well, I will continue to say that a target that provides
no information on a received packet of information that is part of a
SCSI transfer is not a great target.  If some well-intentioned initiator
keeps sending what it believes to be valid PDUs, but appears to the
target to be invalid, then where and how does the initiator learn about
what is going on at the target level?

Section 2.16.1
...
+++ The target should request logout if it supports connection recovery
but
not
data snack +++

[Bob Griswold]  So is that information (supporting recovery but no data
snack) inclusive in the discovery information?


Section 4.2
...

+++ I think we can leave this to be implementation dependent. If I would
have to chose a "way out" would say limited number of text exchanges
rather
than a timeout.  ++++

[Bob Griswold]  OK, then can that be defined, or should that also be
left for implementation?


Section 7.1c
This description of the use of the Retry bit seems to put the onus of
interpretation of the Retry bit on the target for command replay.  Is it
at all possible for a Replay request to get issued, within the scope of
an initiator delaying its acknowledgement, such that the command
actually did get completed, but the Retry bit was set too soon?  Would
one assume that an initiator just avoids doing something like this?

+++ I will come back to this later. +++

[Bob Griswold]  Great, I am looking forward to it.

Section 7.6
...
+++ It is not defined here - it is assumed that when we let SCSI
commands
dry out (drop data packets, status etc.) the SCSI drivers will recover
after a timeout and do some cleanup +++

[Bob Griswold]  OK, but can ULP still be defined as an acronym for this
document?


Thanks,
Bob

Robert Griswold
Technologist
Crossroads Systems, Inc.
512-928-7272








From owner-ips@ece.cmu.edu  Thu Aug  9 12:10:21 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28852
	for <ips-archive@odin.ietf.org>; Thu, 9 Aug 2001 12:10:21 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f79Etjk24610
	for ips-outgoing; Thu, 9 Aug 2001 10:55:45 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f79Etie24604
	for <ips@ece.cmu.edu>; Thu, 9 Aug 2001 10:55:44 -0400 (EDT)
Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA16853; Thu, 9 Aug 2001 10:55:30 -0400 (EDT)
Message-ID: <3B72A2E7.4435316A@cisco.com>
Date: Thu, 09 Aug 2001 09:49:11 -0500
From: Mark Bakke <mbakke@cisco.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686)
X-Accept-Language: en, de
MIME-Version: 1.0
To: Julian Satran <julian_satran@il.ibm.com>, IPS <ips@ece.cmu.edu>
Subject: iSCSI: R2T and Bidi R2T
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Julian-

I received some comments on the iSCSI MIB about the fact
that if InitialR2T and BidiInitialR2T are not independent,
then they should be combined into the same variable instead
of negotiated separately.

Since we don't do anything with bi-directional data right
now, I hadn't looked at this before, but is it possible
to have InitialR2T=yes with BidiInitialR2T=no?  If not,
then we should probably combine them into:

InitialR2T=<all|bidi-only|none>

or something like that.

Any thoughts?  Is there someone out there planning to use the
Bidi stuff who can comment?

Thanks,


-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054


From owner-ips@ece.cmu.edu  Thu Aug  9 13:43:05 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01322
	for <ips-archive@odin.ietf.org>; Thu, 9 Aug 2001 13:43:05 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f79Gftk03406
	for ips-outgoing; Thu, 9 Aug 2001 12:41:55 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f79Gfqe03400
	for <ips@ece.cmu.edu>; Thu, 9 Aug 2001 12:41:53 -0400 (EDT)
Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190])
	by atlrel1.hp.com (Postfix) with ESMTP
	id 1A09AB9B; Thu,  9 Aug 2001 12:41:52 -0400 (EDT)
Received: from xatlbh1.atl.hp.com (xatlbh1.atl.hp.com [15.45.89.186])
	by xatlrelay1.atl.hp.com (Postfix) with ESMTP
	id 019911F52F; Thu,  9 Aug 2001 12:41:52 -0400 (EDT)
Received: by xatlbh1.atl.hp.com with Internet Mail Service (5.5.2653.19)
	id <Q3W5P15H>; Thu, 9 Aug 2001 12:41:51 -0400
Message-ID: <6BD67FFB937FD411A04F00D0B74FE87802A09241@xrose06.rose.hp.com>
From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
To: "'John Hufferd'" <hufferd@us.ibm.com>, ips@ece.cmu.edu
Subject: RE: iSCSI: Support Alias in the protocol 
Date: Thu, 9 Aug 2001 12:41:50 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Well, this interpretation of events is a bit skewed: 

> -----Original Message-----
> From: John Hufferd [mailto:hufferd@us.ibm.com]
> Sent: Tuesday, August 07, 2001 9:52 AM
> To: ips@ece.cmu.edu
> Subject: iSCSI: Support Alias in the protocol 
> 
> 
> Today at the 51st meeting of the IETF, I presented an issue that came out
> of the Naming and Discovery Team.

Didn't come out of NDT, I raised it on the IPS list.

> 
> That was that some members of the team did not understand why we needed to
> have an Alias field, which is in the base protocol today, since it was
> technically not needed.   

There is no question of "not understanding" anything, the statement of fact
is that this is not used by the protocol, not necessary to the protocol
function, and therefore should be deleted.  I can think of all sorts of
things that "it would be nice for the protocol to do", can I add them all?
It would be nice, for instance, to have a color text command, that would
cause the display on the device to turn a different color - shall we add
that?  Where do you draw the line? ;-)

>The position I presented to the  group was that
> the Naming and Discovery Team did not have consensus, since 
> many of us felt that having a Human oriented "Tagging" function was useful

Many?  Most didn't care!!  A few thought it would "be nice" but agreed it
was not used by the protocol.
 
..snip..
> One person, at the meeting today, stated that it might not be of extreme
> importance on large Networks with sophisticated Management tools, but it
> was very useful in small to medium environments, where the Management
tools
> were slim.  

But it requires a management tool for the alias information to be displayed
to the user.  Does it make a mgmt tool "sophisticated" to add a text label
of it's own to iSCSI target names?  I think not ;-)
  
> As the conversations when on, it was pointed out by the area director,
> Scott  Bradner, that SLP used a similar Text field in its protocol, so
> there was clearly a president.

This statement is incorrect. Scott made a reference to the fact that *SNMP*
carries this sort of information (mgmt information!).  There is no known
*precident* for this sort of field in a protocol.  Even if you find a
precident, it doesn't mean it's a smart thing to do.

We have been discussing simplifying the protocol.  Deleting this command
doesn't represent a huge simplification, but retaining it on the basis that
"it is nice" is not logical.  The point is where do you draw the line
regarding protocol commands?  Shall we add more "nice to have" things, even
though they aren't used by the protocol but provide some sort of mgmt
function?  Didn't we already go thru this discussion regarding the
SendTargets command?  Let's at least try to be consistant.

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: marjorie_krueger@hp.com 


From owner-ips@ece.cmu.edu  Thu Aug  9 14:48:03 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02766
	for <ips-archive@odin.ietf.org>; Thu, 9 Aug 2001 14:47:58 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f79HYEU05946
	for ips-outgoing; Thu, 9 Aug 2001 13:34:14 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f79HY8e05936
	for <ips@ece.cmu.edu>; Thu, 9 Aug 2001 13:34:09 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id TAA223144
	for <ips@ece.cmu.edu>; Thu, 9 Aug 2001 19:33:55 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f79HXtL86506
	for <ips@ece.cmu.edu>; Thu, 9 Aug 2001 19:33:55 +0200
Importance: Normal
Subject: iSCSI - Response/Status
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF8AB8A639.A6A97AAF-ONC2256AA3.005FF72C@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Thu, 9 Aug 2001 20:33:36 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 09/08/2001 20:33:55
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

According to the discusions on the list 2.4.2 & 2.4.3 have been fixed to
read:

1.1.1     Status

   The Status field is used to report the SCSI status of the command (as
   specified in [SAM2]) and is valid only if the Response Code is Command
   Completed at target.

   If a SCSI device error is detected while data from the initiator is
   still expected (the command PDU did not contain all the data and the
   target has not received a Data PDU with the final bit Set) the target
   MUST wait until it receives the a Data PDU with the F bit set, in the
   last expected sequence, before sending the Response PDU.

1.1.2     Response

   This field contains iSCSI service response.

   Valid iSCSI service response codes are:

      0x00 - Command Completed at Target
      0x01 - Target Failure
      0x02 - Delivery Subsystem Failure
      0x80-0xff - Reserved for Vendor-Unique Responses

   The Response is used to report a Service Response. The exact mapping of
   the iSCSI response codes to SAM service response symbols is outside the
   scope of this document.

   Certain iSCSI conditions result in the command being terminated at the
   target (response Command Completed at Target) with a SCSI Check
   Condition Status as outlined in the next table:

   +------------------------------+---------------------------+
   | Reason                       | with SCSI CHECK CONDITION |
   +------------------------------+---------------------------+
   | Unsolicited data rejected    | ASC = 0x49 ASCQ = 0x00    |
   +------------------------------+---------------------------+
   | Not enough unsolicited       | ASC = 0x4B ASCQ = 0x00    |
   +------------------------------+---------------------------+
   | SNACK rejected               | ASC = 0x47 ASCQ = 0x03    |
   +------------------------------+---------------------------+

   N.B. Unsolicited data rejected condition is reported used by the target
   only if it does not support output (write) operations in which the total
   data length is higher than FirstBurstSize but the initiator sent less
   than first burst size and out-of-order R2Ts can't be used.

   Julo



From owner-ips@ece.cmu.edu  Thu Aug  9 16:06:39 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04371
	for <ips-archive@odin.ietf.org>; Thu, 9 Aug 2001 16:06:38 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f79J8bn10506
	for ips-outgoing; Thu, 9 Aug 2001 15:08:37 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from hotmail.com (oe36.law11.hotmail.com [64.4.16.93])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f79J8Ze10502
	for <ips@ece.cmu.edu>; Thu, 9 Aug 2001 15:08:35 -0400 (EDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 9 Aug 2001 12:08:29 -0700
X-Originating-IP: [66.31.75.202]
From: "Eddy Quicksall" <ESQuicksall@hotmail.com>
To: "Robert Griswold" <rgriswold@Crossroads.com>,
        "Jim Hafner" <hafner@almaden.ibm.com>
Cc: <ips@ece.cmu.edu>
References: <OF4052726A.3C7AF210-ON88256A9D.0074339D@boulder.ibm.com>
Subject: Re: Review of the 07 draft
Date: Thu, 9 Aug 2001 15:07:47 -0400
MIME-Version: 1.0
Content-Type: text/plain;	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Message-ID: <OE36oVexDAeys8FSA4A00003d27@hotmail.com>
X-OriginalArrivalTime: 09 Aug 2001 19:08:29.0078 (UTC) FILETIME=[AC819B60:01C12106]
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

I don't like the idea of not letting a user of a SCSI utility be able to
change some of the parameters for iSCSI. Because they may be relevant to him
and there may not be a user interface to the iSCSI driver. pSCSI sets these
low level parameters via a standard mode set, so why not iSCSI?

It would be best if we could work out something where only the SCSI layer
can set the mode pages. That would solve everything.

Eddy

----- Original Message -----
From: "Jim Hafner" <hafner@almaden.ibm.com>
To: "Robert Griswold" <rgriswold@Crossroads.com>
Cc: <ips@ece.cmu.edu>
Sent: Friday, August 03, 2001 5:26 PM
Subject: Re: Review of the 07 draft

> Well, in fact, the draft is supposed to say that MODE_SELECT for the
> transport-specific mode page will NOT be done via SCSI, only via Text
> commands.  I read that as saying that from the SCSI layer, all fields in
> these pages are "unchangeable" (even though they can change in the iSCSI
> layer).  Of course, the draft doesn't say whether MODE PARAMETERS HAVE
> CHANGED unit attentions get thrown up at the SCSI layer when this happens
> at the iSCSI layer.... You later have a clarifying question (Section 3) on
> this as well.
>
> Regards,
> Jim Hafner
>
>
>
>


From owner-ips@ece.cmu.edu  Thu Aug  9 16:10:13 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04474
	for <ips-archive@odin.ietf.org>; Thu, 9 Aug 2001 16:10:13 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f79JGqT10946
	for ips-outgoing; Thu, 9 Aug 2001 15:16:52 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from hotmail.com (oe76.law11.hotmail.com [64.4.16.211])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f79JGne10930
	for <ips@ece.cmu.edu>; Thu, 9 Aug 2001 15:16:49 -0400 (EDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 9 Aug 2001 12:16:43 -0700
X-Originating-IP: [66.31.75.202]
From: "Eddy Quicksall" <ESQuicksall@hotmail.com>
To: "Julian Satran" <Julian_Satran@il.ibm.com>
Cc: <ips@ece.cmu.edu>
References: <OF8AB8A639.A6A97AAF-ONC2256AA3.005FF72C@telaviv.ibm.com>
Subject: Re: iSCSI - Response/Status
Date: Thu, 9 Aug 2001 15:16:50 -0400
MIME-Version: 1.0
Content-Type: text/plain;	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Message-ID: <OE76tyi67EKRuYDlrjb0000122d@hotmail.com>
X-OriginalArrivalTime: 09 Aug 2001 19:16:43.0350 (UTC) FILETIME=[D31D8760:01C12107]
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Can you list, in the table, which "iSCSI conditions" result in the Check
Condition?

Also, would it be useful to make it clear that the Status and Response
fields would both be set in this case?

Eddy
----- Original Message -----
From: "Julian Satran" <Julian_Satran@il.ibm.com>
To: <ips@ece.cmu.edu>
Sent: Thursday, August 09, 2001 1:33 PM
Subject: iSCSI - Response/Status


> According to the discusions on the list 2.4.2 & 2.4.3 have been fixed to
> read:
>
> 1.1.1     Status
>
>    The Status field is used to report the SCSI status of the command (as
>    specified in [SAM2]) and is valid only if the Response Code is Command
>    Completed at target.
>
>    If a SCSI device error is detected while data from the initiator is
>    still expected (the command PDU did not contain all the data and the
>    target has not received a Data PDU with the final bit Set) the target
>    MUST wait until it receives the a Data PDU with the F bit set, in the
>    last expected sequence, before sending the Response PDU.
>
> 1.1.2     Response
>
>    This field contains iSCSI service response.
>
>    Valid iSCSI service response codes are:
>
>       0x00 - Command Completed at Target
>       0x01 - Target Failure
>       0x02 - Delivery Subsystem Failure
>       0x80-0xff - Reserved for Vendor-Unique Responses
>
>    The Response is used to report a Service Response. The exact mapping of
>    the iSCSI response codes to SAM service response symbols is outside the
>    scope of this document.
>
>    Certain iSCSI conditions result in the command being terminated at the
>    target (response Command Completed at Target) with a SCSI Check
>    Condition Status as outlined in the next table:
>
>    +------------------------------+---------------------------+
>    | Reason                       | with SCSI CHECK CONDITION |
>    +------------------------------+---------------------------+
>    | Unsolicited data rejected    | ASC = 0x49 ASCQ = 0x00    |
>    +------------------------------+---------------------------+
>    | Not enough unsolicited       | ASC = 0x4B ASCQ = 0x00    |
>    +------------------------------+---------------------------+
>    | SNACK rejected               | ASC = 0x47 ASCQ = 0x03    |
>    +------------------------------+---------------------------+
>
>    N.B. Unsolicited data rejected condition is reported used by the target
>    only if it does not support output (write) operations in which the
total
>    data length is higher than FirstBurstSize but the initiator sent less
>    than first burst size and out-of-order R2Ts can't be used.
>
>    Julo
>
>


From owner-ips@ece.cmu.edu  Thu Aug  9 17:23:13 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05787
	for <ips-archive@odin.ietf.org>; Thu, 9 Aug 2001 17:23:12 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f79KPfR14331
	for ips-outgoing; Thu, 9 Aug 2001 16:25:41 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f79KPae14324
	for <ips@ece.cmu.edu>; Thu, 9 Aug 2001 16:25:38 -0400 (EDT)
Received: by ATLOPS with Internet Mail Service (5.5.2448.0)
	id <QMJCNCB0>; Thu, 9 Aug 2001 16:25:29 -0400
Message-ID: <25369470B6F0D41194820002B328BDD211621F@ATLOPS>
From: Sanjay Goyal <sanjay_goyal@ivivity.com>
To: ips@ece.cmu.edu
Cc: Sanjay Goyal <sanjay_goyal@ivivity.com>
Subject: CmdSN during login
Date: Thu, 9 Aug 2001 16:25:22 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Hi

 Assuming Target and Initiator support multiple connections and the session
is having multiple connection. Assuming out-of-order CmdSN is a possibility
for this session.

 Connection #	1	|	2	|	3
-------------------------------------------------------
Login Cmd  CmdSN=  0	|   CmdSN=8	|  CmdSN=9
Login Cmd  CmdSN=  0	|   CmdSN=8	|  CmdSN=9
Login Cmd  CmdSN=  0	|   CmdSN=8	|  CmdSN=9
Login Cmd  CmdSN=  0	|   CmdSN=8	|  CmdSN=9
Login Cmd  CmdSN=  0	|   CmdSN=8	|  CmdSN=9
Login Cmd  CmdSN=  0	|   CmdSN=8	|  CmdSN=9


From owner-ips@ece.cmu.edu  Thu Aug  9 17:24:40 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05815
	for <ips-archive@odin.ietf.org>; Thu, 9 Aug 2001 17:24:40 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f79KUxe14597
	for ips-outgoing; Thu, 9 Aug 2001 16:30:59 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e33.bld.us.ibm.com (e33.co.us.ibm.com [32.97.110.131])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f79KUwe14593
	for <ips@ece.cmu.edu>; Thu, 9 Aug 2001 16:30:58 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e33.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA10494;
	Thu, 9 Aug 2001 15:28:47 -0500
Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f79KUpG242038;
	Thu, 9 Aug 2001 14:30:51 -0600
X-Priority: 1 (High)
Importance: Normal
Subject: RE: iSCSI: Support Alias in the protocol
To: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
Cc: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OFF8F0585E.6817390A-ON88256AA3.006F47DC@boulder.ibm.com>
From: "John Hufferd" <hufferd@us.ibm.com>
Date: Thu, 9 Aug 2001 13:30:24 -0700
X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.6 |December 14, 2000) at
 08/09/2001 02:30:51 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Marjorie,
I did not intend to give a Skewed report.  Since you think I did, I
apologize.

I get so much e-mail I can not remember if you sent it to the list or to
the NDT team, if you say the list, fine, I am not sure it matters, since we
decided in the NDT for me to take it to the meeting in London.

Perhaps it was SNMP instead of SLP, OK, the precedent (see even I can
sometime get some spelling right) is there.  I know you do not think it
counts as much, and that is true, but it does count for something.

Your point that I think you are making -- that a Management tool to input
the Alias is needed so why not leave it up to the Management tool to handle
and remember the Alias etc. -- is perhaps over stated.  All of the
implementations that I am aware of, will have a way to input the Initiator
and Target iSCSI Node Names, etc.  This is really basic stuff, and not a
Tivoli or HP Open View type of management action, especially in small to
mid environments.  Having this basic tool also add the Alias stuff is not a
hard thing to assume.

It also makes since to have the Alias reflected in the MIB, and reported
via SNMP when something happens.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com


"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>@ece.cmu.edu
on 08/09/2001 09:41:50 AM

Sent by:  owner-ips@ece.cmu.edu


To:   John Hufferd/San Jose/IBM@IBMUS, ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: Support Alias in the protocol



Well, this interpretation of events is a bit skewed:

> -----Original Message-----
> From: John Hufferd [mailto:hufferd@us.ibm.com]
> Sent: Tuesday, August 07, 2001 9:52 AM
> To: ips@ece.cmu.edu
> Subject: iSCSI: Support Alias in the protocol
>
>
> Today at the 51st meeting of the IETF, I presented an issue that came out
> of the Naming and Discovery Team.

Didn't come out of NDT, I raised it on the IPS list.

>
> That was that some members of the team did not understand why we needed
to
> have an Alias field, which is in the base protocol today, since it was
> technically not needed.

There is no question of "not understanding" anything, the statement of fact
is that this is not used by the protocol, not necessary to the protocol
function, and therefore should be deleted.  I can think of all sorts of
things that "it would be nice for the protocol to do", can I add them all?
It would be nice, for instance, to have a color text command, that would
cause the display on the device to turn a different color - shall we add
that?  Where do you draw the line? ;-)

>The position I presented to the  group was that
> the Naming and Discovery Team did not have consensus, since
> many of us felt that having a Human oriented "Tagging" function was
useful

Many?  Most didn't care!!  A few thought it would "be nice" but agreed it
was not used by the protocol.

..snip..
> One person, at the meeting today, stated that it might not be of extreme
> importance on large Networks with sophisticated Management tools, but it
> was very useful in small to medium environments, where the Management
tools
> were slim.

But it requires a management tool for the alias information to be displayed
to the user.  Does it make a mgmt tool "sophisticated" to add a text label
of it's own to iSCSI target names?  I think not ;-)

> As the conversations when on, it was pointed out by the area director,
> Scott  Bradner, that SLP used a similar Text field in its protocol, so
> there was clearly a president.

This statement is incorrect. Scott made a reference to the fact that *SNMP*
carries this sort of information (mgmt information!).  There is no known
*precident* for this sort of field in a protocol.  Even if you find a
precident, it doesn't mean it's a smart thing to do.

We have been discussing simplifying the protocol.  Deleting this command
doesn't represent a huge simplification, but retaining it on the basis that
"it is nice" is not logical.  The point is where do you draw the line
regarding protocol commands?  Shall we add more "nice to have" things, even
though they aren't used by the protocol but provide some sort of mgmt
function?  Didn't we already go thru this discussion regarding the
SendTargets command?  Let's at least try to be consistant.

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: marjorie_krueger@hp.com





From owner-ips@ece.cmu.edu  Thu Aug  9 17:24:53 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05827
	for <ips-archive@odin.ietf.org>; Thu, 9 Aug 2001 17:24:53 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f79L20V16092
	for ips-outgoing; Thu, 9 Aug 2001 17:02:00 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f79L1te16079
	for <ips@ece.cmu.edu>; Thu, 9 Aug 2001 17:01:55 -0400 (EDT)
Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA09348; Thu, 9 Aug 2001 17:01:45 -0400 (EDT)
Message-ID: <3B72F8BD.7D2DD6FA@cisco.com>
Date: Thu, 09 Aug 2001 15:55:25 -0500
From: Mark Bakke <mbakke@cisco.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686)
X-Accept-Language: en, de
MIME-Version: 1.0
To: Sanjay Goyal <sanjay_goyal@ivivity.com>
CC: "Ips (E-mail)" <ips@ece.cmu.edu>
Subject: Re: CmdSN during login
References: <25369470B6F0D41194820002B328BDD2116220@ATLOPS>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


Sanjay-

I absolutely agree with this; CmdSN is owned by the session, and
should not be used until the connection has fully joined the session,
which means full feature phase.

This should also clean up any ambiguity on when to start
using CmdSN.

--
Mark

Sanjay Goyal wrote:
> 
> Hi
> 
>  Assuming Target and Initiator support multiple connections and the session
> is having multiple connections. Assuming out-of-order CmdSN is a possibility
> for this session.
> 
>  Connection #   1       |       2       |       3
> -------------------------------------------------------
> Login Cmd  CmdSN=0      |   CmdSN=8     |  CmdSN=9
> Txt   Cmd  CmdSN=1      |               |
>                                 |               |
>                                 |               |
> Login Cmd  CmdSN=7      |  CmdSN=10     |  CmdSN=11
> -------------------------------------------------------
> Data Cmd   CmdSN=12     | CmdSN=14      | CmdSN=15
> Data Cmd   CmdSN=13     |               |
>                                 |               |
> 
> CmdSN=7 is last of the Login sequence and it is acknowledged by the Target
> with "accept login" response.
> 
> Target would receive the PDUs in this CmdSN order
>  0 to 7, 8, 9, 12, 10, 11, 13, 14, 15
> 
> Now as Login and Text PDUs are being processed even though you have received
> Data Cmd PDUs, you can not pass them to iSCSI layer and hence you are adding
> latency.
> 
> What I want to convey from this example is why not use CmdSN just during the
> FullFeature phase only.
> 
> Regards
> Sanjay Goyal
> 
>   ----------------------------------------------------------------------------------------------------
> 
>    Part 1.2    Type: application/ms-tnef
>            Encoding: base64

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054


From owner-ips@ece.cmu.edu  Thu Aug  9 17:25:07 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05839
	for <ips-archive@odin.ietf.org>; Thu, 9 Aug 2001 17:25:07 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f79KZ7v14796
	for ips-outgoing; Thu, 9 Aug 2001 16:35:07 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f79KZ5e14791
	for <ips@ece.cmu.edu>; Thu, 9 Aug 2001 16:35:05 -0400 (EDT)
Received: by ATLOPS with Internet Mail Service (5.5.2448.0)
	id <QMJCNCCD>; Thu, 9 Aug 2001 16:34:59 -0400
Message-ID: <25369470B6F0D41194820002B328BDD2116220@ATLOPS>
From: Sanjay Goyal <sanjay_goyal@ivivity.com>
To: "Ips (E-mail)" <ips@ece.cmu.edu>
Cc: Sanjay Goyal <sanjay_goyal@ivivity.com>
Subject: CmdSN during login
Date: Thu, 9 Aug 2001 16:34:58 -0400 
X-MS-TNEF-Correlator: <25369470B6F0D41194820002B328BDD2116220@ATLOPS>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C12112.C270D24A"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C12112.C270D24A
Content-Type: text/plain;
	charset="iso-8859-1"

Hi

 Assuming Target and Initiator support multiple connections and the session
is having multiple connections. Assuming out-of-order CmdSN is a possibility
for this session.

 Connection #	1	|	2	|	3
-------------------------------------------------------
Login Cmd  CmdSN=0	|   CmdSN=8	|  CmdSN=9
Txt   Cmd  CmdSN=1	|    		|   
 				|    		|   
 				|   		|   
Login Cmd  CmdSN=7	|  CmdSN=10	|  CmdSN=11
-------------------------------------------------------
Data Cmd   CmdSN=12 	| CmdSN=14	| CmdSN=15
Data Cmd   CmdSN=13	|		|
				|		|

CmdSN=7 is last of the Login sequence and it is acknowledged by the Target
with "accept login" response.

Target would receive the PDUs in this CmdSN order
 0 to 7, 8, 9, 12, 10, 11, 13, 14, 15

Now as Login and Text PDUs are being processed even though you have received
Data Cmd PDUs, you can not pass them to iSCSI layer and hence you are adding
latency. 

What I want to convey from this example is why not use CmdSN just during the
FullFeature phase only.

Regards
Sanjay Goyal

------_=_NextPart_000_01C12112.C270D24A
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64

eJ8+IjwUAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQkABAACAAAAAAAAAAEIAAUABAAAAAAAAAAAAAEFgAMADgAAANEH
CAAJABAAIgA6AAQAWQEBIIADAA4AAADRBwgACQAQACIAOwAEAFoBAQmAAQAhAAAARUE2MjdDNkE2
NThBRDUxMTk0QjMwMDAyQjMyOEJERDIAHQcBBIABABMAAABDbWRTTiBkdXJpbmcgbG9naW4AlwYB
DYAEAAIAAAACAAIAAQOQBgAUCAAAMAAAAAMANgAAAAAAAwBbgAggBgAAAAAAwAAAAAAAAEYAAAAA
UoUAAH1uAQAeAFyACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAQAAAA5LjAACwCFgAggBgAA
AAAAwAAAAAAAAEYAAAAABoUAAAAAAAADAA6ACCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAAAAsA
EIAIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAACwARgAggBgAAAAAAwAAAAAAAAEYAAAAADoUA
AAAAAAADADeACCAGAAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAMAOIAIIAYAAAAAAMAAAAAAAABG
AAAAABGFAAAAAAAAAwA+gAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAACAQkQAQAAAD0DAAA5
AwAAEgYAAExaRnUTcJ6TAwAKAHJjcGcxMjXiMgNDdGV4BUEBAwH3/wqAAqQD5AcTAoAP8wBQBFY/
CFUHshElDlEDAQIAY2jhCsBzZXQyBgAGwxEl9jMERhO3MBIsETMI7wn3tjsYHw4wNREiDGBjAFAz
CwkBZDM2FlALpiBIPwCgCrEKhAqAEMAEEHVtUQuAZyBUCsBnFCAgUQBwZCBJAwB0BzB0EwWxHgBw
cBfBIG11JmwfUAtQZSAFoG5unwWQH1ACIAQgHuJ0aCCwVxQQBBAhQSAEACAT4HY3HjIgTyFRLh3Y
CGB0LRxvZiVQCyASgUNtZGRTTiKCYSAf8CIxYvMDEB9AeSACEAXAIdAikZ0iFS4dGwhQIPYgIwyC
9iAAUCoSfCoDDlAqeBUwfR0jLSxPLV8uby6hHRRMrG9nC4Al4iAl5D0BQLcqczCgMLU4MTYwxDkd
FP5UDtEwozCmKlUxkQMwKhL/MTcddTVINUw1PzZPOEs4P+sv/zEANzI8MTEnNDUa8+8sL0CfQa8v
WkQfcCaAMHOvNCYUQDE1NDU0RMw1Qy//NDUVMCp4KmUdJDmPSG8dR/c85SKCC2BzBUAlYCHDPDTl
FBBxClBuYyCwHuIfQEEmQ2Nrbm93IKBk+x6gHwBiJ0Ah0h51A/Ah0HwgIgDQTpAFMRewMDEi2iAY
IHMf8ACAZShrUKadCGBsHwAYIE6QaXYgsPEh0lBEVQQgMEEnoyX0DyWTHXUWUB+AIDcsILo4V4A5
V4AOIFfhMFfh6jFX4TNX4TRX4UaVHRS+Tk+gHtAEIDw0HuJUDsK3VTMKwCCwYlSgHkFwA2B3TpAE
EFABZVTAVZIIYGf9UUB5CGAisiCwVHUfAEcH91UyV4Bd0mMDkU+QBUAKsAsEESHRbVcyaVNDU/pJ
TQF5EoEe4iHgToJd0vFb0mFkZB4yC2AOsE6AdnkkcB0aVxPgBUBhsHf/AHAFQFdBINFUwCdBA2En
lJkOwGFtIJIikXdoJ0BtYGJ1FBAl5WpoQAVAZBcIcR5BIdJGI0BsRmV3H3AIcCCwcBPgaFECIGyj
ZCAdGlJlZwsRcx0UhQYRamHgIEdveQdABR0UfW4QAAAAHgBwAAEAAAAYAAAAaVNDU0kgLSBSZXNw
b25zZS9TdGF0dXMAAgFxAAEAAAAgAAAAAcEhA+s1anxiDoplEdWUswACsyi90gADPVCgAAAq/lAD
ACYAAAAAAAMALgAAAAAACwACAAEAAAALABcMAAAAAAMAXUAAAAAAAwAJWQEAAAADAN4/5AQAAEAA
OQDgFqbBEiHBAQMA8T8JBAAAHgAxQAEAAAAIAAAAU0FOSkFZRwADABpAAAAAAB4AMEABAAAACAAA
AFNBTkpBWUcAAwAZQAAAAAADAP0/5AQAAAMAgBD/////AgFHAAEAAAAuAAAAYz1VUzthPSA7cD1J
VklWSVRZO2w9QVRMT1BTLTAxMDgwOTIwMzQ1OFotNDk2AAAAAgH5PwEAAABKAAAAAAAAANynQMjA
QhAatLkIACsv4YIBAAAAAAAAAC9PPUlWSVZJVFkvT1U9QVRMT1BTL0NOPVJFQ0lQSUVOVFMvQ049
U0FOSkFZRwAAAB4A+D8BAAAADQAAAFNhbmpheSBHb3lhbAAAAAAeADhAAQAAAAgAAABTQU5KQVlH
AAIB+z8BAAAASgAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAAAAAAvTz1JVklWSVRZL09VPUFU
TE9QUy9DTj1SRUNJUElFTlRTL0NOPVNBTkpBWUcAAAAeAPo/AQAAAA0AAABTYW5qYXkgR295YWwA
AAAAHgA5QAEAAAAIAAAAU0FOSkFZRwBAAAcwou/GiREhwQFAAAgwStJwwhIhwQEeAD0AAQAAAAEA
AAAAAAAAHgAdDgEAAAATAAAAQ21kU04gZHVyaW5nIGxvZ2luAAAeADUQAQAAADAAAAA8MjUzNjk0
NzBCNkYwRDQxMTk0ODIwMDAyQjMyOEJERDIxMTYyMjBAQVRMT1BTPgALACkAAAAAAAsAIwAAAAAA
AwAGEOkiIH8DAAcQBQMAAAMAEBAAAAAAAwAREAAAAAAeAAgQAQAAAGUAAABISUFTU1VNSU5HVEFS
R0VUQU5ESU5JVElBVE9SU1VQUE9SVE1VTFRJUExFQ09OTkVDVElPTlNBTkRUSEVTRVNTSU9OSVNI
QVZJTkdNVUxUSVBMRUNPTk5FQ1RJT05TQVNTVU1JAAAAAAIBfwABAAAAMAAAADwyNTM2OTQ3MEI2
RjBENDExOTQ4MjAwMDJCMzI4QkREMjExNjIyMEBBVExPUFM+AMvT

------_=_NextPart_000_01C12112.C270D24A--


From owner-ips@ece.cmu.edu  Thu Aug  9 18:09:30 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05797
	for <ips-archive@odin.ietf.org>; Thu, 9 Aug 2001 17:23:20 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f79Kad614881
	for ips-outgoing; Thu, 9 Aug 2001 16:36:39 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from va2mc.ummailbox.net (va2mc.ummailbox.net [64.210.247.23])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f79Kabe14876
	for <ips@ece.cmu.edu>; Thu, 9 Aug 2001 16:36:37 -0400 (EDT)
Received: from hqmailweb.COMMSTOR.Crossroads.com (HQMailWeb.Crossroads.com [63.237.99.250:25])
	by va2mc.ummailbox.net with ESMTP id M0809-1636-48f600;
	Thu, 9 Aug 2001 20:36:15 GMT
Received: from HQMAILNODE1.COMMSTOR.Crossroads.com ([10.5.1.42]) by hqmailweb.COMMSTOR.Crossroads.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 9 Aug 2001 15:36:14 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
Subject: RE: Review of the 07 draft
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Thu, 9 Aug 2001 15:36:14 -0500
Message-ID: <CFD808D1D39ACB47ABFF586D484CC52E261E58@HQMAILNODE1.COMMSTOR.Crossroads.com>
Thread-Topic: Review of the 07 draft
Thread-Index: AcEhBrAeMT5ZTq/FSHeL4UAoGIJwcQAACS4Q
From: "Robert Griswold" <rgriswold@Crossroads.com>
To: "Eddy Quicksall" <ESQuicksall@hotmail.com>,
        "Jim Hafner" <hafner@almaden.ibm.com>
Cc: <ips@ece.cmu.edu>
X-OriginalArrivalTime: 09 Aug 2001 20:36:14.0588 (UTC) FILETIME=[EEFEABC0:01C12112]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f79Kabe14877
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit

Eddy:

I actually have no problem with all mode pages (SCSI and iSCSI) being
accessible and changeable from standard SCSI mode commands.  My initial
response to this section was to propose a method that would be
acceptable to the authors of the iSCSI draft.  If there is desire in the
group to allow mode pages for the entire target to be manipulated from
the SCSI level, I think that is a better idea that the one I proposed.
I would assume that an iSCSI aware SCSI utility would understand the
iSCSI specific settings, and allow the user to make those changes.  What
I am really against, is the ability to modify standard SCSI mode page
settings from text messages, as that could lead to target behavior
changes outside of the understanding of the SCSI nexus.  

To recap your thinking:  Allow iSCSI text messages to modify and read
iSCSI only mode settings (potentially allowing the reading if SCSI mode
settings), but allow SCSI mode commands to modify and read all target
mode settings, including iSCSI settings.  Is that what you are saying.
If so, I agree.

Bob

Robert Griswold
Technologist
Crossroads Systems, Inc.
512-928-7272

 -----Original Message-----
From: 	Eddy Quicksall [mailto:ESQuicksall@hotmail.com] 
Sent:	Thursday, August 09, 2001 2:08 PM
To:	Robert Griswold; Jim Hafner
Cc:	ips@ece.cmu.edu
Subject:	Re: Review of the 07 draft

I don't like the idea of not letting a user of a SCSI utility be able to
change some of the parameters for iSCSI. Because they may be relevant to
him
and there may not be a user interface to the iSCSI driver. pSCSI sets
these
low level parameters via a standard mode set, so why not iSCSI?

It would be best if we could work out something where only the SCSI
layer
can set the mode pages. That would solve everything.

Eddy

----- Original Message -----
From: "Jim Hafner" <hafner@almaden.ibm.com>
To: "Robert Griswold" <rgriswold@Crossroads.com>
Cc: <ips@ece.cmu.edu>
Sent: Friday, August 03, 2001 5:26 PM
Subject: Re: Review of the 07 draft

> Well, in fact, the draft is supposed to say that MODE_SELECT for the
> transport-specific mode page will NOT be done via SCSI, only via Text
> commands.  I read that as saying that from the SCSI layer, all fields
in
> these pages are "unchangeable" (even though they can change in the
iSCSI
> layer).  Of course, the draft doesn't say whether MODE PARAMETERS HAVE
> CHANGED unit attentions get thrown up at the SCSI layer when this
happens
> at the iSCSI layer.... You later have a clarifying question (Section
3) on
> this as well.
>
> Regards,
> Jim Hafner
>
>
>
>




From owner-ips@ece.cmu.edu  Thu Aug  9 18:17:15 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06548
	for <ips-archive@odin.ietf.org>; Thu, 9 Aug 2001 18:17:15 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f79LFGu16819
	for ips-outgoing; Thu, 9 Aug 2001 17:15:16 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from smtp.alacritech.com (smtp.alacritech.com [209.10.208.82])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f79LFDe16810
	for <ips@ece.cmu.edu>; Thu, 9 Aug 2001 17:15:13 -0400 (EDT)
Received: from alacritech.com (woking.alacritech.com [10.1.1.70])
	by smtp.alacritech.com (8.11.0/8.11.0) with ESMTP id f79LBks17188;
	Thu, 9 Aug 2001 14:11:46 -0700
Message-ID: <3B72FD4B.4B7165F@alacritech.com>
Date: Thu, 09 Aug 2001 14:15:10 -0700
From: Steve Blightman <steve@alacritech.com>
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: sanjay_goyal@ivivity.com
CC: ips@ece.cmu.edu
Subject: Re: [Fwd: Crc-32c example in iSCSI spec]
References: <3B619FDE.FFB6BDCE@alacritech.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Sanjay -
Did you ever get any response to this email? - I have the same problem.  I
wonder if we can get whoever generated these examples to double check them &
respond.
Thanks for any help
Steve Blightman

>
> Subject: Crc-32c example in iSCSI spec
> Date: Fri, 27 Jul 2001 09:52:44 -0400
> From: Sanjay Goyal <sanjay_goyal@ivivity.com>
> To: ips@ece.cmu.edu
> CC: Sanjay Goyal <sanjay_goyal@ivivity.com>
>
> Hi
>  I tried matching the crc32c example results with mine for all ZEROs and all
> ONEs
>  the result for Zeros matches whereas it does not match for all Ones. My
> result instead of
>       21 44 df 1c
>             is
>       62 a8 ab 43
>
> Can somebody clarify me on the issue.
>
> Regards
> Sanjay Goyal



From owner-ips@ece.cmu.edu  Thu Aug  9 18:23:00 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06599
	for <ips-archive@odin.ietf.org>; Thu, 9 Aug 2001 18:23:00 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f79LJ8B17050
	for ips-outgoing; Thu, 9 Aug 2001 17:19:08 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f79LJ6e17046
	for <ips@ece.cmu.edu>; Thu, 9 Aug 2001 17:19:06 -0400 (EDT)
Received: by ATLOPS with Internet Mail Service (5.5.2448.0)
	id <QMJCNCCJ>; Thu, 9 Aug 2001 17:19:00 -0400
Message-ID: <25369470B6F0D41194820002B328BDD2116223@ATLOPS>
From: Sanjay Goyal <sanjay_goyal@ivivity.com>
To: "'Steve Blightman'" <steve@alacritech.com>,
        Sanjay Goyal
	 <sanjay_goyal@ivivity.com>
Cc: ips@ece.cmu.edu
Subject: RE: [Fwd: Crc-32c example in iSCSI spec]
Date: Thu, 9 Aug 2001 17:18:55 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

No
I am still waiting for the answer.

Regards
Sanjay G


-----Original Message-----
From: Steve Blightman [mailto:steve@alacritech.com]
Sent: Thursday, August 09, 2001 5:15 PM
To: sanjay_goyal@ivivity.com
Cc: ips@ece.cmu.edu
Subject: Re: [Fwd: Crc-32c example in iSCSI spec]


Sanjay -
Did you ever get any response to this email? - I have the same problem.  I
wonder if we can get whoever generated these examples to double check them &
respond.
Thanks for any help
Steve Blightman

>
> Subject: Crc-32c example in iSCSI spec
> Date: Fri, 27 Jul 2001 09:52:44 -0400
> From: Sanjay Goyal <sanjay_goyal@ivivity.com>
> To: ips@ece.cmu.edu
> CC: Sanjay Goyal <sanjay_goyal@ivivity.com>
>
> Hi
>  I tried matching the crc32c example results with mine for all ZEROs and
all
> ONEs
>  the result for Zeros matches whereas it does not match for all Ones. My
> result instead of
>       21 44 df 1c
>             is
>       62 a8 ab 43
>
> Can somebody clarify me on the issue.
>
> Regards
> Sanjay Goyal


From owner-ips@ece.cmu.edu  Thu Aug  9 22:09:04 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09866
	for <ips-archive@odin.ietf.org>; Thu, 9 Aug 2001 22:09:03 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7A0SV024960
	for ips-outgoing; Thu, 9 Aug 2001 20:28:31 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from clyde.stargateip.com ([209.237.5.66])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7A0STe24955
	for <ips@ece.cmu.edu>; Thu, 9 Aug 2001 20:28:29 -0400 (EDT)
Received: from bluestar (dhcp-101.stargateip.com [10.10.5.101])
	by clyde.stargateip.com (8.9.1/8.9.1) with SMTP id RAA14404;
	Thu, 9 Aug 2001 17:22:43 -0700 (PDT)
Reply-To: <deva@stargateip.com>
From: "Dev" <deva@stargateip.com>
To: "Robert Griswold" <rgriswold@Crossroads.com>,
        "Eddy Quicksall" <ESQuicksall@hotmail.com>,
        "Jim Hafner" <hafner@almaden.ibm.com>
Cc: <ips@ece.cmu.edu>
Subject: RE: Review of the 07 draft
Date: Thu, 9 Aug 2001 17:32:44 -0700
Message-ID: <NFBBKBDFJCDMGCBKJLCJGEPBFCAA.deva@stargateip.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <CFD808D1D39ACB47ABFF586D484CC52E261E58@HQMAILNODE1.COMMSTOR.Crossroads.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Importance: Normal
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

All,

I tend to disagree. The parameters for the iSCSI are negotiated between the
initiator and target.
If we allow the parameters to be changed through SCSI Mode select, how will
this work?

If parameters can be changed through SCSI Mode select then it will apply
only to Lead only connections.

So, we'll have

a) two methods to change the Lead only parameters common for the entire
session (one through mode select
and the other through text parameters)
b) Just iSCSI text command to change the connection specific parameters.

Does it not add to complexity having multiple ways to change the same stuff?

Thanks

Deva
Platys communications

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Robert Griswold
Sent: Thursday, August 09, 2001 1:36 PM
To: Eddy Quicksall; Jim Hafner
Cc: ips@ece.cmu.edu
Subject: RE: Review of the 07 draft


Eddy:

I actually have no problem with all mode pages (SCSI and iSCSI) being
accessible and changeable from standard SCSI mode commands.  My initial
response to this section was to propose a method that would be
acceptable to the authors of the iSCSI draft.  If there is desire in the
group to allow mode pages for the entire target to be manipulated from
the SCSI level, I think that is a better idea that the one I proposed.
I would assume that an iSCSI aware SCSI utility would understand the
iSCSI specific settings, and allow the user to make those changes.  What
I am really against, is the ability to modify standard SCSI mode page
settings from text messages, as that could lead to target behavior
changes outside of the understanding of the SCSI nexus.

To recap your thinking:  Allow iSCSI text messages to modify and read
iSCSI only mode settings (potentially allowing the reading if SCSI mode
settings), but allow SCSI mode commands to modify and read all target
mode settings, including iSCSI settings.  Is that what you are saying.
If so, I agree.

Bob

Robert Griswold
Technologist
Crossroads Systems, Inc.
512-928-7272

 -----Original Message-----
From: 	Eddy Quicksall [mailto:ESQuicksall@hotmail.com]
Sent:	Thursday, August 09, 2001 2:08 PM
To:	Robert Griswold; Jim Hafner
Cc:	ips@ece.cmu.edu
Subject:	Re: Review of the 07 draft

I don't like the idea of not letting a user of a SCSI utility be able to
change some of the parameters for iSCSI. Because they may be relevant to
him
and there may not be a user interface to the iSCSI driver. pSCSI sets
these
low level parameters via a standard mode set, so why not iSCSI?

It would be best if we could work out something where only the SCSI
layer
can set the mode pages. That would solve everything.

Eddy

----- Original Message -----
From: "Jim Hafner" <hafner@almaden.ibm.com>
To: "Robert Griswold" <rgriswold@Crossroads.com>
Cc: <ips@ece.cmu.edu>
Sent: Friday, August 03, 2001 5:26 PM
Subject: Re: Review of the 07 draft

> Well, in fact, the draft is supposed to say that MODE_SELECT for the
> transport-specific mode page will NOT be done via SCSI, only via Text
> commands.  I read that as saying that from the SCSI layer, all fields
in
> these pages are "unchangeable" (even though they can change in the
iSCSI
> layer).  Of course, the draft doesn't say whether MODE PARAMETERS HAVE
> CHANGED unit attentions get thrown up at the SCSI layer when this
happens
> at the iSCSI layer.... You later have a clarifying question (Section
3) on
> this as well.
>
> Regards,
> Jim Hafner
>
>
>
>




From owner-ips@ece.cmu.edu  Fri Aug 10 03:01:38 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00009
	for <ips-archive@odin.ietf.org>; Fri, 10 Aug 2001 03:01:38 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7A5w1x03626
	for ips-outgoing; Fri, 10 Aug 2001 01:58:01 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7A5w0e03622
	for <ips@ece.cmu.edu>; Fri, 10 Aug 2001 01:58:00 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id HAA54398
	for <ips@ece.cmu.edu>; Fri, 10 Aug 2001 07:57:53 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7A5vrt26974
	for <ips@ece.cmu.edu>; Fri, 10 Aug 2001 07:57:53 +0200
Importance: Normal
Subject: Re: iSCSI: R2T and Bidi R2T
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFBA99ADA4.B4A3045A-ONC2256AA4.0020650A@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Fri, 10 Aug 2001 08:57:34 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 10/08/2001 08:57:52
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Mark,

I am not sure what the usage pattern will be. There are 2 different bits
for SCSI so they must have had a reason to keep them separate and I think
that so should we.

Julo

Mark Bakke <mbakke@cisco.com>@cisco.com on 09-08-2001 17:49:11

Please respond to Mark Bakke <mbakke@cisco.com>

Sent by:  mbakke@cisco.com


To:   Julian Satran/Haifa/IBM@IBMIL, IPS <ips@ece.cmu.edu>
cc:
Subject:  iSCSI: R2T and Bidi R2T



Julian-

I received some comments on the iSCSI MIB about the fact
that if InitialR2T and BidiInitialR2T are not independent,
then they should be combined into the same variable instead
of negotiated separately.

Since we don't do anything with bi-directional data right
now, I hadn't looked at this before, but is it possible
to have InitialR2T=yes with BidiInitialR2T=no?  If not,
then we should probably combine them into:

InitialR2T=<all|bidi-only|none>

or something like that.

Any thoughts?  Is there someone out there planning to use the
Bidi stuff who can comment?

Thanks,


--
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054





From owner-ips@ece.cmu.edu  Fri Aug 10 03:01:44 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00020
	for <ips-archive@odin.ietf.org>; Fri, 10 Aug 2001 03:01:44 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7A6bm204737
	for ips-outgoing; Fri, 10 Aug 2001 02:37:48 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7A6bde04726
	for <ips@ece.cmu.edu>; Fri, 10 Aug 2001 02:37:41 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id IAA142462
	for <ips@ece.cmu.edu>; Fri, 10 Aug 2001 08:37:31 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7A6bVt64458
	for <ips@ece.cmu.edu>; Fri, 10 Aug 2001 08:37:31 +0200
Importance: Normal
Subject: Re: iSCSI: DataOrder and DataDeliveryOrder
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFD33507CC.49FABCAA-ONC2256AA4.0020D251@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Fri, 10 Aug 2001 09:02:34 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 10/08/2001 09:37:30
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Those are independent (we have changed their names to better reflect what
they are doing to DataDeliveryOrder and DataSequenceOrder).

Julo



Mark Bakke <mbakke@cisco.com>@cisco.com on 09-08-2001 17:57:44

Please respond to Mark Bakke <mbakke@cisco.com>

Sent by:  mbakke@cisco.com


To:   Julian Satran/Haifa/IBM@IBMIL, IPS <ips@ece.cmu.edu>
cc:
Subject:  iSCSI: DataOrder and DataDeliveryOrder




Julian-

Another possible dependency in the negotiated parameters.

Are DataOrder and DataDeliveryOrder independent?

Can we have DataOder=true and DataDeliverOrder=false?

If not, we could combine them into:

  DataOrder=<strict | sequence | none>

or something like that.

Any thoughts?

--
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054





From owner-ips@ece.cmu.edu  Fri Aug 10 03:04:50 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00057
	for <ips-archive@odin.ietf.org>; Fri, 10 Aug 2001 03:04:50 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7A6bjl04732
	for ips-outgoing; Fri, 10 Aug 2001 02:37:45 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7A6bde04725
	for <ips@ece.cmu.edu>; Fri, 10 Aug 2001 02:37:39 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id IAA14988
	for <ips@ece.cmu.edu>; Fri, 10 Aug 2001 08:37:32 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7A6bVw108192
	for <ips@ece.cmu.edu>; Fri, 10 Aug 2001 08:37:31 +0200
Importance: Normal
Subject: RE: Review of the 07 draft
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF188DB4B3.2FCC1D53-ONC2256AA4.0021F108@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Fri, 10 Aug 2001 09:24:25 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 10/08/2001 09:37:31
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Robert,

Snippets and comments in text - Julo





Section 1.2.6
...

+++ Logout has also history. We started without a logout but realized
soon
that we will need a synchronized logout to enable command allegiance
change
for recovery (that is possible only after logout). Besides it is a
simple
and painless way to do a clean shutdown of a connection. As for a target
only logout that is what the Asynch Message does (after some timeouts)
Please keep in mind that there is also a fine interplay between logout
and
recovery and that both initiator and target may decide to start some
recovery action+++

[Bob Griswold]  I see the need for the logout to be as quick and as
clean as possible.  If one assumes the Initiator and Target have agreed
on some form of possible recovery scenario, then having the target spend
cycles trying to deliver some recovery information in response to a
Logout seems reasonable; but I am not confident divergent iSCSI
platforms could come to such an agreement, short of it being defined in
one of the iSCSI specifications.

>>>> Logout brings commands associted with the coonection in a state in
which they can change allegiance. This is specified in 7 and recovery
appendix <<<<<<






As for not  returning anything this is acceptable for Target Cold Reset
-
where the TCP connections are teared down but not for those that leave
the
connections standing +++

[Bob Griswold]  I have reread this comment, but cannot understand what
you are saying.

>>>> Cold reset tears down TCP connections <<<<

Section 2.8.5
...

+++ We think that hex will be the preferred encoding used but sometimes
people will copy decimal numbers. Once you have to have a decimal
conversion routine it makes little sense to force hexadecimal only by
dictate
+++

[Bob Griswold]  Well, if you assume that someone somewhere will have to
do the conversion of decimal to hex, then the burden has to live
somewhere, right?  If the wire is going to be exposed to two different
encoding schemes, then how is a lowly target going to know if its
getting decimal or hex values?  Will there be some marker, key=value
system, or something that will allow the receiver of an ambiguous data
type to know what it is getting?
>>>>> Syntat - Hexadecimal start with 0x <<<<<<<<


keeps sending what it believes to be valid PDUs, but appears to the
target to be invalid, then where and how does the initiator learn about
what is going on at the target level?

Section 2.16.1
...
+++ The target should request logout if it supports connection recovery
but
not
data snack +++

[Bob Griswold]  So is that information (supporting recovery but no data
snack) inclusive in the discovery information?

>>> That will be negotiated recovery level <<<<


Section 7.1c
This description of the use of the Retry bit seems to put the onus of
interpretation of the Retry bit on the target for command replay.  Is it
at all possible for a Replay request to get issued, within the scope of
an initiator delaying its acknowledgement, such that the command
actually did get completed, but the Retry bit was set too soon?  Would
one assume that an initiator just avoids doing something like this?

+++ I will come back to this later. +++

[Bob Griswold]  Great, I am looking forward to it.

>>> We will at tiny encoded field to say what the retry means in a day or
two <<<


Thanks,
Bob

Robert Griswold
Technologist
Crossroads Systems, Inc.
512-928-7272











From owner-ips@ece.cmu.edu  Fri Aug 10 03:10:29 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00169
	for <ips-archive@odin.ietf.org>; Fri, 10 Aug 2001 03:10:29 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7A6i3A04915
	for ips-outgoing; Fri, 10 Aug 2001 02:44:03 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7A6i0e04910
	for <ips@ece.cmu.edu>; Fri, 10 Aug 2001 02:44:00 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id IAA338464
	for <ips@ece.cmu.edu>; Fri, 10 Aug 2001 08:43:46 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7A6hjw168982
	for <ips@ece.cmu.edu>; Fri, 10 Aug 2001 08:43:45 +0200
Importance: Normal
Subject: Re: CmdSN during login
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFBA3A669B.57778046-ONC2256AA4.0024B676@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Fri, 10 Aug 2001 09:43:26 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 10/08/2001 09:43:44
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Sanjay,

If you want to ignore CmdSN and expedite Login processing you can do so by
having the commands being issued as immediate.
This will help us keep away from creating ambiguity about (or another
conditional) for when CmdSN is to be used or not.

Julo

Mark Bakke <mbakke@cisco.com>@ece.cmu.edu on 09-08-2001 23:55:25

Please respond to Mark Bakke <mbakke@cisco.com>

Sent by:  owner-ips@ece.cmu.edu


To:   Sanjay Goyal <sanjay_goyal@ivivity.com>
cc:   "Ips (E-mail)" <ips@ece.cmu.edu>
Subject:  Re: CmdSN during login




Sanjay-

I absolutely agree with this; CmdSN is owned by the session, and
should not be used until the connection has fully joined the session,
which means full feature phase.

This should also clean up any ambiguity on when to start
using CmdSN.

--
Mark

Sanjay Goyal wrote:
>
> Hi
>
>  Assuming Target and Initiator support multiple connections and the
session
> is having multiple connections. Assuming out-of-order CmdSN is a
possibility
> for this session.
>
>  Connection #   1       |       2       |       3
> -------------------------------------------------------
> Login Cmd  CmdSN=0      |   CmdSN=8     |  CmdSN=9
> Txt   Cmd  CmdSN=1      |               |
>                                 |               |
>                                 |               |
> Login Cmd  CmdSN=7      |  CmdSN=10     |  CmdSN=11
> -------------------------------------------------------
> Data Cmd   CmdSN=12     | CmdSN=14      | CmdSN=15
> Data Cmd   CmdSN=13     |               |
>                                 |               |
>
> CmdSN=7 is last of the Login sequence and it is acknowledged by the
Target
> with "accept login" response.
>
> Target would receive the PDUs in this CmdSN order
>  0 to 7, 8, 9, 12, 10, 11, 13, 14, 15
>
> Now as Login and Text PDUs are being processed even though you have
received
> Data Cmd PDUs, you can not pass them to iSCSI layer and hence you are
adding
> latency.
>
> What I want to convey from this example is why not use CmdSN just during
the
> FullFeature phase only.
>
> Regards
> Sanjay Goyal
>
>
----------------------------------------------------------------------------------------------------

>
>    Part 1.2    Type: application/ms-tnef
>            Encoding: base64

--
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054





From owner-ips@ece.cmu.edu  Fri Aug 10 03:54:45 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00839
	for <ips-archive@odin.ietf.org>; Fri, 10 Aug 2001 03:54:44 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7A78Ig05570
	for ips-outgoing; Fri, 10 Aug 2001 03:08:18 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7A78He05565
	for <ips@ece.cmu.edu>; Fri, 10 Aug 2001 03:08:17 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id JAA291920
	for <ips@ece.cmu.edu>; Fri, 10 Aug 2001 09:08:11 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7A78Aw85738
	for <ips@ece.cmu.edu>; Fri, 10 Aug 2001 09:08:10 +0200
Importance: Normal
Subject: Re: iSCSI - Response/Status
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF980285DD.B46001DB-ONC2256AA4.0026FD52@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Fri, 10 Aug 2001 10:07:50 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 10/08/2001 10:08:10
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Eddy,

The iSCSI condition is listed under reason.
The Response field is 00 (else the status is not valid) as stated in the
first paragraph..

Julo

"Eddy Quicksall" <ESQuicksall@hotmail.com> on 09-08-2001 22:16:50

Please respond to "Eddy Quicksall" <ESQuicksall@hotmail.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   <ips@ece.cmu.edu>
Subject:  Re: iSCSI - Response/Status



Can you list, in the table, which "iSCSI conditions" result in the Check
Condition?

Also, would it be useful to make it clear that the Status and Response
fields would both be set in this case?

Eddy
----- Original Message -----
From: "Julian Satran" <Julian_Satran@il.ibm.com>
To: <ips@ece.cmu.edu>
Sent: Thursday, August 09, 2001 1:33 PM
Subject: iSCSI - Response/Status


> According to the discusions on the list 2.4.2 & 2.4.3 have been fixed to
> read:
>
> 1.1.1     Status
>
>    The Status field is used to report the SCSI status of the command (as
>    specified in [SAM2]) and is valid only if the Response Code is Command
>    Completed at target.
>
>    If a SCSI device error is detected while data from the initiator is
>    still expected (the command PDU did not contain all the data and the
>    target has not received a Data PDU with the final bit Set) the target
>    MUST wait until it receives the a Data PDU with the F bit set, in the
>    last expected sequence, before sending the Response PDU.
>
> 1.1.2     Response
>
>    This field contains iSCSI service response.
>
>    Valid iSCSI service response codes are:
>
>       0x00 - Command Completed at Target
>       0x01 - Target Failure
>       0x02 - Delivery Subsystem Failure
>       0x80-0xff - Reserved for Vendor-Unique Responses
>
>    The Response is used to report a Service Response. The exact mapping
of
>    the iSCSI response codes to SAM service response symbols is outside
the
>    scope of this document.
>
>    Certain iSCSI conditions result in the command being terminated at the
>    target (response Command Completed at Target) with a SCSI Check
>    Condition Status as outlined in the next table:
>
>    +------------------------------+---------------------------+
>    | Reason                       | with SCSI CHECK CONDITION |
>    +------------------------------+---------------------------+
>    | Unsolicited data rejected    | ASC = 0x49 ASCQ = 0x00    |
>    +------------------------------+---------------------------+
>    | Not enough unsolicited       | ASC = 0x4B ASCQ = 0x00    |
>    +------------------------------+---------------------------+
>    | SNACK rejected               | ASC = 0x47 ASCQ = 0x03    |
>    +------------------------------+---------------------------+
>
>    N.B. Unsolicited data rejected condition is reported used by the
target
>    only if it does not support output (write) operations in which the
total
>    data length is higher than FirstBurstSize but the initiator sent less
>    than first burst size and out-of-order R2Ts can't be used.
>
>    Julo
>
>





From owner-ips@ece.cmu.edu  Fri Aug 10 03:56:01 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00859
	for <ips-archive@odin.ietf.org>; Fri, 10 Aug 2001 03:56:00 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7A7HQW05802
	for ips-outgoing; Fri, 10 Aug 2001 03:17:26 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7A7HOe05798
	for <ips@ece.cmu.edu>; Fri, 10 Aug 2001 03:17:25 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id JAA280094
	for <ips@ece.cmu.edu>; Fri, 10 Aug 2001 09:17:18 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7A7HHt44590
	for <ips@ece.cmu.edu>; Fri, 10 Aug 2001 09:17:17 +0200
Importance: Normal
Subject: Re: CmdSN during login
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFD6B18BFF.FBA3CC60-ONC2256AA4.0027F1E8@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Fri, 10 Aug 2001 10:16:58 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 10/08/2001 10:17:17
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Fine. Just use immediate and you are done.  Julo

Sanjay Goyal <sanjay_goyal@ivivity.com>@ece.cmu.edu on 09-08-2001 23:34:58

Please respond to Sanjay Goyal <sanjay_goyal@ivivity.com>

Sent by:  owner-ips@ece.cmu.edu


To:   "Ips (E-mail)" <ips@ece.cmu.edu>
cc:   Sanjay Goyal <sanjay_goyal@ivivity.com>
Subject:  CmdSN during login



Hi

 Assuming Target and Initiator support multiple connections and the session
is having multiple connections. Assuming out-of-order CmdSN is a
possibility
for this session.

 Connection #  1    |    2    |    3
-------------------------------------------------------
Login Cmd  CmdSN=0  |   CmdSN=8    |  CmdSN=9
Txt   Cmd  CmdSN=1  |              |
                    |              |
                    |         |
Login Cmd  CmdSN=7  |  CmdSN=10    |  CmdSN=11
-------------------------------------------------------
Data Cmd   CmdSN=12      | CmdSN=14      | CmdSN=15
Data Cmd   CmdSN=13 |         |
                    |         |

CmdSN=7 is last of the Login sequence and it is acknowledged by the Target
with "accept login" response.

Target would receive the PDUs in this CmdSN order
 0 to 7, 8, 9, 12, 10, 11, 13, 14, 15

Now as Login and Text PDUs are being processed even though you have
received
Data Cmd PDUs, you can not pass them to iSCSI layer and hence you are
adding
latency.

What I want to convey from this example is why not use CmdSN just during
the
FullFeature phase only.

Regards
Sanjay Goyal







From owner-ips@ece.cmu.edu  Fri Aug 10 04:12:27 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01129
	for <ips-archive@odin.ietf.org>; Fri, 10 Aug 2001 04:12:27 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7A7Ku205885
	for ips-outgoing; Fri, 10 Aug 2001 03:20:56 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7A7Kke05879
	for <ips@ece.cmu.edu>; Fri, 10 Aug 2001 03:20:49 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id JAA137638
	for <ips@ece.cmu.edu>; Fri, 10 Aug 2001 09:20:40 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7A7Kdt36596
	for <ips@ece.cmu.edu>; Fri, 10 Aug 2001 09:20:39 +0200
Importance: Normal
Subject: RE: Review of the 07 draft
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFC84F2F76.F37E9950-ONC2256AA4.00280C13@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Fri, 10 Aug 2001 10:20:20 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 10/08/2001 10:20:39
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


This issue was raised several times. Having parameters changed in two
layers is not a good idea and
leaving only SCSI change them will not enable us to restrict some changes
to login or initial login.
The compromise we have now does not break any existing software and allows
us to do what we want.

Julo

"Robert Griswold" <rgriswold@Crossroads.com>@ece.cmu.edu on 09-08-2001
23:36:14

Please respond to "Robert Griswold" <rgriswold@Crossroads.com>

Sent by:  owner-ips@ece.cmu.edu


To:   "Eddy Quicksall" <ESQuicksall@hotmail.com>, Jim
      Hafner/Almaden/IBM@IBMUS
cc:   <ips@ece.cmu.edu>
Subject:  RE: Review of the 07 draft



Eddy:

I actually have no problem with all mode pages (SCSI and iSCSI) being
accessible and changeable from standard SCSI mode commands.  My initial
response to this section was to propose a method that would be
acceptable to the authors of the iSCSI draft.  If there is desire in the
group to allow mode pages for the entire target to be manipulated from
the SCSI level, I think that is a better idea that the one I proposed.
I would assume that an iSCSI aware SCSI utility would understand the
iSCSI specific settings, and allow the user to make those changes.  What
I am really against, is the ability to modify standard SCSI mode page
settings from text messages, as that could lead to target behavior
changes outside of the understanding of the SCSI nexus.

To recap your thinking:  Allow iSCSI text messages to modify and read
iSCSI only mode settings (potentially allowing the reading if SCSI mode
settings), but allow SCSI mode commands to modify and read all target
mode settings, including iSCSI settings.  Is that what you are saying.
If so, I agree.

Bob

Robert Griswold
Technologist
Crossroads Systems, Inc.
512-928-7272

 -----Original Message-----
From:     Eddy Quicksall [mailto:ESQuicksall@hotmail.com]
Sent:     Thursday, August 09, 2001 2:08 PM
To:  Robert Griswold; Jim Hafner
Cc:  ips@ece.cmu.edu
Subject:  Re: Review of the 07 draft

I don't like the idea of not letting a user of a SCSI utility be able to
change some of the parameters for iSCSI. Because they may be relevant to
him
and there may not be a user interface to the iSCSI driver. pSCSI sets
these
low level parameters via a standard mode set, so why not iSCSI?

It would be best if we could work out something where only the SCSI
layer
can set the mode pages. That would solve everything.

Eddy

----- Original Message -----
From: "Jim Hafner" <hafner@almaden.ibm.com>
To: "Robert Griswold" <rgriswold@Crossroads.com>
Cc: <ips@ece.cmu.edu>
Sent: Friday, August 03, 2001 5:26 PM
Subject: Re: Review of the 07 draft

> Well, in fact, the draft is supposed to say that MODE_SELECT for the
> transport-specific mode page will NOT be done via SCSI, only via Text
> commands.  I read that as saying that from the SCSI layer, all fields
in
> these pages are "unchangeable" (even though they can change in the
iSCSI
> layer).  Of course, the draft doesn't say whether MODE PARAMETERS HAVE
> CHANGED unit attentions get thrown up at the SCSI layer when this
happens
> at the iSCSI layer.... You later have a clarifying question (Section
3) on
> this as well.
>
> Regards,
> Jim Hafner
>
>
>
>







From owner-ips@ece.cmu.edu  Fri Aug 10 07:06:40 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03513
	for <ips-archive@odin.ietf.org>; Fri, 10 Aug 2001 07:06:40 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7AA46Y21074
	for ips-outgoing; Fri, 10 Aug 2001 06:04:06 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7AA44e21069
	for <ips@ece.cmu.edu>; Fri, 10 Aug 2001 06:04:04 -0400 (EDT)
Received: by ztxmail04.ztx.compaq.com (Postfix, from userid 12345)
	id 03A0E26C1; Fri, 10 Aug 2001 05:03:58 -0500 (CDT)
Received: from exchou-gh02.cca.cpqcorp.net (exchou-gh02.cca.cpqcorp.net [16.110.248.202])
	by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id E4ECF158C
	for <ips@ece.cmu.edu>; Fri, 10 Aug 2001 05:03:58 -0500 (CDT)
Received: by exchou-gh02.cca.cpqcorp.net with Internet Mail Service (5.5.2652.78)
	id <QTJPQMCC>; Fri, 10 Aug 2001 05:03:58 -0500
Message-ID: <78AF3C342AEAEF4BA33B35A8A15668C6016ABEFB@cceexc17.americas.cpqcorp.net>
From: "Elliott, Robert" <Robert.Elliott@compaq.com>
To: ips@ece.cmu.edu
Subject: RE: iSCSI - Response/Status
Date: Fri, 10 Aug 2001 05:03:57 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

I would call out those additional sense codes by name rather than number
(perhaps both).  The sense key(s) to be used also need to be listed.

Status=CHECK CONDITION
Sense Key=
additional sense code (ASC+ASCQ)=

--
Robert.Elliott@compaq.com
Compaq Computer Server Storage


-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, August 09, 2001 6:34 PM
To: ips@ece.cmu.edu
Subject: iSCSI - Response/Status


According to the discusions on the list 2.4.2 & 2.4.3 have been fixed to
read:

1.1.1     Status

   The Status field is used to report the SCSI status of the command (as
   specified in [SAM2]) and is valid only if the Response Code is Command
   Completed at target.

   If a SCSI device error is detected while data from the initiator is
   still expected (the command PDU did not contain all the data and the
   target has not received a Data PDU with the final bit Set) the target
   MUST wait until it receives the a Data PDU with the F bit set, in the
   last expected sequence, before sending the Response PDU.

1.1.2     Response

   This field contains iSCSI service response.

   Valid iSCSI service response codes are:

      0x00 - Command Completed at Target
      0x01 - Target Failure
      0x02 - Delivery Subsystem Failure
      0x80-0xff - Reserved for Vendor-Unique Responses

   The Response is used to report a Service Response. The exact mapping of
   the iSCSI response codes to SAM service response symbols is outside the
   scope of this document.

   Certain iSCSI conditions result in the command being terminated at the
   target (response Command Completed at Target) with a SCSI Check
   Condition Status as outlined in the next table:

   +------------------------------+---------------------------+
   | Reason                       | with SCSI CHECK CONDITION |
   +------------------------------+---------------------------+
   | Unsolicited data rejected    | ASC = 0x49 ASCQ = 0x00    |
   +------------------------------+---------------------------+
   | Not enough unsolicited       | ASC = 0x4B ASCQ = 0x00    |
   +------------------------------+---------------------------+
   | SNACK rejected               | ASC = 0x47 ASCQ = 0x03    |
   +------------------------------+---------------------------+

   N.B. Unsolicited data rejected condition is reported used by the target
   only if it does not support output (write) operations in which the total
   data length is higher than FirstBurstSize but the initiator sent less
   than first burst size and out-of-order R2Ts can't be used.

   Julo


From owner-ips@ece.cmu.edu  Fri Aug 10 10:01:00 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05047
	for <ips-archive@odin.ietf.org>; Fri, 10 Aug 2001 10:00:59 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7ADPJE27886
	for ips-outgoing; Fri, 10 Aug 2001 09:25:19 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from va2mc.ummailbox.net (va2mc.ummailbox.net [64.210.247.19])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7ADPIe27882
	for <ips@ece.cmu.edu>; Fri, 10 Aug 2001 09:25:18 -0400 (EDT)
Received: from hqmailweb.COMMSTOR.Crossroads.com (HQMailWeb.Crossroads.com [63.237.99.250:25])
	by va2mc.ummailbox.net with ESMTP id U0810-0925-5a2600;
	Fri, 10 Aug 2001 13:25:02 GMT
Received: from HQMAILNODE1.COMMSTOR.Crossroads.com ([10.5.1.42]) by hqmailweb.COMMSTOR.Crossroads.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 10 Aug 2001 08:25:02 -0500
Subject: RE: Review of the 07 draft
Date: Fri, 10 Aug 2001 08:25:01 -0500
Message-ID: <CFD808D1D39ACB47ABFF586D484CC52E261E5C@HQMAILNODE1.COMMSTOR.Crossroads.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
content-class: urn:content-classes:message
Thread-Topic: Review of the 07 draft
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Thread-Index: AcEhM2DeAm4T4bMHSDqNtfwoPb66tgAaymBA
From: "Robert Griswold" <rgriswold@Crossroads.com>
To: <deva@stargateip.com>, "Eddy Quicksall" <ESQuicksall@hotmail.com>,
        "Jim Hafner" <hafner@almaden.ibm.com>
Cc: <ips@ece.cmu.edu>
X-OriginalArrivalTime: 10 Aug 2001 13:25:02.0081 (UTC) FILETIME=[DC312710:01C1219F]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f7ADPIe27883
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit

Deva:

I would argue that having two ways to change the same thing adds
flexibility, rather than complexity.  If the iSCSI Text Messages are
allowed to change iSCSI only parameters, then the transport has access
to what it needs.  In addition, if the SCSI utility is aware of iSCSI
mode pages (which of course it would need to be to even understand
accessing iSCSI pages), then only one interface is needed for all
aspects of the target.  As stated by Eddy, the legacy of SCSI is that
mode pages, irrespective of what those parameters are manipulating
(transport, commands, responses, timing, etc.), are accessible through
SCSI mode commands.  

If mode page changes were not allowed to modify existing communication
parameters (for existing connections), then there is no problem.  Once
all active connections were dropped, then the re-establishment of
connections would present new defaults for critical iSCSI or SCSI
parameters.  Does this sound reasonable?

Bob

Robert Griswold
Technologist
Crossroads Systems, Inc.
512-928-7272

 -----Original Message-----
From: 	Dev [mailto:deva@stargateip.com] 
Sent:	Thursday, August 09, 2001 7:33 PM
To:	Robert Griswold; Eddy Quicksall; Jim Hafner
Cc:	ips@ece.cmu.edu
Subject:	RE: Review of the 07 draft

All,

I tend to disagree. The parameters for the iSCSI are negotiated between
the
initiator and target.
If we allow the parameters to be changed through SCSI Mode select, how
will
this work?

If parameters can be changed through SCSI Mode select then it will apply
only to Lead only connections.

So, we'll have

a) two methods to change the Lead only parameters common for the entire
session (one through mode select
and the other through text parameters)
b) Just iSCSI text command to change the connection specific parameters.

Does it not add to complexity having multiple ways to change the same
stuff?

Thanks

Deva
Platys communications

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Robert Griswold
Sent: Thursday, August 09, 2001 1:36 PM
To: Eddy Quicksall; Jim Hafner
Cc: ips@ece.cmu.edu
Subject: RE: Review of the 07 draft


Eddy:

I actually have no problem with all mode pages (SCSI and iSCSI) being
accessible and changeable from standard SCSI mode commands.  My initial
response to this section was to propose a method that would be
acceptable to the authors of the iSCSI draft.  If there is desire in the
group to allow mode pages for the entire target to be manipulated from
the SCSI level, I think that is a better idea that the one I proposed.
I would assume that an iSCSI aware SCSI utility would understand the
iSCSI specific settings, and allow the user to make those changes.  What
I am really against, is the ability to modify standard SCSI mode page
settings from text messages, as that could lead to target behavior
changes outside of the understanding of the SCSI nexus.

To recap your thinking:  Allow iSCSI text messages to modify and read
iSCSI only mode settings (potentially allowing the reading if SCSI mode
settings), but allow SCSI mode commands to modify and read all target
mode settings, including iSCSI settings.  Is that what you are saying.
If so, I agree.

Bob

Robert Griswold
Technologist
Crossroads Systems, Inc.
512-928-7272

 -----Original Message-----
From: 	Eddy Quicksall [mailto:ESQuicksall@hotmail.com]
Sent:	Thursday, August 09, 2001 2:08 PM
To:	Robert Griswold; Jim Hafner
Cc:	ips@ece.cmu.edu
Subject:	Re: Review of the 07 draft

I don't like the idea of not letting a user of a SCSI utility be able to
change some of the parameters for iSCSI. Because they may be relevant to
him
and there may not be a user interface to the iSCSI driver. pSCSI sets
these
low level parameters via a standard mode set, so why not iSCSI?

It would be best if we could work out something where only the SCSI
layer
can set the mode pages. That would solve everything.

Eddy

----- Original Message -----
From: "Jim Hafner" <hafner@almaden.ibm.com>
To: "Robert Griswold" <rgriswold@Crossroads.com>
Cc: <ips@ece.cmu.edu>
Sent: Friday, August 03, 2001 5:26 PM
Subject: Re: Review of the 07 draft

> Well, in fact, the draft is supposed to say that MODE_SELECT for the
> transport-specific mode page will NOT be done via SCSI, only via Text
> commands.  I read that as saying that from the SCSI layer, all fields
in
> these pages are "unchangeable" (even though they can change in the
iSCSI
> layer).  Of course, the draft doesn't say whether MODE PARAMETERS HAVE
> CHANGED unit attentions get thrown up at the SCSI layer when this
happens
> at the iSCSI layer.... You later have a clarifying question (Section
3) on
> this as well.
>
> Regards,
> Jim Hafner
>
>
>
>






From owner-ips@ece.cmu.edu  Fri Aug 10 10:10:47 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05201
	for <ips-archive@odin.ietf.org>; Fri, 10 Aug 2001 10:10:46 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7AD7Q627080
	for ips-outgoing; Fri, 10 Aug 2001 09:07:26 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from siaar1aa.compuserve.com (siaar1aa.compuserve.com [149.174.40.9])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7AD7Oe27076
	for <ips@ece.cmu.edu>; Fri, 10 Aug 2001 09:07:24 -0400 (EDT)
Received: (from mailgate@localhost)
	by siaar1aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id JAA01973
	for ips@ece.cmu.edu; Fri, 10 Aug 2001 09:07:18 -0400 (EDT)
Received: from compuserve.com (sfr-tgn-sfu-vty13.as.wcom.net [216.192.39.13])
	by siaar1aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id JAA01959
	for <ips@ece.cmu.edu>; Fri, 10 Aug 2001 09:07:13 -0400 (EDT)
Message-ID: <3B73DD58.5965DB1@compuserve.com>
Date: Fri, 10 Aug 2001 08:10:48 -0500
From: Ralph Weber <ralphoweber@compuserve.com>
Reply-To: ENDL_TX@computer.org
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47  (Win98; I)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: IPS Reflector <ips@ece.cmu.edu>
Subject: Use of project identifiers in posting subjects
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

So, has this reflector officially gone over to being
the all iSCSI all the time reflector?

I notice that over 50% of the recent messages have
dropped the pretense that other topics are discussed
on this reflector by failing to include the "iSCSI"
identifier in the subject lines for topics devoted
solely that OTHER protocol for SCSI.  :-)

I think I speak for all of us working on the less
famous topics discussed on this reflector by reminding
you all that the subject lines of messages posted here
are supposed to contain a topic identifier, one of:

  FCIP
  iFCP
  iSCSI

Thanks.

Ralph...




From owner-ips@ece.cmu.edu  Fri Aug 10 10:55:54 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05751
	for <ips-archive@odin.ietf.org>; Fri, 10 Aug 2001 10:55:53 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7AE6Id29882
	for ips-outgoing; Fri, 10 Aug 2001 10:06:18 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7A7Wge06192
	for <ips@ece.cmu.edu>; Fri, 10 Aug 2001 03:32:42 -0400 (EDT)
Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35])
	by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id AAA16753;
	Fri, 10 Aug 2001 00:32:21 -0700 (PDT)
Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19)
	id <QRMM78BG>; Fri, 10 Aug 2001 00:32:21 -0700
Message-ID: <FFD40DB4943CD411876500508BAD02790299373D@sj5-ex2.brocade.com>
From: Robert Snively <rsnively@Brocade.COM>
To: "'deva@stargateip.com'" <deva@stargateip.com>,
        Robert Griswold
	 <rgriswold@Crossroads.com>,
        Eddy Quicksall <ESQuicksall@hotmail.com>,
        Jim Hafner <hafner@almaden.ibm.com>
Cc: ips@ece.cmu.edu
Subject: RE: Review of the 07 draft
Date: Fri, 10 Aug 2001 00:32:20 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Deva,

Both of you are right if iSCSI sticks to negotiating only
parameters related with the TCP connections, the iSCSI
session operational parameters other than EMDP and 
burst length, and iSCSI security parameters.  Then, all
parameters relating to the normal SCSI activities, including
EMDP and burst length (which are required for SCSI, not iSCSI,
buffer management) would be negotiated in the normal 
SCSI manner through the MODE SENSE/SELECT pages and everybody
would live happily ever after.

Otherwise, and especially with respect to EMDP and burst length,
I have to agree with Robert.

Bob Snively                        e-mail:    rsnively@brocade.com
Brocade Communications Systems     phone:  408 487 8135
1745 Technology Drive
San Jose, CA 95110



-----Original Message-----
From: Dev [mailto:deva@stargateip.com]
Sent: Thursday, August 09, 2001 5:33 PM
To: Robert Griswold; Eddy Quicksall; Jim Hafner
Cc: ips@ece.cmu.edu
Subject: RE: Review of the 07 draft


All,

I tend to disagree. The parameters for the iSCSI are negotiated between the
initiator and target.
If we allow the parameters to be changed through SCSI Mode select, how will
this work?

If parameters can be changed through SCSI Mode select then it will apply
only to Lead only connections.

So, we'll have

a) two methods to change the Lead only parameters common for the entire
session (one through mode select
and the other through text parameters)
b) Just iSCSI text command to change the connection specific parameters.

Does it not add to complexity having multiple ways to change the same stuff?

Thanks

Deva
Platys communications

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Robert Griswold
Sent: Thursday, August 09, 2001 1:36 PM
To: Eddy Quicksall; Jim Hafner
Cc: ips@ece.cmu.edu
Subject: RE: Review of the 07 draft


Eddy:

I actually have no problem with all mode pages (SCSI and iSCSI) being
accessible and changeable from standard SCSI mode commands.  My initial
response to this section was to propose a method that would be
acceptable to the authors of the iSCSI draft.  If there is desire in the
group to allow mode pages for the entire target to be manipulated from
the SCSI level, I think that is a better idea that the one I proposed.
I would assume that an iSCSI aware SCSI utility would understand the
iSCSI specific settings, and allow the user to make those changes.  What
I am really against, is the ability to modify standard SCSI mode page
settings from text messages, as that could lead to target behavior
changes outside of the understanding of the SCSI nexus.

To recap your thinking:  Allow iSCSI text messages to modify and read
iSCSI only mode settings (potentially allowing the reading if SCSI mode
settings), but allow SCSI mode commands to modify and read all target
mode settings, including iSCSI settings.  Is that what you are saying.
If so, I agree.

Bob

Robert Griswold
Technologist
Crossroads Systems, Inc.
512-928-7272

 -----Original Message-----
From: 	Eddy Quicksall [mailto:ESQuicksall@hotmail.com]
Sent:	Thursday, August 09, 2001 2:08 PM
To:	Robert Griswold; Jim Hafner
Cc:	ips@ece.cmu.edu
Subject:	Re: Review of the 07 draft

I don't like the idea of not letting a user of a SCSI utility be able to
change some of the parameters for iSCSI. Because they may be relevant to
him
and there may not be a user interface to the iSCSI driver. pSCSI sets
these
low level parameters via a standard mode set, so why not iSCSI?

It would be best if we could work out something where only the SCSI
layer
can set the mode pages. That would solve everything.

Eddy

----- Original Message -----
From: "Jim Hafner" <hafner@almaden.ibm.com>
To: "Robert Griswold" <rgriswold@Crossroads.com>
Cc: <ips@ece.cmu.edu>
Sent: Friday, August 03, 2001 5:26 PM
Subject: Re: Review of the 07 draft

> Well, in fact, the draft is supposed to say that MODE_SELECT for the
> transport-specific mode page will NOT be done via SCSI, only via Text
> commands.  I read that as saying that from the SCSI layer, all fields
in
> these pages are "unchangeable" (even though they can change in the
iSCSI
> layer).  Of course, the draft doesn't say whether MODE PARAMETERS HAVE
> CHANGED unit attentions get thrown up at the SCSI layer when this
happens
> at the iSCSI layer.... You later have a clarifying question (Section
3) on
> this as well.
>
> Regards,
> Jim Hafner
>
>
>
>



From owner-ips@ece.cmu.edu  Fri Aug 10 10:57:53 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05779
	for <ips-archive@odin.ietf.org>; Fri, 10 Aug 2001 10:57:53 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7AE69K29871
	for ips-outgoing; Fri, 10 Aug 2001 10:06:09 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7A773e05520
	for <ips@ece.cmu.edu>; Fri, 10 Aug 2001 03:07:03 -0400 (EDT)
Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35])
	by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id AAA16369;
	Fri, 10 Aug 2001 00:06:55 -0700 (PDT)
Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19)
	id <QRMM779L>; Fri, 10 Aug 2001 00:06:55 -0700
Message-ID: <FFD40DB4943CD411876500508BAD0279037FF8AC@sj5-ex2.brocade.com>
From: Robert Snively <rsnively@Brocade.COM>
To: John Hufferd <hufferd@us.ibm.com>, ips@ece.cmu.edu
Subject: RE: iSCSI: Support Alias in the protocol
Date: Fri, 10 Aug 2001 00:06:54 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

John,

I feel that the alias does not belong in the iSCSI architecture.
Aliasing is already routinely provided at two other levels in
the protocol stack and need not be redundantly inserted in iSCSI.

a)  In the SCSI command set

There is already available a logical unit level aliasing process
using the SET/REPORT DEVICE IDENTIFIER service actions defined
in the SCSI command set standard SPC-2.  

b)  In the operating system stack

Most implementations use aliases created at the system level, not
the protocol level, that are far more useful and can be tuned
to the particular environment.  A particularly naive example of
this is the mapping of identified devices to the A:, B:, or 
C: disk drives in the similarly naive MS-DOS operating system.
More sophisticated systems and management structures use similar
aliasing at the system level.

Bob

-----Original Message-----
From: John Hufferd [mailto:hufferd@us.ibm.com]
Sent: Tuesday, August 07, 2001 9:52 AM
To: ips@ece.cmu.edu
Subject: iSCSI: Support Alias in the protocol


Today at the 51st meeting of the IETF, I presented an issue that came out
of the Naming and Discovery Team.

That was that some members of the team did not understand why we needed to
have an Alias field, which is in the base protocol today, since it was
technically not needed.   The position I presented to the group was that
the Naming and Discovery Team did not have consensus, since many of us felt
that having a Human oriented "Tagging" function was useful, and a small
item which would be useful for Administrators especially when EUI names are
used.

One person, at the meeting today, stated that it might not be of extreme
importance on large Networks with sophisticated Management tools, but it
was very useful in small to medium environments, where the Management tools
were slim.  And at least one person stated that since it was not required,
it should not be in the protocol.

As the conversations when on, it was pointed out by the area director,
Scott  Bradner, that SLP used a similar Text field in its protocol, so
there was clearly a president.

In any event, we could not reach consensus at the meeting, so I was asked
to bring the issue to the List.  (So here it is!)

Please state your positions so that David can call a consensus.



.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com


From owner-ips@ece.cmu.edu  Fri Aug 10 11:03:11 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05894
	for <ips-archive@odin.ietf.org>; Fri, 10 Aug 2001 11:03:11 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7AELFY00675
	for ips-outgoing; Fri, 10 Aug 2001 10:21:15 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from hotmail.com (oe37.law11.hotmail.com [64.4.16.94])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7AELEe00671
	for <ips@ece.cmu.edu>; Fri, 10 Aug 2001 10:21:14 -0400 (EDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 10 Aug 2001 07:21:08 -0700
X-Originating-IP: [66.31.75.202]
From: "Eddy Quicksall" <ESQuicksall@hotmail.com>
To: "Robert Griswold" <rgriswold@Crossroads.com>, <deva@stargateip.com>,
        "Jim Hafner" <hafner@almaden.ibm.com>
Cc: <ips@ece.cmu.edu>
References: <CFD808D1D39ACB47ABFF586D484CC52E261E5C@HQMAILNODE1.COMMSTOR.Crossroads.com>
Subject: Re: Review of the 07 draft
Date: Fri, 10 Aug 2001 10:21:16 -0400
MIME-Version: 1.0
Content-Type: text/plain;	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Message-ID: <OE37F1IT18olkDTM9wG000042d2@hotmail.com>
X-OriginalArrivalTime: 10 Aug 2001 14:21:08.0043 (UTC) FILETIME=[B27631B0:01C121A7]
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Actually, when I said SCSI Utility, I meant generic SCSI Utilities that
don't know or care about the transport. There are some things that are
"duals" in the various transports and have meaning to a generic SCSI
Utilities.

If, for example, a user wants to try fiddling with EMPD, he should not have
to use an iSCSI utility ... he should be able to use a generic utility.

Eddy
----- Original Message -----
From: "Robert Griswold" <rgriswold@crossroads.com>
To: <deva@stargateip.com>; "Eddy Quicksall" <ESQuicksall@hotmail.com>; "Jim
Hafner" <hafner@almaden.ibm.com>
Cc: <ips@ece.cmu.edu>
Sent: Friday, August 10, 2001 9:25 AM
Subject: RE: Review of the 07 draft


Deva:

I would argue that having two ways to change the same thing adds
flexibility, rather than complexity.  If the iSCSI Text Messages are
allowed to change iSCSI only parameters, then the transport has access
to what it needs.  In addition, if the SCSI utility is aware of iSCSI
mode pages (which of course it would need to be to even understand
accessing iSCSI pages), then only one interface is needed for all
aspects of the target.  As stated by Eddy, the legacy of SCSI is that
mode pages, irrespective of what those parameters are manipulating
(transport, commands, responses, timing, etc.), are accessible through
SCSI mode commands.

If mode page changes were not allowed to modify existing communication
parameters (for existing connections), then there is no problem.  Once
all active connections were dropped, then the re-establishment of
connections would present new defaults for critical iSCSI or SCSI
parameters.  Does this sound reasonable?

Bob

Robert Griswold
Technologist
Crossroads Systems, Inc.
512-928-7272

 -----Original Message-----
From: Dev [mailto:deva@stargateip.com]
Sent: Thursday, August 09, 2001 7:33 PM
To: Robert Griswold; Eddy Quicksall; Jim Hafner
Cc: ips@ece.cmu.edu
Subject: RE: Review of the 07 draft

All,

I tend to disagree. The parameters for the iSCSI are negotiated between
the
initiator and target.
If we allow the parameters to be changed through SCSI Mode select, how
will
this work?

If parameters can be changed through SCSI Mode select then it will apply
only to Lead only connections.

So, we'll have

a) two methods to change the Lead only parameters common for the entire
session (one through mode select
and the other through text parameters)
b) Just iSCSI text command to change the connection specific parameters.

Does it not add to complexity having multiple ways to change the same
stuff?

Thanks

Deva
Platys communications

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Robert Griswold
Sent: Thursday, August 09, 2001 1:36 PM
To: Eddy Quicksall; Jim Hafner
Cc: ips@ece.cmu.edu
Subject: RE: Review of the 07 draft


Eddy:

I actually have no problem with all mode pages (SCSI and iSCSI) being
accessible and changeable from standard SCSI mode commands.  My initial
response to this section was to propose a method that would be
acceptable to the authors of the iSCSI draft.  If there is desire in the
group to allow mode pages for the entire target to be manipulated from
the SCSI level, I think that is a better idea that the one I proposed.
I would assume that an iSCSI aware SCSI utility would understand the
iSCSI specific settings, and allow the user to make those changes.  What
I am really against, is the ability to modify standard SCSI mode page
settings from text messages, as that could lead to target behavior
changes outside of the understanding of the SCSI nexus.

To recap your thinking:  Allow iSCSI text messages to modify and read
iSCSI only mode settings (potentially allowing the reading if SCSI mode
settings), but allow SCSI mode commands to modify and read all target
mode settings, including iSCSI settings.  Is that what you are saying.
If so, I agree.

Bob

Robert Griswold
Technologist
Crossroads Systems, Inc.
512-928-7272

 -----Original Message-----
From: Eddy Quicksall [mailto:ESQuicksall@hotmail.com]
Sent: Thursday, August 09, 2001 2:08 PM
To: Robert Griswold; Jim Hafner
Cc: ips@ece.cmu.edu
Subject: Re: Review of the 07 draft

I don't like the idea of not letting a user of a SCSI utility be able to
change some of the parameters for iSCSI. Because they may be relevant to
him
and there may not be a user interface to the iSCSI driver. pSCSI sets
these
low level parameters via a standard mode set, so why not iSCSI?

It would be best if we could work out something where only the SCSI
layer
can set the mode pages. That would solve everything.

Eddy

----- Original Message -----
From: "Jim Hafner" <hafner@almaden.ibm.com>
To: "Robert Griswold" <rgriswold@Crossroads.com>
Cc: <ips@ece.cmu.edu>
Sent: Friday, August 03, 2001 5:26 PM
Subject: Re: Review of the 07 draft

> Well, in fact, the draft is supposed to say that MODE_SELECT for the
> transport-specific mode page will NOT be done via SCSI, only via Text
> commands.  I read that as saying that from the SCSI layer, all fields
in
> these pages are "unchangeable" (even though they can change in the
iSCSI
> layer).  Of course, the draft doesn't say whether MODE PARAMETERS HAVE
> CHANGED unit attentions get thrown up at the SCSI layer when this
happens
> at the iSCSI layer.... You later have a clarifying question (Section
3) on
> this as well.
>
> Regards,
> Jim Hafner
>
>
>
>







From owner-ips@ece.cmu.edu  Fri Aug 10 11:40:36 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06508
	for <ips-archive@odin.ietf.org>; Fri, 10 Aug 2001 11:40:35 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7AEinQ01778
	for ips-outgoing; Fri, 10 Aug 2001 10:44:49 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7AEile01773
	for <ips@ece.cmu.edu>; Fri, 10 Aug 2001 10:44:47 -0400 (EDT)
Received: by ATLOPS with Internet Mail Service (5.5.2448.0)
	id <QMJCNCGL>; Fri, 10 Aug 2001 10:44:41 -0400
Message-ID: <25369470B6F0D41194820002B328BDD2116226@ATLOPS>
From: Sanjay Goyal <sanjay_goyal@ivivity.com>
To: "Ips (E-mail)" <ips@ece.cmu.edu>
Cc: Sanjay Goyal <sanjay_goyal@ivivity.com>
Subject: iSCSI:   CmdSN during login   :   Tabs removed
Date: Fri, 10 Aug 2001 10:44:41 -0400
X-MS-TNEF-Correlator: <25369470B6F0D41194820002B328BDD2116226@ATLOPS>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C121AA.FCE14264"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C121AA.FCE14264
Content-Type: text/plain;
	charset="iso-8859-1"

Hi

 Assuming Target and Initiator support multiple connections and the session
is having multiple connections. Assuming out-of-order CmdSN is a possibility
for this session.

 Connection #     1     |    2      |     3
-------------------------------------------------------
Login Cmd  CmdSN=0      |   CmdSN=8	|  CmdSN=9
Txt   Cmd  CmdSN=1      |    	      |   
                        |           |   
                        |   	      |   
Txt   Cmd  CmdSN=7      |  CmdSN=10	|  CmdSN=11
-------------------------------------------------------
Data Cmd   CmdSN=12     | CmdSN=14  | CmdSN=15
Data Cmd   CmdSN=13     |           |
                        |           |

CmdSN=7 is last of the Login sequence and it is acknowledged by the Target
with "accept login" response.

Target would receive the PDUs in this CmdSN order
 0 to 7, 8, 9, 12, 10, 11, 13, 14, 15

Now as Login and Text PDUs are being processed even though you have received
Data Cmd PDUs, you can not pass them to SCSI layer and hence you are adding
latency. 

What I want to convey from this example is why not use CmdSN just during the
FullFeature phase only.

Regards
Sanjay Goyal

------_=_NextPart_000_01C121AA.FCE14264
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64

eJ8+IioOAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQkABAACAAAAAAAAAAEIAAUABAAAAAAAAAAAAAEFgAMADgAAANEH
CAAKAAoALAApAAUATgEBIIADAA4AAADRBwgACgAKACwAKQAFAE4BAQmAAQAhAAAANTA2ODdDNkE2
NThBRDUxMTk0QjMwMDAyQjMyOEJERDIAAgcBBIABAC8AAABpU0NTSTogICBDbWRTTiBkdXJpbmcg
bG9naW4gICA6ICAgVGFicyByZW1vdmVkAGIOAQ2ABAACAAAAAgACAAEDkAYANAgAADAAAAADADYA
AAAAAAMAW4AIIAYAAAAAAMAAAAAAAABGAAAAAFKFAAB9bgEAHgBcgAggBgAAAAAAwAAAAAAAAEYA
AAAAVIUAAAEAAAAEAAAAOS4wAAsAhYAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAAAwAOgAgg
BgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALABCACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAA
AAsAEYAIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwA3gAggBgAAAAAAwAAAAAAAAEYAAAAA
EIUAAAAAAAADADiACCAGAAAAAADAAAAAAAAARgAAAAARhQAAAAAAAAMAPoAIIAYAAAAAAMAAAAAA
AABGAAAAABiFAAAAAAAAAgEJEAEAAAA7AwAANwMAABsGAABMWkZ1Z53AZQMACgByY3BnMTI14jID
Q3RleAVBAQMB9/8KgAKkA+QHEwKAD/MAUARWPwhVB7IRJQ5RAwECAGNo4QrAc2V0MgYABsMRJfYz
BEYTtzASLBEzCO8J97Y7GB8OMDURIgxgYwBQMwsJAWQzNhZQC6YgSD8AoAqxCoQKgBDABBB1bVEL
gGcgVArAZxQgIFEAcGQgSQMAdAcwdBMFsR4AcHAXwSBtdSZsH1ALUGUgBaBubp8FkB9QAiAEIB7i
dGggsFcUEAQQIUEgBAAgE+B2Nx4yIE8hUS4d2AhgdC0cb2YlUAsgEoFDbWRkU04igmEgH/AiMWLz
AxAfQHkgAhAFwCHQIpEdIhUuHRsIUCD2ICMgdSoCMSoDfCoCFEAqaCD7FTAdIy0sTy1fLm8uoR0U
eExvZwuAJeIqACXzPXcWUCpnMMQ4DIIqojDEOf0dFFQO0TCjMKYqVCqkMkP/KxgddTa/Kxo1vzmf
OJk1f3szbzDxNysXNEUBQDJbMd8a8ywvQR9CLy9aRB9wJoBfMHM0NisEKrA0RTRFaTXrQ680RTM3
73w5PzpPSQ3vHRQ9ViKRC2BzBUAlYCHDyzAUFBBxClBuYyCwHuKDH0AmQ2Nrbm93IKD2ZB6gHwBi
J0Ah0h51A/D5IdAgIgDQTzAFMRewMDG0IiAYIHMf8ACAZShrO1FGCGBsHwAYIE8waXbjILAh0lBE
VQQgMEEnox8l9CWTHXUWUB+AIDcsdCA4WCA5WCAOIFiBMNVYgTFYgTNYgTRYgUbVfR0UTlBAHtAE
IDAUHuJUbw7CVdMKwCCwYlVAHkFw7wNgTzAEEFChZVVgVjIIYPpnUeB5CGAisiCwVRUfAO9HR1XS
WCBecmMDkVAwBUAXCrAEESHRbVfSU0NT+klNoXkSgR7iIeBPIl5y8VxyYWRkHjILYA6wTyB2eSRw
HRpXE+AFQGJAd/8AcAVAV+Eg0VVgJ0EDYSeUmQ7AYW0gkiKRd2gnQG1hAnUUECXlamjQBUBkFwhx
HkEh0kYjQGxGZXcfcAhwILBwE+Bo4QIgbKNksB0aUmVnCxFzHRSFBhFqYnAgR295B0AFHRR9bqAA
HgBwAAEAAAAYAAAAaVNDU0kgLSBSZXNwb25zZS9TdGF0dXMAAgFxAAEAAAAlAAAAAcEhA+s1anxi
DoplEdWUswACsyi90gADPVCgAAAq/lAAJjHPsAAAAAMAJgAAAAAAAwAuAAAAAAALAAIAAQAAAAsA
FwwAAAAAAwBdQAAAAAADAAlZAQAAAAMA3j/kBAAAQAA5APA+wvyqIcEBAwDxPwkEAAAeADFAAQAA
AAgAAABTQU5KQVlHAAMAGkAAAAAAHgAwQAEAAAAIAAAAU0FOSkFZRwADABlAAAAAAAMA/T/kBAAA
AwCAEP////8CAUcAAQAAAC4AAABjPVVTO2E9IDtwPUlWSVZJVFk7bD1BVExPUFMtMDEwODEwMTQ0
NDQxWi01NTAAAAACAfk/AQAAAEoAAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAAL089SVZJ
VklUWS9PVT1BVExPUFMvQ049UkVDSVBJRU5UUy9DTj1TQU5KQVlHAAAAHgD4PwEAAAANAAAAU2Fu
amF5IEdveWFsAAAAAB4AOEABAAAACAAAAFNBTkpBWUcAAgH7PwEAAABKAAAAAAAAANynQMjAQhAa
tLkIACsv4YIBAAAAAAAAAC9PPUlWSVZJVFkvT1U9QVRMT1BTL0NOPVJFQ0lQSUVOVFMvQ049U0FO
SkFZRwAAAB4A+j8BAAAADQAAAFNhbmpheSBHb3lhbAAAAAAeADlAAQAAAAgAAABTQU5KQVlHAEAA
BzBeIP5OqiHBAUAACDBkQuH8qiHBAR4APQABAAAAAQAAAAAAAAAeAB0OAQAAAC8AAABpU0NTSTog
ICBDbWRTTiBkdXJpbmcgbG9naW4gICA6ICAgVGFicyByZW1vdmVkAAAeADUQAQAAADAAAAA8MjUz
Njk0NzBCNkYwRDQxMTk0ODIwMDAyQjMyOEJERDIxMTYyMjZAQVRMT1BTPgALACkAAAAAAAsAIwAA
AAAAAwAGEAwlY24DAAcQAgMAAAMAEBAAAAAAAwAREAAAAAAeAAgQAQAAAGUAAABISUFTU1VNSU5H
VEFSR0VUQU5ESU5JVElBVE9SU1VQUE9SVE1VTFRJUExFQ09OTkVDVElPTlNBTkRUSEVTRVNTSU9O
SVNIQVZJTkdNVUxUSVBMRUNPTk5FQ1RJT05TQVNTVU1JAAAAAAIBfwABAAAAMAAAADwyNTM2OTQ3
MEI2RjBENDExOTQ4MjAwMDJCMzI4QkREMjExNjIyNkBBVExPUFM+AM/Z

------_=_NextPart_000_01C121AA.FCE14264--


From owner-ips@ece.cmu.edu  Fri Aug 10 11:41:42 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06553
	for <ips-archive@odin.ietf.org>; Fri, 10 Aug 2001 11:41:41 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7AFDV003291
	for ips-outgoing; Fri, 10 Aug 2001 11:13:31 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from hotmail.com (oe61.law11.hotmail.com [64.4.16.196])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7AFDUe03286
	for <ips@ece.cmu.edu>; Fri, 10 Aug 2001 11:13:30 -0400 (EDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 10 Aug 2001 08:13:24 -0700
X-Originating-IP: [66.31.75.202]
From: "Eddy Quicksall" <ESQuicksall@hotmail.com>
To: "Julian Satran" <Julian_Satran@il.ibm.com>
Cc: <ips@ece.cmu.edu>
References: <OFBA3A669B.57778046-ONC2256AA4.0024B676@telaviv.ibm.com>
Subject: Re: CmdSN during login
Date: Fri, 10 Aug 2001 11:13:32 -0400
MIME-Version: 1.0
Content-Type: text/plain;	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Message-ID: <OE61wFutJLtosJ3Ih7j0000a741@hotmail.com>
X-OriginalArrivalTime: 10 Aug 2001 15:13:24.0079 (UTC) FILETIME=[FFAF4FF0:01C121AE]
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

But, what if someone does this without setting the Immediate bit? What would
one do?

What is wrong with just making the CmdSN not run during login? It seems like
it was an arbitrary choice in the first place since it was originally
optional and not using it actually worked.

If CmdSN is stated as only used in FFP, then I don't see any ambiguity.

Eddy
----- Original Message -----
From: "Julian Satran" <Julian_Satran@il.ibm.com>
To: <ips@ece.cmu.edu>
Sent: Friday, August 10, 2001 2:43 AM
Subject: Re: CmdSN during login


>
> Sanjay,
>
> If you want to ignore CmdSN and expedite Login processing you can do so by
> having the commands being issued as immediate.
> This will help us keep away from creating ambiguity about (or another
> conditional) for when CmdSN is to be used or not.
>
> Julo
>
> Mark Bakke <mbakke@cisco.com>@ece.cmu.edu on 09-08-2001 23:55:25
>
> Please respond to Mark Bakke <mbakke@cisco.com>
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   Sanjay Goyal <sanjay_goyal@ivivity.com>
> cc:   "Ips (E-mail)" <ips@ece.cmu.edu>
> Subject:  Re: CmdSN during login
>
>
>
>
> Sanjay-
>
> I absolutely agree with this; CmdSN is owned by the session, and
> should not be used until the connection has fully joined the session,
> which means full feature phase.
>
> This should also clean up any ambiguity on when to start
> using CmdSN.
>
> --
> Mark
>
> Sanjay Goyal wrote:
> >
> > Hi
> >
> >  Assuming Target and Initiator support multiple connections and the
> session
> > is having multiple connections. Assuming out-of-order CmdSN is a
> possibility
> > for this session.
> >
> >  Connection #   1       |       2       |       3
> > -------------------------------------------------------
> > Login Cmd  CmdSN=0      |   CmdSN=8     |  CmdSN=9
> > Txt   Cmd  CmdSN=1      |               |
> >                                 |               |
> >                                 |               |
> > Login Cmd  CmdSN=7      |  CmdSN=10     |  CmdSN=11
> > -------------------------------------------------------
> > Data Cmd   CmdSN=12     | CmdSN=14      | CmdSN=15
> > Data Cmd   CmdSN=13     |               |
> >                                 |               |
> >
> > CmdSN=7 is last of the Login sequence and it is acknowledged by the
> Target
> > with "accept login" response.
> >
> > Target would receive the PDUs in this CmdSN order
> >  0 to 7, 8, 9, 12, 10, 11, 13, 14, 15
> >
> > Now as Login and Text PDUs are being processed even though you have
> received
> > Data Cmd PDUs, you can not pass them to iSCSI layer and hence you are
> adding
> > latency.
> >
> > What I want to convey from this example is why not use CmdSN just during
> the
> > FullFeature phase only.
> >
> > Regards
> > Sanjay Goyal
> >
> >
> --------------------------------------------------------------------------
--------------------------
>
> >
> >    Part 1.2    Type: application/ms-tnef
> >            Encoding: base64
>
> --
> Mark A. Bakke
> Cisco Systems
> mbakke@cisco.com
> 763.398.1054
>
>
>
>


From owner-ips@ece.cmu.edu  Fri Aug 10 11:41:44 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06567
	for <ips-archive@odin.ietf.org>; Fri, 10 Aug 2001 11:41:43 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7AF0UJ02589
	for ips-outgoing; Fri, 10 Aug 2001 11:00:30 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from hotmail.com (oe16.law11.hotmail.com [64.4.16.120])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7AF0Te02585
	for <ips@ece.cmu.edu>; Fri, 10 Aug 2001 11:00:29 -0400 (EDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 10 Aug 2001 08:00:23 -0700
X-Originating-IP: [66.31.75.202]
From: "Eddy Quicksall" <ESQuicksall@hotmail.com>
To: "Julian Satran" <Julian_Satran@il.ibm.com>
Cc: <ips@ece.cmu.edu>
References: <OF980285DD.B46001DB-ONC2256AA4.0026FD52@telaviv.ibm.com>
Subject: Re: iSCSI - Response/Status
Date: Fri, 10 Aug 2001 11:00:31 -0400
MIME-Version: 1.0
Content-Type: text/plain;	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Message-ID: <OE16olmRBaYFkuutSgc00004263@hotmail.com>
X-OriginalArrivalTime: 10 Aug 2001 15:00:23.0330 (UTC) FILETIME=[2E527820:01C121AD]
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Sorry, I get it now ... I was mixing the old and new in my thinking.

But, I'm still wondering why the S bit was removed and the fields were put
into two places because they still seem to be mutually exclusive. I really
don't have a problem but I thought someone had a good idea since the S bit
clearly showed they are mutually exclusive.

Also, it looks like the old S bit has been changed to a fixed zero instead
of a reserved bit. Could it be that in this case "0" means "reserved"?

Eddy

----- Original Message -----
From: "Julian Satran" <Julian_Satran@il.ibm.com>
To: <ips@ece.cmu.edu>
Sent: Friday, August 10, 2001 3:07 AM
Subject: Re: iSCSI - Response/Status


>
> Eddy,
>
> The iSCSI condition is listed under reason.
> The Response field is 00 (else the status is not valid) as stated in the
> first paragraph..
>
> Julo
>
> "Eddy Quicksall" <ESQuicksall@hotmail.com> on 09-08-2001 22:16:50
>
> Please respond to "Eddy Quicksall" <ESQuicksall@hotmail.com>
>
> To:   Julian Satran/Haifa/IBM@IBMIL
> cc:   <ips@ece.cmu.edu>
> Subject:  Re: iSCSI - Response/Status
>
>
>
> Can you list, in the table, which "iSCSI conditions" result in the Check
> Condition?
>
> Also, would it be useful to make it clear that the Status and Response
> fields would both be set in this case?
>
> Eddy
> ----- Original Message -----
> From: "Julian Satran" <Julian_Satran@il.ibm.com>
> To: <ips@ece.cmu.edu>
> Sent: Thursday, August 09, 2001 1:33 PM
> Subject: iSCSI - Response/Status
>
>
> > According to the discusions on the list 2.4.2 & 2.4.3 have been fixed to
> > read:
> >
> > 1.1.1     Status
> >
> >    The Status field is used to report the SCSI status of the command (as
> >    specified in [SAM2]) and is valid only if the Response Code is
Command
> >    Completed at target.
> >
> >    If a SCSI device error is detected while data from the initiator is
> >    still expected (the command PDU did not contain all the data and the
> >    target has not received a Data PDU with the final bit Set) the target
> >    MUST wait until it receives the a Data PDU with the F bit set, in the
> >    last expected sequence, before sending the Response PDU.
> >
> > 1.1.2     Response
> >
> >    This field contains iSCSI service response.
> >
> >    Valid iSCSI service response codes are:
> >
> >       0x00 - Command Completed at Target
> >       0x01 - Target Failure
> >       0x02 - Delivery Subsystem Failure
> >       0x80-0xff - Reserved for Vendor-Unique Responses
> >
> >    The Response is used to report a Service Response. The exact mapping
> of
> >    the iSCSI response codes to SAM service response symbols is outside
> the
> >    scope of this document.
> >
> >    Certain iSCSI conditions result in the command being terminated at
the
> >    target (response Command Completed at Target) with a SCSI Check
> >    Condition Status as outlined in the next table:
> >
> >    +------------------------------+---------------------------+
> >    | Reason                       | with SCSI CHECK CONDITION |
> >    +------------------------------+---------------------------+
> >    | Unsolicited data rejected    | ASC = 0x49 ASCQ = 0x00    |
> >    +------------------------------+---------------------------+
> >    | Not enough unsolicited       | ASC = 0x4B ASCQ = 0x00    |
> >    +------------------------------+---------------------------+
> >    | SNACK rejected               | ASC = 0x47 ASCQ = 0x03    |
> >    +------------------------------+---------------------------+
> >
> >    N.B. Unsolicited data rejected condition is reported used by the
> target
> >    only if it does not support output (write) operations in which the
> total
> >    data length is higher than FirstBurstSize but the initiator sent less
> >    than first burst size and out-of-order R2Ts can't be used.
> >
> >    Julo
> >
> >
>
>
>
>


From owner-ips@ece.cmu.edu  Fri Aug 10 11:55:35 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06877
	for <ips-archive@odin.ietf.org>; Fri, 10 Aug 2001 11:55:34 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7AEo5m02017
	for ips-outgoing; Fri, 10 Aug 2001 10:50:05 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7AEo4e02012
	for <ips@ece.cmu.edu>; Fri, 10 Aug 2001 10:50:04 -0400 (EDT)
Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100])
	by atlrel1.hp.com (Postfix) with ESMTP
	id 2AC64B00; Fri, 10 Aug 2001 10:50:03 -0400 (EDT)
Received: from rose.hp.com (dhcp-15-145-149-181.bri.hp.com [15.145.149.181]) by core.rose.hp.com with ESMTP (8.8.6 (PHNE_14041)/8.8.6 SMKit7.02) id HAA26458; Fri, 10 Aug 2001 07:51:17 -0700 (PDT)
Message-ID: <3B73F5AE.DDBBE8FB@rose.hp.com>
Date: Fri, 10 Aug 2001 07:54:38 -0700
From: "Mallikarjun C." <cbm@rose.hp.com>
Reply-To: cbm@rose.hp.com
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Julian Satran <Julian_Satran@il.ibm.com>
Cc: ips@ece.cmu.edu
Subject: Re: CmdSN during login
References: <OFBA3A669B.57778046-ONC2256AA4.0024B676@telaviv.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Julian,

I tend to agree with Mark and Sanjay.

In cases where all connections in a session failed and a new
connection is being added to the existing session state (before
the session timeout), an initiator must issue the Login as an
immediate command to avoid the possibility of a deadlock - since
the initiator does not know for sure if target received all commands
on the failed connections.

Since this appears to be a mandatory requirement, I suggest that
we make it the default behavior - that Login PDUs never *consume*
CmdSNs (though the leading login carries a valid "seed" CmdSN), 
including the leading login PDU.  There are no conditionals this way.

Sorry, I can't find the reasoning you offered earlier for rev07 
behavior, in the middle of my travel.  Please comment if I missed
something.
-- 
Mallikarjun 

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

Julian Satran wrote:
> 
> Sanjay,
> 
> If you want to ignore CmdSN and expedite Login processing you can do so by
> having the commands being issued as immediate.
> This will help us keep away from creating ambiguity about (or another
> conditional) for when CmdSN is to be used or not.
> 
> Julo
> 
> Mark Bakke <mbakke@cisco.com>@ece.cmu.edu on 09-08-2001 23:55:25
> 
> Please respond to Mark Bakke <mbakke@cisco.com>
> 
> Sent by:  owner-ips@ece.cmu.edu
> 
> To:   Sanjay Goyal <sanjay_goyal@ivivity.com>
> cc:   "Ips (E-mail)" <ips@ece.cmu.edu>
> Subject:  Re: CmdSN during login
> 
> Sanjay-
> 
> I absolutely agree with this; CmdSN is owned by the session, and
> should not be used until the connection has fully joined the session,
> which means full feature phase.
> 
> This should also clean up any ambiguity on when to start
> using CmdSN.
> 
> --
> Mark
> 
> Sanjay Goyal wrote:
> >
> > Hi
> >
> >  Assuming Target and Initiator support multiple connections and the
> session
> > is having multiple connections. Assuming out-of-order CmdSN is a
> possibility
> > for this session.
> >
> >  Connection #   1       |       2       |       3
> > -------------------------------------------------------
> > Login Cmd  CmdSN=0      |   CmdSN=8     |  CmdSN=9
> > Txt   Cmd  CmdSN=1      |               |
> >                                 |               |
> >                                 |               |
> > Login Cmd  CmdSN=7      |  CmdSN=10     |  CmdSN=11
> > -------------------------------------------------------
> > Data Cmd   CmdSN=12     | CmdSN=14      | CmdSN=15
> > Data Cmd   CmdSN=13     |               |
> >                                 |               |
> >
> > CmdSN=7 is last of the Login sequence and it is acknowledged by the
> Target
> > with "accept login" response.
> >
> > Target would receive the PDUs in this CmdSN order
> >  0 to 7, 8, 9, 12, 10, 11, 13, 14, 15
> >
> > Now as Login and Text PDUs are being processed even though you have
> received
> > Data Cmd PDUs, you can not pass them to iSCSI layer and hence you are
> adding
> > latency.
> >
> > What I want to convey from this example is why not use CmdSN just during
> the
> > FullFeature phase only.
> >
> > Regards
> > Sanjay Goyal
> >
> >
> ----------------------------------------------------------------------------------------------------
> 
> >
> >    Part 1.2    Type: application/ms-tnef
> >            Encoding: base64
> 
> --
> Mark A. Bakke
> Cisco Systems
> mbakke@cisco.com
> 763.398.1054


From owner-ips@ece.cmu.edu  Fri Aug 10 13:39:04 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08805
	for <ips-archive@odin.ietf.org>; Fri, 10 Aug 2001 13:39:04 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7AGcdi07821
	for ips-outgoing; Fri, 10 Aug 2001 12:38:39 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from clyde.stargateip.com ([209.237.5.66])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7AGcbe07816
	for <ips@ece.cmu.edu>; Fri, 10 Aug 2001 12:38:37 -0400 (EDT)
Received: from bluestar (dhcp-101.stargateip.com [10.10.5.101])
	by clyde.stargateip.com (8.9.1/8.9.1) with SMTP id JAA21060;
	Fri, 10 Aug 2001 09:32:52 -0700 (PDT)
Reply-To: <deva@stargateip.com>
From: "Dev" <deva@stargateip.com>
To: "Robert Griswold" <rgriswold@Crossroads.com>,
        "Eddy Quicksall" <ESQuicksall@hotmail.com>,
        "Jim Hafner" <hafner@almaden.ibm.com>
Cc: <ips@ece.cmu.edu>
Subject: RE: Review of the 07 draft
Date: Fri, 10 Aug 2001 09:42:58 -0700
Message-ID: <NFBBKBDFJCDMGCBKJLCJCEPGFCAA.deva@stargateip.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <CFD808D1D39ACB47ABFF586D484CC52E261E5C@HQMAILNODE1.COMMSTOR.Crossroads.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


Bob,

You wrote:
If mode page changes were not allowed to modify existing communication
parameters (for existing connections), then there is no problem.

[Deva]

I am not for modifying the mode pages through Mode select and I am fine
accessing the mode pages through
Mode sense commands,which the current draft anyway allows.

[You wrote]
Once all active connections were dropped, then the re-establishment of
connections would present new defaults for critical iSCSI or SCSI
parameters.  Does this sound reasonable?

[Deva]
I am also not clear whether you are indicating a potential problem or the
expected behaviour.
When all connections are dropped then a session is as well closed. For a new
session anyway
parameters will be negotiated and should work the way it would. May be I
miss something. Can you
please clarify?

Thanks

Deva


-----Original Message-----
From: Robert Griswold [mailto:rgriswold@crossroads.com]
Sent: Friday, August 10, 2001 6:25 AM
To: deva@stargateip.com; Eddy Quicksall; Jim Hafner
Cc: ips@ece.cmu.edu
Subject: RE: Review of the 07 draft


Deva:

I would argue that having two ways to change the same thing adds
flexibility, rather than complexity.  If the iSCSI Text Messages are
allowed to change iSCSI only parameters, then the transport has access
to what it needs.  In addition, if the SCSI utility is aware of iSCSI
mode pages (which of course it would need to be to even understand
accessing iSCSI pages), then only one interface is needed for all
aspects of the target.  As stated by Eddy, the legacy of SCSI is that
mode pages, irrespective of what those parameters are manipulating
(transport, commands, responses, timing, etc.), are accessible through
SCSI mode commands.

If mode page changes were not allowed to modify existing communication
parameters (for existing connections), then there is no problem.  Once
all active connections were dropped, then the re-establishment of
connections would present new defaults for critical iSCSI or SCSI
parameters.  Does this sound reasonable?

Bob

Robert Griswold
Technologist
Crossroads Systems, Inc.
512-928-7272

 -----Original Message-----
From: 	Dev [mailto:deva@stargateip.com]
Sent:	Thursday, August 09, 2001 7:33 PM
To:	Robert Griswold; Eddy Quicksall; Jim Hafner
Cc:	ips@ece.cmu.edu
Subject:	RE: Review of the 07 draft

All,

I tend to disagree. The parameters for the iSCSI are negotiated between
the
initiator and target.
If we allow the parameters to be changed through SCSI Mode select, how
will
this work?

If parameters can be changed through SCSI Mode select then it will apply
only to Lead only connections.

So, we'll have

a) two methods to change the Lead only parameters common for the entire
session (one through mode select
and the other through text parameters)
b) Just iSCSI text command to change the connection specific parameters.

Does it not add to complexity having multiple ways to change the same
stuff?

Thanks

Deva
Platys communications

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Robert Griswold
Sent: Thursday, August 09, 2001 1:36 PM
To: Eddy Quicksall; Jim Hafner
Cc: ips@ece.cmu.edu
Subject: RE: Review of the 07 draft


Eddy:

I actually have no problem with all mode pages (SCSI and iSCSI) being
accessible and changeable from standard SCSI mode commands.  My initial
response to this section was to propose a method that would be
acceptable to the authors of the iSCSI draft.  If there is desire in the
group to allow mode pages for the entire target to be manipulated from
the SCSI level, I think that is a better idea that the one I proposed.
I would assume that an iSCSI aware SCSI utility would understand the
iSCSI specific settings, and allow the user to make those changes.  What
I am really against, is the ability to modify standard SCSI mode page
settings from text messages, as that could lead to target behavior
changes outside of the understanding of the SCSI nexus.

To recap your thinking:  Allow iSCSI text messages to modify and read
iSCSI only mode settings (potentially allowing the reading if SCSI mode
settings), but allow SCSI mode commands to modify and read all target
mode settings, including iSCSI settings.  Is that what you are saying.
If so, I agree.

Bob

Robert Griswold
Technologist
Crossroads Systems, Inc.
512-928-7272

 -----Original Message-----
From: 	Eddy Quicksall [mailto:ESQuicksall@hotmail.com]
Sent:	Thursday, August 09, 2001 2:08 PM
To:	Robert Griswold; Jim Hafner
Cc:	ips@ece.cmu.edu
Subject:	Re: Review of the 07 draft

I don't like the idea of not letting a user of a SCSI utility be able to
change some of the parameters for iSCSI. Because they may be relevant to
him
and there may not be a user interface to the iSCSI driver. pSCSI sets
these
low level parameters via a standard mode set, so why not iSCSI?

It would be best if we could work out something where only the SCSI
layer
can set the mode pages. That would solve everything.

Eddy

----- Original Message -----
From: "Jim Hafner" <hafner@almaden.ibm.com>
To: "Robert Griswold" <rgriswold@Crossroads.com>
Cc: <ips@ece.cmu.edu>
Sent: Friday, August 03, 2001 5:26 PM
Subject: Re: Review of the 07 draft

> Well, in fact, the draft is supposed to say that MODE_SELECT for the
> transport-specific mode page will NOT be done via SCSI, only via Text
> commands.  I read that as saying that from the SCSI layer, all fields
in
> these pages are "unchangeable" (even though they can change in the
iSCSI
> layer).  Of course, the draft doesn't say whether MODE PARAMETERS HAVE
> CHANGED unit attentions get thrown up at the SCSI layer when this
happens
> at the iSCSI layer.... You later have a clarifying question (Section
3) on
> this as well.
>
> Regards,
> Jim Hafner
>
>
>
>






From owner-ips@ece.cmu.edu  Fri Aug 10 20:12:40 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13348
	for <ips-archive@odin.ietf.org>; Fri, 10 Aug 2001 20:12:40 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7AMYcd28137
	for ips-outgoing; Fri, 10 Aug 2001 18:34:38 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7AMYXe28131
	for <ips@ece.cmu.edu>; Fri, 10 Aug 2001 18:34:33 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id AAA57390
	for <ips@ece.cmu.edu>; Sat, 11 Aug 2001 00:34:16 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7AMYFt78760
	for <ips@ece.cmu.edu>; Sat, 11 Aug 2001 00:34:15 +0200
Importance: Normal
Subject: Re: iSCSI - Response/Status
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFE40FE7D4.F3B90460-ONC2256AA4.007BB43C@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Sat, 11 Aug 2001 01:33:55 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 11/08/2001 01:34:15
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


We left them both as they might end-up not being mutually exclusive
sometime in the future.
On the surface it looks like the FCP designers went through the same line
of argument.

Regards,
Julo


"Eddy Quicksall" <ESQuicksall@hotmail.com> on 10-08-2001 18:00:31

Please respond to "Eddy Quicksall" <ESQuicksall@hotmail.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   <ips@ece.cmu.edu>
Subject:  Re: iSCSI - Response/Status



Sorry, I get it now ... I was mixing the old and new in my thinking.

But, I'm still wondering why the S bit was removed and the fields were put
into two places because they still seem to be mutually exclusive. I really
don't have a problem but I thought someone had a good idea since the S bit
clearly showed they are mutually exclusive.

Also, it looks like the old S bit has been changed to a fixed zero instead
of a reserved bit. Could it be that in this case "0" means "reserved"?

Eddy

----- Original Message -----
From: "Julian Satran" <Julian_Satran@il.ibm.com>
To: <ips@ece.cmu.edu>
Sent: Friday, August 10, 2001 3:07 AM
Subject: Re: iSCSI - Response/Status


>
> Eddy,
>
> The iSCSI condition is listed under reason.
> The Response field is 00 (else the status is not valid) as stated in the
> first paragraph..
>
> Julo
>
> "Eddy Quicksall" <ESQuicksall@hotmail.com> on 09-08-2001 22:16:50
>
> Please respond to "Eddy Quicksall" <ESQuicksall@hotmail.com>
>
> To:   Julian Satran/Haifa/IBM@IBMIL
> cc:   <ips@ece.cmu.edu>
> Subject:  Re: iSCSI - Response/Status
>
>
>
> Can you list, in the table, which "iSCSI conditions" result in the Check
> Condition?
>
> Also, would it be useful to make it clear that the Status and Response
> fields would both be set in this case?
>
> Eddy
> ----- Original Message -----
> From: "Julian Satran" <Julian_Satran@il.ibm.com>
> To: <ips@ece.cmu.edu>
> Sent: Thursday, August 09, 2001 1:33 PM
> Subject: iSCSI - Response/Status
>
>
> > According to the discusions on the list 2.4.2 & 2.4.3 have been fixed
to
> > read:
> >
> > 1.1.1     Status
> >
> >    The Status field is used to report the SCSI status of the command
(as
> >    specified in [SAM2]) and is valid only if the Response Code is
Command
> >    Completed at target.
> >
> >    If a SCSI device error is detected while data from the initiator is
> >    still expected (the command PDU did not contain all the data and the
> >    target has not received a Data PDU with the final bit Set) the
target
> >    MUST wait until it receives the a Data PDU with the F bit set, in
the
> >    last expected sequence, before sending the Response PDU.
> >
> > 1.1.2     Response
> >
> >    This field contains iSCSI service response.
> >
> >    Valid iSCSI service response codes are:
> >
> >       0x00 - Command Completed at Target
> >       0x01 - Target Failure
> >       0x02 - Delivery Subsystem Failure
> >       0x80-0xff - Reserved for Vendor-Unique Responses
> >
> >    The Response is used to report a Service Response. The exact mapping
> of
> >    the iSCSI response codes to SAM service response symbols is outside
> the
> >    scope of this document.
> >
> >    Certain iSCSI conditions result in the command being terminated at
the
> >    target (response Command Completed at Target) with a SCSI Check
> >    Condition Status as outlined in the next table:
> >
> >    +------------------------------+---------------------------+
> >    | Reason                       | with SCSI CHECK CONDITION |
> >    +------------------------------+---------------------------+
> >    | Unsolicited data rejected    | ASC = 0x49 ASCQ = 0x00    |
> >    +------------------------------+---------------------------+
> >    | Not enough unsolicited       | ASC = 0x4B ASCQ = 0x00    |
> >    +------------------------------+---------------------------+
> >    | SNACK rejected               | ASC = 0x47 ASCQ = 0x03    |
> >    +------------------------------+---------------------------+
> >
> >    N.B. Unsolicited data rejected condition is reported used by the
> target
> >    only if it does not support output (write) operations in which the
> total
> >    data length is higher than FirstBurstSize but the initiator sent
less
> >    than first burst size and out-of-order R2Ts can't be used.
> >
> >    Julo
> >
> >
>
>
>
>





From owner-ips@ece.cmu.edu  Fri Aug 10 23:37:44 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16737
	for <ips-archive@odin.ietf.org>; Fri, 10 Aug 2001 23:37:43 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7B2VBQ06978
	for ips-outgoing; Fri, 10 Aug 2001 22:31:11 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail07b.vwh1.net (mail07b.vwh1.net [209.238.9.59])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f7AIBYe12357
	for <ips@ece.cmu.edu>; Fri, 10 Aug 2001 14:11:34 -0400 (EDT)
Received: from www.platys.com (208.55.89.7)
	by mail07b.vwh1.net (RS ver 1.0.60s) with SMTP id 031359527;
	Fri, 10 Aug 2001 14:11:16 -0400 (EDT)
From: "Dev - Platys" <deva@platys.com>
To: "Robert Snively" <rsnively@Brocade.COM>,
        "Robert Griswold" <rgriswold@Crossroads.com>,
        "Eddy Quicksall" <ESQuicksall@hotmail.com>,
        "Jim Hafner" <hafner@almaden.ibm.com>
Cc: <ips@ece.cmu.edu>
Subject: RE: Review of the 07 draft
Date: Fri, 10 Aug 2001 11:15:43 -0700
Message-ID: <NFBBKBDFJCDMGCBKJLCJEEPIFCAA.deva@platys.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
In-Reply-To: <FFD40DB4943CD411876500508BAD02790299373D@sj5-ex2.brocade.com>
X-Loop-Detect: 1
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Bob,

Are you suggesting that specific fields within mode parameters be changable
ONLY through
Mode select commands - e.g. EMDP - i.e. iSCSI Data order. (I guess
iSCSI-Data delivery order should be
iSCSI specific and not reflected in mode parameters), EPDC (CRN) etc? If so,
I am with you.

Thanks

Deva




-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Robert Snively
Sent: Friday, August 10, 2001 12:32 AM
To: 'deva@stargateip.com'; Robert Griswold; Eddy Quicksall; Jim Hafner
Cc: ips@ece.cmu.edu
Subject: RE: Review of the 07 draft


Deva,

Both of you are right if iSCSI sticks to negotiating only
parameters related with the TCP connections, the iSCSI
session operational parameters other than EMDP and
burst length, and iSCSI security parameters.  Then, all
parameters relating to the normal SCSI activities, including
EMDP and burst length (which are required for SCSI, not iSCSI,
buffer management) would be negotiated in the normal
SCSI manner through the MODE SENSE/SELECT pages and everybody
would live happily ever after.

Otherwise, and especially with respect to EMDP and burst length,
I have to agree with Robert.

Bob Snively                        e-mail:    rsnively@brocade.com
Brocade Communications Systems     phone:  408 487 8135
1745 Technology Drive
San Jose, CA 95110



-----Original Message-----
From: Dev [mailto:deva@stargateip.com]
Sent: Thursday, August 09, 2001 5:33 PM
To: Robert Griswold; Eddy Quicksall; Jim Hafner
Cc: ips@ece.cmu.edu
Subject: RE: Review of the 07 draft


All,

I tend to disagree. The parameters for the iSCSI are negotiated between the
initiator and target.
If we allow the parameters to be changed through SCSI Mode select, how will
this work?

If parameters can be changed through SCSI Mode select then it will apply
only to Lead only connections.

So, we'll have

a) two methods to change the Lead only parameters common for the entire
session (one through mode select
and the other through text parameters)
b) Just iSCSI text command to change the connection specific parameters.

Does it not add to complexity having multiple ways to change the same stuff?

Thanks

Deva
Platys communications

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Robert Griswold
Sent: Thursday, August 09, 2001 1:36 PM
To: Eddy Quicksall; Jim Hafner
Cc: ips@ece.cmu.edu
Subject: RE: Review of the 07 draft


Eddy:

I actually have no problem with all mode pages (SCSI and iSCSI) being
accessible and changeable from standard SCSI mode commands.  My initial
response to this section was to propose a method that would be
acceptable to the authors of the iSCSI draft.  If there is desire in the
group to allow mode pages for the entire target to be manipulated from
the SCSI level, I think that is a better idea that the one I proposed.
I would assume that an iSCSI aware SCSI utility would understand the
iSCSI specific settings, and allow the user to make those changes.  What
I am really against, is the ability to modify standard SCSI mode page
settings from text messages, as that could lead to target behavior
changes outside of the understanding of the SCSI nexus.

To recap your thinking:  Allow iSCSI text messages to modify and read
iSCSI only mode settings (potentially allowing the reading if SCSI mode
settings), but allow SCSI mode commands to modify and read all target
mode settings, including iSCSI settings.  Is that what you are saying.
If so, I agree.

Bob

Robert Griswold
Technologist
Crossroads Systems, Inc.
512-928-7272

 -----Original Message-----
From: 	Eddy Quicksall [mailto:ESQuicksall@hotmail.com]
Sent:	Thursday, August 09, 2001 2:08 PM
To:	Robert Griswold; Jim Hafner
Cc:	ips@ece.cmu.edu
Subject:	Re: Review of the 07 draft

I don't like the idea of not letting a user of a SCSI utility be able to
change some of the parameters for iSCSI. Because they may be relevant to
him
and there may not be a user interface to the iSCSI driver. pSCSI sets
these
low level parameters via a standard mode set, so why not iSCSI?

It would be best if we could work out something where only the SCSI
layer
can set the mode pages. That would solve everything.

Eddy

----- Original Message -----
From: "Jim Hafner" <hafner@almaden.ibm.com>
To: "Robert Griswold" <rgriswold@Crossroads.com>
Cc: <ips@ece.cmu.edu>
Sent: Friday, August 03, 2001 5:26 PM
Subject: Re: Review of the 07 draft

> Well, in fact, the draft is supposed to say that MODE_SELECT for the
> transport-specific mode page will NOT be done via SCSI, only via Text
> commands.  I read that as saying that from the SCSI layer, all fields
in
> these pages are "unchangeable" (even though they can change in the
iSCSI
> layer).  Of course, the draft doesn't say whether MODE PARAMETERS HAVE
> CHANGED unit attentions get thrown up at the SCSI layer when this
happens
> at the iSCSI layer.... You later have a clarifying question (Section
3) on
> this as well.
>
> Regards,
> Jim Hafner
>
>
>
>


From owner-ips@ece.cmu.edu  Fri Aug 10 23:38:10 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16749
	for <ips-archive@odin.ietf.org>; Fri, 10 Aug 2001 23:38:10 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7B2UOF06944
	for ips-outgoing; Fri, 10 Aug 2001 22:30:24 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dominoe.integrix.com ([207.171.9.89])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7AGTee07357
	for <ips@ece.cmu.edu>; Fri, 10 Aug 2001 12:29:40 -0400 (EDT)
Received: from integrix.com (rellis [192.9.200.208])
	by dominoe.integrix.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA15003
	for <ips@ece.cmu.edu>; Fri, 10 Aug 2001 09:28:04 -0700 (PDT)
Message-ID: <3B740CA5.8B1F82CF@integrix.com>
Date: Fri, 10 Aug 2001 09:32:37 -0700
From: Rick Ellis <rellis@integrix.com>
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: ips@ece.cmu.edu
Subject: Re: iSCSI - Response/Status
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


>If a SCSI device error is detected while data from the initiator is
>still expected (the command PDU did not contain all the data and the
>target has not received a Data PDU with the final bit Set) the target
>MUST wait until it receives the a Data PDU with the F bit set, in the
>last expected sequence, before sending the Response PDU.

Is there any provision for timeout?


From owner-ips@ece.cmu.edu  Sat Aug 11 02:00:58 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26791
	for <ips-archive@odin.ietf.org>; Sat, 11 Aug 2001 02:00:58 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7B4xYr17846
	for ips-outgoing; Sat, 11 Aug 2001 00:59:34 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e34.bld.us.ibm.com (e34.co.us.ibm.com [32.97.110.132])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7B4xXe17841
	for <ips@ece.cmu.edu>; Sat, 11 Aug 2001 00:59:33 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e34.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id AAA72948
	for <ips@ece.cmu.edu>; Sat, 11 Aug 2001 00:57:26 -0400
Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7B4xVO46032
	for <ips@ece.cmu.edu>; Fri, 10 Aug 2001 22:59:31 -0600
X-Priority: 1 (High)
Importance: Normal
Subject: Re: iSCSI: draft 7: remove S bit and Status field from the Data-in PD U?
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OF2912043E.45930D7F-ON88256AA4.004CEC70@boulder.ibm.com>
From: "John Hufferd" <hufferd@us.ibm.com>
Date: Fri, 10 Aug 2001 07:35:39 -0700
X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.6 |December 14, 2000) at
 08/10/2001 10:59:31 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Folks,
I might have this all wrong, but it seems to me that we are jumping on the
simplification horse from all directions, whether or not it is right, just
to say we are trying to simplify.  I am afraid that some of this may be at
the expense of "at Distance" installations.

First, immediate and unsolicited separate Data PDUs are very valuable for
situations where the Target is at distance from the Initiator.  (A good
example is writing to tape.  Most tape are only written and hardly ever
read.  Further, many folks would like to have tapes somewhere else -- at a
distance.)  The ability not to have to have R2T exchanges over distance is
an important feature.  Let us not quickly throw that out.

Second, thoughts of removing the immediate data seem not to be
simplification, since all the information to tie the data to the command is
right there with the command.  That has got to be easier then matching up
separate PDUs of data with the approprate commands.

So I am concerned that one of the important strengths of iSCSI -- that
being the ability to efficiently operate at distances where Fibre Channel
would fear to tread -- is being too quickly put aside.

Therefore, if you do not eliminate immediate Data (since that is the most
efficient, especially for the smaller data sizes), you are faced with
removing unsolicited Data Packets and only permitting R2T -- which has a
round trip handshake that is needed to get the data.  From a latency
standpoint this does not seem good.

I can imagine some vendor making a claim that their Storage Unit is the
Industry's best "at Distance" storage controller, but it has more memory
and might be a bit more expensive then the typical R2T based Storage Units
(since they accept unsolicited Data PDUs), but I think that is good.  We
need vendors to offer those types of solutions.

If you do not want unsolicited or immediate Data PDUs, don't accept them at
Login.  But, they were put into the protocol for a reason, and I hope we
continue to have the features that keep iSCSI a distance compatible
protocol.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com



From owner-ips@ece.cmu.edu  Sat Aug 11 02:02:34 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28511
	for <ips-archive@odin.ietf.org>; Sat, 11 Aug 2001 02:02:34 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7B4xip17854
	for ips-outgoing; Sat, 11 Aug 2001 00:59:44 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e33.bld.us.ibm.com (e33.co.us.ibm.com [32.97.110.131])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7B4xhe17850
	for <ips@ece.cmu.edu>; Sat, 11 Aug 2001 00:59:43 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e33.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id XAA09694;
	Fri, 10 Aug 2001 23:57:33 -0500
Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7B4xZO300242;
	Fri, 10 Aug 2001 22:59:38 -0600
X-Priority: 1 (High)
Importance: Normal
Subject: RE: Review of the 07 draft
To: "Robert Griswold" <rgriswold@Crossroads.com>
Cc: "Eddy Quicksall" <ESQuicksall@hotmail.com>,
        "Jim Hafner" <hafner@almaden.ibm.com>, <ips@ece.cmu.edu>
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OFEC22943F.9668FD57-ON88256AA4.0053F731@boulder.ibm.com>
From: "John Hufferd" <hufferd@us.ibm.com>
Date: Fri, 10 Aug 2001 08:48:32 -0700
X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.6 |December 14, 2000) at
 08/10/2001 10:59:38 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


I am not sure that I feel real good about what you are stating here.  I
think the iSCSI Mode Pages are the persistent location for the iSCSI Modes,
but I think iSCSI will have the values in variables that they have in
memory/cache that iSCSI uses ongoing.  If a SCSI command was to change
those values I am not sure that iSCSI will see the changes.

I thought we had previously agreed (for the reasons above) that iSCSI sets
its pages and SCSI sets its pages.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com


"Robert Griswold" <rgriswold@Crossroads.com>@ece.cmu.edu on 08/09/2001
01:36:14 PM

Sent by:  owner-ips@ece.cmu.edu


To:   "Eddy Quicksall" <ESQuicksall@hotmail.com>, Jim
      Hafner/Almaden/IBM@IBMUS
cc:   <ips@ece.cmu.edu>
Subject:  RE: Review of the 07 draft



Eddy:

I actually have no problem with all mode pages (SCSI and iSCSI) being
accessible and changeable from standard SCSI mode commands.  My initial
response to this section was to propose a method that would be
acceptable to the authors of the iSCSI draft.  If there is desire in the
group to allow mode pages for the entire target to be manipulated from
the SCSI level, I think that is a better idea that the one I proposed.
I would assume that an iSCSI aware SCSI utility would understand the
iSCSI specific settings, and allow the user to make those changes.  What
I am really against, is the ability to modify standard SCSI mode page
settings from text messages, as that could lead to target behavior
changes outside of the understanding of the SCSI nexus.

To recap your thinking:  Allow iSCSI text messages to modify and read
iSCSI only mode settings (potentially allowing the reading if SCSI mode
settings), but allow SCSI mode commands to modify and read all target
mode settings, including iSCSI settings.  Is that what you are saying.
If so, I agree.

Bob

Robert Griswold
Technologist
Crossroads Systems, Inc.
512-928-7272

 -----Original Message-----
From:     Eddy Quicksall [mailto:ESQuicksall@hotmail.com]
Sent:     Thursday, August 09, 2001 2:08 PM
To:  Robert Griswold; Jim Hafner
Cc:  ips@ece.cmu.edu
Subject:  Re: Review of the 07 draft

I don't like the idea of not letting a user of a SCSI utility be able to
change some of the parameters for iSCSI. Because they may be relevant to
him
and there may not be a user interface to the iSCSI driver. pSCSI sets
these
low level parameters via a standard mode set, so why not iSCSI?

It would be best if we could work out something where only the SCSI
layer
can set the mode pages. That would solve everything.

Eddy

----- Original Message -----
From: "Jim Hafner" <hafner@almaden.ibm.com>
To: "Robert Griswold" <rgriswold@Crossroads.com>
Cc: <ips@ece.cmu.edu>
Sent: Friday, August 03, 2001 5:26 PM
Subject: Re: Review of the 07 draft

> Well, in fact, the draft is supposed to say that MODE_SELECT for the
> transport-specific mode page will NOT be done via SCSI, only via Text
> commands.  I read that as saying that from the SCSI layer, all fields
in
> these pages are "unchangeable" (even though they can change in the
iSCSI
> layer).  Of course, the draft doesn't say whether MODE PARAMETERS HAVE
> CHANGED unit attentions get thrown up at the SCSI layer when this
happens
> at the iSCSI layer.... You later have a clarifying question (Section
3) on
> this as well.
>
> Regards,
> Jim Hafner
>
>
>
>







From owner-ips@ece.cmu.edu  Sat Aug 11 02:03:16 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAB29215
	for <ips-archive@odin.ietf.org>; Sat, 11 Aug 2001 02:03:16 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7B4xUe17839
	for ips-outgoing; Sat, 11 Aug 2001 00:59:30 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e33.bld.us.ibm.com (e33.co.us.ibm.com [32.97.110.131])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7B4xSe17834
	for <ips@ece.cmu.edu>; Sat, 11 Aug 2001 00:59:28 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e33.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id XAA25770;
	Fri, 10 Aug 2001 23:57:22 -0500
Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7B4xRO243394;
	Fri, 10 Aug 2001 22:59:27 -0600
X-Priority: 1 (High)
Importance: Normal
Subject: RE: iSCSI: Support Alias in the protocol
To: Robert Snively <rsnively@Brocade.COM>
Cc: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OF1BAF8BEC.F0794B70-ON88256AA4.00411C79@boulder.ibm.com>
From: "John Hufferd" <hufferd@us.ibm.com>
Date: Fri, 10 Aug 2001 05:10:27 -0700
X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.6 |December 14, 2000) at
 08/10/2001 10:59:26 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Robert,
You make good points, however, I would say that they show that an alias in
the protocol is useful.  The items you list are not an "eui" iSCSI
Initiator or Target Node name.  The fact that and "eui" name can be a bunch
of Hex numbers, is the exact reason that a human way to talk about it, and
get MIB and SNMP reports is useful and important.  There is no other item
in the system or the SCSI level that has a method of identifying an iSCSI
Initiator or Target via a Human oriented name.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com


Robert Snively <rsnively@brocade.com> on 08/10/2001 12:06:54 AM

To:   John Hufferd/San Jose/IBM@IBMUS, ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: Support Alias in the protocol



John,

I feel that the alias does not belong in the iSCSI architecture.
Aliasing is already routinely provided at two other levels in
the protocol stack and need not be redundantly inserted in iSCSI.

a)  In the SCSI command set

There is already available a logical unit level aliasing process
using the SET/REPORT DEVICE IDENTIFIER service actions defined
in the SCSI command set standard SPC-2.

b)  In the operating system stack

Most implementations use aliases created at the system level, not
the protocol level, that are far more useful and can be tuned
to the particular environment.  A particularly naive example of
this is the mapping of identified devices to the A:, B:, or
C: disk drives in the similarly naive MS-DOS operating system.
More sophisticated systems and management structures use similar
aliasing at the system level.

Bob

-----Original Message-----
From: John Hufferd [mailto:hufferd@us.ibm.com]
Sent: Tuesday, August 07, 2001 9:52 AM
To: ips@ece.cmu.edu
Subject: iSCSI: Support Alias in the protocol


Today at the 51st meeting of the IETF, I presented an issue that came out
of the Naming and Discovery Team.

That was that some members of the team did not understand why we needed to
have an Alias field, which is in the base protocol today, since it was
technically not needed.   The position I presented to the group was that
the Naming and Discovery Team did not have consensus, since many of us felt
that having a Human oriented "Tagging" function was useful, and a small
item which would be useful for Administrators especially when EUI names are
used.

One person, at the meeting today, stated that it might not be of extreme
importance on large Networks with sophisticated Management tools, but it
was very useful in small to medium environments, where the Management tools
were slim.  And at least one person stated that since it was not required,
it should not be in the protocol.

As the conversations when on, it was pointed out by the area director,
Scott  Bradner, that SLP used a similar Text field in its protocol, so
there was clearly a president.

In any event, we could not reach consensus at the meeting, so I was asked
to bring the issue to the List.  (So here it is!)

Please state your positions so that David can call a consensus.



.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com






From owner-ips@ece.cmu.edu  Sat Aug 11 04:22:47 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04709
	for <ips-archive@odin.ietf.org>; Sat, 11 Aug 2001 04:22:47 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7B7Ksj22110
	for ips-outgoing; Sat, 11 Aug 2001 03:20:54 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7B7Kqe22106
	for <ips@ece.cmu.edu>; Sat, 11 Aug 2001 03:20:53 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id JAA260658
	for <ips@ece.cmu.edu>; Sat, 11 Aug 2001 09:20:45 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7B7KjY77770
	for <ips@ece.cmu.edu>; Sat, 11 Aug 2001 09:20:45 +0200
Importance: Normal
Subject: Re: CmdSN during login
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF20251D1C.B554A3E2-ONC2256AA5.002783FA@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Sat, 11 Aug 2001 10:20:24 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 11/08/2001 10:20:44
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Mallikarjun,

I do realize that there are cases when the whole of the login sequence have
to be executed "out of order".
There are however cases when the login has to be executed in order (e.g.,
after an abort or after a logoout).
This is why I think that no new mechanism is needed (not considering them
unnumbered by default) and the Immediate command flag will cover all the
needs (together with the "one outstanding command" rule that holds for
login).
The confusion previously quote is when does numbering start and that is
from the first command of the first login.
For the leading login (the one creating a session) having the commands
immediate or not is less relevant as
those are the only commands arriving and no other connection can be
established.

Regards,
Julo

"Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on 10-08-2001 17:54:38

Please respond to cbm@rose.hp.com

Sent by:  owner-ips@ece.cmu.edu


To:   Julian Satran/Haifa/IBM@IBMIL
cc:   ips@ece.cmu.edu
Subject:  Re: CmdSN during login



Julian,

I tend to agree with Mark and Sanjay.

In cases where all connections in a session failed and a new
connection is being added to the existing session state (before
the session timeout), an initiator must issue the Login as an
immediate command to avoid the possibility of a deadlock - since
the initiator does not know for sure if target received all commands
on the failed connections.

Since this appears to be a mandatory requirement, I suggest that
we make it the default behavior - that Login PDUs never *consume*
CmdSNs (though the leading login carries a valid "seed" CmdSN),
including the leading login PDU.  There are no conditionals this way.

Sorry, I can't find the reasoning you offered earlier for rev07
behavior, in the middle of my travel.  Please comment if I missed
something.
--
Mallikarjun

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

Julian Satran wrote:
>
> Sanjay,
>
> If you want to ignore CmdSN and expedite Login processing you can do so
by
> having the commands being issued as immediate.
> This will help us keep away from creating ambiguity about (or another
> conditional) for when CmdSN is to be used or not.
>
> Julo
>
> Mark Bakke <mbakke@cisco.com>@ece.cmu.edu on 09-08-2001 23:55:25
>
> Please respond to Mark Bakke <mbakke@cisco.com>
>
> Sent by:  owner-ips@ece.cmu.edu
>
> To:   Sanjay Goyal <sanjay_goyal@ivivity.com>
> cc:   "Ips (E-mail)" <ips@ece.cmu.edu>
> Subject:  Re: CmdSN during login
>
> Sanjay-
>
> I absolutely agree with this; CmdSN is owned by the session, and
> should not be used until the connection has fully joined the session,
> which means full feature phase.
>
> This should also clean up any ambiguity on when to start
> using CmdSN.
>
> --
> Mark
>
> Sanjay Goyal wrote:
> >
> > Hi
> >
> >  Assuming Target and Initiator support multiple connections and the
> session
> > is having multiple connections. Assuming out-of-order CmdSN is a
> possibility
> > for this session.
> >
> >  Connection #   1       |       2       |       3
> > -------------------------------------------------------
> > Login Cmd  CmdSN=0      |   CmdSN=8     |  CmdSN=9
> > Txt   Cmd  CmdSN=1      |               |
> >                                 |               |
> >                                 |               |
> > Login Cmd  CmdSN=7      |  CmdSN=10     |  CmdSN=11
> > -------------------------------------------------------
> > Data Cmd   CmdSN=12     | CmdSN=14      | CmdSN=15
> > Data Cmd   CmdSN=13     |               |
> >                                 |               |
> >
> > CmdSN=7 is last of the Login sequence and it is acknowledged by the
> Target
> > with "accept login" response.
> >
> > Target would receive the PDUs in this CmdSN order
> >  0 to 7, 8, 9, 12, 10, 11, 13, 14, 15
> >
> > Now as Login and Text PDUs are being processed even though you have
> received
> > Data Cmd PDUs, you can not pass them to iSCSI layer and hence you are
> adding
> > latency.
> >
> > What I want to convey from this example is why not use CmdSN just
during
> the
> > FullFeature phase only.
> >
> > Regards
> > Sanjay Goyal
> >
> >
>
----------------------------------------------------------------------------------------------------

>
> >
> >    Part 1.2    Type: application/ms-tnef
> >            Encoding: base64
>
> --
> Mark A. Bakke
> Cisco Systems
> mbakke@cisco.com
> 763.398.1054





From owner-ips@ece.cmu.edu  Sat Aug 11 12:40:41 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07268
	for <ips-archive@odin.ietf.org>; Sat, 11 Aug 2001 12:40:41 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7BFbJZ17424
	for ips-outgoing; Sat, 11 Aug 2001 11:37:19 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7BFbBe17416
	for <ips@ece.cmu.edu>; Sat, 11 Aug 2001 11:37:12 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id RAA180972
	for <ips@ece.cmu.edu>; Sat, 11 Aug 2001 17:37:04 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7BFb3Y215056
	for <ips@ece.cmu.edu>; Sat, 11 Aug 2001 17:37:04 +0200
Importance: Normal
Subject: Re: CmdSN during login
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFC7A76140.9DA71B12-ONC2256AA5.00558939@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Sat, 11 Aug 2001 18:36:41 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 11/08/2001 18:37:04
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

There was ambiguity at first login that we have cleared in text and as I
said I don't see any good reason
for another case of immediate when we have the immediate bit available.
What we could do is add anothe pragraph to 8
recommending when to use the I bit in login.

Julo

"Eddy Quicksall" <ESQuicksall@hotmail.com> on 10-08-2001 18:13:32

Please respond to "Eddy Quicksall" <ESQuicksall@hotmail.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   <ips@ece.cmu.edu>
Subject:  Re: CmdSN during login



But, what if someone does this without setting the Immediate bit? What
would
one do?

What is wrong with just making the CmdSN not run during login? It seems
like
it was an arbitrary choice in the first place since it was originally
optional and not using it actually worked.

If CmdSN is stated as only used in FFP, then I don't see any ambiguity.

Eddy
----- Original Message -----
From: "Julian Satran" <Julian_Satran@il.ibm.com>
To: <ips@ece.cmu.edu>
Sent: Friday, August 10, 2001 2:43 AM
Subject: Re: CmdSN during login


>
> Sanjay,
>
> If you want to ignore CmdSN and expedite Login processing you can do so
by
> having the commands being issued as immediate.
> This will help us keep away from creating ambiguity about (or another
> conditional) for when CmdSN is to be used or not.
>
> Julo
>
> Mark Bakke <mbakke@cisco.com>@ece.cmu.edu on 09-08-2001 23:55:25
>
> Please respond to Mark Bakke <mbakke@cisco.com>
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   Sanjay Goyal <sanjay_goyal@ivivity.com>
> cc:   "Ips (E-mail)" <ips@ece.cmu.edu>
> Subject:  Re: CmdSN during login
>
>
>
>
> Sanjay-
>
> I absolutely agree with this; CmdSN is owned by the session, and
> should not be used until the connection has fully joined the session,
> which means full feature phase.
>
> This should also clean up any ambiguity on when to start
> using CmdSN.
>
> --
> Mark
>
> Sanjay Goyal wrote:
> >
> > Hi
> >
> >  Assuming Target and Initiator support multiple connections and the
> session
> > is having multiple connections. Assuming out-of-order CmdSN is a
> possibility
> > for this session.
> >
> >  Connection #   1       |       2       |       3
> > -------------------------------------------------------
> > Login Cmd  CmdSN=0      |   CmdSN=8     |  CmdSN=9
> > Txt   Cmd  CmdSN=1      |               |
> >                                 |               |
> >                                 |               |
> > Login Cmd  CmdSN=7      |  CmdSN=10     |  CmdSN=11
> > -------------------------------------------------------
> > Data Cmd   CmdSN=12     | CmdSN=14      | CmdSN=15
> > Data Cmd   CmdSN=13     |               |
> >                                 |               |
> >
> > CmdSN=7 is last of the Login sequence and it is acknowledged by the
> Target
> > with "accept login" response.
> >
> > Target would receive the PDUs in this CmdSN order
> >  0 to 7, 8, 9, 12, 10, 11, 13, 14, 15
> >
> > Now as Login and Text PDUs are being processed even though you have
> received
> > Data Cmd PDUs, you can not pass them to iSCSI layer and hence you are
> adding
> > latency.
> >
> > What I want to convey from this example is why not use CmdSN just
during
> the
> > FullFeature phase only.
> >
> > Regards
> > Sanjay Goyal
> >
> >
>
--------------------------------------------------------------------------
--------------------------
>
> >
> >    Part 1.2    Type: application/ms-tnef
> >            Encoding: base64
>
> --
> Mark A. Bakke
> Cisco Systems
> mbakke@cisco.com
> 763.398.1054
>
>
>
>





From owner-ips@ece.cmu.edu  Sat Aug 11 14:47:41 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08134
	for <ips-archive@odin.ietf.org>; Sat, 11 Aug 2001 14:47:41 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7BI08022093
	for ips-outgoing; Sat, 11 Aug 2001 14:00:08 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7BI07e22089
	for <ips@ece.cmu.edu>; Sat, 11 Aug 2001 14:00:07 -0400 (EDT)
Received: by ATLOPS with Internet Mail Service (5.5.2448.0)
	id <QMJCNCMZ>; Sat, 11 Aug 2001 14:00:02 -0400
Message-ID: <25369470B6F0D41194820002B328BDD210B328@ATLOPS>
From: Sukha Ghosh <sukha_ghosh@ivivity.com>
To: ips@ece.cmu.edu
Subject: iSCSI: Target Transfer Tag
Date: Sat, 11 Aug 2001 14:00:01 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Hi,

As I understood reading the specs, the Target Transfer Tag is supplied by
Target through R2T packets in the case of write command from Initiator (W
bit set) for solicited data transfer. In the case of unsolicited data
packets from Initiator through SCSI Data-Out, what should be the value of
Target Transfer Tag field in the SCSI Data-Out header? Would it be the
reserved value of 0xffffffff ?


From owner-ips@ece.cmu.edu  Sat Aug 11 20:05:16 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09861
	for <ips-archive@odin.ietf.org>; Sat, 11 Aug 2001 20:05:16 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7BNImg02560
	for ips-outgoing; Sat, 11 Aug 2001 19:18:48 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e34.bld.us.ibm.com (e34.co.us.ibm.com [32.97.110.132])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7BNIje02546
	for <ips@ece.cmu.edu>; Sat, 11 Aug 2001 19:18:45 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e34.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id TAA58912
	for <ips@ece.cmu.edu>; Sat, 11 Aug 2001 19:16:38 -0400
Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7BNIiT234272
	for <ips@ece.cmu.edu>; Sat, 11 Aug 2001 17:18:44 -0600
X-Priority: 1 (High)
Importance: High
Subject: Re: Use of project identifiers in posting subjects
To: IPS Reflector <ips@ece.cmu.edu>
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OF170361A1.5CC92D2E-ON88256AA5.006F6DE5@boulder.ibm.com>
From: "John Hufferd" <hufferd@us.ibm.com>
Date: Sat, 11 Aug 2001 13:33:29 -0700
X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.6 |December 14, 2000) at
 08/11/2001 05:18:43 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Folks,
Ralph Is right, in fact the "subject setting" is starting to get so casual
that it is now very irritating.  Many of us receive many e-mails and need
to respond to some at a different priority then others.  I was about to
send the same request today, when I saw Ralph's message.  So with the
knowledge that others fee the same way, let me stress that the message
should  begin with iSCSI:, iFCP:, or FCIP:, or possibly IPS: if it applies
to all.

If you receive a message, without such a prefix, please just add it in your
response.  Do not forward or respond using an un-prefixed message.   If the
message morphs into a different area, as some have done, then change the
prefix.

Please, everyone help.
.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com


Ralph Weber <ralphoweber@compuserve.com>@ece.cmu.edu on 08/10/2001 06:10:48
AM

Please respond to ENDL_TX@computer.org

Sent by:  owner-ips@ece.cmu.edu


To:   IPS Reflector <ips@ece.cmu.edu>
cc:
Subject:  Use of project identifiers in posting subjects



So, has this reflector officially gone over to being
the all iSCSI all the time reflector?

I notice that over 50% of the recent messages have
dropped the pretense that other topics are discussed
on this reflector by failing to include the "iSCSI"
identifier in the subject lines for topics devoted
solely that OTHER protocol for SCSI.  :-)

I think I speak for all of us working on the less
famous topics discussed on this reflector by reminding
you all that the subject lines of messages posted here
are supposed to contain a topic identifier, one of:

  FCIP
  iFCP
  iSCSI

Thanks.

Ralph...







From owner-ips@ece.cmu.edu  Sat Aug 11 20:05:44 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09872
	for <ips-archive@odin.ietf.org>; Sat, 11 Aug 2001 20:05:44 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7BNXS003044
	for ips-outgoing; Sat, 11 Aug 2001 19:33:28 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e33.bld.us.ibm.com (e33.co.us.ibm.com [32.97.110.131])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7BNXRe03040
	for <ips@ece.cmu.edu>; Sat, 11 Aug 2001 19:33:27 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e33.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA62930;
	Sat, 11 Aug 2001 18:31:20 -0500
Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7BNXPT123496;
	Sat, 11 Aug 2001 17:33:26 -0600
X-Priority: 1 (High)
Importance: Normal
Subject: RE: iSCSI: Support Alias in the protocol
To: Robert Snively <rsnively@Brocade.COM>
Cc: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OF015D5703.A4342C0C-ON88256AA5.00813223@boulder.ibm.com>
From: "John Hufferd" <hufferd@us.ibm.com>
Date: Sat, 11 Aug 2001 16:32:59 -0700
X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.6 |December 14, 2000) at
 08/11/2001 05:33:25 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Robert (the following resend has the sentence structured somewhat
improved),

You make good points, however, I would say that they show that an alias in
the protocol is useful.  The items you list are not an "eui" iSCSI
Initiator or Target Node name.  The fact that and "eui" name can be a bunch
of Hex numbers, is the exact reason that a human might want another way to
talk about it, and
that includes Alias in MIB and SNMP reports. There is no other item
in the system or the SCSI level that has a method of identifying an iSCSI
Initiator or Target via a Human oriented name.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com


Robert Snively <rsnively@brocade.com> on 08/10/2001 12:06:54 AM

To:   John Hufferd/San Jose/IBM@IBMUS, ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: Support Alias in the protocol



John,

I feel that the alias does not belong in the iSCSI architecture.
Aliasing is already routinely provided at two other levels in
the protocol stack and need not be redundantly inserted in iSCSI.

a)  In the SCSI command set

There is already available a logical unit level aliasing process
using the SET/REPORT DEVICE IDENTIFIER service actions defined
in the SCSI command set standard SPC-2.

b)  In the operating system stack

Most implementations use aliases created at the system level, not
the protocol level, that are far more useful and can be tuned
to the particular environment.  A particularly naive example of
this is the mapping of identified devices to the A:, B:, or
C: disk drives in the similarly naive MS-DOS operating system.
More sophisticated systems and management structures use similar
aliasing at the system level.

Bob

-----Original Message-----
From: John Hufferd [mailto:hufferd@us.ibm.com]
Sent: Tuesday, August 07, 2001 9:52 AM
To: ips@ece.cmu.edu
Subject: iSCSI: Support Alias in the protocol


Today at the 51st meeting of the IETF, I presented an issue that came out
of the Naming and Discovery Team.

That was that some members of the team did not understand why we needed to
have an Alias field, which is in the base protocol today, since it was
technically not needed.   The position I presented to the group was that
the Naming and Discovery Team did not have consensus, since many of us felt
that having a Human oriented "Tagging" function was useful, and a small
item which would be useful for Administrators especially when EUI names are
used.

One person, at the meeting today, stated that it might not be of extreme
importance on large Networks with sophisticated Management tools, but it
was very useful in small to medium environments, where the Management tools
were slim.  And at least one person stated that since it was not required,
it should not be in the protocol.

As the conversations when on, it was pointed out by the area director,
Scott  Bradner, that SLP used a similar Text field in its protocol, so
there was clearly a president.

In any event, we could not reach consensus at the meeting, so I was asked
to bring the issue to the List.  (So here it is!)

Please state your positions so that David can call a consensus.



.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com






From owner-ips@ece.cmu.edu  Sat Aug 11 20:09:57 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09892
	for <ips-archive@odin.ietf.org>; Sat, 11 Aug 2001 20:09:57 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7BNImu02561
	for ips-outgoing; Sat, 11 Aug 2001 19:18:48 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e33.bld.us.ibm.com (e33.co.us.ibm.com [32.97.110.131])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7BNIke02556
	for <ips@ece.cmu.edu>; Sat, 11 Aug 2001 19:18:46 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e33.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA48932
	for <ips@ece.cmu.edu>; Sat, 11 Aug 2001 18:16:40 -0500
Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7BNIjT279538
	for <ips@ece.cmu.edu>; Sat, 11 Aug 2001 17:18:45 -0600
X-Priority: 1 (High)
Importance: High
Subject: IPS: Use of project identifiers in posting subjects
To: IPS Reflector <ips@ece.cmu.edu>
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OF170361A1.5CC92D2E-ON88256AA5.006F6DE5@boulder.ibm.com>
From: "John Hufferd" <hufferd@us.ibm.com>
Date: Sat, 11 Aug 2001 13:39:21 -0700
X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.6 |December 14, 2000) at
 08/11/2001 05:18:45 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Folks, (Notice that this copy of the message has the prefix IPS)
Ralph Is right, in fact the "subject setting" is starting to get so casual
that it is now very irritating.  Many of us receive many e-mails and need
to respond to some at a different priority then others.  I was about to
send the same request today, when I saw Ralph's message.  So with the
knowledge that others fee the same way, let me stress that the message
should  begin with iSCSI:, iFCP:, or FCIP:, or possibly IPS: if it applies
to all.

If you receive a message, without such a prefix, please just add it in your
response.  Do not forward or respond using an un-prefixed message.   If the
message morphs into a different area, as some have done, then change the
prefix.

Please, everyone help.


.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com


Ralph Weber <ralphoweber@compuserve.com>@ece.cmu.edu on 08/10/2001 06:10:48
AM

Please respond to ENDL_TX@computer.org

Sent by:  owner-ips@ece.cmu.edu


To:   IPS Reflector <ips@ece.cmu.edu>
cc:
Subject:  Use of project identifiers in posting subjects



So, has this reflector officially gone over to being
the all iSCSI all the time reflector?

I notice that over 50% of the recent messages have
dropped the pretense that other topics are discussed
on this reflector by failing to include the "iSCSI"
identifier in the subject lines for topics devoted
solely that OTHER protocol for SCSI.  :-)

I think I speak for all of us working on the less
famous topics discussed on this reflector by reminding
you all that the subject lines of messages posted here
are supposed to contain a topic identifier, one of:

  FCIP
  iFCP
  iSCSI

Thanks.

Ralph...







From owner-ips@ece.cmu.edu  Sun Aug 12 00:46:50 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13571
	for <ips-archive@odin.ietf.org>; Sun, 12 Aug 2001 00:46:50 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7C3d9d10929
	for ips-outgoing; Sat, 11 Aug 2001 23:39:09 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from siaar2aa.compuserve.com (siaar2aa.compuserve.com [149.174.40.137])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7C3d8e10925
	for <ips@ece.cmu.edu>; Sat, 11 Aug 2001 23:39:08 -0400 (EDT)
Received: (from mailgate@localhost)
	by siaar2aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id XAA25107
	for ips@ece.cmu.edu; Sat, 11 Aug 2001 23:39:02 -0400 (EDT)
Received: from compuserve.com (dal-tgn-tky-vty21.as.wcom.net [216.192.234.21])
	by siaar2aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id XAA25093
	for <ips@ece.cmu.edu>; Sat, 11 Aug 2001 23:38:58 -0400 (EDT)
Message-ID: <3B75FB66.A238ACB2@compuserve.com>
Date: Sat, 11 Aug 2001 22:43:34 -0500
From: Ralph Weber <ralphoweber@compuserve.com>
Reply-To: ENDL_TX@computer.org
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47  (Win95; I)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: IPS Reflector <ips@ece.cmu.edu>
Subject: Re: IPS: Use of project identifiers in posting subjects
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Thank you, John.

And here is a note of appreciation to all of you who follow
John's advice, especially those who modify the subject line
when making replies.  I know that is extra work.

Thanks.

Ralph...

John Hufferd wrote:

> Folks, (Notice that this copy of the message has the prefix IPS)
> Ralph Is right, in fact the "subject setting" is starting to get so casual
> that it is now very irritating.  Many of us receive many e-mails and need
> to respond to some at a different priority then others.  I was about to
> send the same request today, when I saw Ralph's message.  So with the
> knowledge that others fee the same way, let me stress that the message
> should  begin with iSCSI:, iFCP:, or FCIP:, or possibly IPS: if it applies
> to all.
>
> If you receive a message, without such a prefix, please just add it in your
> response.  Do not forward or respond using an un-prefixed message.   If the
> message morphs into a different area, as some have done, then change the
> prefix.
>
> Please, everyone help.
>
> .
> .
> John L. Hufferd
> Senior Technical Staff Member (STSM)
> IBM/SSG San Jose Ca
> Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
> Home Office (408) 997-6136
> Internet address: hufferd@us.ibm.com


From owner-ips@ece.cmu.edu  Sun Aug 12 07:24:29 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12476
	for <ips-archive@odin.ietf.org>; Sun, 12 Aug 2001 07:24:23 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7CAUPY03335
	for ips-outgoing; Sun, 12 Aug 2001 06:30:25 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7CAUFe03325
	for <ips@ece.cmu.edu>; Sun, 12 Aug 2001 06:30:15 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id MAA232418
	for <ips@ece.cmu.edu>; Sun, 12 Aug 2001 12:30:04 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7CAU4821022
	for <ips@ece.cmu.edu>; Sun, 12 Aug 2001 12:30:04 +0200
Importance: Normal
Subject: Re: iSCSI: draft 7: Final bit in Data PDUs
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFF36857D1.91A33898-ONC2256AA5.007E0400@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Sun, 12 Aug 2001 02:00:26 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 12/08/2001 13:30:03
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Rishab,

I am not sure what you are asking for.
Both for read and for write the status is the one that dictate when things
end.
For bidirectional this does not change.
It is obvious an error to have a status arrive when a data sequence is not
terminated.

Julo


Rishabh Srivastav <rishabh_srivastav@yahoo.com> on 10-08-2001 19:48:43

Please respond to Rishabh Srivastav <rishabh_srivastav@yahoo.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:
Subject:  Re: iSCSI: draft 7: Final bit in Data PDUs



Julian,
Can we retain the previous definition of F bit ? In
the case of write, the term "sequence of PDU's" has a
meaning since a sequence is always demarcated by an
R2T. However, the new concept of "sequence of PDU's"
in the case of read is not analogous to the write
sequence as there is no definite demarcation like R2T
even in the case of bi-di reads.
I would rather ask for another bit in the case of
write that tells that the whole write transaction is
over, synonymous to the old F-bit defintion for read.
regards,
Rishabh

--- Julian Satran <Julian_Satran@il.ibm.com> wrote:
>
> Yes. Julo
>
> Rishabh Srivastav <rishabh_srivastav@yahoo.com> on
> 08-08-2001 20:48:40
>
> Please respond to Rishabh Srivastav
> <rishabh_srivastav@yahoo.com>
>
> To:   Julian Satran/Haifa/IBM@IBMIL
> cc:
> Subject:  Re: iSCSI: draft 7: Final bit in Data PDUs
>
>
>
> which means, there can even be a case of consecutive
> sequences of Data-in PDUs,
> with each sequence consisting of 1 PDU with F bit
> set.
> is it so ?
>
> -rishabh
>
> Julian Satran wrote:
>
>   Elliot,
>
>   Thanks .  Will change 2.7.1 to read:
>
>   1.1.1     F (Final) Bit
>
>      For outgoing data, this bit is 1 for the last
> PDU
> of unsolicited data or
>      the last PDU of a sequence answering a R2T.
>
>      For incoming data, this bit is 1 for the last
> input (read) data PDU of a
>      sequence.  Input can be split in several
> sequences each one having it's
>      own F bit. Splitting in sequences does not
> affect
> DataSN counting on
>      Data-IN PDUs but MAY be used as a "change
> direction" indication for
>      Bidirectional operations that need such a
> change
> and/or end of
>      recoverable sequences by targets with a limited
> replay buffer.
>
>      For Bidirectional operations, the F bit is 1
> both
> for the end of the
>      input sequences as well as the end of the
> output
> sequences.
>
>    Comments?
>
>    Julo
>
> __________________________________________________
> Do You Yahoo!?
> Make international calls for as low as $.04/minute
> with Yahoo! Messenger
> http://phonecard.yahoo.com/
>
>
>


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/





From owner-ips@ece.cmu.edu  Sun Aug 12 07:26:54 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12538
	for <ips-archive@odin.ietf.org>; Sun, 12 Aug 2001 07:26:54 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7CAUHo03329
	for ips-outgoing; Sun, 12 Aug 2001 06:30:17 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7CAUDe03323
	for <ips@ece.cmu.edu>; Sun, 12 Aug 2001 06:30:13 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id MAA98770;
	Sun, 12 Aug 2001 12:30:03 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7CAU2821018;
	Sun, 12 Aug 2001 12:30:02 +0200
Importance: Normal
Subject: RE: iSCSI - Response/Status
To: "Elliott, Robert" <Robert.Elliott@compaq.com>
Cc: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFD8BE0082.8167CA53-ONC2256AA5.007449BC@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Sun, 12 Aug 2001 01:31:47 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 12/08/2001 13:30:02
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Thanks Elliot - I am not sure that we have it closed we may have to
rearrange things.
There is nothing to convey the fact that this was an error originated in
iSCSI at the target and the detailed nature of the error (we had this in
the iSCSI response, now we might have to add this information to sense.

Julo

"Elliott, Robert" <Robert.Elliott@compaq.com>@ece.cmu.edu on 10-08-2001
13:03:57

Please respond to "Elliott, Robert" <Robert.Elliott@compaq.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI - Response/Status



I would call out those additional sense codes by name rather than number
(perhaps both).  The sense key(s) to be used also need to be listed.

Status=CHECK CONDITION
Sense Key=
additional sense code (ASC+ASCQ)=

--
Robert.Elliott@compaq.com
Compaq Computer Server Storage


-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, August 09, 2001 6:34 PM
To: ips@ece.cmu.edu
Subject: iSCSI - Response/Status


According to the discusions on the list 2.4.2 & 2.4.3 have been fixed to
read:

1.1.1     Status

   The Status field is used to report the SCSI status of the command (as
   specified in [SAM2]) and is valid only if the Response Code is Command
   Completed at target.

   If a SCSI device error is detected while data from the initiator is
   still expected (the command PDU did not contain all the data and the
   target has not received a Data PDU with the final bit Set) the target
   MUST wait until it receives the a Data PDU with the F bit set, in the
   last expected sequence, before sending the Response PDU.

1.1.2     Response

   This field contains iSCSI service response.

   Valid iSCSI service response codes are:

      0x00 - Command Completed at Target
      0x01 - Target Failure
      0x02 - Delivery Subsystem Failure
      0x80-0xff - Reserved for Vendor-Unique Responses

   The Response is used to report a Service Response. The exact mapping of
   the iSCSI response codes to SAM service response symbols is outside the
   scope of this document.

   Certain iSCSI conditions result in the command being terminated at the
   target (response Command Completed at Target) with a SCSI Check
   Condition Status as outlined in the next table:

   +------------------------------+---------------------------+
   | Reason                       | with SCSI CHECK CONDITION |
   +------------------------------+---------------------------+
   | Unsolicited data rejected    | ASC = 0x49 ASCQ = 0x00    |
   +------------------------------+---------------------------+
   | Not enough unsolicited       | ASC = 0x4B ASCQ = 0x00    |
   +------------------------------+---------------------------+
   | SNACK rejected               | ASC = 0x47 ASCQ = 0x03    |
   +------------------------------+---------------------------+

   N.B. Unsolicited data rejected condition is reported used by the target
   only if it does not support output (write) operations in which the total
   data length is higher than FirstBurstSize but the initiator sent less
   than first burst size and out-of-order R2Ts can't be used.

   Julo





From owner-ips@ece.cmu.edu  Sun Aug 12 07:30:49 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12646
	for <ips-archive@odin.ietf.org>; Sun, 12 Aug 2001 07:30:48 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7CAUfv03350
	for ips-outgoing; Sun, 12 Aug 2001 06:30:41 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7CAUde03345
	for <ips@ece.cmu.edu>; Sun, 12 Aug 2001 06:30:39 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id MAA230874;
	Sun, 12 Aug 2001 12:30:26 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7CAU2170126;
	Sun, 12 Aug 2001 12:30:02 +0200
Importance: Normal
Subject: RE: Review of the 07 draft
To: Robert Snively <rsnively@Brocade.COM>
Cc: "'deva@stargateip.com'" <deva@stargateip.com>,
        Robert Griswold <rgriswold@Crossroads.com>,
        Eddy Quicksall <ESQuicksall@hotmail.com>,
        "Jim Hafner" <hafner@almaden.ibm.com>, ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF491FD131.1CD69B83-ONC2256AA5.007C9494@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Sun, 12 Aug 2001 01:50:01 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 12/08/2001 13:30:25
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

I think that for regularity it would be wise to remove completely EMDP and
FirstBurstsize from iSCSI control.
MaximumBurstSize defines the DataPDU length and is transport related
(affects iSCSI and less SCSI) and should stay under iSCSI control.


Comments?

Julo

Robert Snively <rsnively@Brocade.COM>@ece.cmu.edu on 10-08-2001 10:32:20

Please respond to Robert Snively <rsnively@Brocade.COM>

Sent by:  owner-ips@ece.cmu.edu


To:   "'deva@stargateip.com'" <deva@stargateip.com>, Robert Griswold
      <rgriswold@Crossroads.com>, Eddy Quicksall <ESQuicksall@hotmail.com>,
      Jim Hafner/Almaden/IBM@IBMUS
cc:   ips@ece.cmu.edu
Subject:  RE: Review of the 07 draft



Deva,

Both of you are right if iSCSI sticks to negotiating only
parameters related with the TCP connections, the iSCSI
session operational parameters other than EMDP and
burst length, and iSCSI security parameters.  Then, all
parameters relating to the normal SCSI activities, including
EMDP and burst length (which are required for SCSI, not iSCSI,
buffer management) would be negotiated in the normal
SCSI manner through the MODE SENSE/SELECT pages and everybody
would live happily ever after.

Otherwise, and especially with respect to EMDP and burst length,
I have to agree with Robert.

Bob Snively                        e-mail:    rsnively@brocade.com
Brocade Communications Systems     phone:  408 487 8135
1745 Technology Drive
San Jose, CA 95110



-----Original Message-----
From: Dev [mailto:deva@stargateip.com]
Sent: Thursday, August 09, 2001 5:33 PM
To: Robert Griswold; Eddy Quicksall; Jim Hafner
Cc: ips@ece.cmu.edu
Subject: RE: Review of the 07 draft


All,

I tend to disagree. The parameters for the iSCSI are negotiated between the
initiator and target.
If we allow the parameters to be changed through SCSI Mode select, how will
this work?

If parameters can be changed through SCSI Mode select then it will apply
only to Lead only connections.

So, we'll have

a) two methods to change the Lead only parameters common for the entire
session (one through mode select
and the other through text parameters)
b) Just iSCSI text command to change the connection specific parameters.

Does it not add to complexity having multiple ways to change the same
stuff?

Thanks

Deva
Platys communications

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Robert Griswold
Sent: Thursday, August 09, 2001 1:36 PM
To: Eddy Quicksall; Jim Hafner
Cc: ips@ece.cmu.edu
Subject: RE: Review of the 07 draft


Eddy:

I actually have no problem with all mode pages (SCSI and iSCSI) being
accessible and changeable from standard SCSI mode commands.  My initial
response to this section was to propose a method that would be
acceptable to the authors of the iSCSI draft.  If there is desire in the
group to allow mode pages for the entire target to be manipulated from
the SCSI level, I think that is a better idea that the one I proposed.
I would assume that an iSCSI aware SCSI utility would understand the
iSCSI specific settings, and allow the user to make those changes.  What
I am really against, is the ability to modify standard SCSI mode page
settings from text messages, as that could lead to target behavior
changes outside of the understanding of the SCSI nexus.

To recap your thinking:  Allow iSCSI text messages to modify and read
iSCSI only mode settings (potentially allowing the reading if SCSI mode
settings), but allow SCSI mode commands to modify and read all target
mode settings, including iSCSI settings.  Is that what you are saying.
If so, I agree.

Bob

Robert Griswold
Technologist
Crossroads Systems, Inc.
512-928-7272

 -----Original Message-----
From:     Eddy Quicksall [mailto:ESQuicksall@hotmail.com]
Sent:     Thursday, August 09, 2001 2:08 PM
To:  Robert Griswold; Jim Hafner
Cc:  ips@ece.cmu.edu
Subject:  Re: Review of the 07 draft

I don't like the idea of not letting a user of a SCSI utility be able to
change some of the parameters for iSCSI. Because they may be relevant to
him
and there may not be a user interface to the iSCSI driver. pSCSI sets
these
low level parameters via a standard mode set, so why not iSCSI?

It would be best if we could work out something where only the SCSI
layer
can set the mode pages. That would solve everything.

Eddy

----- Original Message -----
From: "Jim Hafner" <hafner@almaden.ibm.com>
To: "Robert Griswold" <rgriswold@Crossroads.com>
Cc: <ips@ece.cmu.edu>
Sent: Friday, August 03, 2001 5:26 PM
Subject: Re: Review of the 07 draft

> Well, in fact, the draft is supposed to say that MODE_SELECT for the
> transport-specific mode page will NOT be done via SCSI, only via Text
> commands.  I read that as saying that from the SCSI layer, all fields
in
> these pages are "unchangeable" (even though they can change in the
iSCSI
> layer).  Of course, the draft doesn't say whether MODE PARAMETERS HAVE
> CHANGED unit attentions get thrown up at the SCSI layer when this
happens
> at the iSCSI layer.... You later have a clarifying question (Section
3) on
> this as well.
>
> Regards,
> Jim Hafner
>
>
>
>






From owner-ips@ece.cmu.edu  Sun Aug 12 07:31:14 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12668
	for <ips-archive@odin.ietf.org>; Sun, 12 Aug 2001 07:31:13 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7CAUCD03322
	for ips-outgoing; Sun, 12 Aug 2001 06:30:12 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7CAU9e03318
	for <ips@ece.cmu.edu>; Sun, 12 Aug 2001 06:30:10 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id MAA98768
	for <ips@ece.cmu.edu>; Sun, 12 Aug 2001 12:30:02 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7CAU1170124
	for <ips@ece.cmu.edu>; Sun, 12 Aug 2001 12:30:01 +0200
Importance: Normal
Subject: Re: Reserved field definitions
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF276494DB.5F578E3D-ONC2256AA5.006B2ECA@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Sat, 11 Aug 2001 22:59:00 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 12/08/2001 13:30:00
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Robert,

I iSCSI the reserved fiels are generally said to be 0 except in the very
few cases in which we use a "reserved value" to indicate that the field has
an invalid value and the value 0 is a (convenient) valid value. The tags
fall in this category - Initiators may use for tags
some simple derivative of a control-block-address and so do targets and
reserving 0 was felt to be prohibitive.

As for checking the reserved fields for the reserved value the draft
refrains from asking this.

As for some specifics - coments are inserted in text.

Julo

"Robert Griswold" <rgriswold@Crossroads.com>@ece.cmu.edu on 08-08-2001
21:34:55

Please respond to "Robert Griswold" <rgriswold@Crossroads.com>

Sent by:  owner-ips@ece.cmu.edu


To:   Julian Satran/Haifa/IBM@IBMIL
cc:   <ips@ece.cmu.edu>
Subject:  Reserved field definitions



Julian:

In review the use of Reserved fields in the iSCSI draft, there seem to
be some inconsistencies through the document, and the assumptions of
their use appear to be in conflict with SAM-2.  First, two quotes from
07 and SAM-2:

"2. iSCSI PDU Formats
...  Any bits not defined MUST be set to zero. Any reserved fields and
values MUST be 0 unless specified otherwise. "

"3.3.8 reserved: A keyword referring to bits, bytes, words, fields and
code values that are set aside for future standardization. Their use and
interpretation may be specified by future extensions to this or other
standards. A reserved bit, byte, word or field shall be set to zero, or
in accordance with a future extension to this standard. Recipients are
not required to check reserved bits, bytes, words or fields for zero
values.  Receipt of reserved code values in defined fields shall be
reported as an error."

It appears that there are some conflicts with the usage of the
definition of reserved in the iSCSI document and the definitions coming
from T10, specifically how to handle garbage in reserved fields.  I
would suggest that a PDU format error in iSCSI is actually a PDU
received that has errors in any defined fields, but does not require a
reject if inconsistencies are found in reserved fields.  Also, the fact
that some reserved fields require zeros, while others require ones seems
odd, and will probably lead to more incompatibilities than the value of
having dissimilar reserved field use provides.  If there is previous art
that forces this difference than let's call that use of the field for
what it is, versus calling it reserved.  My understanding of TCP network
protocols is very weak, though, and there could be a really good reason
why this mapping is happening, so please whack me with the stupid stick
if necessary.

The following are cases where 07 has lapses in the use of reserved
fields:

Page 44, under AHSType, bits 0 and 3-59 are declared Reserved, but not
"must be 0".  But also strangely here, it seems that AHSType is an
eight-bit field, that has 64-bits worth of explanation.  Am I reading
something wrong here?

+++You must have been confused by the B - it means bit. The first 2 bits
have special meaning while the rest are a coded field with 64 value+++

Page 45, byte 2 of word 0 of op-code 0x01 is declared Reserved, but no
requirement for zeros (aside from the directive in Section 2).

+++There is a general requirement sated in the last statement before 2.1
that reads:
Any bits not defined MUST be set to zero. Any reserved fields and values
MUST be 0 unless specified otherwise.
++++
Page 49, bits 5 and 6 of Flags are declared as Reserved, but no
requirement for zeros.  Also, bit 7 is not even declared even though the
table above (pg 48) shows bit 7 as a 1.  Does this mean bit 7 falls into
the odd category of a reserved field that must be 1?

Page 49, bits 80-ff of Response are declared as "Reserved" for
Vendor-unique responses.  Now most developers would interpret this
correctly, but the use of the word reserved here could lead some into
thinking only 0's are allowed, or must be checked for 0's.

+++ I doubt that somebody would really think so but if you mean to suggest
another wording please do so +++
Page 51, both 2.4.7 and 2.4.8 declare that if the S field is 0, then the
two mentioned fields are reserved, but no requirement for zeros (aside
from the directive in Section 2).

Page 53, the definition of Reference Task Tag or Reserved shows that a
reserved (even though specified) field need not be 0 (aside from the
directive in Section 2).

Page 80, bytes 0 and 1 of word 8 show CID or Reserved, but no
requirement for zeros (aside from the directive in Section 2).

Page 84, definition of Bit S, says 'otherwise, it is reserved,' but no
requirement for zeros (aside from the directive in Section 2).
+++ all requirements for 0 are covered y the general statement +++
Thanks,
Bob

Robert Griswold
Technologist
Crossroads Systems, Inc.
512-928-7272






From owner-ips@ece.cmu.edu  Sun Aug 12 23:58:42 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23895
	for <ips-archive@odin.ietf.org>; Sun, 12 Aug 2001 23:58:42 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7D2NJP02588
	for ips-outgoing; Sun, 12 Aug 2001 22:23:19 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7D2NIe02584
	for <ips@ece.cmu.edu>; Sun, 12 Aug 2001 22:23:18 -0400 (EDT)
Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <QSSXZRS5>; Sun, 12 Aug 2001 22:23:09 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD5A3@CORPMX14>
From: Black_David@emc.com
To: ips@ece.cmu.edu
Subject: IPS: Schedule and Security Update
Date: Sun, 12 Aug 2001 22:17:44 -0400
Importance: high
X-Priority: 1
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

-- Schedule

New set of milestones will be coming in the near future (this week,
I hope).  We're not going to be able to meet the current milestones (main
protocols finished and submitted to the IESG by the end of September).  A
rough guess is that major technical work on the main protocols should be
basically complete by the end of this year (i.e., the final set of technical
issues should be on the Salt Lake City agenda for closure).  Security is a
visible reason, and then there's the last 10% of the details that will
take the proverbial "other 90%" of the time ...

-- Security

A number of thing have been happening in this area that may not be visible
to everyone.  This section is all about iSCSI, although it also applies to
FCIP and iFCP to the extent that they want to follow iSCSI's direction.  At
the moment, iSCSI has open technical issues in (at least) the following four
areas of security, all of which are potential discussion topics for the
interim meeting (although the first one would be for clarification only -
disputing that set of requirements is not a good use of meeting time).

- Requirements

The question of whether security could be optional for FCIP was brought to
the IESG Plenary in London, and the result was a definitive "NO - security
is a 'MUST implement'".  Between this and my discussion of the saag whyenc
draft (draft-ietf-saag-whyenc-00.txt) with both our ADs and the one security
AD who was in London, we should assume that the IESG will add
confidentiality
(i.e., encryption) to the current requirements that iSCSI, FCIP and iFCP
"MUST implement" authentication and keyed cryptographic data integrity.

- Keying and Rekeying

iSCSI needs an automatic keying and rekeying mechanism (and it will be
"MUST implement").  There are currently a couple of active proposals to
do this:

o Use SRP (or some other inband authentication protocol) to generate ESP
	keying material.  See draft-black-ips-iscsi-security-00.txt, which
	I hope to revise to -01 by the end of the week.  This draft also
	contains a general discussion of security requirements.
o Use IKE.  A draft on this should be coming on this in the next few days
	from Bernard Aboba and a bunch of folks who have been working on
this.

Both of these proposals are headed in the direction of end-to-end security
that would make it difficult to use an off-the-shelf IPsec security gateway
to meet iSCSI's "MUST implement" security requirements.  The SRP approach
generates the keys outside the gateway, and there's no standard protocol to
insert the keys into the gateway, and the IKE draft wants to use transport
mode ESP instead of tunnel mode (gateways generally use tunnel mode).  Based
on discussions with Marcus Leech (security AD) and Steve Bellovin (IAB
member and security expert), this end-to-end security direction is the
preferred approach (vs. saying "just use IPsec gateways").

- Algorithm Selection

We need to select encryption and keyed MAC (keyed cryptographic integrity)
algorithms.  This area is somewhat in flux, because a new generation of
these
algorithms is becoming usable - this is about using AES and UMAC instead of
3DES and HMAC.  More details should be in the forthcoming IKE draft.  The
new draft charter for the IPsec WG indicates that they intend to complete
work on the drafts needed for these algorithms (and a draft to extend the
ESP sequence number for high-speed implementations) in the next few months
(and will take all the help they can get in generating those drafts).

- Authentication

We've been a bit vague on exactly what is being authenticated (e.g.,
machine, user), and authentication requirements beyond the fact that
we need authentication.  The two drafts noted above contain some material
that makes a start in that direction, but some additional thought (and
text) will be needed to ensure that we have the right authentication
mechanisms specified/required.  In the case of IKE, this includes
requirements on the relationship between iSCSI and IKE authentication
if both are performed, fortunately Bernard Aboba worked on l2tp security
which has some analogous issues.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


From owner-ips@ece.cmu.edu  Mon Aug 13 00:08:31 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23999
	for <ips-archive@odin.ietf.org>; Mon, 13 Aug 2001 00:08:31 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7D2okg03523
	for ips-outgoing; Sun, 12 Aug 2001 22:50:46 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7D2oje03519
	for <ips@ece.cmu.edu>; Sun, 12 Aug 2001 22:50:45 -0400 (EDT)
Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <QSSXZSJH>; Sun, 12 Aug 2001 22:50:40 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD5A5@CORPMX14>
From: Black_David@emc.com
To: ips@ece.cmu.edu
Cc: Black_David@emc.com, egrodriguez@lucent.com
Subject: IPS Interim Meeting: Preliminary Agenda
Date: Sun, 12 Aug 2001 22:45:14 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Hi all, 
 
Following is the preliminary interim meeting agenda.
This is still subject to some juggling and adjustment, but in general the
breakdown will be FC related topics (e.g. FCIP, IFCP and related drafts) on
Monday and Security related topics (for iSCSI, FCIP, and iFCP) on Tuesday.
 
Please note: The meetings will begin at 8:00 am each day!  We have a full
day
planned for each day, and cannot move the start time any further.  If you
are
flying  in the morning of one of the meetings, please try to get there as
soon
as possible, but you are welcome to come in late if necessary.
 
For those who have missed it, the interim meeting will be held on August 27
& 28 at
the Irvine Marriott John Wayne Airport.  The hotel has a courtesy shuttle
bus which
runs between SNA and the hotel on a regular basis.  The phone number for the
Marriott is 949-553-0100.  The address is 18000 Von Karman Avenue, Irvine,
CA 92612
 
Note to all draft authors for the interim meeting -- drafts need to be
submitted
to the IETF as soon as possible this week.  IETF drafts office reopens on
Tuesday.
Drafts must be submitted no later than 5pm EST on Friday.  Since it may take
a
couple of days for the drafts office to process the drafts, please put the
draft
on a web site as soon as possible, and let everyone know where the draft can
be
accessed.  If you have any difficulties, or do not have a web site that you
can
post the draft to, please let us know.  List of drafts for the meeting will
be
out in the next day or so.
 
Thanks,
 
Elizabeth and David
 
Monday, August 27
-----------------------------
  8:00a: Agenda Bashing -- 15 min
  8:15a: Common Encapsulation update -- 15 min
  8:30a: FCIP -- 90 min
 10:00a: FC-BB2 Assumptions & impact on FCIP draft -- 30 min
 10:30a: FCIP Discovery -- 2 hrs
 12:30p: Lunch -- 1 hr
  1:30p: FCIP MIB -- 30 min
  2:00p: iFCP requirements for TCP/IP transit time -- 30 min
  2:30p: IP to FC routing functionality in an iFCP gateway -- 30min
  3:00p: Fabric services supported by an iFCP gateway -- 45 min
  3:45p: Augmenting TRPLO -- 15 min
  4:00p: iFCP MIB -- 30 min
  4:30p: iSNS/SLP Discovery for iFCP -- 30 min
  5:00p: Misc FC related issues -- 1hr

Tuesday, August 28
  8:00a: Agenda Bashing -- 15 min
  8:15a: IETF Security Policy/Requirements -- 45 min
  9:00a: iFCP Security Issues/Requirements -- 30 min
  9:30a: FCIP Security Issues/Requirements -- 30 min
 10:00a: iSCSI Security Issues/Requirements -- 30 min
 10:30a: SRP keying -- 20 min
 10:50a: IKE keying -- 20 min
 11:10a: Keying discussion/selection of approach - 50 min
 12:00p: Lunch -- 1 hr
  1:00p: iSCSI MAC and encryption algorithm selection - 1 hour
  2:00p: iSCSI Authentication - 1 hour
  3:00p: FCIP Security Direction - 1.5 hours
  4:30p: iFCP Security Direction - 1 hour
  5:30p: Wrap-up -- 30 min


From owner-ips@ece.cmu.edu  Mon Aug 13 08:24:19 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16888
	for <ips-archive@odin.ietf.org>; Mon, 13 Aug 2001 08:24:19 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7DBA7529881
	for ips-outgoing; Mon, 13 Aug 2001 07:10:07 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from yamuna.ctd.hcltech.com ([202.140.153.6])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7DBA1e29875
	for <ips@ece.cmu.edu>; Mon, 13 Aug 2001 07:10:03 -0400 (EDT)
Received: from kaveri.ctd.hcltech.com (KAVERI [192.168.102.25]) by yamuna.ctd.hcltech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id Q1C5BVSW; Mon, 13 Aug 2001 16:43:42 +0530
Received: from ASAI ([192.168.201.159]) by kaveri.ctd.hcltech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id Q1CWWKTC; Mon, 13 Aug 2001 16:40:52 +0530
Message-ID: <00f701c123e8$d1786e00$9fc9a8c0@techmas.hcltech.com>
Reply-To: "Asai Thambi S P" <sp_asai@ctd.hcltech.com>
From: "Asai Thambi S P" <sp_asai@ctd.hcltech.com>
To: <ips@ece.cmu.edu>
Subject: iSCSI: Ping Data,CmdSN
Date: Mon, 13 Aug 2001 16:42:15 +0530
Organization: HCL Technologies Ltd
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f7DBA6e29877
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit

hi,

I have read iSCSI draft 6.
I need clarifiaction on the issues given below:

 * NOP-Out can be sent in response to NOP-In or to test the target or to
        test the connection.

        Section 2.12:

        "The NOP-Out may be useful in the case where an initiator has been
        waiting a long time for the response to some command, and the
        initiator suspects that there is some problem with the connection."

        "A NOP-Out should also be used to confirm a changed ExpStatSN if
there is no other PDU to carry it for a long time. "

      The draft also says that the timeout value is outside the scope of the
document.

        In the former case, how do we know that we've been waiting for a
long time?
        In the latter case, how do we know that there is no other PDU's to
carry this for a long time?

* Similarly  for NOP-In,
        NOP-In can be sent
                        * in response to NOP-In
                        * to test the initiator
                        * to test the connection

        When to test the initiator or connection? How to decide it?

In case of target/initiator issuing NOP-In/NOP-Out on its own, what will be
the Ping Data?


* if CmdSN  is not equal to ExpCmdSN, what should the target do?
        suppose CmdSN > ExpCmdSN,  whether the target should assume that it
missed the commands in between and ask for retransmission of commands. 
If so, how the target asks for command retransmission.
        If not, what the target should  do?

    The initiator asks for retransmission of status or data through SNACK request. 

Is there anything similar to this for target?


 - asai.




From owner-ips@ece.cmu.edu  Mon Aug 13 10:34:54 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21180
	for <ips-archive@odin.ietf.org>; Mon, 13 Aug 2001 10:34:54 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7DD97S04228
	for ips-outgoing; Mon, 13 Aug 2001 09:09:07 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from va2mc.ummailbox.net (va2mc.ummailbox.net [64.210.247.17])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7DD95e04224
	for <ips@ece.cmu.edu>; Mon, 13 Aug 2001 09:09:06 -0400 (EDT)
Received: from hqmailweb.COMMSTOR.Crossroads.com (HQMailWeb.Crossroads.com [63.237.99.250:25])
	by va2mc.ummailbox.net with ESMTP id U0813-0908-5c8600;
	Mon, 13 Aug 2001 13:08:24 GMT
Received: from HQMAILNODE1.COMMSTOR.Crossroads.com ([10.5.1.42]) by hqmailweb.COMMSTOR.Crossroads.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Mon, 13 Aug 2001 08:08:23 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
Subject: RE: Review of the 07 draft
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Mon, 13 Aug 2001 08:08:22 -0500
Message-ID: <CFD808D1D39ACB47ABFF586D484CC52E261E5D@HQMAILNODE1.COMMSTOR.Crossroads.com>
Thread-Topic: Review of the 07 draft
Thread-Index: AcEiInLmHpSfhNlfSbWdZzs7s6qIygB1eBuw
From: "Robert Griswold" <rgriswold@Crossroads.com>
To: "John Hufferd" <hufferd@us.ibm.com>
Cc: "Eddy Quicksall" <ESQuicksall@hotmail.com>,
        "Jim Hafner" <hafner@almaden.ibm.com>, <ips@ece.cmu.edu>
X-OriginalArrivalTime: 13 Aug 2001 13:08:23.0209 (UTC) FILETIME=[080EA190:01C123F9]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f7DD96e04225
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit

John:

You are saying what I originally described in my comments on this topic,
if that is what this group decides is important.  The fact that I would
like to see all mode pages available (as others do) to the SCSI mode
commands does not mean that limiting iSCSI to iSCSI and SCSI to SCSI is
not workable.  I personally think that limiting any mode page (the
assumption here is that that the target entity owns the responsibility
for keeping that mode page data) access to a command outside of the
domain of the entity itself (SCSI interface) is not consistent with the
historical use of SCSI.  But again, if the overriding agreement is that
separation is the best way to go, then so be it, it can be made to work.

Bob

Robert Griswold
Technologist
Crossroads Systems, Inc.
512-928-7272

 -----Original Message-----
From: 	John Hufferd [mailto:hufferd@us.ibm.com] 
Sent:	Friday, August 10, 2001 10:49 AM
To:	Robert Griswold
Cc:	Eddy Quicksall; Jim Hafner; ips@ece.cmu.edu
Subject:	RE: Review of the 07 draft


I am not sure that I feel real good about what you are stating here.  I
think the iSCSI Mode Pages are the persistent location for the iSCSI
Modes,
but I think iSCSI will have the values in variables that they have in
memory/cache that iSCSI uses ongoing.  If a SCSI command was to change
those values I am not sure that iSCSI will see the changes.

I thought we had previously agreed (for the reasons above) that iSCSI
sets
its pages and SCSI sets its pages.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com


"Robert Griswold" <rgriswold@Crossroads.com>@ece.cmu.edu on 08/09/2001
01:36:14 PM

Sent by:  owner-ips@ece.cmu.edu


To:   "Eddy Quicksall" <ESQuicksall@hotmail.com>, Jim
      Hafner/Almaden/IBM@IBMUS
cc:   <ips@ece.cmu.edu>
Subject:  RE: Review of the 07 draft



Eddy:

I actually have no problem with all mode pages (SCSI and iSCSI) being
accessible and changeable from standard SCSI mode commands.  My initial
response to this section was to propose a method that would be
acceptable to the authors of the iSCSI draft.  If there is desire in the
group to allow mode pages for the entire target to be manipulated from
the SCSI level, I think that is a better idea that the one I proposed.
I would assume that an iSCSI aware SCSI utility would understand the
iSCSI specific settings, and allow the user to make those changes.  What
I am really against, is the ability to modify standard SCSI mode page
settings from text messages, as that could lead to target behavior
changes outside of the understanding of the SCSI nexus.

To recap your thinking:  Allow iSCSI text messages to modify and read
iSCSI only mode settings (potentially allowing the reading if SCSI mode
settings), but allow SCSI mode commands to modify and read all target
mode settings, including iSCSI settings.  Is that what you are saying.
If so, I agree.

Bob

Robert Griswold
Technologist
Crossroads Systems, Inc.
512-928-7272

 -----Original Message-----
From:     Eddy Quicksall [mailto:ESQuicksall@hotmail.com]
Sent:     Thursday, August 09, 2001 2:08 PM
To:  Robert Griswold; Jim Hafner
Cc:  ips@ece.cmu.edu
Subject:  Re: Review of the 07 draft

I don't like the idea of not letting a user of a SCSI utility be able to
change some of the parameters for iSCSI. Because they may be relevant to
him
and there may not be a user interface to the iSCSI driver. pSCSI sets
these
low level parameters via a standard mode set, so why not iSCSI?

It would be best if we could work out something where only the SCSI
layer
can set the mode pages. That would solve everything.

Eddy

----- Original Message -----
From: "Jim Hafner" <hafner@almaden.ibm.com>
To: "Robert Griswold" <rgriswold@Crossroads.com>
Cc: <ips@ece.cmu.edu>
Sent: Friday, August 03, 2001 5:26 PM
Subject: Re: Review of the 07 draft

> Well, in fact, the draft is supposed to say that MODE_SELECT for the
> transport-specific mode page will NOT be done via SCSI, only via Text
> commands.  I read that as saying that from the SCSI layer, all fields
in
> these pages are "unchangeable" (even though they can change in the
iSCSI
> layer).  Of course, the draft doesn't say whether MODE PARAMETERS HAVE
> CHANGED unit attentions get thrown up at the SCSI layer when this
happens
> at the iSCSI layer.... You later have a clarifying question (Section
3) on
> this as well.
>
> Regards,
> Jim Hafner
>
>
>
>









From owner-ips@ece.cmu.edu  Mon Aug 13 10:35:17 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21192
	for <ips-archive@odin.ietf.org>; Mon, 13 Aug 2001 10:35:17 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7DDwE806422
	for ips-outgoing; Mon, 13 Aug 2001 09:58:14 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7DB6ce29764
	for <ips@ece.cmu.edu>; Mon, 13 Aug 2001 07:06:38 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13596;
	Mon, 13 Aug 2001 07:05:26 -0400 (EDT)
Message-Id: <200108131105.HAA13596@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: ips@ece.cmu.edu
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-tseng-ifcpmib-00.txt
Date: Mon, 13 Aug 2001 07:05:26 -0400
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Definitions of Managed Objects For iFCP
	Author(s)	: K. Gibbons, J. Tseng, C. Monia
	Filename	: draft-tseng-ifcpmib-00.txt
	Pages		: 21
	Date		: 10-Aug-01
	
This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community.  In particular, it defines a basic set of managed
objects for SNMP-based monitoring and management of an Internet
Storage Name Service (iSNS).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-tseng-ifcpmib-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-tseng-ifcpmib-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-tseng-ifcpmib-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010810104819.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-tseng-ifcpmib-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-tseng-ifcpmib-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010810104819.I-D@ietf.org>

--OtherAccess--

--NextPart--



From owner-ips@ece.cmu.edu  Mon Aug 13 12:13:03 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23370
	for <ips-archive@odin.ietf.org>; Mon, 13 Aug 2001 12:13:03 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7DElPU08857
	for ips-outgoing; Mon, 13 Aug 2001 10:47:25 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from apollo.pirus.com ([4.36.58.225])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7DElNe08851
	for <ips@ece.cmu.edu>; Mon, 13 Aug 2001 10:47:23 -0400 (EDT)
Received: by apollo.pirus.com with Internet Mail Service (5.5.2650.21)
	id <Q3P7HC9G>; Mon, 13 Aug 2001 10:49:13 -0400
Message-ID: <E132D13F58DAAB45AE5D01CA75BD3D56B6D1@OZ.pirus.com>
From: "Binford, Charles" <CBinford@pirus.com>
To: ips@ece.cmu.edu
Subject: RE: Review of the 07 draft
Date: Mon, 13 Aug 2001 10:49:10 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

I agree with Julian about removing EMDP and FirstBurstSize from iSCSI
control.  I disagree on MaxBurstSize.

MaxBustSize defines DataPDU length only because we said it does.  We could
just as easily remove the relationship between DataPDU length and
MaxBurstSize.  I would prefer we let iSCSI control DataPDU length as it does
today and change the meaning of MaxBurstSize under iSCSI to be more in line
with what MaxBurstSize means under other SCSI protocols.  As pointed out
earlier on this thread a generic SCSI mode page utility doesn't/shouldn't
know/care what the transport it.

The meaning of MaxBurstSize under FCP is largest FC Sequence a target can
send.  Since an FC class 3 target can send multiple Read data sequences to
the host with no handshake, the parameter is essentially a don't care for
reads.  For Writes it effectively governs the largest amount of data a
target can ask for on an XFER_RDY.

For iSCSI, I'd like to see MaxBurstSize be defined as one of the following:
- largest amount of data a target can ask for under a single R2T; or
- ignored.

My problem with the current definition is typical iSCSI DataPDU lengths are
relatively small (default 8K in the spec.)  The typical MaxBurstSize for
other protocols is much larger - 64K to 512K.  

Charles Binford
Pirus Networks
316.315.0382 x222


-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, August 11, 2001 5:50 PM
To: Robert Snively
Cc: 'deva@stargateip.com'; Robert Griswold; Eddy Quicksall; Jim Hafner;
ips@ece.cmu.edu
Subject: RE: Review of the 07 draft


I think that for regularity it would be wise to remove completely EMDP and
FirstBurstsize from iSCSI control.
MaximumBurstSize defines the DataPDU length and is transport related
(affects iSCSI and less SCSI) and should stay under iSCSI control.


Comments?

Julo

Robert Snively <rsnively@Brocade.COM>@ece.cmu.edu on 10-08-2001 10:32:20

Please respond to Robert Snively <rsnively@Brocade.COM>

Sent by:  owner-ips@ece.cmu.edu


To:   "'deva@stargateip.com'" <deva@stargateip.com>, Robert Griswold
      <rgriswold@Crossroads.com>, Eddy Quicksall <ESQuicksall@hotmail.com>,
      Jim Hafner/Almaden/IBM@IBMUS
cc:   ips@ece.cmu.edu
Subject:  RE: Review of the 07 draft



Deva,

Both of you are right if iSCSI sticks to negotiating only
parameters related with the TCP connections, the iSCSI
session operational parameters other than EMDP and
burst length, and iSCSI security parameters.  Then, all
parameters relating to the normal SCSI activities, including
EMDP and burst length (which are required for SCSI, not iSCSI,
buffer management) would be negotiated in the normal
SCSI manner through the MODE SENSE/SELECT pages and everybody
would live happily ever after.

Otherwise, and especially with respect to EMDP and burst length,
I have to agree with Robert.

Bob Snively                        e-mail:    rsnively@brocade.com
Brocade Communications Systems     phone:  408 487 8135
1745 Technology Drive
San Jose, CA 95110



-----Original Message-----
From: Dev [mailto:deva@stargateip.com]
Sent: Thursday, August 09, 2001 5:33 PM
To: Robert Griswold; Eddy Quicksall; Jim Hafner
Cc: ips@ece.cmu.edu
Subject: RE: Review of the 07 draft


All,

I tend to disagree. The parameters for the iSCSI are negotiated between the
initiator and target.
If we allow the parameters to be changed through SCSI Mode select, how will
this work?

If parameters can be changed through SCSI Mode select then it will apply
only to Lead only connections.

So, we'll have

a) two methods to change the Lead only parameters common for the entire
session (one through mode select
and the other through text parameters)
b) Just iSCSI text command to change the connection specific parameters.

Does it not add to complexity having multiple ways to change the same
stuff?

Thanks

Deva
Platys communications

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Robert Griswold
Sent: Thursday, August 09, 2001 1:36 PM
To: Eddy Quicksall; Jim Hafner
Cc: ips@ece.cmu.edu
Subject: RE: Review of the 07 draft


Eddy:

I actually have no problem with all mode pages (SCSI and iSCSI) being
accessible and changeable from standard SCSI mode commands.  My initial
response to this section was to propose a method that would be
acceptable to the authors of the iSCSI draft.  If there is desire in the
group to allow mode pages for the entire target to be manipulated from
the SCSI level, I think that is a better idea that the one I proposed.
I would assume that an iSCSI aware SCSI utility would understand the
iSCSI specific settings, and allow the user to make those changes.  What
I am really against, is the ability to modify standard SCSI mode page
settings from text messages, as that could lead to target behavior
changes outside of the understanding of the SCSI nexus.

To recap your thinking:  Allow iSCSI text messages to modify and read
iSCSI only mode settings (potentially allowing the reading if SCSI mode
settings), but allow SCSI mode commands to modify and read all target
mode settings, including iSCSI settings.  Is that what you are saying.
If so, I agree.

Bob

Robert Griswold
Technologist
Crossroads Systems, Inc.
512-928-7272

 -----Original Message-----
From:     Eddy Quicksall [mailto:ESQuicksall@hotmail.com]
Sent:     Thursday, August 09, 2001 2:08 PM
To:  Robert Griswold; Jim Hafner
Cc:  ips@ece.cmu.edu
Subject:  Re: Review of the 07 draft

I don't like the idea of not letting a user of a SCSI utility be able to
change some of the parameters for iSCSI. Because they may be relevant to
him
and there may not be a user interface to the iSCSI driver. pSCSI sets
these
low level parameters via a standard mode set, so why not iSCSI?

It would be best if we could work out something where only the SCSI
layer
can set the mode pages. That would solve everything.

Eddy

----- Original Message -----
From: "Jim Hafner" <hafner@almaden.ibm.com>
To: "Robert Griswold" <rgriswold@Crossroads.com>
Cc: <ips@ece.cmu.edu>
Sent: Friday, August 03, 2001 5:26 PM
Subject: Re: Review of the 07 draft

> Well, in fact, the draft is supposed to say that MODE_SELECT for the
> transport-specific mode page will NOT be done via SCSI, only via Text
> commands.  I read that as saying that from the SCSI layer, all fields
in
> these pages are "unchangeable" (even though they can change in the
iSCSI
> layer).  Of course, the draft doesn't say whether MODE PARAMETERS HAVE
> CHANGED unit attentions get thrown up at the SCSI layer when this
happens
> at the iSCSI layer.... You later have a clarifying question (Section
3) on
> this as well.
>
> Regards,
> Jim Hafner
>
>
>
>





From owner-ips@ece.cmu.edu  Mon Aug 13 13:34:48 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25692
	for <ips-archive@odin.ietf.org>; Mon, 13 Aug 2001 13:34:47 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7DGZ5U14457
	for ips-outgoing; Mon, 13 Aug 2001 12:35:05 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from bramg1.net.external.hp.com (bramg1.net.external.hp.com [192.6.126.73])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7DGZ3e14451
	for <ips@ece.cmu.edu>; Mon, 13 Aug 2001 12:35:03 -0400 (EDT)
Received: from quasit.br.itc.hp.com (quasit.br.itc.hp.com [15.145.8.135])
	by bramg1.net.external.hp.com (Postfix) with ESMTP id CA1CA15
	for <ips@ece.cmu.edu>; Mon, 13 Aug 2001 18:35:13 +0200 (METDST)
Received: from loddon.br.itc.hp.com (loddon.br.itc.hp.com [15.145.8.166])
	by quasit.br.itc.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id RAA13073
	for <ips@ece.cmu.edu>; Mon, 13 Aug 2001 17:34:58 +0100 (BST)
Received: from 15.145.8.166 by loddon.br.itc.hp.com (InterScan E-Mail VirusWall NT); Mon, 13 Aug 2001 17:34:58 +0100 (GMT Daylight Time)
Received: by loddon.br.itc.hp.com with Internet Mail Service (5.5.2653.19)
	id <QN1BKWB4>; Mon, 13 Aug 2001 17:34:58 +0100
Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC101E7A80A@dickens.bri.hp.com>
From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <matthew_burbridge@hp.com>
To: ips@ece.cmu.edu
Subject: RE: CmdSN during login
Date: Mon, 13 Aug 2001 17:34:56 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Could commands sent during the login phase (ie LOGIN + TEXT) be mandatory to
be immediate and therefore MUST have the I bit set or is there a reason why
non-immediate login phase commands make sense?

Cheers

Matthew Burbridge

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, August 11, 2001 4:37 PM
To: ips@ece.cmu.edu
Subject: Re: CmdSN during login


There was ambiguity at first login that we have cleared in text and as I
said I don't see any good reason
for another case of immediate when we have the immediate bit available.
What we could do is add anothe pragraph to 8
recommending when to use the I bit in login.

Julo

"Eddy Quicksall" <ESQuicksall@hotmail.com> on 10-08-2001 18:13:32

Please respond to "Eddy Quicksall" <ESQuicksall@hotmail.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   <ips@ece.cmu.edu>
Subject:  Re: CmdSN during login



But, what if someone does this without setting the Immediate bit? What
would
one do?

What is wrong with just making the CmdSN not run during login? It seems
like
it was an arbitrary choice in the first place since it was originally
optional and not using it actually worked.

If CmdSN is stated as only used in FFP, then I don't see any ambiguity.

Eddy
----- Original Message -----
From: "Julian Satran" <Julian_Satran@il.ibm.com>
To: <ips@ece.cmu.edu>
Sent: Friday, August 10, 2001 2:43 AM
Subject: Re: CmdSN during login


>
> Sanjay,
>
> If you want to ignore CmdSN and expedite Login processing you can do so
by
> having the commands being issued as immediate.
> This will help us keep away from creating ambiguity about (or another
> conditional) for when CmdSN is to be used or not.
>
> Julo
>
> Mark Bakke <mbakke@cisco.com>@ece.cmu.edu on 09-08-2001 23:55:25
>
> Please respond to Mark Bakke <mbakke@cisco.com>
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   Sanjay Goyal <sanjay_goyal@ivivity.com>
> cc:   "Ips (E-mail)" <ips@ece.cmu.edu>
> Subject:  Re: CmdSN during login
>
>
>
>
> Sanjay-
>
> I absolutely agree with this; CmdSN is owned by the session, and
> should not be used until the connection has fully joined the session,
> which means full feature phase.
>
> This should also clean up any ambiguity on when to start
> using CmdSN.
>
> --
> Mark
>
> Sanjay Goyal wrote:
> >
> > Hi
> >
> >  Assuming Target and Initiator support multiple connections and the
> session
> > is having multiple connections. Assuming out-of-order CmdSN is a
> possibility
> > for this session.
> >
> >  Connection #   1       |       2       |       3
> > -------------------------------------------------------
> > Login Cmd  CmdSN=0      |   CmdSN=8     |  CmdSN=9
> > Txt   Cmd  CmdSN=1      |               |
> >                                 |               |
> >                                 |               |
> > Login Cmd  CmdSN=7      |  CmdSN=10     |  CmdSN=11
> > -------------------------------------------------------
> > Data Cmd   CmdSN=12     | CmdSN=14      | CmdSN=15
> > Data Cmd   CmdSN=13     |               |
> >                                 |               |
> >
> > CmdSN=7 is last of the Login sequence and it is acknowledged by the
> Target
> > with "accept login" response.
> >
> > Target would receive the PDUs in this CmdSN order
> >  0 to 7, 8, 9, 12, 10, 11, 13, 14, 15
> >
> > Now as Login and Text PDUs are being processed even though you have
> received
> > Data Cmd PDUs, you can not pass them to iSCSI layer and hence you are
> adding
> > latency.
> >
> > What I want to convey from this example is why not use CmdSN just
during
> the
> > FullFeature phase only.
> >
> > Regards
> > Sanjay Goyal
> >
> >
>
--------------------------------------------------------------------------
--------------------------
>
> >
> >    Part 1.2    Type: application/ms-tnef
> >            Encoding: base64
>
> --
> Mark A. Bakke
> Cisco Systems
> mbakke@cisco.com
> 763.398.1054
>
>
>
>




From owner-ips@ece.cmu.edu  Mon Aug 13 16:41:30 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28365
	for <ips-archive@odin.ietf.org>; Mon, 13 Aug 2001 16:41:29 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7DJWrZ24252
	for ips-outgoing; Mon, 13 Aug 2001 15:32:53 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from clyde.stargateip.com ([209.237.5.66])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7DJWoe24244
	for <ips@ece.cmu.edu>; Mon, 13 Aug 2001 15:32:50 -0400 (EDT)
Received: from bluestar (dhcp-101.stargateip.com [10.10.5.101])
	by clyde.stargateip.com (8.9.1/8.9.1) with SMTP id MAA19534;
	Mon, 13 Aug 2001 12:26:53 -0700 (PDT)
Reply-To: <deva@stargateip.com>
From: "Dev" <deva@stargateip.com>
To: "Julian Satran" <Julian_Satran@il.ibm.com>,
        "Robert Snively" <rsnively@Brocade.COM>
Cc: "Robert Griswold" <rgriswold@Crossroads.com>,
        "Eddy Quicksall" <ESQuicksall@hotmail.com>,
        "Jim Hafner" <hafner@almaden.ibm.com>, <ips@ece.cmu.edu>
Subject: RE: Review of the 07 draft
Date: Mon, 13 Aug 2001 12:37:10 -0700
Message-ID: <NFBBKBDFJCDMGCBKJLCJMEAAFDAA.deva@stargateip.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
In-Reply-To: <OF491FD131.1CD69B83-ONC2256AA5.007C9494@telaviv.ibm.com>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Yes I agree with this. 

Definitely MaxBurstsize is in the iSCSI domain. 

Thanks

Deva
Platys communications


-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, August 11, 2001 3:50 PM
To: Robert Snively
Cc: 'deva@stargateip.com'; Robert Griswold; Eddy Quicksall; Jim Hafner;
ips@ece.cmu.edu
Subject: RE: Review of the 07 draft


I think that for regularity it would be wise to remove completely EMDP and
FirstBurstsize from iSCSI control.
MaximumBurstSize defines the DataPDU length and is transport related
(affects iSCSI and less SCSI) and should stay under iSCSI control.


Comments?

Julo

Robert Snively <rsnively@Brocade.COM>@ece.cmu.edu on 10-08-2001 10:32:20

Please respond to Robert Snively <rsnively@Brocade.COM>

Sent by:  owner-ips@ece.cmu.edu


To:   "'deva@stargateip.com'" <deva@stargateip.com>, Robert Griswold
      <rgriswold@Crossroads.com>, Eddy Quicksall <ESQuicksall@hotmail.com>,
      Jim Hafner/Almaden/IBM@IBMUS
cc:   ips@ece.cmu.edu
Subject:  RE: Review of the 07 draft



Deva,

Both of you are right if iSCSI sticks to negotiating only
parameters related with the TCP connections, the iSCSI
session operational parameters other than EMDP and
burst length, and iSCSI security parameters.  Then, all
parameters relating to the normal SCSI activities, including
EMDP and burst length (which are required for SCSI, not iSCSI,
buffer management) would be negotiated in the normal
SCSI manner through the MODE SENSE/SELECT pages and everybody
would live happily ever after.

Otherwise, and especially with respect to EMDP and burst length,
I have to agree with Robert.

Bob Snively                        e-mail:    rsnively@brocade.com
Brocade Communications Systems     phone:  408 487 8135
1745 Technology Drive
San Jose, CA 95110



-----Original Message-----
From: Dev [mailto:deva@stargateip.com]
Sent: Thursday, August 09, 2001 5:33 PM
To: Robert Griswold; Eddy Quicksall; Jim Hafner
Cc: ips@ece.cmu.edu
Subject: RE: Review of the 07 draft


All,

I tend to disagree. The parameters for the iSCSI are negotiated between the
initiator and target.
If we allow the parameters to be changed through SCSI Mode select, how will
this work?

If parameters can be changed through SCSI Mode select then it will apply
only to Lead only connections.

So, we'll have

a) two methods to change the Lead only parameters common for the entire
session (one through mode select
and the other through text parameters)
b) Just iSCSI text command to change the connection specific parameters.

Does it not add to complexity having multiple ways to change the same
stuff?

Thanks

Deva
Platys communications

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Robert Griswold
Sent: Thursday, August 09, 2001 1:36 PM
To: Eddy Quicksall; Jim Hafner
Cc: ips@ece.cmu.edu
Subject: RE: Review of the 07 draft


Eddy:

I actually have no problem with all mode pages (SCSI and iSCSI) being
accessible and changeable from standard SCSI mode commands.  My initial
response to this section was to propose a method that would be
acceptable to the authors of the iSCSI draft.  If there is desire in the
group to allow mode pages for the entire target to be manipulated from
the SCSI level, I think that is a better idea that the one I proposed.
I would assume that an iSCSI aware SCSI utility would understand the
iSCSI specific settings, and allow the user to make those changes.  What
I am really against, is the ability to modify standard SCSI mode page
settings from text messages, as that could lead to target behavior
changes outside of the understanding of the SCSI nexus.

To recap your thinking:  Allow iSCSI text messages to modify and read
iSCSI only mode settings (potentially allowing the reading if SCSI mode
settings), but allow SCSI mode commands to modify and read all target
mode settings, including iSCSI settings.  Is that what you are saying.
If so, I agree.

Bob

Robert Griswold
Technologist
Crossroads Systems, Inc.
512-928-7272

 -----Original Message-----
From:     Eddy Quicksall [mailto:ESQuicksall@hotmail.com]
Sent:     Thursday, August 09, 2001 2:08 PM
To:  Robert Griswold; Jim Hafner
Cc:  ips@ece.cmu.edu
Subject:  Re: Review of the 07 draft

I don't like the idea of not letting a user of a SCSI utility be able to
change some of the parameters for iSCSI. Because they may be relevant to
him
and there may not be a user interface to the iSCSI driver. pSCSI sets
these
low level parameters via a standard mode set, so why not iSCSI?

It would be best if we could work out something where only the SCSI
layer
can set the mode pages. That would solve everything.

Eddy

----- Original Message -----
From: "Jim Hafner" <hafner@almaden.ibm.com>
To: "Robert Griswold" <rgriswold@Crossroads.com>
Cc: <ips@ece.cmu.edu>
Sent: Friday, August 03, 2001 5:26 PM
Subject: Re: Review of the 07 draft

> Well, in fact, the draft is supposed to say that MODE_SELECT for the
> transport-specific mode page will NOT be done via SCSI, only via Text
> commands.  I read that as saying that from the SCSI layer, all fields
in
> these pages are "unchangeable" (even though they can change in the
iSCSI
> layer).  Of course, the draft doesn't say whether MODE PARAMETERS HAVE
> CHANGED unit attentions get thrown up at the SCSI layer when this
happens
> at the iSCSI layer.... You later have a clarifying question (Section
3) on
> this as well.
>
> Regards,
> Jim Hafner
>
>
>
>






From owner-ips@ece.cmu.edu  Mon Aug 13 16:45:42 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28435
	for <ips-archive@odin.ietf.org>; Mon, 13 Aug 2001 16:45:41 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7DJa5k24451
	for ips-outgoing; Mon, 13 Aug 2001 15:36:05 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.147.1.144])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7DJa3e24446
	for <ips@ece.cmu.edu>; Mon, 13 Aug 2001 15:36:03 -0400 (EDT)
Received: from breinhold ([140.186.66.73])
	by chmls06.mediaone.net (8.11.1/8.11.1) with SMTP id f7DJZOm02322;
	Mon, 13 Aug 2001 15:35:27 -0400 (EDT)
From: "Barry Reinhold" <bbrtrebia@mediaone.net>
To: "ISCSI" <ips@ece.cmu.edu>
Cc: "James Smart" <james.smart@trebia.com>,
        "Chris Loveland" <chris.loveland@trebia.com>
Subject: iSCSI: Multiple markers before end of a data PDU
Date: Mon, 13 Aug 2001 15:37:09 -0400
Message-ID: <BJEIKPAFDFPFNCPPBCGPIECDCKAA.bbrtrebia@mediaone.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit

Julian and framing folks:

If markers are being used a there is a long PDU with a short marker interval
such that multiple markers come before the end of the PDU, are the bytes (as
measured on the wire) counted in the offset to the start of the PDU that is
the value of the marker.

Example: An iSCSI PDU is 8192 bytes long starting at byte position 1024. A
marker is to be inserted at byte position 1028. If no other markers were to
be placed into the stream the value in the marker would be 8188 (number of
bytes to get to the next PDU starting after the marker). Now if the marker
interval is 256 (1024 bytes) then there would be six additional markers in
the PDU. Would the value contained in the first marker still be 8188 or
would it now be 8188+6*8?

The 0.7 draft does not addresses the marker interval and the inital
marker-less interval which do not have this issue. The marker value (marker
to end of PDU) value need to be specified.

If the marker value is to be the TCP byte stream offset as seen on the wire
then the process that does the insertion of the markers will need to know
the size of the PDU, the position of the last marker and the marker
interval.

If the marker value does not contain the "additional" markers that are
inserted then the receiver when using markers to recover a PDU header must
scan the TCP stream and remove the markers while advancing to the next PDU
or calculate the number of extra bytes in the received stream to get the
offset.

At this point in time I don't really care which way we do it, just as long
as we all understand how this is going to be done.

From 0.7:

The marker interval and the initial marker-less interval are counted
        in terms of the TCP stream data. Anything counted in the TCP
        sequence-number is counted for the interval and the initial marker-
        less interval. Specifically this includes any bytes "inserted" in
the
        TCP stream by an UFL.


     Satran, J.      Standards-Track, Expire November 2001             155

                                     iSCSI                   July 20, 2001


        When reduced to iSCSI terms markers MUST indicate the offset to a 4-
        byte word boundary in the stream.  The last 2 bits of each marker
        word are reserved and are considered 0 for offset computation.

        Padding iSCSI PDU payloads to 4-byte word boundaries simplifies
        marker manipulation.


Barry Reinhold
Principal Architect
Trebia Networks
barry.reinhold@trebia.com
603-868-5144/603-659-0885/978-929-0830 x138



From owner-ips@ece.cmu.edu  Mon Aug 13 17:56:17 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29306
	for <ips-archive@odin.ietf.org>; Mon, 13 Aug 2001 17:56:17 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7DL3pT28893
	for ips-outgoing; Mon, 13 Aug 2001 17:03:51 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from sandmail.sandburst.com (sandmail.sandburst.com [216.57.132.42])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7DL3oe28889
	for <ips@ece.cmu.edu>; Mon, 13 Aug 2001 17:03:50 -0400 (EDT)
To: "Barry Reinhold" <bbrtrebia@mediaone.net>
Cc: "ISCSI" <ips@ece.cmu.edu>, "James Smart" <james.smart@trebia.com>,
        "Chris Loveland" <chris.loveland@trebia.com>
Subject: Re: iSCSI: Multiple markers before end of a data PDU 
In-Reply-To: Message from "Barry Reinhold" <bbrtrebia@mediaone.net> 
   of "Mon, 13 Aug 2001 15:37:09 EDT." <BJEIKPAFDFPFNCPPBCGPIECDCKAA.bbrtrebia@mediaone.net> 
References: <BJEIKPAFDFPFNCPPBCGPIECDCKAA.bbrtrebia@mediaone.net> 
Date: Mon, 13 Aug 2001 17:03:21 -0400
From: Stephen Bailey <steph@cs.uchicago.edu>
Message-Id: <20010813210333.C54F04E96@sandmail.sandburst.com>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Barry,

> If markers are being used a there is a long PDU with a short marker interval
> such that multiple markers come before the end of the PDU, are the bytes (as
> measured on the wire) counted in the offset to the start of the PDU that is
> the value of the marker.

Yes.

In other words, the TCP sequence number of the start of the PDU
pointed to by a marker is TCP sequence number of the byte following
the marker, plus the `Next PDU Offset' value contained in the marker.

This makes markers a bit more complicated to insert, but easier to
process on the receiver (which is working harder in other ways
already).

> If the marker value is to be the TCP byte stream offset as seen on the wire
> then the process that does the insertion of the markers will need to know
> the size of the PDU, the position of the last marker and the marker
> interval.

Yes.

Note that it probably doesn't make a lot of sense to have a short
marker interval and a long maximum PDU size.  The minimum grain size
to which you could possibly bound your eddy buffer is O(PDU size).
You just need to have markers frequently enough that you'll be able to
find the beginning of the next PDU with high probability.

In that sense, a maximum PDU which is roughly MSS bytes and markers
which occur roughly every MSS bytes gives you about the best bound you
could hope for.

Steph


From owner-ips@ece.cmu.edu  Mon Aug 13 18:00:12 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29364
	for <ips-archive@odin.ietf.org>; Mon, 13 Aug 2001 18:00:11 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7DKkuw28025
	for ips-outgoing; Mon, 13 Aug 2001 16:46:56 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7DKkse28021
	for <ips@ece.cmu.edu>; Mon, 13 Aug 2001 16:46:54 -0400 (EDT)
Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <QSSX6QVZ>; Mon, 13 Aug 2001 16:46:49 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD5B3@CORPMX14>
From: Black_David@emc.com
To: matthew_burbridge@hp.com, ips@ece.cmu.edu
Subject: RE: iSCSI: CmdSN during login
Date: Mon, 13 Aug 2001 16:41:19 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Sounds like a good idea to me, and this would also lead to
a definitive resolution of the resource allocation requirements
at targets for immediate commands (which I believe is still
an open issue).  Providing both options just adds complexity,
and I have seen no requests for logins on connections other
than the first to be ordered with respect to other commands
on the first connection.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


> -----Original Message-----
> From: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)
> [mailto:matthew_burbridge@hp.com]
> Sent: Monday, August 13, 2001 12:35 PM
> To: ips@ece.cmu.edu
> Subject: RE: CmdSN during login
> 
> 
> Could commands sent during the login phase (ie LOGIN + TEXT) 
> be mandatory to
> be immediate and therefore MUST have the I bit set or is 
> there a reason why
> non-immediate login phase commands make sense?
> 
> Cheers
> 
> Matthew Burbridge
> 
> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Saturday, August 11, 2001 4:37 PM
> To: ips@ece.cmu.edu
> Subject: Re: CmdSN during login
> 
> 
> There was ambiguity at first login that we have cleared in 
> text and as I
> said I don't see any good reason
> for another case of immediate when we have the immediate bit 
> available.
> What we could do is add anothe pragraph to 8
> recommending when to use the I bit in login.
> 
> Julo
> 
> "Eddy Quicksall" <ESQuicksall@hotmail.com> on 10-08-2001 18:13:32
> 
> Please respond to "Eddy Quicksall" <ESQuicksall@hotmail.com>
> 
> To:   Julian Satran/Haifa/IBM@IBMIL
> cc:   <ips@ece.cmu.edu>
> Subject:  Re: CmdSN during login
> 
> 
> 
> But, what if someone does this without setting the Immediate bit? What
> would
> one do?
> 
> What is wrong with just making the CmdSN not run during 
> login? It seems
> like
> it was an arbitrary choice in the first place since it was originally
> optional and not using it actually worked.
> 
> If CmdSN is stated as only used in FFP, then I don't see any 
> ambiguity.
> 
> Eddy
> ----- Original Message -----
> From: "Julian Satran" <Julian_Satran@il.ibm.com>
> To: <ips@ece.cmu.edu>
> Sent: Friday, August 10, 2001 2:43 AM
> Subject: Re: CmdSN during login
> 
> 
> >
> > Sanjay,
> >
> > If you want to ignore CmdSN and expedite Login processing 
> you can do so
> by
> > having the commands being issued as immediate.
> > This will help us keep away from creating ambiguity about 
> (or another
> > conditional) for when CmdSN is to be used or not.
> >
> > Julo
> >
> > Mark Bakke <mbakke@cisco.com>@ece.cmu.edu on 09-08-2001 23:55:25
> >
> > Please respond to Mark Bakke <mbakke@cisco.com>
> >
> > Sent by:  owner-ips@ece.cmu.edu
> >
> >
> > To:   Sanjay Goyal <sanjay_goyal@ivivity.com>
> > cc:   "Ips (E-mail)" <ips@ece.cmu.edu>
> > Subject:  Re: CmdSN during login
> >
> >
> >
> >
> > Sanjay-
> >
> > I absolutely agree with this; CmdSN is owned by the session, and
> > should not be used until the connection has fully joined 
> the session,
> > which means full feature phase.
> >
> > This should also clean up any ambiguity on when to start
> > using CmdSN.
> >
> > --
> > Mark
> >
> > Sanjay Goyal wrote:
> > >
> > > Hi
> > >
> > >  Assuming Target and Initiator support multiple 
> connections and the
> > session
> > > is having multiple connections. Assuming out-of-order CmdSN is a
> > possibility
> > > for this session.
> > >
> > >  Connection #   1       |       2       |       3
> > > -------------------------------------------------------
> > > Login Cmd  CmdSN=0      |   CmdSN=8     |  CmdSN=9
> > > Txt   Cmd  CmdSN=1      |               |
> > >                                 |               |
> > >                                 |               |
> > > Login Cmd  CmdSN=7      |  CmdSN=10     |  CmdSN=11
> > > -------------------------------------------------------
> > > Data Cmd   CmdSN=12     | CmdSN=14      | CmdSN=15
> > > Data Cmd   CmdSN=13     |               |
> > >                                 |               |
> > >
> > > CmdSN=7 is last of the Login sequence and it is 
> acknowledged by the
> > Target
> > > with "accept login" response.
> > >
> > > Target would receive the PDUs in this CmdSN order
> > >  0 to 7, 8, 9, 12, 10, 11, 13, 14, 15
> > >
> > > Now as Login and Text PDUs are being processed even 
> though you have
> > received
> > > Data Cmd PDUs, you can not pass them to iSCSI layer and 
> hence you are
> > adding
> > > latency.
> > >
> > > What I want to convey from this example is why not use CmdSN just
> during
> > the
> > > FullFeature phase only.
> > >
> > > Regards
> > > Sanjay Goyal
> > >
> > >
> >
> --------------------------------------------------------------
> ------------
> --------------------------
> >
> > >
> > >    Part 1.2    Type: application/ms-tnef
> > >            Encoding: base64
> >
> > --
> > Mark A. Bakke
> > Cisco Systems
> > mbakke@cisco.com
> > 763.398.1054
> >
> >
> >
> >
> 
> 


From owner-ips@ece.cmu.edu  Mon Aug 13 20:25:02 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00654
	for <ips-archive@odin.ietf.org>; Mon, 13 Aug 2001 20:25:01 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7DNKm204641
	for ips-outgoing; Mon, 13 Aug 2001 19:20:48 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7DLNde29909
	for <ips@ece.cmu.edu>; Mon, 13 Aug 2001 17:23:39 -0400 (EDT)
Received: from phys-ha6nwka.ebay.sun.com ([129.149.1.82])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA09506;
	Mon, 13 Aug 2001 14:23:36 -0700 (PDT)
Received: from animal (animal.Central.Sun.COM [129.153.128.21])
	by phys-ha6nwka.ebay.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id OAA24530;
	Mon, 13 Aug 2001 14:23:33 -0700 (PDT)
Message-Id: <200108132123.OAA24530@phys-ha6nwka.ebay.sun.com>
Date: Mon, 13 Aug 2001 16:23:36 -0500 (CDT)
From: David Robinson <David.Robinson@sun.com>
Reply-To: David Robinson <David.Robinson@sun.com>
Subject: RE: can i discuss infiniband here
To: sharan@ctd.hcltech.com, ips@ece.cmu.edu, Black_David@emc.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: wEJ43Dg0RtgerEAUs2Femw==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc 
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

If someone were to investigate replacing TCP as the reliable transport
for iSCSI with an IB reliable transport, and the found architectural 
problems with iSCSI, then this would be a good forum to discuss
those iSCSI problems.  But not the forum to debate what the
right storage over IB solution is.

	-David
	(Pondering iSCSI taking over the IB world as well)
	
> InfiniBand could be discussed here in the context of
> proposing new work (e.g., SRP over IP in some form), but
> discussion of InfiniBand as it currently exists belongs
> elsewhere - you might start with the InfiniBand Trade
> Association (www.infinibandta.org) to look for a suitable
> forum.
> 
> --David (WG co-chair)
> 
> > -----Original Message-----
> > From: Sharan Basappa [mailto:sharan@ctd.hcltech.com]
> > Sent: Tuesday, July 31, 2001 2:41 AM
> > To: 'ips@ece.cmu.edu'
> > Subject: can i discuss infiniband here
> > 
> > 
> > Just wanted to know if infiniband can be discussed in this forum.
> > Sharan
> > 


From owner-ips@ece.cmu.edu  Mon Aug 13 22:07:12 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02762
	for <ips-archive@odin.ietf.org>; Mon, 13 Aug 2001 22:07:12 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7E13Te07073
	for ips-outgoing; Mon, 13 Aug 2001 21:03:29 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7E13Se07067
	for <ips@ece.cmu.edu>; Mon, 13 Aug 2001 21:03:28 -0400 (EDT)
Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <QSSX695K>; Mon, 13 Aug 2001 21:03:23 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD5BD@CORPMX14>
From: Black_David@emc.com
To: hufferd@us.ibm.com, ips@ece.cmu.edu
Subject: RE: iSCSI: draft 7: remove S bit and Status field from the Data-i
	n PD U?
Date: Mon, 13 Aug 2001 20:57:56 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

John,

I think you've taken a wrong turn.  
 
> First, immediate and unsolicited separate Data PDUs are very valuable for
> situations where the Target is at distance from the Initiator.

Ok, that's fine.

> Second, thoughts of removing the immediate data seem not to be
> simplification, since all the information to tie the data to the command
is
> right there with the command.  That has got to be easier than matching up
> separate PDUs of data with the appropriate commands.

Actually, that was the point, since the logic for "matching up separate
PDUs of data with the appropriate commands" has to exist for inbound
Data PDUs already.  The slide I presented in London was about replacing
immediate data with an unsolicited data PDU immediately following the
command, thus removing the immediate data case in favor of reusing the
logic for dealing with separate Data PDUs.  Remember that this was presented
as a simplification possibility.

Comments?
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


From owner-ips@ece.cmu.edu  Mon Aug 13 22:08:53 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02776
	for <ips-archive@odin.ietf.org>; Mon, 13 Aug 2001 22:08:53 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7E1FVQ07451
	for ips-outgoing; Mon, 13 Aug 2001 21:15:31 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mxic2.us.dg.com (mxic2.us.dg.com [128.221.31.40])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7E1FTe07445
	for <ips@ece.cmu.edu>; Mon, 13 Aug 2001 21:15:29 -0400 (EDT)
Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19)
	id <QQ9Q3ZX0>; Mon, 13 Aug 2001 21:13:25 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD5BE@CORPMX14>
From: Black_David@emc.com
To: rsnively@Brocade.COM, ips@ece.cmu.edu
Subject: RE: iSCSI: Support Alias in the protocol
Date: Mon, 13 Aug 2001 21:09:56 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

A couple of clarifications ...

> I feel that the alias does not belong in the iSCSI architecture.
> Aliasing is already routinely provided at two other levels in
> the protocol stack and need not be redundantly inserted in iSCSI.
> 
> a)  In the SCSI command set
> 
> There is already available a logical unit level aliasing process
> using the SET/REPORT DEVICE IDENTIFIER service actions defined
> in the SCSI command set standard SPC-2.  
> 
> b)  In the operating system stack
> 
> Most implementations use aliases created at the system level, not
> the protocol level, that are far more useful and can be tuned
> to the particular environment.  A particularly naive example of
> this is the mapping of identified devices to the A:, B:, or 
> C: disk drives in the similarly naive MS-DOS operating system.
> More sophisticated systems and management structures use similar
> aliasing at the system level.

As John has pointed out, both of these are LU or LUN aliases rather
that Initiator or Target aliases.  Further, the second one can be
somewhat fragile.  It's entirely too easy to inadvertently change
device mappings (e.g., pull disk E: out of an MS-DOS system, reboot,
and under the right conditions disk F: becomes disk E:).  I'm sure
someone from Veritas can explain the lengths to which the Veritas
Volume Manager (VxVM) goes to avoid relying on any configuration
information of this sort -- VxVM writes its own header on every
volume so that it knows *exactly* what each volume is no matter
how/where it shows up.  

Let me also acknowledge as valid Marj's opinion that anything of
this sort belongs in a management tool rather than the protocol.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


From owner-ips@ece.cmu.edu  Tue Aug 14 02:58:43 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23302
	for <ips-archive@odin.ietf.org>; Tue, 14 Aug 2001 02:58:43 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7E5m9M14313
	for ips-outgoing; Tue, 14 Aug 2001 01:48:09 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail.san.yahoo.com (mail.san.yahoo.com [209.132.1.30])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7E5m8e14308
	for <ips@ece.cmu.edu>; Tue, 14 Aug 2001 01:48:08 -0400 (EDT)
Received: from bursar.muttsnuts.com (193.120.246.22) by mail.san.yahoo.com (5.5.041.1)
        id 3B708C180017644F for ips@ece.cmu.edu; Mon, 13 Aug 2001 22:46:21 -0700
Message-Id: <5.1.0.14.2.20010814064149.01db1b88@mail.muttsnuts.com>
X-Sender: markemuttsnuts@mail.muttsnuts.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 14 Aug 2001 06:46:35 +0100
To: ips@ece.cmu.edu
From: "Mark S. Edwards" <marke@muttsnuts.com>
Subject: RE: iSCSI: Support Alias in the protocol
In-Reply-To: <277DD60FB639D511AC0400B0D068B71ECAD5BE@CORPMX14>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

At 09:09 PM 8/13/2001 -0400, Black_David@emc.com wrote:

>Let me also acknowledge as valid Marj's opinion that anything of
>this sort belongs in a management tool rather than the protocol.

But it only works if everyone uses the same management tool, or the tools 
agree upon the location and storage format of the information --  Somebody 
dig me up from my grave when Tivoli and OpenView merge.

As a way of easily identifying virtual LUN's or LU's within a Target Space 
of potential hundreds or thousands the alias is very valuable.

Mark.



From owner-ips@ece.cmu.edu  Tue Aug 14 03:00:16 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23370
	for <ips-archive@odin.ietf.org>; Tue, 14 Aug 2001 03:00:15 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7E69Bq14785
	for ips-outgoing; Tue, 14 Aug 2001 02:09:11 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7E699e14781
	for <ips@ece.cmu.edu>; Tue, 14 Aug 2001 02:09:10 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id IAA169230
	for <ips@ece.cmu.edu>; Tue, 14 Aug 2001 08:09:03 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7E692T71158
	for <ips@ece.cmu.edu>; Tue, 14 Aug 2001 08:09:02 +0200
Importance: Normal
Subject: RE: CmdSN during login
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFEDEA6175.6D8F9B28-ONC2256AA8.0020B8D9@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Tue, 14 Aug 2001 09:08:40 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 14/08/2001 09:09:02
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


I can see scenarios in which you would want the login request  be regular -
as when you issue it after
a task management clear LU or reset command and want to make sure that it
executed after the clear and the CmdSN clearly indicates that.  However
even this effect can be achieved by other means and the discussion is
rather academic - should we mandate the I bit in the login phase (MUST) or
just say that it should be used whenever adequate and explain why (which I
prefer) as it won't be required in all cases (e.g., it is not necessary in
a session establishing login).

Julo

"BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <matthew_burbridge@hp.com>
@ece.cmu.edu on 13-08-2001 19:34:56

Please respond to "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)"
      <matthew_burbridge@hp.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: CmdSN during login



Could commands sent during the login phase (ie LOGIN + TEXT) be mandatory
to
be immediate and therefore MUST have the I bit set or is there a reason why
non-immediate login phase commands make sense?

Cheers

Matthew Burbridge

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, August 11, 2001 4:37 PM
To: ips@ece.cmu.edu
Subject: Re: CmdSN during login


There was ambiguity at first login that we have cleared in text and as I
said I don't see any good reason
for another case of immediate when we have the immediate bit available.
What we could do is add anothe pragraph to 8
recommending when to use the I bit in login.

Julo

"Eddy Quicksall" <ESQuicksall@hotmail.com> on 10-08-2001 18:13:32

Please respond to "Eddy Quicksall" <ESQuicksall@hotmail.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   <ips@ece.cmu.edu>
Subject:  Re: CmdSN during login



But, what if someone does this without setting the Immediate bit? What
would
one do?

What is wrong with just making the CmdSN not run during login? It seems
like
it was an arbitrary choice in the first place since it was originally
optional and not using it actually worked.

If CmdSN is stated as only used in FFP, then I don't see any ambiguity.

Eddy
----- Original Message -----
From: "Julian Satran" <Julian_Satran@il.ibm.com>
To: <ips@ece.cmu.edu>
Sent: Friday, August 10, 2001 2:43 AM
Subject: Re: CmdSN during login


>
> Sanjay,
>
> If you want to ignore CmdSN and expedite Login processing you can do so
by
> having the commands being issued as immediate.
> This will help us keep away from creating ambiguity about (or another
> conditional) for when CmdSN is to be used or not.
>
> Julo
>
> Mark Bakke <mbakke@cisco.com>@ece.cmu.edu on 09-08-2001 23:55:25
>
> Please respond to Mark Bakke <mbakke@cisco.com>
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   Sanjay Goyal <sanjay_goyal@ivivity.com>
> cc:   "Ips (E-mail)" <ips@ece.cmu.edu>
> Subject:  Re: CmdSN during login
>
>
>
>
> Sanjay-
>
> I absolutely agree with this; CmdSN is owned by the session, and
> should not be used until the connection has fully joined the session,
> which means full feature phase.
>
> This should also clean up any ambiguity on when to start
> using CmdSN.
>
> --
> Mark
>
> Sanjay Goyal wrote:
> >
> > Hi
> >
> >  Assuming Target and Initiator support multiple connections and the
> session
> > is having multiple connections. Assuming out-of-order CmdSN is a
> possibility
> > for this session.
> >
> >  Connection #   1       |       2       |       3
> > -------------------------------------------------------
> > Login Cmd  CmdSN=0      |   CmdSN=8     |  CmdSN=9
> > Txt   Cmd  CmdSN=1      |               |
> >                                 |               |
> >                                 |               |
> > Login Cmd  CmdSN=7      |  CmdSN=10     |  CmdSN=11
> > -------------------------------------------------------
> > Data Cmd   CmdSN=12     | CmdSN=14      | CmdSN=15
> > Data Cmd   CmdSN=13     |               |
> >                                 |               |
> >
> > CmdSN=7 is last of the Login sequence and it is acknowledged by the
> Target
> > with "accept login" response.
> >
> > Target would receive the PDUs in this CmdSN order
> >  0 to 7, 8, 9, 12, 10, 11, 13, 14, 15
> >
> > Now as Login and Text PDUs are being processed even though you have
> received
> > Data Cmd PDUs, you can not pass them to iSCSI layer and hence you are
> adding
> > latency.
> >
> > What I want to convey from this example is why not use CmdSN just
during
> the
> > FullFeature phase only.
> >
> > Regards
> > Sanjay Goyal
> >
> >
>
--------------------------------------------------------------------------
--------------------------
>
> >
> >    Part 1.2    Type: application/ms-tnef
> >            Encoding: base64
>
> --
> Mark A. Bakke
> Cisco Systems
> mbakke@cisco.com
> 763.398.1054
>
>
>
>







From owner-ips@ece.cmu.edu  Tue Aug 14 03:50:56 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23933
	for <ips-archive@odin.ietf.org>; Tue, 14 Aug 2001 03:50:56 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7E6rWm15740
	for ips-outgoing; Tue, 14 Aug 2001 02:53:32 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7E6rUe15735
	for <ips@ece.cmu.edu>; Tue, 14 Aug 2001 02:53:30 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id IAA145752;
	Tue, 14 Aug 2001 08:53:15 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7E6qxT46196;
	Tue, 14 Aug 2001 08:52:59 +0200
Importance: Normal
Subject: Re: iSCSI: Multiple markers before end of a data PDU
To: ips@ece.cmu.edu
Cc: "Barry Reinhold" <bbrtrebia@mediaone.net>,
        "James Smart" <james.smart@trebia.com>,
        "Chris Loveland" <chris.loveland@trebia.com>
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF0CB62F28.4965F6ED-ONC2256AA8.00253826@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Tue, 14 Aug 2001 09:52:37 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 14/08/2001 09:53:14
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


I've added to appendix C the following:


      The offset to the next iSCSI PDU header is counted in terms of the
      TCP stream data. Anything counted in the TCP sequence-number is
      counted for the offset. Specifically this includes any bytes
      "inserted" in the TCP stream by an UFL and it excludes any other
      markers inserted between the one we are examining and the next PDU
      header. The inserted value is independent of the marker interval.





Regards,

Julo

Please respond to "Barry Reinhold" <bbrtrebia@mediaone.net>

Sent by:  owner-ips@ece.cmu.edu


To:   "ISCSI" <ips@ece.cmu.edu>
cc:   "James Smart" <james.smart@trebia.com>, "Chris Loveland"
      <chris.loveland@trebia.com>
Subject:  iSCSI: Multiple markers before end of a data PDU



Julian and framing folks:

If markers are being used a there is a long PDU with a short marker
interval
such that multiple markers come before the end of the PDU, are the bytes
(as
measured on the wire) counted in the offset to the start of the PDU that is
the value of the marker.

Example: An iSCSI PDU is 8192 bytes long starting at byte position 1024. A
marker is to be inserted at byte position 1028. If no other markers were to
be placed into the stream the value in the marker would be 8188 (number of
bytes to get to the next PDU starting after the marker). Now if the marker
interval is 256 (1024 bytes) then there would be six additional markers in
the PDU. Would the value contained in the first marker still be 8188 or
would it now be 8188+6*8?

The 0.7 draft does not addresses the marker interval and the inital
marker-less interval which do not have this issue. The marker value (marker
to end of PDU) value need to be specified.

If the marker value is to be the TCP byte stream offset as seen on the wire
then the process that does the insertion of the markers will need to know
the size of the PDU, the position of the last marker and the marker
interval.

If the marker value does not contain the "additional" markers that are
inserted then the receiver when using markers to recover a PDU header must
scan the TCP stream and remove the markers while advancing to the next PDU
or calculate the number of extra bytes in the received stream to get the
offset.

At this point in time I don't really care which way we do it, just as long
as we all understand how this is going to be done.

From 0.7:

The marker interval and the initial marker-less interval are counted
        in terms of the TCP stream data. Anything counted in the TCP
        sequence-number is counted for the interval and the initial marker-
        less interval. Specifically this includes any bytes "inserted" in
the
        TCP stream by an UFL.


     Satran, J.      Standards-Track, Expire November 2001             155

                                     iSCSI                   July 20, 2001


        When reduced to iSCSI terms markers MUST indicate the offset to a
4-
        byte word boundary in the stream.  The last 2 bits of each marker
        word are reserved and are considered 0 for offset computation.

        Padding iSCSI PDU payloads to 4-byte word boundaries simplifies
        marker manipulation.


Barry Reinhold
Principal Architect
Trebia Networks
barry.reinhold@trebia.com
603-868-5144/603-659-0885/978-929-0830 x138






From owner-ips@ece.cmu.edu  Tue Aug 14 03:51:40 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23955
	for <ips-archive@odin.ietf.org>; Tue, 14 Aug 2001 03:51:40 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7E7DDS16113
	for ips-outgoing; Tue, 14 Aug 2001 03:13:13 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7E7DBe16109
	for <ips@ece.cmu.edu>; Tue, 14 Aug 2001 03:13:11 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id JAA192418
	for <ips@ece.cmu.edu>; Tue, 14 Aug 2001 09:13:05 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7E7D4T24818
	for <ips@ece.cmu.edu>; Tue, 14 Aug 2001 09:13:04 +0200
Importance: Normal
Subject: RE: iSCSI: draft 7: remove S bit and Status field from the Data-i	n PD U?
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFD823E177.24A6EB89-ONC2256AA8.00276023@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Tue, 14 Aug 2001 10:12:37 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 14/08/2001 10:13:04
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Performance for the receiver is an issue - 3 reads instead of 2.
We agreed that we will examine the need for both immediate and
non-immediate unsolicited in the same execution
and this is by no means a major simplification.

Julo

Black_David@emc.com@ece.cmu.edu on 14-08-2001 03:57:56

Please respond to Black_David@emc.com

Sent by:  owner-ips@ece.cmu.edu


To:   John Hufferd/San Jose/IBM@IBMUS, ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: draft 7: remove S bit and Status field from the Data-i
      n PD U?



John,

I think you've taken a wrong turn.

> First, immediate and unsolicited separate Data PDUs are very valuable for
> situations where the Target is at distance from the Initiator.

Ok, that's fine.

> Second, thoughts of removing the immediate data seem not to be
> simplification, since all the information to tie the data to the command
is
> right there with the command.  That has got to be easier than matching up
> separate PDUs of data with the appropriate commands.

Actually, that was the point, since the logic for "matching up separate
PDUs of data with the appropriate commands" has to exist for inbound
Data PDUs already.  The slide I presented in London was about replacing
immediate data with an unsolicited data PDU immediately following the
command, thus removing the immediate data case in favor of reusing the
logic for dealing with separate Data PDUs.  Remember that this was
presented
as a simplification possibility.

Comments?
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------





From owner-ips@ece.cmu.edu  Tue Aug 14 09:37:51 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04174
	for <ips-archive@odin.ietf.org>; Tue, 14 Aug 2001 09:37:51 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7ECL4x03931
	for ips-outgoing; Tue, 14 Aug 2001 08:21:04 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7ECL2e03925
	for <ips@ece.cmu.edu>; Tue, 14 Aug 2001 08:21:02 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id OAA190026
	for <ips@ece.cmu.edu>; Tue, 14 Aug 2001 14:20:54 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7ECKrg213670
	for <ips@ece.cmu.edu>; Tue, 14 Aug 2001 14:20:53 +0200
Importance: Normal
Subject: RE: iSCSI: Support Alias in the protocol
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF744145D3.8DCB25DF-ONC2256AA8.004367FB@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Tue, 14 Aug 2001 15:20:31 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 14/08/2001 15:20:52
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Whoever brought to the list the notion that TargetAlias or InitiatorAlias
name LUs must have  been reading a document that is not accessible to the
rest of us.

As specified today they are referring to what they say they are referring -
Targets and Initiators.

In any case please don't misread me - I am not part of this debate.

Julo

"Mark S. Edwards" <marke@muttsnuts.com>@ece.cmu.edu on 14-08-2001 08:46:35

Please respond to "Mark S. Edwards" <marke@muttsnuts.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: Support Alias in the protocol



At 09:09 PM 8/13/2001 -0400, Black_David@emc.com wrote:

>Let me also acknowledge as valid Marj's opinion that anything of
>this sort belongs in a management tool rather than the protocol.

But it only works if everyone uses the same management tool, or the tools
agree upon the location and storage format of the information --  Somebody
dig me up from my grave when Tivoli and OpenView merge.

As a way of easily identifying virtual LUN's or LU's within a Target Space
of potential hundreds or thousands the alias is very valuable.

Mark.






From owner-ips@ece.cmu.edu  Tue Aug 14 12:12:11 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08465
	for <ips-archive@odin.ietf.org>; Tue, 14 Aug 2001 12:12:10 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7EEpwL10136
	for ips-outgoing; Tue, 14 Aug 2001 10:51:58 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7EEpte10126
	for <ips@ece.cmu.edu>; Tue, 14 Aug 2001 10:51:55 -0400 (EDT)
Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA19476; Tue, 14 Aug 2001 10:51:46 -0400 (EDT)
Message-ID: <3B79397B.F46F1C8B@cisco.com>
Date: Tue, 14 Aug 2001 09:45:15 -0500
From: Mark Bakke <mbakke@cisco.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686)
X-Accept-Language: en, de
MIME-Version: 1.0
To: Julian Satran <Julian_Satran@il.ibm.com>
CC: ips@ece.cmu.edu
Subject: Re: CmdSN during login
References: <OFEDEA6175.6D8F9B28-ONC2256AA8.0020B8D9@telaviv.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Julian-

What are the specific scenarios where this would happen?  My
assumption has been that there is exactly one login exchange
when a connection is established, and if a connection is logged
out for some reason, that connection is destroyed.  To do
another login, a new connection would have to be created.  If
a connection is joining a session already in progress, how
would it make any difference if task management commands were
happening in full feature phase within other connections on
the session?  Why would the login have to wait?  You mentioned
that there were other ways to handle this.  Can we settle on
using the "other ways" instead?

I do think that your suggestion of mandating the I bit set
during login and negotiation would work; if the I bit is set,
the CmdSN is ignored and can be set to anything (I'd prefer
zero).  This effectively means that CmdSN does not start
incrementing until full feature phase, which is what we wanted,
but is still in the login and text command format "just in case"
it's needed at some other time.

However, I would like to strongly word this such that the login
and negotiation phases always set the I bit, send CmdSN=0, and
ignore CmdSN on receive, until full feature phase is started.
I think that a statement like "use whenever adequate" is too
weak and ambiguous.

--
Mark

Julian Satran wrote:
> 
> I can see scenarios in which you would want the login request  be regular -
> as when you issue it after
> a task management clear LU or reset command and want to make sure that it
> executed after the clear and the CmdSN clearly indicates that.  However
> even this effect can be achieved by other means and the discussion is
> rather academic - should we mandate the I bit in the login phase (MUST) or
> just say that it should be used whenever adequate and explain why (which I
> prefer) as it won't be required in all cases (e.g., it is not necessary in
> a session establishing login).
> 
> Julo
> 
> "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <matthew_burbridge@hp.com>
> @ece.cmu.edu on 13-08-2001 19:34:56
> 
> Please respond to "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)"
>       <matthew_burbridge@hp.com>
> 
> Sent by:  owner-ips@ece.cmu.edu
> 
> To:   ips@ece.cmu.edu
> cc:
> Subject:  RE: CmdSN during login
> 
> Could commands sent during the login phase (ie LOGIN + TEXT) be mandatory
> to
> be immediate and therefore MUST have the I bit set or is there a reason why
> non-immediate login phase commands make sense?
> 
> Cheers
> 
> Matthew Burbridge
> 
> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Saturday, August 11, 2001 4:37 PM
> To: ips@ece.cmu.edu
> Subject: Re: CmdSN during login
> 
> There was ambiguity at first login that we have cleared in text and as I
> said I don't see any good reason
> for another case of immediate when we have the immediate bit available.
> What we could do is add anothe pragraph to 8
> recommending when to use the I bit in login.
> 
> Julo
> 
> "Eddy Quicksall" <ESQuicksall@hotmail.com> on 10-08-2001 18:13:32
> 
> Please respond to "Eddy Quicksall" <ESQuicksall@hotmail.com>
> 
> To:   Julian Satran/Haifa/IBM@IBMIL
> cc:   <ips@ece.cmu.edu>
> Subject:  Re: CmdSN during login
> 
> But, what if someone does this without setting the Immediate bit? What
> would
> one do?
> 
> What is wrong with just making the CmdSN not run during login? It seems
> like
> it was an arbitrary choice in the first place since it was originally
> optional and not using it actually worked.
> 
> If CmdSN is stated as only used in FFP, then I don't see any ambiguity.
> 
> Eddy
> ----- Original Message -----
> From: "Julian Satran" <Julian_Satran@il.ibm.com>
> To: <ips@ece.cmu.edu>
> Sent: Friday, August 10, 2001 2:43 AM
> Subject: Re: CmdSN during login
> 
> >
> > Sanjay,
> >
> > If you want to ignore CmdSN and expedite Login processing you can do so
> by
> > having the commands being issued as immediate.
> > This will help us keep away from creating ambiguity about (or another
> > conditional) for when CmdSN is to be used or not.
> >
> > Julo
> >
> > Mark Bakke <mbakke@cisco.com>@ece.cmu.edu on 09-08-2001 23:55:25
> >
> > Please respond to Mark Bakke <mbakke@cisco.com>
> >
> > Sent by:  owner-ips@ece.cmu.edu
> >
> >
> > To:   Sanjay Goyal <sanjay_goyal@ivivity.com>
> > cc:   "Ips (E-mail)" <ips@ece.cmu.edu>
> > Subject:  Re: CmdSN during login
> >
> >
> >
> >
> > Sanjay-
> >
> > I absolutely agree with this; CmdSN is owned by the session, and
> > should not be used until the connection has fully joined the session,
> > which means full feature phase.
> >
> > This should also clean up any ambiguity on when to start
> > using CmdSN.
> >
> > --
> > Mark
> >
> > Sanjay Goyal wrote:
> > >
> > > Hi
> > >
> > >  Assuming Target and Initiator support multiple connections and the
> > session
> > > is having multiple connections. Assuming out-of-order CmdSN is a
> > possibility
> > > for this session.
> > >
> > >  Connection #   1       |       2       |       3
> > > -------------------------------------------------------
> > > Login Cmd  CmdSN=0      |   CmdSN=8     |  CmdSN=9
> > > Txt   Cmd  CmdSN=1      |               |
> > >                                 |               |
> > >                                 |               |
> > > Login Cmd  CmdSN=7      |  CmdSN=10     |  CmdSN=11
> > > -------------------------------------------------------
> > > Data Cmd   CmdSN=12     | CmdSN=14      | CmdSN=15
> > > Data Cmd   CmdSN=13     |               |
> > >                                 |               |
> > >
> > > CmdSN=7 is last of the Login sequence and it is acknowledged by the
> > Target
> > > with "accept login" response.
> > >
> > > Target would receive the PDUs in this CmdSN order
> > >  0 to 7, 8, 9, 12, 10, 11, 13, 14, 15
> > >
> > > Now as Login and Text PDUs are being processed even though you have
> > received
> > > Data Cmd PDUs, you can not pass them to iSCSI layer and hence you are
> > adding
> > > latency.
> > >
> > > What I want to convey from this example is why not use CmdSN just
> during
> > the
> > > FullFeature phase only.
> > >
> > > Regards
> > > Sanjay Goyal
> > >
> > >
> >
> --------------------------------------------------------------------------
> --------------------------
> >
> > >
> > >    Part 1.2    Type: application/ms-tnef
> > >            Encoding: base64
> >
> > --
> > Mark A. Bakke
> > Cisco Systems
> > mbakke@cisco.com
> > 763.398.1054
> >
> >
> >
> >

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054


From owner-ips@ece.cmu.edu  Tue Aug 14 13:09:06 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10548
	for <ips-archive@odin.ietf.org>; Tue, 14 Aug 2001 13:09:06 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7EGFw514544
	for ips-outgoing; Tue, 14 Aug 2001 12:15:58 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from best.eurologic.com ([193.120.246.5])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7EGFte14538
	for <ips@ece.cmu.edu>; Tue, 14 Aug 2001 12:15:55 -0400 (EDT)
Received: from wombat (wombat [192.168.7.41])
	by best.eurologic.com (8.9.3+Sun/8.9.3) with SMTP id RAA17706;
	Tue, 14 Aug 2001 17:07:59 +0100 (BST)
Message-ID: <017201c124dc$5fd84aa0$2907a8c0@wombat>
From: "Ken Sandars" <ksandars@eurologic.com>
To: <ips@ece.cmu.edu>, "Julian Satran" <Julian_Satran@il.ibm.com>
References: <OFEDEA6175.6D8F9B28-ONC2256AA8.0020B8D9@telaviv.ibm.com>
Subject: Re: CmdSN during login
Date: Tue, 14 Aug 2001 17:15:44 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Gidday,

Please read these inline comments standing on your head as they are
coming from an Australian ;-) ....


----- Original Message -----
From: "Julian Satran" <Julian_Satran@il.ibm.com>
To: <ips@ece.cmu.edu>
Sent: Tuesday, August 14, 2001 7:08 AM
Subject: RE: CmdSN during login


>
> I can see scenarios in which you would want the login request  be
regular -
> as when you issue it after
> a task management clear LU or reset command and want to make sure that it
> executed after the clear and the CmdSN clearly indicates that.  However
> even this effect can be achieved by other means

Yes - like waiting for the Task Management response before issuing the
login.

>and the discussion is
> rather academic - should we mandate the I bit in the login phase (MUST) or

Yes. Consider this as a guide. "Until a connection has reached Full Feature
Phase, it is not a member of the session it is either trying to create or
join." As such, there seems no point in regulating the flow of Login Phase
commands with respect to the session context.

> just say that it should be used whenever adequate and explain why (which I
> prefer) as it won't be required in all cases (e.g., it is not necessary in
> a session establishing login).
>

By all means, but ONLY if those circumstances can be spelled out in black
and white. Leaving things open to interpretation leads to inconsistent
handling
between implementations. I haven't seen any scenarios yet, and until one is
presented, please rule it out.


Thanks,

Ken Sandars
ksandars@eurologic.com
Eurologic Systems
+44 117 930 9616


> Julo
>
> "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <matthew_burbridge@hp.com>
> @ece.cmu.edu on 13-08-2001 19:34:56
>
> Please respond to "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)"
>       <matthew_burbridge@hp.com>
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   ips@ece.cmu.edu
> cc:
> Subject:  RE: CmdSN during login
>
>
>
> Could commands sent during the login phase (ie LOGIN + TEXT) be mandatory
> to
> be immediate and therefore MUST have the I bit set or is there a reason
why
> non-immediate login phase commands make sense?
>
> Cheers
>
> Matthew Burbridge
>
> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Saturday, August 11, 2001 4:37 PM
> To: ips@ece.cmu.edu
> Subject: Re: CmdSN during login
>
>
> There was ambiguity at first login that we have cleared in text and as I
> said I don't see any good reason
> for another case of immediate when we have the immediate bit available.
> What we could do is add anothe pragraph to 8
> recommending when to use the I bit in login.
>
> Julo
>
> "Eddy Quicksall" <ESQuicksall@hotmail.com> on 10-08-2001 18:13:32
>
> Please respond to "Eddy Quicksall" <ESQuicksall@hotmail.com>
>
> To:   Julian Satran/Haifa/IBM@IBMIL
> cc:   <ips@ece.cmu.edu>
> Subject:  Re: CmdSN during login
>
>
>
> But, what if someone does this without setting the Immediate bit? What
> would
> one do?
>
> What is wrong with just making the CmdSN not run during login? It seems
> like
> it was an arbitrary choice in the first place since it was originally
> optional and not using it actually worked.
>
> If CmdSN is stated as only used in FFP, then I don't see any ambiguity.
>
> Eddy
> ----- Original Message -----
> From: "Julian Satran" <Julian_Satran@il.ibm.com>
> To: <ips@ece.cmu.edu>
> Sent: Friday, August 10, 2001 2:43 AM
> Subject: Re: CmdSN during login
>
>
> >
> > Sanjay,
> >
> > If you want to ignore CmdSN and expedite Login processing you can do so
> by
> > having the commands being issued as immediate.
> > This will help us keep away from creating ambiguity about (or another
> > conditional) for when CmdSN is to be used or not.
> >
> > Julo
> >
> > Mark Bakke <mbakke@cisco.com>@ece.cmu.edu on 09-08-2001 23:55:25
> >
> > Please respond to Mark Bakke <mbakke@cisco.com>
> >
> > Sent by:  owner-ips@ece.cmu.edu
> >
> >
> > To:   Sanjay Goyal <sanjay_goyal@ivivity.com>
> > cc:   "Ips (E-mail)" <ips@ece.cmu.edu>
> > Subject:  Re: CmdSN during login
> >
> >
> >
> >
> > Sanjay-
> >
> > I absolutely agree with this; CmdSN is owned by the session, and
> > should not be used until the connection has fully joined the session,
> > which means full feature phase.
> >
> > This should also clean up any ambiguity on when to start
> > using CmdSN.
> >
> > --
> > Mark
> >
> > Sanjay Goyal wrote:
> > >
> > > Hi
> > >
> > >  Assuming Target and Initiator support multiple connections and the
> > session
> > > is having multiple connections. Assuming out-of-order CmdSN is a
> > possibility
> > > for this session.
> > >
> > >  Connection #   1       |       2       |       3
> > > -------------------------------------------------------
> > > Login Cmd  CmdSN=0      |   CmdSN=8     |  CmdSN=9
> > > Txt   Cmd  CmdSN=1      |               |
> > >                                 |               |
> > >                                 |               |
> > > Login Cmd  CmdSN=7      |  CmdSN=10     |  CmdSN=11
> > > -------------------------------------------------------
> > > Data Cmd   CmdSN=12     | CmdSN=14      | CmdSN=15
> > > Data Cmd   CmdSN=13     |               |
> > >                                 |               |
> > >
> > > CmdSN=7 is last of the Login sequence and it is acknowledged by the
> > Target
> > > with "accept login" response.
> > >
> > > Target would receive the PDUs in this CmdSN order
> > >  0 to 7, 8, 9, 12, 10, 11, 13, 14, 15
> > >
> > > Now as Login and Text PDUs are being processed even though you have
> > received
> > > Data Cmd PDUs, you can not pass them to iSCSI layer and hence you are
> > adding
> > > latency.
> > >
> > > What I want to convey from this example is why not use CmdSN just
> during
> > the
> > > FullFeature phase only.
> > >
> > > Regards
> > > Sanjay Goyal
> > >
> > >
> >
> --------------------------------------------------------------------------
> --------------------------
> >
> > >
> > >    Part 1.2    Type: application/ms-tnef
> > >            Encoding: base64
> >
> > --
> > Mark A. Bakke
> > Cisco Systems
> > mbakke@cisco.com
> > 763.398.1054
> >
> >
> >
> >
>
>
>
>
>
>



From owner-ips@ece.cmu.edu  Tue Aug 14 13:14:48 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10670
	for <ips-archive@odin.ietf.org>; Tue, 14 Aug 2001 13:14:48 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7EFiSQ12896
	for ips-outgoing; Tue, 14 Aug 2001 11:44:28 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7EFiQe12892
	for <ips@ece.cmu.edu>; Tue, 14 Aug 2001 11:44:27 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id RAA18528
	for <ips@ece.cmu.edu>; Tue, 14 Aug 2001 17:44:19 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7EFiEg201238
	for <ips@ece.cmu.edu>; Tue, 14 Aug 2001 17:44:19 +0200
Importance: Normal
Subject: Re: iSCSI: Target Transfer Tag
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF6DDF4972.9C6244A3-ONC2256AA8.00565F4D@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Tue, 14 Aug 2001 18:43:52 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 14/08/2001 18:44:19
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Yes - the reserved value.  Julo

Sukha Ghosh <sukha_ghosh@ivivity.com>@ece.cmu.edu on 11-08-2001 21:00:01

Please respond to Sukha Ghosh <sukha_ghosh@ivivity.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  iSCSI: Target Transfer Tag



Hi,

As I understood reading the specs, the Target Transfer Tag is supplied by
Target through R2T packets in the case of write command from Initiator (W
bit set) for solicited data transfer. In the case of unsolicited data
packets from Initiator through SCSI Data-Out, what should be the value of
Target Transfer Tag field in the SCSI Data-Out header? Would it be the
reserved value of 0xffffffff ?





From owner-ips@ece.cmu.edu  Tue Aug 14 14:44:15 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12748
	for <ips-archive@odin.ietf.org>; Tue, 14 Aug 2001 14:44:15 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7EHObI19089
	for ips-outgoing; Tue, 14 Aug 2001 13:24:37 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from chi6-1.relay.mail.uu.net (chi6-1.relay.mail.uu.net [199.171.54.98])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7EHOae19085
	for <ips@ece.cmu.edu>; Tue, 14 Aug 2001 13:24:36 -0400 (EDT)
Received: from dccmail2.dcc.com by chi6sosrv11.alter.net with ESMTP 
	(peer crosschecked as: [208.207.95.30])
	id QQlcbl06804
	for <ips@ece.cmu.edu>; Tue, 14 Aug 2001 17:24:35 GMT
Received: by dccmail2.dcc.com with Internet Mail Service (5.5.2653.19)
	id <QSWRDVX1>; Tue, 14 Aug 2001 13:25:55 -0400
Message-ID: <0FB6FCA766AFD411BF0100500499B6FB01F40243@dccmail2.dcc.com>
From: Nicholas Dambrosio <NDambrosio@lifecare.com>
To: "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
Subject: please remove me from this list
Date: Tue, 14 Aug 2001 13:25:54 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Please remove


The information in this electronic mail message is confidential and may be
legally privileged. It is intended solely for the addressee. Access to this
Internet electronic mail message by anyone else is unauthorized. If you are
not the intended recipient, any disclosure, copying, distribution or any
action taken in reliance on it is prohibited and may be unlawful.


From owner-ips@ece.cmu.edu  Tue Aug 14 14:54:26 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12920
	for <ips-archive@odin.ietf.org>; Tue, 14 Aug 2001 14:54:26 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7EHMYr18958
	for ips-outgoing; Tue, 14 Aug 2001 13:22:34 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from atlrel6.hp.com (atlrel6.hp.com [192.151.27.8])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7EHMVe18945
	for <ips@ece.cmu.edu>; Tue, 14 Aug 2001 13:22:31 -0400 (EDT)
Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100])
	by atlrel6.hp.com (Postfix) with ESMTP
	id F366B1F8FB; Tue, 14 Aug 2001 13:22:21 -0400 (EDT)
Received: (from cbm@localhost) by core.rose.hp.com (8.8.6 (PHNE_14041)/8.8.6 SMKit7.02) id KAA09333; Tue, 14 Aug 2001 10:23:37 -0700 (PDT)
Message-Id: <200108141723.KAA09333@core.rose.hp.com>
Subject: Re: iSCSI-07: recovery
To: sandeepj@research.bell-labs.com
Date: Tue, 14 Aug 2001 10:23:37 PDT
Cc: ips@ece.cmu.edu
In-Reply-To: <200107271533.LAA04588@aura.research.bell-labs.com>; from "Sandeep Joshi" at Jul 27, 101 9:06 am
Reply-To: cbm@rose.hp.com
From: "Mallikarjun C." <cbm@rose.hp.com>
X-Mailer: Elm [revision: 212.4]
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Sandeep,

Thank you for the detailed review, and apologies for the
delay in responding, I was travelling to London and elsewhere.

>Comments/questions on new Appendix F and related Section 7.x
>These are arranged sequentially down the appendix.
>
>-Sandeep
>
>1) Page 173: What is the usage of nextCmdSN in the Connection 
>   structure ?
>
>   If it is being used to check gaps, something like this 
>   seems more appropriate to the Session and not Connection.

You are right, it is incorrectly placed in Connection.  I will
move this to the Session datastructure.

>
>2) Page 174: Within-command recovery
>   Initiator algo for Recover-Data-If-Possible
>
>   The step of sending an abort here could be skipped if 
>   the initiator knew that task has already completed at the 
>   target.   This avoids an extra task cmd & response 
>   (Function-complete)
>
>   The initiator knows the task has completed if this routine 
>   is invoked on an expDataSN mismatch in a SCSI Response 
>   (middle of page 175)

I see that you are suggesting an optimization.  These algorithms 
are not really tuned to be optimal - they strive to convey the 
recovery semantics in the simplest manner.

Anyway, I will add an additional check to convey the point you
make.

>
>3) Top of Page 175: Within-command recovery 
>   Initiator algo for Receive-a-In-PDU
>
>   When SoFarInOrder is False, and current DataSN is expected 
>   (its the next) then the action seems to be "discard; return".
>   Is this correct ?  So when does one *accept* the next 
>   DataSN (say 9) in the presence of outstanding missing data 
>   PDUs (say 4-6)

If there were outstanding missing data PDUs 4-6, the TCB.ExpectedDataSN
would stay stuck at 4 per the algorithm.  So, a subsequent DataSN=9
would result in send-data-SNACK being TRUE, and it may generate a
new Data SNACK on the wire (if deemed appropriate in the procedure 
Build-And-Send-DSnack - which is not described).

>
>4) Page 175-176: Within-command recovery 
>   Initiator algo for Receive-a-In-PDU
>
>   The psuedo-code under "Connection.SoFarInOrder is TRUE"
>   could be moved to Within-Connection recovery since the logic 
>   applies to all other PDUs (not just SCSI response) sent from 
>   target bearing statSNs.

This is something I debated myself while putting this together -
you are right, the code is fairly generic.  The only reason I finally
put this under Within-command is to have all SCSI response handling
in one place.  Let me split this into a separate procedure callable
from both Within-command and Within-connection algorithms.

>
>5) Page 177 : Within-command recovery
>   Target algo for Receive-a-In-PDU
>  
>   Please confirm, can the target use R2T for digest errors on 
>   unsolicited bursts ?   If yes, can we add an explicit statement 
>   to this effect.  Neither Section 7.4.(a) nor this section 
>   seem to imply otherwise but just want to confirm.

Yes, I certainly think so (of course if DataSequenceOrder was negotiated 
as "no").  Unsolicited bursts are technically a lot similar to solicited
in target handling - the only difference being that the TargetTransferTag
is spec-defined as 0xffffffff.  This is the running assumption in the
pseudo-code.

I will add a statement to this effect to section 7.4, if Julian agrees :-)

>
>6) Page 177 : Within-command recovery
>   Target algo for Receive-a-In-PDU
>
>   Bottom of the case for "if (CurrentPDU.type=DATA)"
>   we have "if (TCB.activeR2Ts=0) Build-and-send-Status()"
>
>   This needs an extra predicate as follows..
>     "If TCB.Response=DeliveryFailure && TCB.ActiveR2Ts=0"
>
>   This is correct in Transfer-Context-Timeout-Handler.

The code is for the case of successful reception of all data PDUs, so
it doesn't really need the extra predicate you suggest.  The case in
Transfer-Context-Timeout-Handler is different where the target is 
declaring a DeliveryFailure since it never received the last data PDU
for the transfer context in question.  

However, I did realize now in reviewing the code that it doesn't 
contain the subsequent changes to the spec - the "Not enough unsolicited
data" case - I will add what's missing now.

>
>7) Page 179 : Within-connection recovery
>   Initiator algo for Recover-Status-If-Possible
>
>   Typo error..  "note the missing statSNs in TCB"
>   should be     "note the missing statSNs in Connection"
>
>   statSN list is per-connection state.

You are right, I will fix it.

>
>8) Page 180: Within-Connection recovery
>   Initiator algo for Command-Acknowledge-Timeout-Handler
>   
>   This function seems like a better fit for the previous 
>   section on "within-command-recovery" and could be moved 
>   over there.

This functionality is actually part of the definition of Within-connection 
recovery, 7.11.2.

>
>9) Page 184 : Within-Session recovery
>   Target algo for Receive-A-In-PDU
>
>   It does not cover the case of receiving a login-restart 
>   (implicit logout).  This would have the same action as 
>   "logout.reason=recoveryRemove" 

The implicit logout may mean either recovery/close of the connection
based on the negotiated recovery capabilities (CommandFailoverSupport
= yes/no).  It is not clearly called out in the current spec.  Please
wait for my write-up on London error recovery proposals in the next
two days, which I hope would make it much more straightforward to grasp
this.

Thanks again.
--
Mallikarjun 


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


From owner-ips@ece.cmu.edu  Tue Aug 14 17:14:15 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15304
	for <ips-archive@odin.ietf.org>; Tue, 14 Aug 2001 17:14:15 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7EJtVs27169
	for ips-outgoing; Tue, 14 Aug 2001 15:55:31 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7EJtQe27159
	for <ips@ece.cmu.edu>; Tue, 14 Aug 2001 15:55:30 -0400 (EDT)
Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191])
	by atlrel1.hp.com (Postfix) with ESMTP
	id 2C40135D; Tue, 14 Aug 2001 15:55:22 -0400 (EDT)
Received: from xatlbh3.atl.hp.com (xatlbh3.atl.hp.com [15.45.89.188])
	by xatlrelay2.atl.hp.com (Postfix) with ESMTP
	id 094FF1F559; Tue, 14 Aug 2001 15:55:22 -0400 (EDT)
Received: by xatlbh3.atl.hp.com with Internet Mail Service (5.5.2653.19)
	id <Q6RXD7QR>; Tue, 14 Aug 2001 15:55:21 -0400
Message-ID: <499DC368E25AD411B3F100902740AD65BC5BEF@xrose03.rose.hp.com>
From: "WENDT,JIM (HP-Roseville,ex1)" <jim_wendt@hp.com>
To: "'Mark Bakke'" <mbakke@cisco.com>,
        "WENDT,JIM (HP-Roseville,ex1)" <jim_wendt@hp.com>
Cc: "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>,
        "'Jeff Chase (E-mail)'" <chase@cs.duke.edu>,
        "HAAGENS,RANDY (HP-Roseville,ex1)" <randy_haagens@hp.com>,
        "'sandeepj@research.bell-labs.com'" <sandeepj@research.bell-labs.com>
Subject: RE: F2F Mtg Summary for Framing and Error Recovery
Date: Tue, 14 Aug 2001 15:51:22 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

All of the F2F meeting slides are now on Julian's web site, including the
following two slides sets used for discussion purposes:

http://www.haifa.il.ibm.com/satran/ips/PaloAlto-MattWakeley-framing.pdf

http://www.haifa.il.ibm.com/satran/ips/PaloAlto-JimWendt-framing.pdf

Jim

> -----Original Message-----
> From: Mark Bakke [mailto:mbakke@cisco.com]
> Sent: Wednesday, July 18, 2001 12:26 PM
> To: WENDT,JIM (HP-Roseville,ex1)
> Cc: 'ips@ece.cmu.edu'; 'Jeff Chase (E-mail)'; HAAGENS,RANDY
> (HP-Roseville,ex1)
> Subject: Re: F2F Mtg Summary for Framing and Error Recovery
> 
> 
> Jim-
> 
> The error recovery slides and spreadsheet are now available
> on Julian's web site at:
> 
> http://www.haifa.il.ibm.com/satran/ips/PaloAlto-MarkBakke-crc-
> recovery.pdf
> 
> http://www.haifa.il.ibm.com/satran/ips/PaloAlto-MarkBakke-iSCS
> I-errors.xls
> 
> They make a lot of assumptions; please enjoy them responsibly.
> 
> --
> Mark
> 


From owner-ips@ece.cmu.edu  Tue Aug 14 17:14:25 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15316
	for <ips-archive@odin.ietf.org>; Tue, 14 Aug 2001 17:14:25 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7EJJ0725258
	for ips-outgoing; Tue, 14 Aug 2001 15:19:00 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from atlrel7.hp.com (atlrel7.hp.com [192.151.27.9])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7EJIse25248
	for <ips@ece.cmu.edu>; Tue, 14 Aug 2001 15:18:59 -0400 (EDT)
Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100])
	by atlrel7.hp.com (Postfix) with ESMTP id 2AEAB1F851
	for <ips@ece.cmu.edu>; Tue, 14 Aug 2001 15:17:41 -0400 (EDT)
Received: from rose.hp.com (dhcp-rosefl-bba163.rose.hp.com [15.3.110.163]) by core.rose.hp.com with ESMTP (8.8.6 (PHNE_14041)/8.8.6 SMKit7.02) id MAA00505 for <ips@ece.cmu.edu>; Tue, 14 Aug 2001 12:20:03 -0700 (PDT)
Message-ID: <3B797AAA.5250DFE5@rose.hp.com>
Date: Tue, 14 Aug 2001 12:23:22 -0700
From: "Mallikarjun C." <cbm@rose.hp.com>
Reply-To: cbm@rose.hp.com
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: ips@ece.cmu.edu
Subject: iSCSI: rev07 - ISID-TSID & naming comments
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Julian,

Some comments in this area.

- Section 2.10.6, last sentence in para 1 states "An initiator is
uniquely
  identified by the value pair (InitiatorName, ISID).".  Suggest s/b
"initiator"
  with "initiator SCSI port".

- Section 2.11.4, first sentence.  "The TSID is an initiator identifying
tag 
  set by the target." s/b with "The TSID is a target-defined tag
assigned to 
  an initiator SCSI port.".

- Section 1.5, para 1, "Network portals (IP names, addresses and TCP
ports)"
  Suggest dropping "IP names" since what really matters is just the IP
addresses
  and TCP ports.  IIRC, two DNS names can resolve to the same IP
address, and one 
  DNS name can resolve to multiple IP addresses.

- The section in general is not consistent in the usage of iSCSI Name. 
It uses 
  "iSCSI name" "iSCSI Node name", and "iSCSI Name".  I would suggest
using 
  a consistent phrase wherever iSCSI-defined Names are used, like
"iSCSI-Name".  
  Simlar comments  apply for "Network Portal".

- Section 1.5.1, description for "Network Entity" has "This device or
gateway 
  may support one or more iSCSI Node" s/b with "This device or gateway
may
  support one or more iSCSI Nodes and one or more Network Portals". 
Similarly
  for "The iSCSI Node is accessed via a network portal", s/b with "The
iSCSI 
  Node is accessed via one or more network portals".

- Section 1.5.1, description for "iSCSI Node".  The reasoning offered
for the
  definition for iSCSI-Names is not quite right.  Suggested sentence
"iSCSI-Names
  are required because multiple iSCSI Nodes may be present behind a
given 
  combination of IP address and TCP port.".

- Section 1.5.1, second para under "iSCSI Node" discussion, first
sentence.  This
  states that names are not required for default node access.  Is this
still true?  I 
  thought we are  mandating InitiatorName and TargetName text key
exchange now.

- Section 1.5.1, description for "Network Portal".  Suggest rewording
the very first 
  sentence to include the  last sentence.  The current first sentence 
appears very
  vague ("port" - TCP/SCSI/ethernet?).  Also the last sentence defines a
network 
  portal for a target to comprise the "listening TCP port", should we
identify what
  it is for an initiator?  

- The picture shown at the beginning of section 1.5 does not show TCP
port
  being part of the Network Portal on the initiator side.  Is it then
implied that 
  only the IP address constitues a Network Portal for an initiator iSCSI
Node?
   
- Section 1.5.2, last para.  This defines the I-T nexus as the session
for iSCSI.
  This doesn't suggest a nexus identifier - is it the four tuple
<InitiatorName, 
  ISID, TargetName, portal group tag> or the SSID <ISID, TSID>?  Or is
it both 
  - the four-tuple being nexus id at the SCSI layer, and the latter at
the iSCSI
  layer?

- Section 1.5.3, second para with the ISID RULE, last sentence.  Suggest
"...nor 
  does it preclude other sessions with different ...." s/b with "...nor
does it
  preclude multiple sessions with different....".

- Section 1.5.3, third para.  This mentions the term "parallel nexus". 
I assume 
  the equivalence of two 4-tuples is what is being implied here.  Unless
this term 
  is already defined in some latest SCSI documents, I suggest defining
this as 
  such.

- Section 1.5.2 does not comment on if iSCSI mandates the support of
SCSI Port names
  for iSCSI initiators (the requirement appears only the iSCSI targets
para).  
  I assume it is mandatory. 

- The following initiator requirement:
"The iSCSI Name should be configurable parameter of each initiator
portal group."
   would be more clear if stated as (if this is a correct
interpretation):
"All the initiator portal groups of one iSCSI Node MUST share the same 
 iSCSI-Node name."

   Similar comments apply for the target requirement.
- The following initiator requirement:
"The ISID name space of the iSCSI Initiator should be partitioned among
the initiator
 portal groups."
   would be better stated as (if this is a correct interpretation):
"All initiator portal groups of one iSCSI Node MUST share an ISID name
space 
 for sessions established to one iSCSI target node.  Sessions
established to 
 multiple iSCSI target nodes MAY share one ISID name space."

- The following target requirement:
"The TSID name space of the iSCSI Target should be partitioned among the
target 
portal groups."
   would be better stated as (if this is a correct interpretation):
"All target portal groups of one iSCSI Node MUST share an TSID name
space for 
sessions established to one iSCSI initiator node.  Sessions established
to 
multiple iSCSI initiator nodes MAY share one TSID name space."

-- 
Mallikarjun 

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


From owner-ips@ece.cmu.edu  Tue Aug 14 17:57:07 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15860
	for <ips-archive@odin.ietf.org>; Tue, 14 Aug 2001 17:57:07 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7EL0wu00626
	for ips-outgoing; Tue, 14 Aug 2001 17:00:58 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7EL0ve00621
	for <ips@ece.cmu.edu>; Tue, 14 Aug 2001 17:00:57 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id QAA54342;
	Tue, 14 Aug 2001 16:58:47 -0400
Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7EL0p4250962;
	Tue, 14 Aug 2001 15:00:51 -0600
Importance: Normal
Subject: Re: iSCSI: rev07 - ISID-TSID & naming comments
To: cbm@rose.hp.com
Cc: ips@ece.cmu.edu
From: "Jim Hafner" <hafner@almaden.ibm.com>
Date: Tue, 14 Aug 2001 14:00:49 -0700
Message-ID: <OFE898EBF6.4A66052D-ON88256AA8.006FEB64@boulder.ibm.com>
X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at
 08/14/2001 02:00:51 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Mallikarjun,

Some comments in-line.  In general, however, most of your comments are
right on.  This part of the draft is essentially and rev0.0.0.1 :-{) and
needs cleanup (and as the contributing author, I thought I should respond).
Thanks for reading this so carefully.

I'm planning on collecting a lot of these comments (I have others from
other people), and running a rev of the text sometime soon.

Thanks again,
Jim Hafner


"Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on 08/14/2001 12:23:22 pm

Please respond to cbm@rose.hp.com

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  iSCSI: rev07 - ISID-TSID & naming comments



Julian,

Some comments in this area.

- Section 2.10.6, last sentence in para 1 states "An initiator is
uniquely
  identified by the value pair (InitiatorName, ISID).".  Suggest s/b
"initiator"
  with "initiator SCSI port".
<JLH>
Yes.  In fact, there are (were?) inconsistent use of the term 'initiator'
throughout the document.  Hopefully, that can get cleared up.
</JLH>

- Section 2.11.4, first sentence.  "The TSID is an initiator identifying
tag
  set by the target." s/b with "The TSID is a target-defined tag
assigned to
  an initiator SCSI port.".
<JLH>
This is actually an incorrect interpretation.  In the model we (I) am
proposing, the TSID has nothing to do with identifying either the target or
initiator SCSI port.  It is a tag used by the target (iSCSI target) to help
identify a session *along with the ISID* of that session.  In the model,
the TSID plays no role in the SCSI layer.

This sentence needs clarification.
</JLH>

- Section 1.5, para 1, "Network portals (IP names, addresses and TCP
ports)"
  Suggest dropping "IP names" since what really matters is just the IP
addresses
  and TCP ports.  IIRC, two DNS names can resolve to the same IP
address, and one
  DNS name can resolve to multiple IP addresses.
<JLH>
But IPnames (because of DNS) can be perfectly good identifiers for Network
portals.  The network portal can be virtual (shared across many nics that
have different IP addresses) or physical (used by a single nic that has a
unique address).  It all depends on the mapping.  The point here (and it
isn't that critical a point) is that I can initiate a connection to a
network portal (say in software) by openning a socket to a given
"IPnamed:tcpport" combination and let the lower layers deal with address
resolution.

On the other hand, I have no real problem with your suggestion, if you
think it simplifies things.
</JLH>

- The section in general is not consistent in the usage of iSCSI Name.
It uses
  "iSCSI name" "iSCSI Node name", and "iSCSI Name".  I would suggest
using
  a consistent phrase wherever iSCSI-defined Names are used, like
"iSCSI-Name".
  Simlar comments  apply for "Network Portal".
<JLH>
Agreed.
</JLH>

- Section 1.5.1, description for "Network Entity" has "This device or
gateway
  may support one or more iSCSI Node" s/b with "This device or gateway
may
  support one or more iSCSI Nodes and one or more Network Portals".
Similarly
  for "The iSCSI Node is accessed via a network portal", s/b with "The
iSCSI
  Node is accessed via one or more network portals".
<JLH>
Sounds OK to me.
</JLH>

- Section 1.5.1, description for "iSCSI Node".  The reasoning offered
for the
  definition for iSCSI-Names is not quite right.  Suggested sentence
"iSCSI-Names
  are required because multiple iSCSI Nodes may be present behind a
given
  combination of IP address and TCP port.".
<JLH>
OK too.
</JLH>

- Section 1.5.1, second para under "iSCSI Node" discussion, first
sentence.  This
  states that names are not required for default node access.  Is this
still true?  I
  thought we are  mandating InitiatorName and TargetName text key
exchange now.
<JLH>
I think this will have to be massaged in the direction you're going.
There's been some flux about this requirement.  At the moment, the
requirement (I think) is that for full function login names are required.
For a Discovery session, names are not.  When that gets finalized, this
wording can be adjusted as well.
</JLH>

- Section 1.5.1, description for "Network Portal".  Suggest rewording
the very first
  sentence to include the  last sentence.  The current first sentence
appears very
  vague ("port" - TCP/SCSI/ethernet?).  Also the last sentence defines a
network
  portal for a target to comprise the "listening TCP port", should we
identify what
  it is for an initiator?
<JLH>
The initiator doesn't have the listening TCP port in it's network portal
definition because the initiator doesn't listen. Once a session
(connection) is created the listening port on the target side is out of the
picture and the connection goes to other ports that bind to the connection.
So, there is a definite asymmetry here between a target network portal and
an initiator network portal.
</JLH>

- The picture shown at the beginning of section 1.5 does not show TCP
port
  being part of the Network Portal on the initiator side.  Is it then
implied that
  only the IP address constitues a Network Portal for an initiator iSCSI
Node?
<JLH>
See the previous comment.
</JLH>

- Section 1.5.2, last para.  This defines the I-T nexus as the session
for iSCSI.
  This doesn't suggest a nexus identifier - is it the four tuple
<InitiatorName,
  ISID, TargetName, portal group tag> or the SSID <ISID, TSID>?  Or is
it both
  - the four-tuple being nexus id at the SCSI layer, and the latter at
the iSCSI
  layer?
<JLH>
There really is no strong need to define a nexus identifier as it never
really surfaces anywhere in the protocol.  There are two choices for the
identifier, one is the 4-tuple you suggest (the one with target portal
group tag), the other is the two names together with the session ID.  The
first builds a nexus identifier from the identifiers of the two SCSI ports
involved.  The other builds the nexus identifier from protocol layer things
(TSID, in particular which does not identify a SCSI port).   The importance
of the nexus identifier is really an internal implementation issue.  We can
call it either one.  For the moment, I'd lean towards the first option, but
SAM-3 (the future) may think that the second is a better choice.
</JLH>

- Section 1.5.3, second para with the ISID RULE, last sentence.  Suggest
"...nor
  does it preclude other sessions with different ...." s/b with "...nor
does it
  preclude multiple sessions with different....".
<JLH>
Fine
</JLH>

- Section 1.5.3, third para.  This mentions the term "parallel nexus".
I assume
  the equivalence of two 4-tuples is what is being implied here.  Unless
this term
  is already defined in some latest SCSI documents, I suggest defining
this as
  such.
<JLH>
It's not defined in any SCSI documents because it's never been physically
possible before!  A definition in my mind would be "two nexus are parallel
if they are independent relationships between the same two SCSI ports" (or
something like this).
</JLH>

- Section 1.5.2 does not comment on if iSCSI mandates the support of
SCSI Port names
  for iSCSI initiators (the requirement appears only the iSCSI targets
para).
  I assume it is mandatory.
<JLH>
I'm not sure what you're asking for here.  Perhaps this is just a misplaces
sentence.  SAM-2 now has the notion defined of SCSI port names and the
protocol can define what they are and if they are mandatory.  I'm sort of
assumed that by defining what they are (for the initiator as iSCSI
Name+ISID and for the target as iSCSI Name+Portal group tag) that they are
implied to be mandatory.

Did I miss something?
</JLH>

- The following initiator requirement:
"The iSCSI Name should be configurable parameter of each initiator
portal group."
   would be more clear if stated as (if this is a correct
interpretation):
"All the initiator portal groups of one iSCSI Node MUST share the same
 iSCSI-Node name."
<JLH>
Yeah, that's pretty much a requirement, in that if the names are different,
then the portal groups are not in the same iSCSI node.  What this sentence
(and the related sentences) are aiming for is less of a requirement (this
is a more recent understanding that hasn't made it into text yet) than a
prefered common API for people building hardware.  If my host has multiple
iSCSI hardware cards, in order that they coordinate the same iSCSI node
concept, then they should get their iSCSI name from outside -- i.e., be
configurable.  This is not a hard requirement because each could act on its
own as separate iSCSI node.  Unfortunately, that management/configuration
nightmare in FC is what this sentence is hoping to preclude.  We need to
find the right words to back away from this as a hard requirement and more
as request to implementors that this be available.

The same logic applies to the ISID and TSID partitioning, though in a
somewhat different way.  There are two assumptions that are at the root of
this rule: (a) no parallel nexus and (b) the session identifier for a
session is unique between two given iSCSI nodes.  The partitioning rules
(if implemented by the hw cards as an API) enable the least amount of
coordination required among different hw components.  For example, to
enforce (b), the target portal groups don't need to share the set of SIDs
that are active. They each own a portion of the name space and can use that
as they wish, regardless of what's happening on the other portal groups.
For (a), if the ISID name space is partitioned, then no two initiator
portal groups would ever attempt a login with the same target portal group
reusing the same ISID (so fewer rejected login's because the target portal
group is enforcing the ISID rule).

In short, (and I'm the first to admit this), we need very different
language to convey this idea.  It's more a "request to implementors" to
make life easy for everybody (easier management, easier target
implementations, fewer rejected logins, etc.) than it is a hard
requirement.  The two assumptions above and the resulting ISID RULE are
requirements.  The others are facilitators to that end.
</JLH>

   Similar comments apply for the target requirement.
- The following initiator requirement:
"The ISID name space of the iSCSI Initiator should be partitioned among
the initiator
 portal groups."
   would be better stated as (if this is a correct interpretation):
"All initiator portal groups of one iSCSI Node MUST share an ISID name
space
 for sessions established to one iSCSI target node.  Sessions
established to
 multiple iSCSI target nodes MAY share one ISID name space."
<JLH>
As I've indicated above, this is only part of the equation.  The ISID name
space is already scoped by the iSCSI Name.   The issue is facilitating
enforcement of the ISID rule and minimal cross hw implementations.
</JLH>



- The following target requirement:
"The TSID name space of the iSCSI Target should be partitioned among the
target
portal groups."
   would be better stated as (if this is a correct interpretation):
"All target portal groups of one iSCSI Node MUST share an TSID name
space for
sessions established to one iSCSI initiator node.  Sessions established
to
multiple iSCSI initiator nodes MAY share one TSID name space."
<JLH>
See previous two comments.
</JLH>

--
Mallikarjun

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





From owner-ips@ece.cmu.edu  Tue Aug 14 19:33:03 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17214
	for <ips-archive@odin.ietf.org>; Tue, 14 Aug 2001 19:33:03 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7EMYLh05252
	for ips-outgoing; Tue, 14 Aug 2001 18:34:21 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7EMYKe05245
	for <ips@ece.cmu.edu>; Tue, 14 Aug 2001 18:34:20 -0400 (EDT)
Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100])
	by atlrel1.hp.com (Postfix) with ESMTP
	id ACD876C3; Tue, 14 Aug 2001 18:34:18 -0400 (EDT)
Received: from rose.hp.com (dhcp-rosefl-bba163.rose.hp.com [15.3.110.163]) by core.rose.hp.com with ESMTP (8.8.6 (PHNE_14041)/8.8.6 SMKit7.02) id PAA00874; Tue, 14 Aug 2001 15:35:33 -0700 (PDT)
Message-ID: <3B79A87D.ADE085E7@rose.hp.com>
Date: Tue, 14 Aug 2001 15:38:53 -0700
From: "Mallikarjun C." <cbm@rose.hp.com>
Reply-To: cbm@rose.hp.com
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Jim Hafner <hafner@almaden.ibm.com>
Cc: ips@ece.cmu.edu
Subject: Re: iSCSI: rev07 - ISID-TSID & naming comments
References: <OFE898EBF6.4A66052D-ON88256AA8.006FEB64@boulder.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Jim,

Thanks for the quick response.  I agree with most of your responses.
However, some comments below on your responses.

Regards.
-- 
Mallikarjun 

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

Jim Hafner wrote:
> 
.....

> - Section 2.11.4, first sentence.  "The TSID is an initiator identifying
> tag
>   set by the target." s/b with "The TSID is a target-defined tag
> assigned to
>   an initiator SCSI port.".
> <JLH>
> This is actually an incorrect interpretation.  In the model we (I) am
> proposing, the TSID has nothing to do with identifying either the target or
> initiator SCSI port.  It is a tag used by the target (iSCSI target) to help
> identify a session *along with the ISID* of that session.  In the model,
> the TSID plays no role in the SCSI layer.

I agree with what you state, but I don't quite see why the suggested
sentence
violates this philosophy.  If you substitute "<InitiatorName+ISID>" for
the
phrase "initiator SCSI port" (since they are the same) in my suggested
sentence, 
that's essentially what you state above...  Did I miss something?

> 
> This sentence needs clarification.
> </JLH>
> 
> - Section 1.5, para 1, "Network portals (IP names, addresses and TCP
> ports)"
>   Suggest dropping "IP names" since what really matters is just the IP
> addresses
>   and TCP ports.  IIRC, two DNS names can resolve to the same IP
> address, and one
>   DNS name can resolve to multiple IP addresses.
> <JLH>
> But IPnames (because of DNS) can be perfectly good identifiers for Network
> portals.  The network portal can be virtual (shared across many nics that
> have different IP addresses) or physical (used by a single nic that has a
> unique address).  It all depends on the mapping.  The point here (and it
> isn't that critical a point) is that I can initiate a connection to a
> network portal (say in software) by openning a socket to a given
> "IPnamed:tcpport" combination and let the lower layers deal with address
> resolution.
> 
> On the other hand, I have no real problem with your suggestion, if you
> think it simplifies things.

Okay, I see your point.  I don't have a strong opinion on this.  It just
appears to me that it's simply easier to visualize a network portal with
an
IP address, than with a higher abstraction (DNS name) possibly resolving
into multiple IP addresses.

Your description however, of a virtual network portal spanning multiple
NICs
doesn't come across in the current Network Portal definition, nor do I
see the
need for such a construct.  It appears to me that you could instead call
such
a virtual portal as a portal group, decomposable into a bunch of portals
each
associated with one <IPaddress+TCP port> - since the notion of a poral
group and
its identifier (tag) is already defined in iSCSI.

> </JLH>
> 
....

> 
> - Section 1.5.1, second para under "iSCSI Node" discussion, first
> sentence.  This
>   states that names are not required for default node access.  Is this
> still true?  I
>   thought we are  mandating InitiatorName and TargetName text key
> exchange now.
> <JLH>
> I think this will have to be massaged in the direction you're going.
> There's been some flux about this requirement.  At the moment, the
> requirement (I think) is that for full function login names are required.
> For a Discovery session, names are not.  When that gets finalized, this
> wording can be adjusted as well.

OK, I didn't realize that it's still under debate.  My personal
preference
is to mandate the exchange of iSCSI-Names always (in the login command
PDU 
itself), and then differentiate a discovery session only based on the 
SessionType key - unless some issues were discovered in NDT with this 
simplistic approach.

> </JLH>
> 
> - Section 1.5.1, description for "Network Portal".  Suggest rewording
> the very first
>   sentence to include the  last sentence.  The current first sentence
> appears very
>   vague ("port" - TCP/SCSI/ethernet?).  Also the last sentence defines a
> network
>   portal for a target to comprise the "listening TCP port", should we
> identify what
>   it is for an initiator?
> <JLH>
> The initiator doesn't have the listening TCP port in it's network portal
> definition because the initiator doesn't listen. Once a session
> (connection) is created the listening port on the target side is out of the
> picture and the connection goes to other ports that bind to the connection.
> So, there is a definite asymmetry here between a target network portal and
> an initiator network portal.

Agreed, I am not arguing for symmetry in my comment.  I was merely
pointing out
the non-definition of what you just mentioned in the last sentence as
"initiator
network portal"!

> </JLH>
> 
> - The picture shown at the beginning of section 1.5 does not show TCP
> port
>   being part of the Network Portal on the initiator side.  Is it then
> implied that
>   only the IP address constitues a Network Portal for an initiator iSCSI
> Node?
> <JLH>
> See the previous comment.

Yup, I was hinting that what's implied by the picture could be the
answer
to my own previous question on "initiator network portal".  Just wanted
to 
confirm.

> </JLH>
> 
> - Section 1.5.2, last para.  This defines the I-T nexus as the session
> for iSCSI.
>   This doesn't suggest a nexus identifier - is it the four tuple
> <InitiatorName,
>   ISID, TargetName, portal group tag> or the SSID <ISID, TSID>?  Or is
> it both
>   - the four-tuple being nexus id at the SCSI layer, and the latter at
> the iSCSI
>   layer?
> <JLH>
> There really is no strong need to define a nexus identifier as it never
> really surfaces anywhere in the protocol.  There are two choices for the
> identifier, one is the 4-tuple you suggest (the one with target portal
> group tag), the other is the two names together with the session ID.  The
> first builds a nexus identifier from the identifiers of the two SCSI ports
> involved.  The other builds the nexus identifier from protocol layer things
> (TSID, in particular which does not identify a SCSI port).   The importance
> of the nexus identifier is really an internal implementation issue.  We can
> call it either one.  For the moment, I'd lean towards the first option, but
> SAM-3 (the future) may think that the second is a better choice.
> </JLH>
> 

I agree that nexus identifier appears more an implementation issue.  The
only
reason I thought it might make sense for iSCSI to call it out is because
of
draft's reference to "parallel nexus" (comment below).  My immediate
inclination
was to say "two nexus are parallel if their nexus identifiers are the
same" -
that led to this query on what's a legitimate nexus id for an
implementation 
in order to ensure that it doesn't establish parallel nexus during
runtime.

BTW, my understanding of an I-T nexus has been that it's a two-tuple - 
<initiator SCSI port-identifier, target SCSI port-identifier>.  So, I
guess I'd 
agree with your first option, since iSCSI defines port identfiers the
same as 
port names.

....

> 
> - Section 1.5.3, third para.  This mentions the term "parallel nexus".
> I assume
>   the equivalence of two 4-tuples is what is being implied here.  Unless
> this term
>   is already defined in some latest SCSI documents, I suggest defining
> this as
>   such.
> <JLH>
> It's not defined in any SCSI documents because it's never been physically
> possible before!  A definition in my mind would be "two nexus are parallel
> if they are independent relationships between the same two SCSI ports" (or
> something like this).
> </JLH>
> 
> - Section 1.5.2 does not comment on if iSCSI mandates the support of
> SCSI Port names
>   for iSCSI initiators (the requirement appears only the iSCSI targets
> para).
>   I assume it is mandatory.
> <JLH>
> I'm not sure what you're asking for here.  Perhaps this is just a misplaces
> sentence.  SAM-2 now has the notion defined of SCSI port names and the
> protocol can define what they are and if they are mandatory.  I'm sort of
> assumed that by defining what they are (for the initiator as iSCSI
> Name+ISID and for the target as iSCSI Name+Portal group tag) that they are
> implied to be mandatory.
> 
> Did I miss something?
> </JLH>

Sorry, I was referring to a post-rev07 word doc on the plane for typing
up these
comments.  Your guess is probably right - that it is a misplaced
sentence.  The
document that I was referring to explicitly states that iSCSI mandates
SCSI Device 
name support and SCSI Port name support - except it put the latter
requirement 
in the SCSI target port discussion.
 
> 
> - The following initiator requirement:
> "The iSCSI Name should be configurable parameter of each initiator
> portal group."
>    would be more clear if stated as (if this is a correct
> interpretation):
> "All the initiator portal groups of one iSCSI Node MUST share the same
>  iSCSI-Node name."
> <JLH>
> Yeah, that's pretty much a requirement, in that if the names are different,
> then the portal groups are not in the same iSCSI node.  What this sentence
> (and the related sentences) are aiming for is less of a requirement (this
> is a more recent understanding that hasn't made it into text yet) than a
> prefered common API for people building hardware.  If my host has multiple
> iSCSI hardware cards, in order that they coordinate the same iSCSI node
> concept, then they should get their iSCSI name from outside -- i.e., be
> configurable.  This is not a hard requirement because each could act on its
> own as separate iSCSI node.  Unfortunately, that management/configuration
> nightmare in FC is what this sentence is hoping to preclude.  We need to
> find the right words to back away from this as a hard requirement and more
> as request to implementors that this be available.

I completely agree with these sentiments.  My suggested sentence does
not
preclude implementors from defining one iSCSI Node per HBA, only that
they
share the same iSCSI-Name *if* they decide to act together as one iSCSI
Node.
I don't see that as any different from what you described above...  

So, I guess the question is: do you see it as a hard requirement *if*
multiple 
portal groups are implemented as one iSCSI Node?  My take is "yes",
hence the
suggestion.

Similar comments apply for other suggestions below.  Please comment.

> 
> The same logic applies to the ISID and TSID partitioning, though in a
> somewhat different way.  There are two assumptions that are at the root of
> this rule: (a) no parallel nexus and (b) the session identifier for a
> session is unique between two given iSCSI nodes.  The partitioning rules
> (if implemented by the hw cards as an API) enable the least amount of
> coordination required among different hw components.  For example, to
> enforce (b), the target portal groups don't need to share the set of SIDs
> that are active. They each own a portion of the name space and can use that
> as they wish, regardless of what's happening on the other portal groups.
> For (a), if the ISID name space is partitioned, then no two initiator
> portal groups would ever attempt a login with the same target portal group
> reusing the same ISID (so fewer rejected login's because the target portal
> group is enforcing the ISID rule).
> 
> In short, (and I'm the first to admit this), we need very different
> language to convey this idea.  It's more a "request to implementors" to
> make life easy for everybody (easier management, easier target
> implementations, fewer rejected logins, etc.) than it is a hard
> requirement.  The two assumptions above and the resulting ISID RULE are
> requirements.  The others are facilitators to that end.
> </JLH>
> 
>    Similar comments apply for the target requirement.
> - The following initiator requirement:
> "The ISID name space of the iSCSI Initiator should be partitioned among
> the initiator
>  portal groups."
>    would be better stated as (if this is a correct interpretation):
> "All initiator portal groups of one iSCSI Node MUST share an ISID name
> space
>  for sessions established to one iSCSI target node.  Sessions
> established to
>  multiple iSCSI target nodes MAY share one ISID name space."
> <JLH>
> As I've indicated above, this is only part of the equation.  The ISID name
> space is already scoped by the iSCSI Name.   The issue is facilitating
> enforcement of the ISID rule and minimal cross hw implementations.
> </JLH>
> 
> - The following target requirement:
> "The TSID name space of the iSCSI Target should be partitioned among the
> target
> portal groups."
>    would be better stated as (if this is a correct interpretation):
> "All target portal groups of one iSCSI Node MUST share an TSID name
> space for
> sessions established to one iSCSI initiator node.  Sessions established
> to
> multiple iSCSI initiator nodes MAY share one TSID name space."
> <JLH>
> See previous two comments.
> </JLH>
> 
> --
> Mallikarjun
> 
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> MS 5668 Hewlett-Packard, Roseville.
> cbm@rose.hp.com


From owner-ips@ece.cmu.edu  Tue Aug 14 22:32:15 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21443
	for <ips-archive@odin.ietf.org>; Tue, 14 Aug 2001 22:32:15 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7F1S2w12116
	for ips-outgoing; Tue, 14 Aug 2001 21:28:02 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from hebe.or.intel.com (jffdns02.or.intel.com [134.134.248.4])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7F1S0e12111
	for <ips@ece.cmu.edu>; Tue, 14 Aug 2001 21:28:00 -0400 (EDT)
Received: from SMTP (orsmsxvs01-1.jf.intel.com [192.168.65.200])
	by hebe.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id BAA06504;
	Wed, 15 Aug 2001 01:27:51 GMT
Received: from orsmsx29.jf.intel.com ([192.168.70.29]) by 192.168.70.200
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Wed, 15 Aug 2001 01:27:51 0000 (GMT)
Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2653.19)
	id <QYXVFV9A>; Tue, 14 Aug 2001 18:27:49 -0700
Message-ID: <638EC1B28663D211AC3E00A0C96B78A8086ABB08@orsmsx40.jf.intel.com>
From: "Wheat, Stephen R" <stephen.r.wheat@intel.com>
To: "'Steve Blightman'" <steve@alacritech.com>, sanjay_goyal@ivivity.com
Cc: ips@ece.cmu.edu
Subject: RE: [Fwd: Crc-32c example in iSCSI spec]
Date: Tue, 14 Aug 2001 18:27:46 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

For what it's worth, I also get the same results as you two; matching three
of the four examples; with the exception being where I get 62 a8 ab 43 for
all 0xff's.

Stephen

-----Original Message-----
From: Steve Blightman [mailto:steve@alacritech.com]
Sent: Thursday, August 09, 2001 2:15 PM
To: sanjay_goyal@ivivity.com
Cc: ips@ece.cmu.edu
Subject: Re: [Fwd: Crc-32c example in iSCSI spec]


Sanjay -
Did you ever get any response to this email? - I have the same problem.  I
wonder if we can get whoever generated these examples to double check them &
respond.
Thanks for any help
Steve Blightman

>
> Subject: Crc-32c example in iSCSI spec
> Date: Fri, 27 Jul 2001 09:52:44 -0400
> From: Sanjay Goyal <sanjay_goyal@ivivity.com>
> To: ips@ece.cmu.edu
> CC: Sanjay Goyal <sanjay_goyal@ivivity.com>
>
> Hi
>  I tried matching the crc32c example results with mine for all ZEROs and
all
> ONEs
>  the result for Zeros matches whereas it does not match for all Ones. My
> result instead of
>       21 44 df 1c
>             is
>       62 a8 ab 43
>
> Can somebody clarify me on the issue.
>
> Regards
> Sanjay Goyal




From owner-ips@ece.cmu.edu  Wed Aug 15 01:00:57 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22921
	for <ips-archive@odin.ietf.org>; Wed, 15 Aug 2001 01:00:57 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7F4aoR21728
	for ips-outgoing; Wed, 15 Aug 2001 00:36:50 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from msgbas1t.cos.agilent.com (msgbas1tx.cos.agilent.com [192.6.9.34])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7F4ane21724
	for <ips@ece.cmu.edu>; Wed, 15 Aug 2001 00:36:49 -0400 (EDT)
Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77])
	by msgbas1t.cos.agilent.com (Postfix) with ESMTP
	id CE46A873; Tue, 14 Aug 2001 22:36:48 -0600 (MDT)
Received: from acropora.rose.agilent.com (acropora.rose.agilent.com [130.30.179.5])
	by msgrel1.cos.agilent.com (Postfix) with ESMTP
	id 5E985709; Tue, 14 Aug 2001 22:36:48 -0600 (MDT)
Received: (from dbs@localhost)
	by acropora.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) id VAA00369;
	Tue, 14 Aug 2001 21:35:56 -0700 (PDT)
From: Dave Sheehy <dbs@acropora.rose.agilent.com>
Message-Id: <200108150435.VAA00369@acropora.rose.agilent.com>
Subject: RE: iSCSI: draft 7: remove S bit and Status field from the Data-i
To: Black_David@emc.com
Date: Tue, 14 Aug 2001 21:35:56 PDT
Cc: ips@ece.cmu.edu (IETF IP SAN Reflector)
In-Reply-To: <277DD60FB639D511AC0400B0D068B71ECAD5BD@CORPMX14>; from "Black_David@emc.com" at Aug 13, 101 6:55 pm
X-Mailer: Elm [revision: 212.4]
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


David,

> I think you've taken a wrong turn.  

I think John hit the nail on the head.

> > Second, thoughts of removing the immediate data seem not to be
> > simplification, since all the information to tie the data to the command
> is
> > right there with the command.  That has got to be easier than matching up
> > separate PDUs of data with the appropriate commands.
> 
> Actually, that was the point, since the logic for "matching up separate
> PDUs of data with the appropriate commands" has to exist for inbound
> Data PDUs already.  

Except that there is a target context present in the solicited case to route 
the data. That doesn't exist in the unsolicited case.

> The slide I presented in London was about replacing
> immediate data with an unsolicited data PDU immediately following the
> command, thus removing the immediate data case in favor of reusing the
> logic for dealing with separate Data PDUs.  Remember that this was presented
> as a simplification possibility.

This does help some. It eliminates the situation where a target can receive
an essentially unlimited number of immediate data commands prior to receiving
*any* data PDUs.

But, do you mean to say that *one* unsolicited data PDU would follow the
command? Wouldn't that be unnecessarily restrictive if the PDU size is small?
Simply guaranteeing that the data PDUs will immediately follow the command
seems like an adequate improvement.

Dave Sheehy



From owner-ips@ece.cmu.edu  Wed Aug 15 01:01:43 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22943
	for <ips-archive@odin.ietf.org>; Wed, 15 Aug 2001 01:01:43 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7F47rQ20579
	for ips-outgoing; Wed, 15 Aug 2001 00:07:53 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.6.9.33])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7F47qe20571
	for <ips@ece.cmu.edu>; Wed, 15 Aug 2001 00:07:52 -0400 (EDT)
Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77])
	by msgbas1.cos.agilent.com (Postfix) with ESMTP
	id 52DB4A6B; Tue, 14 Aug 2001 22:07:51 -0600 (MDT)
Received: from acropora.rose.agilent.com (acropora.rose.agilent.com [130.30.179.5])
	by msgrel1.cos.agilent.com (Postfix) with ESMTP
	id D333714B9; Tue, 14 Aug 2001 22:07:50 -0600 (MDT)
Received: (from dbs@localhost)
	by acropora.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) id VAA00353;
	Tue, 14 Aug 2001 21:06:58 -0700 (PDT)
From: Dave Sheehy <dbs@acropora.rose.agilent.com>
Message-Id: <200108150406.VAA00353@acropora.rose.agilent.com>
Subject: Re: iSCSI: draft 7: remove S bit and Status field from the Data-in PD 
To: steph@cs.uchicago.edu
Date: Tue, 14 Aug 2001 21:06:57 PDT
Cc: ips@ece.cmu.edu (IETF IP SAN Reflector)
In-Reply-To: <E15UOFu-0006aI-00@relay2.bt.net>; from "Stephen Bailey" at Aug 8, 101 1:29 am
X-Mailer: Elm [revision: 212.4]
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Sorry for the delayed response, I was away from the office for most of last
week.

> > What are you trying to simplify?
> 
> Trying to simplify the receiver's data path by eliminating one of the
> two possible ways in which unsolicited data could arrive.

Eliminating immediate data doesn't accomplish that to any significant degree
hence my question.

> Eliminating the unsolicited PDUs is the WRONG choice because if you
> only have immediate data (data within the command PDU), you can must
> either a) make the allowable size of the command PDU relatively
> unbounded (to accomodate arbitrarily sized immediate data), which will
> break either framing mode b) severely limit the amount of unsolicited
> that can be sent, which makes unsolicited data useless.

I did not mean to imply that it was the RIGHT or the WRONG choice. John
Hufferd's post echoes my own thoughts on the matter quite well. Handling
unsolicited data PDUs at the target is a lot of work because they have
no target context and they arrive separately from the command. The handling
of immediate data is trivial in comparison.

> So, unsolicited data should be carried in a similar, if not identical
> way as regular data, tiled into multiple PDUs.

Then forget simplification because you aren't going to get it to any
significant degree.

Dave



From owner-ips@ece.cmu.edu  Wed Aug 15 05:33:54 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11355
	for <ips-archive@odin.ietf.org>; Wed, 15 Aug 2001 05:33:54 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7F8JOR11800
	for ips-outgoing; Wed, 15 Aug 2001 04:19:24 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7F8JMe11794
	for <ips@ece.cmu.edu>; Wed, 15 Aug 2001 04:19:22 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id KAA113418
	for <ips@ece.cmu.edu>; Wed, 15 Aug 2001 10:19:14 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7F8JEM101614
	for <ips@ece.cmu.edu>; Wed, 15 Aug 2001 10:19:14 +0200
Importance: Normal
Subject: iSCSI - Change - proposal RE: Review of the 07 draft
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF77514F2C.92FFBC86-ONC2256AA9.002D52D0@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Wed, 15 Aug 2001 11:18:52 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 15/08/2001 11:19:13
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


You have a good point.  We may want to change it to this definition and
leave it to SCSI (remove from appendix) and add an explicit MaxPDU.

Comments?

Julo

"Binford, Charles" <CBinford@pirus.com>@ece.cmu.edu on 13-08-2001 17:49:10

Please respond to "Binford, Charles" <CBinford@pirus.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: Review of the 07 draft



I agree with Julian about removing EMDP and FirstBurstSize from iSCSI
control.  I disagree on MaxBurstSize.

MaxBustSize defines DataPDU length only because we said it does.  We could
just as easily remove the relationship between DataPDU length and
MaxBurstSize.  I would prefer we let iSCSI control DataPDU length as it
does
today and change the meaning of MaxBurstSize under iSCSI to be more in line
with what MaxBurstSize means under other SCSI protocols.  As pointed out
earlier on this thread a generic SCSI mode page utility doesn't/shouldn't
know/care what the transport it.

The meaning of MaxBurstSize under FCP is largest FC Sequence a target can
send.  Since an FC class 3 target can send multiple Read data sequences to
the host with no handshake, the parameter is essentially a don't care for
reads.  For Writes it effectively governs the largest amount of data a
target can ask for on an XFER_RDY.

For iSCSI, I'd like to see MaxBurstSize be defined as one of the following:
- largest amount of data a target can ask for under a single R2T; or
- ignored.

My problem with the current definition is typical iSCSI DataPDU lengths are
relatively small (default 8K in the spec.)  The typical MaxBurstSize for
other protocols is much larger - 64K to 512K.

Charles Binford
Pirus Networks
316.315.0382 x222


-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, August 11, 2001 5:50 PM
To: Robert Snively
Cc: 'deva@stargateip.com'; Robert Griswold; Eddy Quicksall; Jim Hafner;
ips@ece.cmu.edu
Subject: RE: Review of the 07 draft


I think that for regularity it would be wise to remove completely EMDP and
FirstBurstsize from iSCSI control.
MaximumBurstSize defines the DataPDU length and is transport related
(affects iSCSI and less SCSI) and should stay under iSCSI control.


Comments?

Julo

Robert Snively <rsnively@Brocade.COM>@ece.cmu.edu on 10-08-2001 10:32:20

Please respond to Robert Snively <rsnively@Brocade.COM>

Sent by:  owner-ips@ece.cmu.edu


To:   "'deva@stargateip.com'" <deva@stargateip.com>, Robert Griswold
      <rgriswold@Crossroads.com>, Eddy Quicksall <ESQuicksall@hotmail.com>,
      Jim Hafner/Almaden/IBM@IBMUS
cc:   ips@ece.cmu.edu
Subject:  RE: Review of the 07 draft



Deva,

Both of you are right if iSCSI sticks to negotiating only
parameters related with the TCP connections, the iSCSI
session operational parameters other than EMDP and
burst length, and iSCSI security parameters.  Then, all
parameters relating to the normal SCSI activities, including
EMDP and burst length (which are required for SCSI, not iSCSI,
buffer management) would be negotiated in the normal
SCSI manner through the MODE SENSE/SELECT pages and everybody
would live happily ever after.

Otherwise, and especially with respect to EMDP and burst length,
I have to agree with Robert.

Bob Snively                        e-mail:    rsnively@brocade.com
Brocade Communications Systems     phone:  408 487 8135
1745 Technology Drive
San Jose, CA 95110



-----Original Message-----
From: Dev [mailto:deva@stargateip.com]
Sent: Thursday, August 09, 2001 5:33 PM
To: Robert Griswold; Eddy Quicksall; Jim Hafner
Cc: ips@ece.cmu.edu
Subject: RE: Review of the 07 draft


All,

I tend to disagree. The parameters for the iSCSI are negotiated between the
initiator and target.
If we allow the parameters to be changed through SCSI Mode select, how will
this work?

If parameters can be changed through SCSI Mode select then it will apply
only to Lead only connections.

So, we'll have

a) two methods to change the Lead only parameters common for the entire
session (one through mode select
and the other through text parameters)
b) Just iSCSI text command to change the connection specific parameters.

Does it not add to complexity having multiple ways to change the same
stuff?

Thanks

Deva
Platys communications

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Robert Griswold
Sent: Thursday, August 09, 2001 1:36 PM
To: Eddy Quicksall; Jim Hafner
Cc: ips@ece.cmu.edu
Subject: RE: Review of the 07 draft


Eddy:

I actually have no problem with all mode pages (SCSI and iSCSI) being
accessible and changeable from standard SCSI mode commands.  My initial
response to this section was to propose a method that would be
acceptable to the authors of the iSCSI draft.  If there is desire in the
group to allow mode pages for the entire target to be manipulated from
the SCSI level, I think that is a better idea that the one I proposed.
I would assume that an iSCSI aware SCSI utility would understand the
iSCSI specific settings, and allow the user to make those changes.  What
I am really against, is the ability to modify standard SCSI mode page
settings from text messages, as that could lead to target behavior
changes outside of the understanding of the SCSI nexus.

To recap your thinking:  Allow iSCSI text messages to modify and read
iSCSI only mode settings (potentially allowing the reading if SCSI mode
settings), but allow SCSI mode commands to modify and read all target
mode settings, including iSCSI settings.  Is that what you are saying.
If so, I agree.

Bob

Robert Griswold
Technologist
Crossroads Systems, Inc.
512-928-7272

 -----Original Message-----
From:     Eddy Quicksall [mailto:ESQuicksall@hotmail.com]
Sent:     Thursday, August 09, 2001 2:08 PM
To:  Robert Griswold; Jim Hafner
Cc:  ips@ece.cmu.edu
Subject:  Re: Review of the 07 draft

I don't like the idea of not letting a user of a SCSI utility be able to
change some of the parameters for iSCSI. Because they may be relevant to
him
and there may not be a user interface to the iSCSI driver. pSCSI sets
these
low level parameters via a standard mode set, so why not iSCSI?

It would be best if we could work out something where only the SCSI
layer
can set the mode pages. That would solve everything.

Eddy

----- Original Message -----
From: "Jim Hafner" <hafner@almaden.ibm.com>
To: "Robert Griswold" <rgriswold@Crossroads.com>
Cc: <ips@ece.cmu.edu>
Sent: Friday, August 03, 2001 5:26 PM
Subject: Re: Review of the 07 draft

> Well, in fact, the draft is supposed to say that MODE_SELECT for the
> transport-specific mode page will NOT be done via SCSI, only via Text
> commands.  I read that as saying that from the SCSI layer, all fields
in
> these pages are "unchangeable" (even though they can change in the
iSCSI
> layer).  Of course, the draft doesn't say whether MODE PARAMETERS HAVE
> CHANGED unit attentions get thrown up at the SCSI layer when this
happens
> at the iSCSI layer.... You later have a clarifying question (Section
3) on
> this as well.
>
> Regards,
> Jim Hafner
>
>
>
>








From owner-ips@ece.cmu.edu  Wed Aug 15 10:00:44 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21125
	for <ips-archive@odin.ietf.org>; Wed, 15 Aug 2001 10:00:44 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7FCqEh20517
	for ips-outgoing; Wed, 15 Aug 2001 08:52:14 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7FCqDe20512
	for <ips@ece.cmu.edu>; Wed, 15 Aug 2001 08:52:13 -0400 (EDT)
Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA01168; Wed, 15 Aug 2001 08:52:04 -0400 (EDT)
Message-ID: <3B7A6EEA.37BF1D54@cisco.com>
Date: Wed, 15 Aug 2001 07:45:30 -0500
From: Mark Bakke <mbakke@cisco.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686)
X-Accept-Language: en, de
MIME-Version: 1.0
To: "Wheat, Stephen R" <stephen.r.wheat@intel.com>
CC: "'Steve Blightman'" <steve@alacritech.com>, sanjay_goyal@ivivity.com,
        ips@ece.cmu.edu
Subject: Re: [Fwd: Crc-32c example in iSCSI spec]
References: <638EC1B28663D211AC3E00A0C96B78A8086ABB08@orsmsx40.jf.intel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


I had done the examples, and I apologize for missing the first
email.  You are right; the "all ones" CRC is 62 a8 ab 43.  I
just ran my generator again, and found the problem.  I was running
both the iSCSI and Ethernet CRCs on each pattern, so I could check
the Ethernet CRC against other specs as well.  When I wrote the
examples, I copied the wrong CRC for the all ones example.

We'll fix it.

--
Mark

"Wheat, Stephen R" wrote:
> 
> For what it's worth, I also get the same results as you two; matching three
> of the four examples; with the exception being where I get 62 a8 ab 43 for
> all 0xff's.
> 
> Stephen
> 
> -----Original Message-----
> From: Steve Blightman [mailto:steve@alacritech.com]
> Sent: Thursday, August 09, 2001 2:15 PM
> To: sanjay_goyal@ivivity.com
> Cc: ips@ece.cmu.edu
> Subject: Re: [Fwd: Crc-32c example in iSCSI spec]
> 
> Sanjay -
> Did you ever get any response to this email? - I have the same problem.  I
> wonder if we can get whoever generated these examples to double check them &
> respond.
> Thanks for any help
> Steve Blightman
> 
> >
> > Subject: Crc-32c example in iSCSI spec
> > Date: Fri, 27 Jul 2001 09:52:44 -0400
> > From: Sanjay Goyal <sanjay_goyal@ivivity.com>
> > To: ips@ece.cmu.edu
> > CC: Sanjay Goyal <sanjay_goyal@ivivity.com>
> >
> > Hi
> >  I tried matching the crc32c example results with mine for all ZEROs and
> all
> > ONEs
> >  the result for Zeros matches whereas it does not match for all Ones. My
> > result instead of
> >       21 44 df 1c
> >             is
> >       62 a8 ab 43
> >
> > Can somebody clarify me on the issue.
> >
> > Regards
> > Sanjay Goyal

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054


From owner-ips@ece.cmu.edu  Wed Aug 15 10:28:51 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22138
	for <ips-archive@odin.ietf.org>; Wed, 15 Aug 2001 10:28:51 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7FDVZ422206
	for ips-outgoing; Wed, 15 Aug 2001 09:31:35 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7FDVXe22201
	for <ips@ece.cmu.edu>; Wed, 15 Aug 2001 09:31:33 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id PAA135138
	for <ips@ece.cmu.edu>; Wed, 15 Aug 2001 15:31:25 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7FDVPM17044
	for <ips@ece.cmu.edu>; Wed, 15 Aug 2001 15:31:25 +0200
Importance: Normal
Subject: Re: CmdSN during login
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF36787279.710B96BB-ONC2256AA9.0030F7EE@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Wed, 15 Aug 2001 16:28:05 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 15/08/2001 16:31:25
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Mark,

I am uneasy about mandating the I bit instead of recommending it strongly
and I am against recommending for the CmdSN field other values than our
"reference" CmdSN (i.e., your preferred 0).

Consider the following scenario:

Connection1:
I->T c1(lu1)c2(lu1)c3(lu1)c4(lu2)c5(lu2)c6(lu2)Clear-ACA-LU1(#7) c7(lu1)
c8(lu1) c9(lu1)

Command are executed at target but no statuses make it hardly back.
C2 ends in an error that blocks the execution of C3. Clear-LU1 is meant to
clean the error.
No other traffic after the error report makes it back.

Initiator starts connection 2 and issues a login+restart for connection 1

The target sees the following sequence

c1,c2,c3,c4,c5,c6, Login, Clear-LU1(#7), c7, c8, c9

Target not having a reference for the logout/login will probably not
execute Clear-ACA-LU1(#7).

The initiator can now reissue c9,c8,c7,Clear-ACA-LU1 and all will be
dropped (when c7 arrives)  before Clear-ACA-LU1 is executed.

Although this a "legal" sequence and actions are legal (but not optimal) I
am afraid that there are other sequences in which the side effects are
"non-serial" schedules.

Julo






Please respond to Mark Bakke <mbakke@cisco.com>

Sent by:  mbakke@cisco.com


To:   Julian Satran/Haifa/IBM@IBMIL
cc:   ips@ece.cmu.edu
Subject:  Re: CmdSN during login



Julian-

What are the specific scenarios where this would happen?  My
assumption has been that there is exactly one login exchange
when a connection is established, and if a connection is logged
out for some reason, that connection is destroyed.  To do
another login, a new connection would have to be created.  If
a connection is joining a session already in progress, how
would it make any difference if task management commands were
happening in full feature phase within other connections on
the session?  Why would the login have to wait?  You mentioned
that there were other ways to handle this.  Can we settle on
using the "other ways" instead?

I do think that your suggestion of mandating the I bit set
during login and negotiation would work; if the I bit is set,
the CmdSN is ignored and can be set to anything (I'd prefer
zero).  This effectively means that CmdSN does not start
incrementing until full feature phase, which is what we wanted,
but is still in the login and text command format "just in case"
it's needed at some other time.

However, I would like to strongly word this such that the login
and negotiation phases always set the I bit, send CmdSN=0, and
ignore CmdSN on receive, until full feature phase is started.
I think that a statement like "use whenever adequate" is too
weak and ambiguous.

--
Mark

Julian Satran wrote:
>
> I can see scenarios in which you would want the login request  be regular
-
> as when you issue it after
> a task management clear LU or reset command and want to make sure that it
> executed after the clear and the CmdSN clearly indicates that.  However
> even this effect can be achieved by other means and the discussion is
> rather academic - should we mandate the I bit in the login phase (MUST)
or
> just say that it should be used whenever adequate and explain why (which
I
> prefer) as it won't be required in all cases (e.g., it is not necessary
in
> a session establishing login).
>
> Julo
>
> "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <matthew_burbridge@hp.com>
> @ece.cmu.edu on 13-08-2001 19:34:56
>
> Please respond to "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)"
>       <matthew_burbridge@hp.com>
>
> Sent by:  owner-ips@ece.cmu.edu
>
> To:   ips@ece.cmu.edu
> cc:
> Subject:  RE: CmdSN during login
>
> Could commands sent during the login phase (ie LOGIN + TEXT) be mandatory
> to
> be immediate and therefore MUST have the I bit set or is there a reason
why
> non-immediate login phase commands make sense?
>
> Cheers
>
> Matthew Burbridge
>
> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Saturday, August 11, 2001 4:37 PM
> To: ips@ece.cmu.edu
> Subject: Re: CmdSN during login
>
> There was ambiguity at first login that we have cleared in text and as I
> said I don't see any good reason
> for another case of immediate when we have the immediate bit available.
> What we could do is add anothe pragraph to 8
> recommending when to use the I bit in login.
>
> Julo
>
> "Eddy Quicksall" <ESQuicksall@hotmail.com> on 10-08-2001 18:13:32
>
> Please respond to "Eddy Quicksall" <ESQuicksall@hotmail.com>
>
> To:   Julian Satran/Haifa/IBM@IBMIL
> cc:   <ips@ece.cmu.edu>
> Subject:  Re: CmdSN during login
>
> But, what if someone does this without setting the Immediate bit? What
> would
> one do?
>
> What is wrong with just making the CmdSN not run during login? It seems
> like
> it was an arbitrary choice in the first place since it was originally
> optional and not using it actually worked.
>
> If CmdSN is stated as only used in FFP, then I don't see any ambiguity.
>
> Eddy
> ----- Original Message -----
> From: "Julian Satran" <Julian_Satran@il.ibm.com>
> To: <ips@ece.cmu.edu>
> Sent: Friday, August 10, 2001 2:43 AM
> Subject: Re: CmdSN during login
>
> >
> > Sanjay,
> >
> > If you want to ignore CmdSN and expedite Login processing you can do so
> by
> > having the commands being issued as immediate.
> > This will help us keep away from creating ambiguity about (or another
> > conditional) for when CmdSN is to be used or not.
> >
> > Julo
> >
> > Mark Bakke <mbakke@cisco.com>@ece.cmu.edu on 09-08-2001 23:55:25
> >
> > Please respond to Mark Bakke <mbakke@cisco.com>
> >
> > Sent by:  owner-ips@ece.cmu.edu
> >
> >
> > To:   Sanjay Goyal <sanjay_goyal@ivivity.com>
> > cc:   "Ips (E-mail)" <ips@ece.cmu.edu>
> > Subject:  Re: CmdSN during login
> >
> >
> >
> >
> > Sanjay-
> >
> > I absolutely agree with this; CmdSN is owned by the session, and
> > should not be used until the connection has fully joined the session,
> > which means full feature phase.
> >
> > This should also clean up any ambiguity on when to start
> > using CmdSN.
> >
> > --
> > Mark
> >
> > Sanjay Goyal wrote:
> > >
> > > Hi
> > >
> > >  Assuming Target and Initiator support multiple connections and the
> > session
> > > is having multiple connections. Assuming out-of-order CmdSN is a
> > possibility
> > > for this session.
> > >
> > >  Connection #   1       |       2       |       3
> > > -------------------------------------------------------
> > > Login Cmd  CmdSN=0      |   CmdSN=8     |  CmdSN=9
> > > Txt   Cmd  CmdSN=1      |               |
> > >                                 |               |
> > >                                 |               |
> > > Login Cmd  CmdSN=7      |  CmdSN=10     |  CmdSN=11
> > > -------------------------------------------------------
> > > Data Cmd   CmdSN=12     | CmdSN=14      | CmdSN=15
> > > Data Cmd   CmdSN=13     |               |
> > >                                 |               |
> > >
> > > CmdSN=7 is last of the Login sequence and it is acknowledged by the
> > Target
> > > with "accept login" response.
> > >
> > > Target would receive the PDUs in this CmdSN order
> > >  0 to 7, 8, 9, 12, 10, 11, 13, 14, 15
> > >
> > > Now as Login and Text PDUs are being processed even though you have
> > received
> > > Data Cmd PDUs, you can not pass them to iSCSI layer and hence you are
> > adding
> > > latency.
> > >
> > > What I want to convey from this example is why not use CmdSN just
> during
> > the
> > > FullFeature phase only.
> > >
> > > Regards
> > > Sanjay Goyal
> > >
> > >
> >
>
--------------------------------------------------------------------------
> --------------------------
> >
> > >
> > >    Part 1.2    Type: application/ms-tnef
> > >            Encoding: base64
> >
> > --
> > Mark A. Bakke
> > Cisco Systems
> > mbakke@cisco.com
> > 763.398.1054
> >
> >
> >
> >

--
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054





From owner-ips@ece.cmu.edu  Wed Aug 15 11:37:44 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23939
	for <ips-archive@odin.ietf.org>; Wed, 15 Aug 2001 11:37:44 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7FERMn24821
	for ips-outgoing; Wed, 15 Aug 2001 10:27:22 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from va2mc.ummailbox.net (va2mc.ummailbox.net [64.210.247.22])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7FERKe24817
	for <ips@ece.cmu.edu>; Wed, 15 Aug 2001 10:27:20 -0400 (EDT)
Received: from hqmailweb.COMMSTOR.Crossroads.com (HQMailWeb.Crossroads.com [63.237.99.250:25])
	by va2mc.ummailbox.net with ESMTP id U0815-1027-17a600;
	Wed, 15 Aug 2001 14:27:17 GMT
Received: from HQMAILNODE1.COMMSTOR.Crossroads.com ([10.5.1.42]) by hqmailweb.COMMSTOR.Crossroads.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Wed, 15 Aug 2001 09:27:17 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: Questions on iSCSI 07
Disposition-Notification-To: "Lee Xing" <lxing@Crossroads.com>
Date: Wed, 15 Aug 2001 09:27:17 -0500
Message-ID: <CFD808D1D39ACB47ABFF586D484CC52E341417@HQMAILNODE1.COMMSTOR.Crossroads.com>
Thread-Topic: Questions on iSCSI 07
Thread-Index: AcEllmLG7hijCM/kQK6Yyf5UEHp93Q==
From: "Lee Xing" <lxing@Crossroads.com>
To: <ips@ece.cmu.edu>
X-OriginalArrivalTime: 15 Aug 2001 14:27:17.0012 (UTC) FILETIME=[62732540:01C12596]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f7FERKe24818
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit

Hi All,

I have a few questions on iSCSI 07.  I would appreciate it if someone
could explain them.

Thank you.


Lee Xing
Sr. Software Engineer
Crossroads Systems, Inc.

----------------------------------------------
Q1:
Page 104: "Operational parameters MAY be negotiated outside (after) the
login phase."
Page 157: "Some session specific parameters MUST be carried only on the
leading connection and cannot be changed after the leading connection
login..."

If operational parameters are considered as session parameters, then
should we reword the sentence on page 104, such as "Some operational
parameters MAY be negotiated outside (after) the login phase."?

----------------------------------------------
Q2: 
Page 22: "Any PDU except login and text, which is sent on a TCP
connection before this connection gets into full feature phase, is a
protocol error."

Page 169: "To make use of SendTargets, an initiator must first be logged
in to one of two types of targets."

Since SendTargets is one of the keys for Text Cmds, and we can't issue
it before logging in, we probably should reword the sentence on page 22.

----------------------------------------------
Q3: Page 169: "If it logs in to any other target, the session the
session can be either a discovery session or a normal operational
session".  Should we delete one "the session" from this sentence?

----------------------------------------------
Q4: Why don't section 1.2.2.1 & 1.2.2.2 address where CmdSN & StatSN
should start from (0, 1, or whatever) explicitly like DataSN does?
Should we initialize the counters before start the process?

----------------------------------------------
Q5: Page 102: "An operational parameter negotiation on a connection
SHOULD not start before the security/integrity negotiation if such a
negotiation exists.  Operational parameters negotiated inadvertently
before the security/integrity negotiation MAY be reset after the
security/integrity negotiation at the explicit request of the initiator
or target."

The question is under which circumstance do we need to negotiate
operational parameters before security/integrity negotiation?  If it's
unlikely to happen, why do we leave a potential security hole here?

----------------------------------------------
Q6: 
Page 21: "... ... If an initiator and target are connected through more
than one session, both the initiator and target perceive the other as a
different entity on each session (a different I_T nexus in SAM-2
parlance)."

Page 69: "When a target is detecting an attempt to open a new session by
the same initiator (same InitiatorName and ISID) it MUST check if the
old session is active.  If it is not the old-session must be reset by
the target and the new session established. Otherwise the Login MUST be
terminated with a Login Response."

The sentence on page 21 tells us multi-sessions between an initiator and
a target are allowed; while the sentence on page 69 implies they are
not.  We probably need to clear it a bit.

----------------------------------------------
Q7:
Page 69: "When a target is detecting an attempt to open a new session by
the same initiator (same InitiatorName and ISID) it MUST check if the
old session is active.  If it is not the old-session must be reset by
the target and the new session established. Otherwise the Login MUST be
terminated with a Login Response."

What does "reset" exactly mean here?

----------------------------------------------
Q8: This question is on multi-path.  Suppose two NICs are connected to
the same target, therefore we could have at least two target addresses
a1 & a2.  Suppose address a1 needs to be dedicated to a particular
initiator I1.  Is it OK if we let the target to hide a1 from (i.e. not
sending a1 with "SendTargets" cmd response to) all initiators except I1,
or do we need to modify 07 to do so?

The current Standard 07 on page 171 says "If a SendTargets response
reports an iSCSI address for a target, it SHOULD also report all other
addresses in its portal group in the same response."

----------------------------------------------
Q9:  This is a performance-related question.

After the first (leading) connection logs into a normal operational
session, why can't the same initiator have an option to just "spawn"
more "full featured" connections with the same target without running
Login handshake processes (i.e. authenticate the parties, negotiate the
session's parameters, open security associations protocol and make
connections as belonging to a session) again.  It would be more
efficient if we could have this option.

It seems feasible because:

  - it's not necessary to authenticate both parties 
    again after doing so on the first (leading) 
    connection.
  - security is still possessed without running
    Login process on the following connections 
    because the first (leading) connection has to 
    run Login process, and no extra connections 
    can be spawned without logging into the first 
    one.
  - session parameters, generally, are the same
    for connections within a session.  If not, they
    can be re-negotiated later.
  - All connections within a session belong to
    the same I_T nexus.
  - Text Cmds can be used to "spawn" full-featured 
    connections without adding too much stuff into 
    iSCSI Standard or making it too complex.





From owner-ips@ece.cmu.edu  Wed Aug 15 12:22:21 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25033
	for <ips-archive@odin.ietf.org>; Wed, 15 Aug 2001 12:22:20 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7FFLsV27683
	for ips-outgoing; Wed, 15 Aug 2001 11:21:54 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f7FFLqe27679
	for <ips@ece.cmu.edu>; Wed, 15 Aug 2001 11:21:52 -0400 (EDT)
Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Wed Aug 15 11:21:33 EDT 2001
Received: from aura.research.bell-labs.com (aura.research.bell-labs.com [135.104.46.10])
	by scummy.research.bell-labs.com (8.11.4/8.11.4) with ESMTP id f7FFLMl60311;
	Wed, 15 Aug 2001 11:21:22 -0400 (EDT)
Received: from research.bell-labs.com (IDENT:sandeepj@sandeepj-pcmh.research.bell-labs.com [135.104.47.90])
	by aura.research.bell-labs.com (8.9.1/8.9.1) with ESMTP id LAA29033;
	Wed, 15 Aug 2001 11:21:22 -0400 (EDT)
Message-ID: <3B7A9372.388A60B1@research.bell-labs.com>
Date: Wed, 15 Aug 2001 11:21:22 -0400
From: Sandeep Joshi <sandeepj@research.bell-labs.com>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-3 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Black_David@emc.com
CC: ips@ece.cmu.edu
Subject: Re: IPS: Schedule and Security Update
References: <277DD60FB639D511AC0400B0D068B71ECAD5A3@CORPMX14>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


David,

Given the newly being-proposed rekeying solutions, how does 
"mandatory to implement" translate in terms of the iSCSI 
clients (initiators), where the same box might have some
or all of the following :
(a) a host OS with IPSec stack from vendor A
(b) an iSCSI HBA from vendor B
(c) an IPsec accelerator from vendor C

Since the vendors are different, who "must" undertake the 
fun stuff of changing IKE/SRP for rekeying ?   Part of
the answer may be dictated by performance needs & economics, 
but in any case I am eager to hear the official interpretation.

This question may not arise in case of RAID boxes or filers, 
where a single vendor would be responsible for the iSCSI 
solution.

Second question : how would we run iSCSI over NAT if we are
to use transport mode ESP, given all the problems 
pointed out by Aboba in 
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-nat-reqts-00.txt

thanks,
-Sandeep

Black_David@emc.com wrote:
> -- Security
> 
> A number of thing have been happening in this area that may not be visible
> to everyone.  This section is all about iSCSI, although it also applies to
> FCIP and iFCP to the extent that they want to follow iSCSI's direction.  At
> the moment, iSCSI has open technical issues in (at least) the following four
> areas of security, all of which are potential discussion topics for the
> interim meeting (although the first one would be for clarification only -
> disputing that set of requirements is not a good use of meeting time).
> 
> - Requirements
> 
> The question of whether security could be optional for FCIP was brought to
> the IESG Plenary in London, and the result was a definitive "NO - security
> is a 'MUST implement'".  Between this and my discussion of the saag whyenc
> draft (draft-ietf-saag-whyenc-00.txt) with both our ADs and the one security
> AD who was in London, we should assume that the IESG will add
> confidentiality
> (i.e., encryption) to the current requirements that iSCSI, FCIP and iFCP
> "MUST implement" authentication and keyed cryptographic data integrity.
> 
> - Keying and Rekeying
> 
> iSCSI needs an automatic keying and rekeying mechanism (and it will be
> "MUST implement").  There are currently a couple of active proposals to
> do this:
> 
> o Use SRP (or some other inband authentication protocol) to generate ESP
>         keying material.  See draft-black-ips-iscsi-security-00.txt, which
>         I hope to revise to -01 by the end of the week.  This draft also
>         contains a general discussion of security requirements.
> o Use IKE.  A draft on this should be coming on this in the next few days
>         from Bernard Aboba and a bunch of folks who have been working on
> this.
> 
> Both of these proposals are headed in the direction of end-to-end security
> that would make it difficult to use an off-the-shelf IPsec security gateway
> to meet iSCSI's "MUST implement" security requirements.  The SRP approach
> generates the keys outside the gateway, and there's no standard protocol to
> insert the keys into the gateway, and the IKE draft wants to use transport
> mode ESP instead of tunnel mode (gateways generally use tunnel mode).  Based
> on discussions with Marcus Leech (security AD) and Steve Bellovin (IAB
> member and security expert), this end-to-end security direction is the
> preferred approach (vs. saying "just use IPsec gateways").
> 
> - Algorithm Selection
> 
> We need to select encryption and keyed MAC (keyed cryptographic integrity)
> algorithms.  This area is somewhat in flux, because a new generation of
> these
> algorithms is becoming usable - this is about using AES and UMAC instead of
> 3DES and HMAC.  More details should be in the forthcoming IKE draft.  The
> new draft charter for the IPsec WG indicates that they intend to complete
> work on the drafts needed for these algorithms (and a draft to extend the
> ESP sequence number for high-speed implementations) in the next few months
> (and will take all the help they can get in generating those drafts).
> 
> - Authentication
> 
> We've been a bit vague on exactly what is being authenticated (e.g.,
> machine, user), and authentication requirements beyond the fact that
> we need authentication.  The two drafts noted above contain some material
> that makes a start in that direction, but some additional thought (and
> text) will be needed to ensure that we have the right authentication
> mechanisms specified/required.  In the case of IKE, this includes
> requirements on the relationship between iSCSI and IKE authentication
> if both are performed, fortunately Bernard Aboba worked on l2tp security
> which has some analogous issues.
> 
> Thanks,
> --David
> 
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------


From owner-ips@ece.cmu.edu  Wed Aug 15 12:24:09 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25140
	for <ips-archive@odin.ietf.org>; Wed, 15 Aug 2001 12:24:09 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7FFdZX28796
	for ips-outgoing; Wed, 15 Aug 2001 11:39:35 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7FFdUe28790
	for <ips@ece.cmu.edu>; Wed, 15 Aug 2001 11:39:30 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA75222;
	Wed, 15 Aug 2001 11:37:21 -0400
Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7FFdQR19762;
	Wed, 15 Aug 2001 09:39:26 -0600
Importance: Normal
Subject: Re: iSCSI: rev07 - ISID-TSID & naming comments
To: cbm@rose.hp.com
Cc: ips@ece.cmu.edu
From: "Jim Hafner" <hafner@almaden.ibm.com>
Date: Wed, 15 Aug 2001 08:39:23 -0700
Message-ID: <OF321C4C6A.07C5E3E0-ON88256AA9.0052B44C@boulder.ibm.com>
X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at
 08/15/2001 08:39:26 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Mallikarjun,

We are very close on this stuff.   A few more comments inline.

Jim Hafner


"Mallikarjun C." <cbm@rose.hp.com> on 08/14/2001 03:38:53 pm

Please respond to cbm@rose.hp.com

To:   Jim Hafner/Almaden/IBM@IBMUS
cc:   ips@ece.cmu.edu
Subject:  Re: iSCSI: rev07 - ISID-TSID & naming comments



Jim,

Thanks for the quick response.  I agree with most of your responses.
However, some comments below on your responses.

Regards.
--
Mallikarjun

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

Jim Hafner wrote:
>
.....

> - Section 2.11.4, first sentence.  "The TSID is an initiator identifying
> tag
>   set by the target." s/b with "The TSID is a target-defined tag
> assigned to
>   an initiator SCSI port.".
> <JLH>
> This is actually an incorrect interpretation.  In the model we (I) am
> proposing, the TSID has nothing to do with identifying either the target
or
> initiator SCSI port.  It is a tag used by the target (iSCSI target) to
help
> identify a session *along with the ISID* of that session.  In the model,
> the TSID plays no role in the SCSI layer.

I agree with what you state, but I don't quite see why the suggested
sentence
violates this philosophy.  If you substitute "<InitiatorName+ISID>" for
the
phrase "initiator SCSI port" (since they are the same) in my suggested
sentence,
that's essentially what you state above...  Did I miss something?

<JLH>
Not to be too technical, but the two quoted things aren't actually the
same, one is the name/identifier for the other, but that's nit-picky.  Now
that I re-read your sentence a couple of times, I think I have a better
understanding of where you're going with it and I have less problem with
it.  Though it is literally correct in that the target does assign it and
it ends up pairing with an initiator SCSI port, I think I'm bothered by the
implication that this is a SCSI level tag.  It's really just an iSCSI level
tag, and so is more naturally paired with the I-Name+ISID to identify a
session.  So, I'd prefer (but not strongly) "The TSID is a target-defined
tag assigned to a session to identity that session along with the initiator
Name and ISID" or something like that.  My point is that it's there to
identify the iSCSI session and is independent of the SAM-iSCSI mapping.
But I won't get bent out of shape if the words you propose are used.
</JLH>

>
> This sentence needs clarification.
> </JLH>
>
> - Section 1.5, para 1, "Network portals (IP names, addresses and TCP
> ports)"
>   Suggest dropping "IP names" since what really matters is just the IP
> addresses
>   and TCP ports.  IIRC, two DNS names can resolve to the same IP
> address, and one
>   DNS name can resolve to multiple IP addresses.
> <JLH>
> But IPnames (because of DNS) can be perfectly good identifiers for
Network
> portals.  The network portal can be virtual (shared across many nics that
> have different IP addresses) or physical (used by a single nic that has a
> unique address).  It all depends on the mapping.  The point here (and it
> isn't that critical a point) is that I can initiate a connection to a
> network portal (say in software) by openning a socket to a given
> "IPnamed:tcpport" combination and let the lower layers deal with address
> resolution.
>
> On the other hand, I have no real problem with your suggestion, if you
> think it simplifies things.

Okay, I see your point.  I don't have a strong opinion on this.  It just
appears to me that it's simply easier to visualize a network portal with
an
IP address, than with a higher abstraction (DNS name) possibly resolving
into multiple IP addresses.

<JLH>
With your discussion below, I think I'm coming to agree with you on this.
It might as well stay as simple as possible.
</JLH>


Your description however, of a virtual network portal spanning multiple
NICs
doesn't come across in the current Network Portal definition, nor do I
see the
need for such a construct.  It appears to me that you could instead call
such
a virtual portal as a portal group, decomposable into a bunch of portals
each
associated with one <IPaddress+TCP port> - since the notion of a poral
group and
its identifier (tag) is already defined in iSCSI.

> </JLH>
>
....

>
> - Section 1.5.1, second para under "iSCSI Node" discussion, first
> sentence.  This
>   states that names are not required for default node access.  Is this
> still true?  I
>   thought we are  mandating InitiatorName and TargetName text key
> exchange now.
> <JLH>
> I think this will have to be massaged in the direction you're going.
> There's been some flux about this requirement.  At the moment, the
> requirement (I think) is that for full function login names are required.
> For a Discovery session, names are not.  When that gets finalized, this
> wording can be adjusted as well.

OK, I didn't realize that it's still under debate.  My personal
preference
is to mandate the exchange of iSCSI-Names always (in the login command
PDU
itself), and then differentiate a discovery session only based on the
SessionType key - unless some issues were discovered in NDT with this
simplistic approach.

<JLH>
However, there was a move to not require a target name for a Discovery
session since the point of that session was to discover names (and
addresses).  Hence there's talk of reserving the name "iscsi" for future
use.  I'm personally ambivalent on this one.  In either case, the words
have to reflect what is decided an that's not the case at the moment.
</JLH>

> </JLH>
>
> - Section 1.5.1, description for "Network Portal".  Suggest rewording
> the very first
>   sentence to include the  last sentence.  The current first sentence
> appears very
>   vague ("port" - TCP/SCSI/ethernet?).  Also the last sentence defines a
> network
>   portal for a target to comprise the "listening TCP port", should we
> identify what
>   it is for an initiator?
> <JLH>
> The initiator doesn't have the listening TCP port in it's network portal
> definition because the initiator doesn't listen. Once a session
> (connection) is created the listening port on the target side is out of
the
> picture and the connection goes to other ports that bind to the
connection.
> So, there is a definite asymmetry here between a target network portal
and
> an initiator network portal.

Agreed, I am not arguing for symmetry in my comment.  I was merely
pointing out
the non-definition of what you just mentioned in the last sentence as
"initiator
network portal"!

<JLH>
So a definition of initiator network portal is a network portal with just
an ip address and no listening port.
</JLH>


> </JLH>
>
> - The picture shown at the beginning of section 1.5 does not show TCP
> port
>   being part of the Network Portal on the initiator side.  Is it then
> implied that
>   only the IP address constitues a Network Portal for an initiator iSCSI
> Node?
> <JLH>
> See the previous comment.

Yup, I was hinting that what's implied by the picture could be the
answer
to my own previous question on "initiator network portal".  Just wanted
to
confirm.

> </JLH>
>
> - Section 1.5.2, last para.  This defines the I-T nexus as the session
> for iSCSI.
>   This doesn't suggest a nexus identifier - is it the four tuple
> <InitiatorName,
>   ISID, TargetName, portal group tag> or the SSID <ISID, TSID>?  Or is
> it both
>   - the four-tuple being nexus id at the SCSI layer, and the latter at
> the iSCSI
>   layer?
> <JLH>
> There really is no strong need to define a nexus identifier as it never
> really surfaces anywhere in the protocol.  There are two choices for the
> identifier, one is the 4-tuple you suggest (the one with target portal
> group tag), the other is the two names together with the session ID.  The
> first builds a nexus identifier from the identifiers of the two SCSI
ports
> involved.  The other builds the nexus identifier from protocol layer
things
> (TSID, in particular which does not identify a SCSI port).   The
importance
> of the nexus identifier is really an internal implementation issue.  We
can
> call it either one.  For the moment, I'd lean towards the first option,
but
> SAM-3 (the future) may think that the second is a better choice.
> </JLH>
>

I agree that nexus identifier appears more an implementation issue.  The
only
reason I thought it might make sense for iSCSI to call it out is because
of
draft's reference to "parallel nexus" (comment below).  My immediate
inclination
was to say "two nexus are parallel if their nexus identifiers are the
same" -
that led to this query on what's a legitimate nexus id for an
implementation
in order to ensure that it doesn't establish parallel nexus during
runtime.

<JLH>
I'm not sure if your quoted definition is going to be the case when SAM-3
evolves, or it may be that that's exactly what the definition will be.  Who
knows!  There are two choices for a definition of parallel nexus (a) nexus
identifiers are the same (b) between the same two SCSI ports. For our SAM-2
purposes, I don't think it matters.  And I don't have a problem with either
definition.  They come out the same in both cases, so long as we have a
definition of I_T nexus identifier as using the target portal group tag.
</JLH>

BTW, my understanding of an I-T nexus has been that it's a two-tuple -
<initiator SCSI port-identifier, target SCSI port-identifier>.  So, I
guess I'd
agree with your first option, since iSCSI defines port identfiers the
same as
port names.

<JLH>
Well, that's a good definition of I_T nexus identifier but a nexus is a
"relationship" not a name/identifier... :-{)
</JLH>

....

>
> - Section 1.5.3, third para.  This mentions the term "parallel nexus".
> I assume
>   the equivalence of two 4-tuples is what is being implied here.  Unless
> this term
>   is already defined in some latest SCSI documents, I suggest defining
> this as
>   such.
> <JLH>
> It's not defined in any SCSI documents because it's never been physically
> possible before!  A definition in my mind would be "two nexus are
parallel
> if they are independent relationships between the same two SCSI ports"
(or
> something like this).
> </JLH>
>
> - Section 1.5.2 does not comment on if iSCSI mandates the support of
> SCSI Port names
>   for iSCSI initiators (the requirement appears only the iSCSI targets
> para).
>   I assume it is mandatory.
> <JLH>
> I'm not sure what you're asking for here.  Perhaps this is just a
misplaces
> sentence.  SAM-2 now has the notion defined of SCSI port names and the
> protocol can define what they are and if they are mandatory.  I'm sort of
> assumed that by defining what they are (for the initiator as iSCSI
> Name+ISID and for the target as iSCSI Name+Portal group tag) that they
are
> implied to be mandatory.
>
> Did I miss something?
> </JLH>

Sorry, I was referring to a post-rev07 word doc on the plane for typing
up these
comments.  Your guess is probably right - that it is a misplaced
sentence.  The
document that I was referring to explicitly states that iSCSI mandates
SCSI Device
name support and SCSI Port name support - except it put the latter
requirement
in the SCSI target port discussion.

>
> - The following initiator requirement:
> "The iSCSI Name should be configurable parameter of each initiator
> portal group."
>    would be more clear if stated as (if this is a correct
> interpretation):
> "All the initiator portal groups of one iSCSI Node MUST share the same
>  iSCSI-Node name."
> <JLH>
> Yeah, that's pretty much a requirement, in that if the names are
different,
> then the portal groups are not in the same iSCSI node.  What this
sentence
> (and the related sentences) are aiming for is less of a requirement (this
> is a more recent understanding that hasn't made it into text yet) than a
> prefered common API for people building hardware.  If my host has
multiple
> iSCSI hardware cards, in order that they coordinate the same iSCSI node
> concept, then they should get their iSCSI name from outside -- i.e., be
> configurable.  This is not a hard requirement because each could act on
its
> own as separate iSCSI node.  Unfortunately, that management/configuration
> nightmare in FC is what this sentence is hoping to preclude.  We need to
> find the right words to back away from this as a hard requirement and
more
> as request to implementors that this be available.

I completely agree with these sentiments.  My suggested sentence does
not
preclude implementors from defining one iSCSI Node per HBA, only that
they
share the same iSCSI-Name *if* they decide to act together as one iSCSI
Node.
I don't see that as any different from what you described above...

So, I guess the question is: do you see it as a hard requirement *if*
multiple
portal groups are implemented as one iSCSI Node?  My take is "yes",
hence the
suggestion.

<JLH>
Yes, I think I agree here.  But there are subtleties in how we word this.
We have to make sure the words don't preclude a network portal functioning
on behalf of multiple iSCSI nodes.  Perhaps if we can make it clear that a
network portal can live in multiple portal groups, but a portal group only
belongs to one iSCSI node, then we're OK.

The other issue is the notion of an implementation requirement.  If the
model says "portal groups are in the same node if and only if they expose
the same iSCSI name", then there isn't any other implementation choice so
no explicit requirement is needed.  If one says Bob and one says Alice,
then they are in different Nodes, but if they both say Bob, then they are
in the same node.  The questions are more of "why do they say the name they
say? where does the name come from? how can I get the name to live at the
OS-image layer? ...".  So the intent of this sentence in the draft is to
encourage configuration APIs from outside the hw so that an OS can have a
single node image.  That's not a hard requirement really.

I think we're on the same page here as far as the model is concerned.  I
think we're both fishing for words that meet the "upper level" view of what
the name should be attached to, so that we get the functionality we want.

I'll keep these thoughts in mind when reviewing the draft for alternative
wording.
</JLH>



Similar comments apply for other suggestions below.  Please comment.

>
> The same logic applies to the ISID and TSID partitioning, though in a
> somewhat different way.  There are two assumptions that are at the root
of
> this rule: (a) no parallel nexus and (b) the session identifier for a
> session is unique between two given iSCSI nodes.  The partitioning rules
> (if implemented by the hw cards as an API) enable the least amount of
> coordination required among different hw components.  For example, to
> enforce (b), the target portal groups don't need to share the set of SIDs
> that are active. They each own a portion of the name space and can use
that
> as they wish, regardless of what's happening on the other portal groups.
> For (a), if the ISID name space is partitioned, then no two initiator
> portal groups would ever attempt a login with the same target portal
group
> reusing the same ISID (so fewer rejected login's because the target
portal
> group is enforcing the ISID rule).
>
> In short, (and I'm the first to admit this), we need very different
> language to convey this idea.  It's more a "request to implementors" to
> make life easy for everybody (easier management, easier target
> implementations, fewer rejected logins, etc.) than it is a hard
> requirement.  The two assumptions above and the resulting ISID RULE are
> requirements.  The others are facilitators to that end.
> </JLH>
>
>    Similar comments apply for the target requirement.
> - The following initiator requirement:
> "The ISID name space of the iSCSI Initiator should be partitioned among
> the initiator
>  portal groups."
>    would be better stated as (if this is a correct interpretation):
> "All initiator portal groups of one iSCSI Node MUST share an ISID name
> space
>  for sessions established to one iSCSI target node.  Sessions
> established to
>  multiple iSCSI target nodes MAY share one ISID name space."
> <JLH>
> As I've indicated above, this is only part of the equation.  The ISID
name
> space is already scoped by the iSCSI Name.   The issue is facilitating
> enforcement of the ISID rule and minimal cross hw implementations.
> </JLH>
>
> - The following target requirement:
> "The TSID name space of the iSCSI Target should be partitioned among the
> target
> portal groups."
>    would be better stated as (if this is a correct interpretation):
> "All target portal groups of one iSCSI Node MUST share an TSID name
> space for
> sessions established to one iSCSI initiator node.  Sessions established
> to
> multiple iSCSI initiator nodes MAY share one TSID name space."
> <JLH>
> See previous two comments.
> </JLH>
>
> --
> Mallikarjun
>
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> MS 5668 Hewlett-Packard, Roseville.
> cbm@rose.hp.com





From owner-ips@ece.cmu.edu  Wed Aug 15 12:25:53 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25199
	for <ips-archive@odin.ietf.org>; Wed, 15 Aug 2001 12:25:52 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7FG1G300024
	for ips-outgoing; Wed, 15 Aug 2001 12:01:16 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from erie.mcdata.com (mcgate.mcdata.com [144.49.1.5])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7FG1De00018
	for <ips@ece.cmu.edu>; Wed, 15 Aug 2001 12:01:13 -0400 (EDT)
Received: by erie.mcdata.com with Internet Mail Service (5.5.2653.19)
	id <QS9RDS50>; Wed, 15 Aug 2001 10:01:05 -0600
Message-ID: <F23E86F16912534DA9FA8937CFD7CA7402DF389A@exchange5.mcdata.com>
From: Ryan McGraw <Ryan.McGraw@mcdata.com>
To: "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
Subject: REMOVE
Date: Wed, 15 Aug 2001 10:01:04 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-ips@ece.cmu.edu
Precedence: bulk




From owner-ips@ece.cmu.edu  Wed Aug 15 14:33:28 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28686
	for <ips-archive@odin.ietf.org>; Wed, 15 Aug 2001 14:33:28 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7FHRGM04599
	for ips-outgoing; Wed, 15 Aug 2001 13:27:16 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from internaut.com ([64.38.134.99])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7FHREe04594
	for <ips@ece.cmu.edu>; Wed, 15 Aug 2001 13:27:14 -0400 (EDT)
Received: from localhost (aboba@localhost)
	by internaut.com (8.9.3/8.9.3) with ESMTP id KAA06622;
	Wed, 15 Aug 2001 10:18:44 -0700 (PDT)
	(envelope-from aboba@internaut.com)
Date: Wed, 15 Aug 2001 10:18:44 -0700 (PDT)
From: Bernard Aboba <aboba@internaut.com>
To: Sandeep Joshi <sandeepj@research.bell-labs.com>
cc: Black_David@emc.com, ips@ece.cmu.edu
Subject: Re: IPS: Schedule and Security Update
In-Reply-To: <3B7A9372.388A60B1@research.bell-labs.com>
Message-ID: <Pine.BSF.4.21.0108151011280.6615-100000@internaut.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

> Given the newly being-proposed rekeying solutions, how does 
> "mandatory to implement" translate in terms of the iSCSI 
> clients (initiators), where the same box might have some
> or all of the following :
> (a) a host OS with IPSec stack from vendor A
> (b) an iSCSI HBA from vendor B
> (c) an IPsec accelerator from vendor C
> 

How this will work depends on how the iSCSI HBA is configured within the
system. In some cases it may be configured as a disk driver, and therefore
will not act as an interface withint he system. In this case it  will not
be able to utilize the IPsec stack on the host, or the IPsec accelerator
hardware installed on another NIC. Such HBAs would need to have their own
IPsec and IKE implementations. 

However, it is also possible to have a NIC capable of handling TCP & IPsec
offload, as well as iSCSI. Such a NIC could utilize the IKE residing on
the host for keying, while accelerating cryptographic operations and
calculations such as the TCP checksum and iSCSI CRC. This effectively
merges categories b and c above.


> Second question : how would we run iSCSI over NAT if we are
> to use transport mode ESP, given all the problems 
> pointed out by Aboba in 
> http://www.ietf.org/internet-drafts/draft-ietf-ipsec-nat-reqts-00.txt
> 

The solution is either the IPsec/NAT functionality (in the general case
where you have more than one initiator behind a NAT), or IPsec tunnel mode
(which can work if there is only one initiator behind the NAT). IPsec/NAT
compatibility is now an IPsec WG work item. 



From owner-ips@ece.cmu.edu  Wed Aug 15 14:33:54 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28699
	for <ips-archive@odin.ietf.org>; Wed, 15 Aug 2001 14:33:54 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7FHdAj05267
	for ips-outgoing; Wed, 15 Aug 2001 13:39:10 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from atlrel7.hp.com (atlrel7.hp.com [192.151.27.9])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7FHd9e05263
	for <ips@ece.cmu.edu>; Wed, 15 Aug 2001 13:39:09 -0400 (EDT)
Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100])
	by atlrel7.hp.com (Postfix) with ESMTP
	id 7C7431F532; Wed, 15 Aug 2001 13:37:53 -0400 (EDT)
Received: (from cbm@localhost) by core.rose.hp.com (8.8.6 (PHNE_14041)/8.8.6 SMKit7.02) id KAA19544; Wed, 15 Aug 2001 10:40:17 -0700 (PDT)
Message-Id: <200108151740.KAA19544@core.rose.hp.com>
Subject: Re: iSCSI: rev07 - ISID-TSID & naming comments
To: hafner@almaden.ibm.com
Date: Wed, 15 Aug 2001 10:40:16 PDT
Cc: ips@ece.cmu.edu
In-Reply-To: <OF321C4C6A.07C5E3E0-ON88256AA9.0052B44C@boulder.ibm.com>; from "Jim Hafner" at Aug 15, 101 9:10 am
Reply-To: cbm@rose.hp.com
From: "Mallikarjun C." <cbm@rose.hp.com>
X-Mailer: Elm [revision: 212.4]
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Jim,

As you say, I too think we are very close on this.  Let me comment
on one sentence in your message that I didn't quite follow.

>Perhaps if we can make it clear that a
>network portal can live in multiple portal groups, but a portal group only
>belongs to one iSCSI node, then we're OK.

Two comments -
- My understanding of portal groups has been that they are disjoint
  sets, and that's the reason a session could not span multiple portal
  groups.  You seem to suggest that portal groups are overlapping sets
  with possibly common network portals, or did I misunderstand?

- By saying "a portal group only belongs to one iSCSI node", if you 
  are implying that the scope of the portal group tags is per iSCSI
  node (i.e. the tags are unique and meaningful within one iSCSI node),
  then I am fine.  I just want to confirm that you are not excluding the
  possibility of one *physical* portal group (say an HBA) being able
  to get to multiple (virtual) iSCSI nodes.

Regards.
--
Mallikarjun 


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


>
>Mallikarjun,
>
>We are very close on this stuff.   A few more comments inline.
>
>Jim Hafner
>
>
>"Mallikarjun C." <cbm@rose.hp.com> on 08/14/2001 03:38:53 pm
>
>Please respond to cbm@rose.hp.com
>
>To:   Jim Hafner/Almaden/IBM@IBMUS
>cc:   ips@ece.cmu.edu
>Subject:  Re: iSCSI: rev07 - ISID-TSID & naming comments
>
>
>
>Jim,
>
>Thanks for the quick response.  I agree with most of your responses.
>However, some comments below on your responses.
>
>Regards.
>--
>Mallikarjun
>
>Mallikarjun Chadalapaka
>Networked Storage Architecture
>Network Storage Solutions Organization
>MS 5668 Hewlett-Packard, Roseville.
>cbm@rose.hp.com
>
>Jim Hafner wrote:
>>
>.....
>
>> - Section 2.11.4, first sentence.  "The TSID is an initiator identifying
>> tag
>>   set by the target." s/b with "The TSID is a target-defined tag
>> assigned to
>>   an initiator SCSI port.".
>> <JLH>
>> This is actually an incorrect interpretation.  In the model we (I) am
>> proposing, the TSID has nothing to do with identifying either the target
>or
>> initiator SCSI port.  It is a tag used by the target (iSCSI target) to
>help
>> identify a session *along with the ISID* of that session.  In the model,
>> the TSID plays no role in the SCSI layer.
>
>I agree with what you state, but I don't quite see why the suggested
>sentence
>violates this philosophy.  If you substitute "<InitiatorName+ISID>" for
>the
>phrase "initiator SCSI port" (since they are the same) in my suggested
>sentence,
>that's essentially what you state above...  Did I miss something?
>
><JLH>
>Not to be too technical, but the two quoted things aren't actually the
>same, one is the name/identifier for the other, but that's nit-picky.  Now
>that I re-read your sentence a couple of times, I think I have a better
>understanding of where you're going with it and I have less problem with
>it.  Though it is literally correct in that the target does assign it and
>it ends up pairing with an initiator SCSI port, I think I'm bothered by the
>implication that this is a SCSI level tag.  It's really just an iSCSI level
>tag, and so is more naturally paired with the I-Name+ISID to identify a
>session.  So, I'd prefer (but not strongly) "The TSID is a target-defined
>tag assigned to a session to identity that session along with the initiator
>Name and ISID" or something like that.  My point is that it's there to
>identify the iSCSI session and is independent of the SAM-iSCSI mapping.
>But I won't get bent out of shape if the words you propose are used.
></JLH>
>
>>
>> This sentence needs clarification.
>> </JLH>
>>
>> - Section 1.5, para 1, "Network portals (IP names, addresses and TCP
>> ports)"
>>   Suggest dropping "IP names" since what really matters is just the IP
>> addresses
>>   and TCP ports.  IIRC, two DNS names can resolve to the same IP
>> address, and one
>>   DNS name can resolve to multiple IP addresses.
>> <JLH>
>> But IPnames (because of DNS) can be perfectly good identifiers for
>Network
>> portals.  The network portal can be virtual (shared across many nics that
>> have different IP addresses) or physical (used by a single nic that has a
>> unique address).  It all depends on the mapping.  The point here (and it
>> isn't that critical a point) is that I can initiate a connection to a
>> network portal (say in software) by openning a socket to a given
>> "IPnamed:tcpport" combination and let the lower layers deal with address
>> resolution.
>>
>> On the other hand, I have no real problem with your suggestion, if you
>> think it simplifies things.
>
>Okay, I see your point.  I don't have a strong opinion on this.  It just
>appears to me that it's simply easier to visualize a network portal with
>an
>IP address, than with a higher abstraction (DNS name) possibly resolving
>into multiple IP addresses.
>
><JLH>
>With your discussion below, I think I'm coming to agree with you on this.
>It might as well stay as simple as possible.
></JLH>
>
>
>Your description however, of a virtual network portal spanning multiple
>NICs
>doesn't come across in the current Network Portal definition, nor do I
>see the
>need for such a construct.  It appears to me that you could instead call
>such
>a virtual portal as a portal group, decomposable into a bunch of portals
>each
>associated with one <IPaddress+TCP port> - since the notion of a poral
>group and
>its identifier (tag) is already defined in iSCSI.
>
>> </JLH>
>>
>....
>
>>
>> - Section 1.5.1, second para under "iSCSI Node" discussion, first
>> sentence.  This
>>   states that names are not required for default node access.  Is this
>> still true?  I
>>   thought we are  mandating InitiatorName and TargetName text key
>> exchange now.
>> <JLH>
>> I think this will have to be massaged in the direction you're going.
>> There's been some flux about this requirement.  At the moment, the
>> requirement (I think) is that for full function login names are required.
>> For a Discovery session, names are not.  When that gets finalized, this
>> wording can be adjusted as well.
>
>OK, I didn't realize that it's still under debate.  My personal
>preference
>is to mandate the exchange of iSCSI-Names always (in the login command
>PDU
>itself), and then differentiate a discovery session only based on the
>SessionType key - unless some issues were discovered in NDT with this
>simplistic approach.
>
><JLH>
>However, there was a move to not require a target name for a Discovery
>session since the point of that session was to discover names (and
>addresses).  Hence there's talk of reserving the name "iscsi" for future
>use.  I'm personally ambivalent on this one.  In either case, the words
>have to reflect what is decided an that's not the case at the moment.
></JLH>
>
>> </JLH>
>>
>> - Section 1.5.1, description for "Network Portal".  Suggest rewording
>> the very first
>>   sentence to include the  last sentence.  The current first sentence
>> appears very
>>   vague ("port" - TCP/SCSI/ethernet?).  Also the last sentence defines a
>> network
>>   portal for a target to comprise the "listening TCP port", should we
>> identify what
>>   it is for an initiator?
>> <JLH>
>> The initiator doesn't have the listening TCP port in it's network portal
>> definition because the initiator doesn't listen. Once a session
>> (connection) is created the listening port on the target side is out of
>the
>> picture and the connection goes to other ports that bind to the
>connection.
>> So, there is a definite asymmetry here between a target network portal
>and
>> an initiator network portal.
>
>Agreed, I am not arguing for symmetry in my comment.  I was merely
>pointing out
>the non-definition of what you just mentioned in the last sentence as
>"initiator
>network portal"!
>
><JLH>
>So a definition of initiator network portal is a network portal with just
>an ip address and no listening port.
></JLH>
>
>
>> </JLH>
>>
>> - The picture shown at the beginning of section 1.5 does not show TCP
>> port
>>   being part of the Network Portal on the initiator side.  Is it then
>> implied that
>>   only the IP address constitues a Network Portal for an initiator iSCSI
>> Node?
>> <JLH>
>> See the previous comment.
>
>Yup, I was hinting that what's implied by the picture could be the
>answer
>to my own previous question on "initiator network portal".  Just wanted
>to
>confirm.
>
>> </JLH>
>>
>> - Section 1.5.2, last para.  This defines the I-T nexus as the session
>> for iSCSI.
>>   This doesn't suggest a nexus identifier - is it the four tuple
>> <InitiatorName,
>>   ISID, TargetName, portal group tag> or the SSID <ISID, TSID>?  Or is
>> it both
>>   - the four-tuple being nexus id at the SCSI layer, and the latter at
>> the iSCSI
>>   layer?
>> <JLH>
>> There really is no strong need to define a nexus identifier as it never
>> really surfaces anywhere in the protocol.  There are two choices for the
>> identifier, one is the 4-tuple you suggest (the one with target portal
>> group tag), the other is the two names together with the session ID.  The
>> first builds a nexus identifier from the identifiers of the two SCSI
>ports
>> involved.  The other builds the nexus identifier from protocol layer
>things
>> (TSID, in particular which does not identify a SCSI port).   The
>importance
>> of the nexus identifier is really an internal implementation issue.  We
>can
>> call it either one.  For the moment, I'd lean towards the first option,
>but
>> SAM-3 (the future) may think that the second is a better choice.
>> </JLH>
>>
>
>I agree that nexus identifier appears more an implementation issue.  The
>only
>reason I thought it might make sense for iSCSI to call it out is because
>of
>draft's reference to "parallel nexus" (comment below).  My immediate
>inclination
>was to say "two nexus are parallel if their nexus identifiers are the
>same" -
>that led to this query on what's a legitimate nexus id for an
>implementation
>in order to ensure that it doesn't establish parallel nexus during
>runtime.
>
><JLH>
>I'm not sure if your quoted definition is going to be the case when SAM-3
>evolves, or it may be that that's exactly what the definition will be.  Who
>knows!  There are two choices for a definition of parallel nexus (a) nexus
>identifiers are the same (b) between the same two SCSI ports. For our SAM-2
>purposes, I don't think it matters.  And I don't have a problem with either
>definition.  They come out the same in both cases, so long as we have a
>definition of I_T nexus identifier as using the target portal group tag.
></JLH>
>
>BTW, my understanding of an I-T nexus has been that it's a two-tuple -
><initiator SCSI port-identifier, target SCSI port-identifier>.  So, I
>guess I'd
>agree with your first option, since iSCSI defines port identfiers the
>same as
>port names.
>
><JLH>
>Well, that's a good definition of I_T nexus identifier but a nexus is a
>"relationship" not a name/identifier... :-{)
></JLH>
>
>....
>
>>
>> - Section 1.5.3, third para.  This mentions the term "parallel nexus".
>> I assume
>>   the equivalence of two 4-tuples is what is being implied here.  Unless
>> this term
>>   is already defined in some latest SCSI documents, I suggest defining
>> this as
>>   such.
>> <JLH>
>> It's not defined in any SCSI documents because it's never been physically
>> possible before!  A definition in my mind would be "two nexus are
>parallel
>> if they are independent relationships between the same two SCSI ports"
>(or
>> something like this).
>> </JLH>
>>
>> - Section 1.5.2 does not comment on if iSCSI mandates the support of
>> SCSI Port names
>>   for iSCSI initiators (the requirement appears only the iSCSI targets
>> para).
>>   I assume it is mandatory.
>> <JLH>
>> I'm not sure what you're asking for here.  Perhaps this is just a
>misplaces
>> sentence.  SAM-2 now has the notion defined of SCSI port names and the
>> protocol can define what they are and if they are mandatory.  I'm sort of
>> assumed that by defining what they are (for the initiator as iSCSI
>> Name+ISID and for the target as iSCSI Name+Portal group tag) that they
>are
>> implied to be mandatory.
>>
>> Did I miss something?
>> </JLH>
>
>Sorry, I was referring to a post-rev07 word doc on the plane for typing
>up these
>comments.  Your guess is probably right - that it is a misplaced
>sentence.  The
>document that I was referring to explicitly states that iSCSI mandates
>SCSI Device
>name support and SCSI Port name support - except it put the latter
>requirement
>in the SCSI target port discussion.
>
>>
>> - The following initiator requirement:
>> "The iSCSI Name should be configurable parameter of each initiator
>> portal group."
>>    would be more clear if stated as (if this is a correct
>> interpretation):
>> "All the initiator portal groups of one iSCSI Node MUST share the same
>>  iSCSI-Node name."
>> <JLH>
>> Yeah, that's pretty much a requirement, in that if the names are
>different,
>> then the portal groups are not in the same iSCSI node.  What this
>sentence
>> (and the related sentences) are aiming for is less of a requirement (this
>> is a more recent understanding that hasn't made it into text yet) than a
>> prefered common API for people building hardware.  If my host has
>multiple
>> iSCSI hardware cards, in order that they coordinate the same iSCSI node
>> concept, then they should get their iSCSI name from outside -- i.e., be
>> configurable.  This is not a hard requirement because each could act on
>its
>> own as separate iSCSI node.  Unfortunately, that management/configuration
>> nightmare in FC is what this sentence is hoping to preclude.  We need to
>> find the right words to back away from this as a hard requirement and
>more
>> as request to implementors that this be available.
>
>I completely agree with these sentiments.  My suggested sentence does
>not
>preclude implementors from defining one iSCSI Node per HBA, only that
>they
>share the same iSCSI-Name *if* they decide to act together as one iSCSI
>Node.
>I don't see that as any different from what you described above...
>
>So, I guess the question is: do you see it as a hard requirement *if*
>multiple
>portal groups are implemented as one iSCSI Node?  My take is "yes",
>hence the
>suggestion.
>
><JLH>
>Yes, I think I agree here.  But there are subtleties in how we word this.
>We have to make sure the words don't preclude a network portal functioning
>on behalf of multiple iSCSI nodes.  Perhaps if we can make it clear that a
>network portal can live in multiple portal groups, but a portal group only
>belongs to one iSCSI node, then we're OK.
>
>The other issue is the notion of an implementation requirement.  If the
>model says "portal groups are in the same node if and only if they expose
>the same iSCSI name", then there isn't any other implementation choice so
>no explicit requirement is needed.  If one says Bob and one says Alice,
>then they are in different Nodes, but if they both say Bob, then they are
>in the same node.  The questions are more of "why do they say the name they
>say? where does the name come from? how can I get the name to live at the
>OS-image layer? ...".  So the intent of this sentence in the draft is to
>encourage configuration APIs from outside the hw so that an OS can have a
>single node image.  That's not a hard requirement really.
>
>I think we're on the same page here as far as the model is concerned.  I
>think we're both fishing for words that meet the "upper level" view of what
>the name should be attached to, so that we get the functionality we want.
>
>I'll keep these thoughts in mind when reviewing the draft for alternative
>wording.
></JLH>
>
>
>
>Similar comments apply for other suggestions below.  Please comment.
>
>>
>> The same logic applies to the ISID and TSID partitioning, though in a
>> somewhat different way.  There are two assumptions that are at the root
>of
>> this rule: (a) no parallel nexus and (b) the session identifier for a
>> session is unique between two given iSCSI nodes.  The partitioning rules
>> (if implemented by the hw cards as an API) enable the least amount of
>> coordination required among different hw components.  For example, to
>> enforce (b), the target portal groups don't need to share the set of SIDs
>> that are active. They each own a portion of the name space and can use
>that
>> as they wish, regardless of what's happening on the other portal groups.
>> For (a), if the ISID name space is partitioned, then no two initiator
>> portal groups would ever attempt a login with the same target portal
>group
>> reusing the same ISID (so fewer rejected login's because the target
>portal
>> group is enforcing the ISID rule).
>>
>> In short, (and I'm the first to admit this), we need very different
>> language to convey this idea.  It's more a "request to implementors" to
>> make life easy for everybody (easier management, easier target
>> implementations, fewer rejected logins, etc.) than it is a hard
>> requirement.  The two assumptions above and the resulting ISID RULE are
>> requirements.  The others are facilitators to that end.
>> </JLH>
>>
>>    Similar comments apply for the target requirement.
>> - The following initiator requirement:
>> "The ISID name space of the iSCSI Initiator should be partitioned among
>> the initiator
>>  portal groups."
>>    would be better stated as (if this is a correct interpretation):
>> "All initiator portal groups of one iSCSI Node MUST share an ISID name
>> space
>>  for sessions established to one iSCSI target node.  Sessions
>> established to
>>  multiple iSCSI target nodes MAY share one ISID name space."
>> <JLH>
>> As I've indicated above, this is only part of the equation.  The ISID
>name
>> space is already scoped by the iSCSI Name.   The issue is facilitating
>> enforcement of the ISID rule and minimal cross hw implementations.
>> </JLH>
>>
>> - The following target requirement:
>> "The TSID name space of the iSCSI Target should be partitioned among the
>> target
>> portal groups."
>>    would be better stated as (if this is a correct interpretation):
>> "All target portal groups of one iSCSI Node MUST share an TSID name
>> space for
>> sessions established to one iSCSI initiator node.  Sessions established
>> to
>> multiple iSCSI initiator nodes MAY share one TSID name space."
>> <JLH>
>> See previous two comments.
>> </JLH>
>>
>> --
>> Mallikarjun
>>
>> Mallikarjun Chadalapaka
>> Networked Storage Architecture
>> Network Storage Solutions Organization
>> MS 5668 Hewlett-Packard, Roseville.
>> cbm@rose.hp.com
>
>
>




From owner-ips@ece.cmu.edu  Wed Aug 15 15:50:24 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00072
	for <ips-archive@odin.ietf.org>; Wed, 15 Aug 2001 15:50:23 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7FIgag08885
	for ips-outgoing; Wed, 15 Aug 2001 14:42:36 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7FIgVe08871
	for <ips@ece.cmu.edu>; Wed, 15 Aug 2001 14:42:31 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA23838;
	Wed, 15 Aug 2001 14:40:20 -0400
Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7FIgAR223848;
	Wed, 15 Aug 2001 12:42:24 -0600
Importance: Normal
Subject: Re: iSCSI: rev07 - ISID-TSID & naming comments
To: cbm@rose.hp.com
Cc: ips@ece.cmu.edu
From: "Jim Hafner" <hafner@almaden.ibm.com>
Date: Wed, 15 Aug 2001 11:42:08 -0700
Message-ID: <OF0608E573.03B1B416-ON88256AA9.0061F6BB@boulder.ibm.com>
X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at
 08/15/2001 11:42:23 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Mallikarjun,

My "text" again isn't conveying what I'm thinking, but yours is closer.  I
want the model to allow physical things to span multiple virtual things.
What I was trying to convey is exactly what you're saying.  Is it more
clear if I had said "can live in multiple portal groups *so long as each
portal group was in a different node*"?  But I want a network portal (be it
either physical or virtual) to "connect up" to different nodes (through
unique portal groups on each node).

If a network portal has only one ipaddress/[tcpport], it can service
multiple nodes, but belong to only one portal group per node.  So, maybe
this multi-node (focused on only one network portal) picture helps:

    NodeA           NodeB          NodeC
      |               |              |
PortalGroupA1   PortalGroupB2  PortalGroupC1
      |               |              |
      |_________NetworkPortalX_______|
            (Ipaddress/[tcpport])


The picture doesn't show other portal groups that might be in any of the
nodes nor does it show other network portals that might be in any of the
portal groups.   This is the tree view from a given network portal up.
The up-degree at the network portal can be anything.  The up-degree of each
portal group is one.  There's a different view from the node down.   In the
node-down graph, I can have any number of portal groups below a node and
any number of network portals in each portal group.  The rule is that this
graph is a tree.

And the model allows the leaf structure of one node-down tree to be related
in any way to the leaf structure of another node-down tree.  [I'm finding
it hard to describe this clearly.]  By example:  suppose that PortalGroupA1
above had another NetworkPortalY in it (within NodeA).  This network portal
need not be in PortalGroupB2 of NodeB just because NetworkPortalX was in
PortalGroupB2 .  So the fact that two leaves of one node-down tree are in
one portal group (have a common parent) does not require those two leaves
to be in the same portal group (have a common parent) of another node-down
tree.

Did I make any thing more clear or just muddle things up?

And yes, the scope of the portal group tag is the node.

The tricky part in this is the viewpoint.  If you think only one node at a
time, then the node-down tree is easy enough to describe.  It's when you
try to put more nodes in the picture that the relationships get more
complicated.   I'm not even sure it's possible in 2D to render in one graph
the full set of possibilities even with two nodes!

Jim Hafner


"Mallikarjun C." <cbm@rose.hp.com> on 08/15/2001 10:40:16 am

Please respond to cbm@rose.hp.com

To:   Jim Hafner/Almaden/IBM@IBMUS
cc:   ips@ece.cmu.edu
Subject:  Re: iSCSI: rev07 - ISID-TSID & naming comments



Jim,

As you say, I too think we are very close on this.  Let me comment
on one sentence in your message that I didn't quite follow.

>Perhaps if we can make it clear that a
>network portal can live in multiple portal groups, but a portal group only
>belongs to one iSCSI node, then we're OK.

Two comments -
- My understanding of portal groups has been that they are disjoint
  sets, and that's the reason a session could not span multiple portal
  groups.  You seem to suggest that portal groups are overlapping sets
  with possibly common network portals, or did I misunderstand?

- By saying "a portal group only belongs to one iSCSI node", if you
  are implying that the scope of the portal group tags is per iSCSI
  node (i.e. the tags are unique and meaningful within one iSCSI node),
  then I am fine.  I just want to confirm that you are not excluding the
  possibility of one *physical* portal group (say an HBA) being able
  to get to multiple (virtual) iSCSI nodes.

Regards.
--
Mallikarjun


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


>
>Mallikarjun,
>
>We are very close on this stuff.   A few more comments inline.
>
>Jim Hafner
>
>
>"Mallikarjun C." <cbm@rose.hp.com> on 08/14/2001 03:38:53 pm
>
>Please respond to cbm@rose.hp.com
>
>To:   Jim Hafner/Almaden/IBM@IBMUS
>cc:   ips@ece.cmu.edu
>Subject:  Re: iSCSI: rev07 - ISID-TSID & naming comments
>
>
>
>Jim,
>
>Thanks for the quick response.  I agree with most of your responses.
>However, some comments below on your responses.
>
>Regards.
>--
>Mallikarjun
>
>Mallikarjun Chadalapaka
>Networked Storage Architecture
>Network Storage Solutions Organization
>MS 5668 Hewlett-Packard, Roseville.
>cbm@rose.hp.com
>
>Jim Hafner wrote:
>>
>.....
>
>> - Section 2.11.4, first sentence.  "The TSID is an initiator identifying
>> tag
>>   set by the target." s/b with "The TSID is a target-defined tag
>> assigned to
>>   an initiator SCSI port.".
>> <JLH>
>> This is actually an incorrect interpretation.  In the model we (I) am
>> proposing, the TSID has nothing to do with identifying either the target
>or
>> initiator SCSI port.  It is a tag used by the target (iSCSI target) to
>help
>> identify a session *along with the ISID* of that session.  In the model,
>> the TSID plays no role in the SCSI layer.
>
>I agree with what you state, but I don't quite see why the suggested
>sentence
>violates this philosophy.  If you substitute "<InitiatorName+ISID>" for
>the
>phrase "initiator SCSI port" (since they are the same) in my suggested
>sentence,
>that's essentially what you state above...  Did I miss something?
>
><JLH>
>Not to be too technical, but the two quoted things aren't actually the
>same, one is the name/identifier for the other, but that's nit-picky.  Now
>that I re-read your sentence a couple of times, I think I have a better
>understanding of where you're going with it and I have less problem with
>it.  Though it is literally correct in that the target does assign it and
>it ends up pairing with an initiator SCSI port, I think I'm bothered by
the
>implication that this is a SCSI level tag.  It's really just an iSCSI
level
>tag, and so is more naturally paired with the I-Name+ISID to identify a
>session.  So, I'd prefer (but not strongly) "The TSID is a target-defined
>tag assigned to a session to identity that session along with the
initiator
>Name and ISID" or something like that.  My point is that it's there to
>identify the iSCSI session and is independent of the SAM-iSCSI mapping.
>But I won't get bent out of shape if the words you propose are used.
></JLH>
>
>>
>> This sentence needs clarification.
>> </JLH>
>>
>> - Section 1.5, para 1, "Network portals (IP names, addresses and TCP
>> ports)"
>>   Suggest dropping "IP names" since what really matters is just the IP
>> addresses
>>   and TCP ports.  IIRC, two DNS names can resolve to the same IP
>> address, and one
>>   DNS name can resolve to multiple IP addresses.
>> <JLH>
>> But IPnames (because of DNS) can be perfectly good identifiers for
>Network
>> portals.  The network portal can be virtual (shared across many nics
that
>> have different IP addresses) or physical (used by a single nic that has
a
>> unique address).  It all depends on the mapping.  The point here (and it
>> isn't that critical a point) is that I can initiate a connection to a
>> network portal (say in software) by openning a socket to a given
>> "IPnamed:tcpport" combination and let the lower layers deal with address
>> resolution.
>>
>> On the other hand, I have no real problem with your suggestion, if you
>> think it simplifies things.
>
>Okay, I see your point.  I don't have a strong opinion on this.  It just
>appears to me that it's simply easier to visualize a network portal with
>an
>IP address, than with a higher abstraction (DNS name) possibly resolving
>into multiple IP addresses.
>
><JLH>
>With your discussion below, I think I'm coming to agree with you on this.
>It might as well stay as simple as possible.
></JLH>
>
>
>Your description however, of a virtual network portal spanning multiple
>NICs
>doesn't come across in the current Network Portal definition, nor do I
>see the
>need for such a construct.  It appears to me that you could instead call
>such
>a virtual portal as a portal group, decomposable into a bunch of portals
>each
>associated with one <IPaddress+TCP port> - since the notion of a poral
>group and
>its identifier (tag) is already defined in iSCSI.
>
>> </JLH>
>>
>....
>
>>
>> - Section 1.5.1, second para under "iSCSI Node" discussion, first
>> sentence.  This
>>   states that names are not required for default node access.  Is this
>> still true?  I
>>   thought we are  mandating InitiatorName and TargetName text key
>> exchange now.
>> <JLH>
>> I think this will have to be massaged in the direction you're going.
>> There's been some flux about this requirement.  At the moment, the
>> requirement (I think) is that for full function login names are
required.
>> For a Discovery session, names are not.  When that gets finalized, this
>> wording can be adjusted as well.
>
>OK, I didn't realize that it's still under debate.  My personal
>preference
>is to mandate the exchange of iSCSI-Names always (in the login command
>PDU
>itself), and then differentiate a discovery session only based on the
>SessionType key - unless some issues were discovered in NDT with this
>simplistic approach.
>
><JLH>
>However, there was a move to not require a target name for a Discovery
>session since the point of that session was to discover names (and
>addresses).  Hence there's talk of reserving the name "iscsi" for future
>use.  I'm personally ambivalent on this one.  In either case, the words
>have to reflect what is decided an that's not the case at the moment.
></JLH>
>
>> </JLH>
>>
>> - Section 1.5.1, description for "Network Portal".  Suggest rewording
>> the very first
>>   sentence to include the  last sentence.  The current first sentence
>> appears very
>>   vague ("port" - TCP/SCSI/ethernet?).  Also the last sentence defines a
>> network
>>   portal for a target to comprise the "listening TCP port", should we
>> identify what
>>   it is for an initiator?
>> <JLH>
>> The initiator doesn't have the listening TCP port in it's network portal
>> definition because the initiator doesn't listen. Once a session
>> (connection) is created the listening port on the target side is out of
>the
>> picture and the connection goes to other ports that bind to the
>connection.
>> So, there is a definite asymmetry here between a target network portal
>and
>> an initiator network portal.
>
>Agreed, I am not arguing for symmetry in my comment.  I was merely
>pointing out
>the non-definition of what you just mentioned in the last sentence as
>"initiator
>network portal"!
>
><JLH>
>So a definition of initiator network portal is a network portal with just
>an ip address and no listening port.
></JLH>
>
>
>> </JLH>
>>
>> - The picture shown at the beginning of section 1.5 does not show TCP
>> port
>>   being part of the Network Portal on the initiator side.  Is it then
>> implied that
>>   only the IP address constitues a Network Portal for an initiator iSCSI
>> Node?
>> <JLH>
>> See the previous comment.
>
>Yup, I was hinting that what's implied by the picture could be the
>answer
>to my own previous question on "initiator network portal".  Just wanted
>to
>confirm.
>
>> </JLH>
>>
>> - Section 1.5.2, last para.  This defines the I-T nexus as the session
>> for iSCSI.
>>   This doesn't suggest a nexus identifier - is it the four tuple
>> <InitiatorName,
>>   ISID, TargetName, portal group tag> or the SSID <ISID, TSID>?  Or is
>> it both
>>   - the four-tuple being nexus id at the SCSI layer, and the latter at
>> the iSCSI
>>   layer?
>> <JLH>
>> There really is no strong need to define a nexus identifier as it never
>> really surfaces anywhere in the protocol.  There are two choices for the
>> identifier, one is the 4-tuple you suggest (the one with target portal
>> group tag), the other is the two names together with the session ID.
The
>> first builds a nexus identifier from the identifiers of the two SCSI
>ports
>> involved.  The other builds the nexus identifier from protocol layer
>things
>> (TSID, in particular which does not identify a SCSI port).   The
>importance
>> of the nexus identifier is really an internal implementation issue.  We
>can
>> call it either one.  For the moment, I'd lean towards the first option,
>but
>> SAM-3 (the future) may think that the second is a better choice.
>> </JLH>
>>
>
>I agree that nexus identifier appears more an implementation issue.  The
>only
>reason I thought it might make sense for iSCSI to call it out is because
>of
>draft's reference to "parallel nexus" (comment below).  My immediate
>inclination
>was to say "two nexus are parallel if their nexus identifiers are the
>same" -
>that led to this query on what's a legitimate nexus id for an
>implementation
>in order to ensure that it doesn't establish parallel nexus during
>runtime.
>
><JLH>
>I'm not sure if your quoted definition is going to be the case when SAM-3
>evolves, or it may be that that's exactly what the definition will be.
Who
>knows!  There are two choices for a definition of parallel nexus (a) nexus
>identifiers are the same (b) between the same two SCSI ports. For our
SAM-2
>purposes, I don't think it matters.  And I don't have a problem with
either
>definition.  They come out the same in both cases, so long as we have a
>definition of I_T nexus identifier as using the target portal group tag.
></JLH>
>
>BTW, my understanding of an I-T nexus has been that it's a two-tuple -
><initiator SCSI port-identifier, target SCSI port-identifier>.  So, I
>guess I'd
>agree with your first option, since iSCSI defines port identfiers the
>same as
>port names.
>
><JLH>
>Well, that's a good definition of I_T nexus identifier but a nexus is a
>"relationship" not a name/identifier... :-{)
></JLH>
>
>....
>
>>
>> - Section 1.5.3, third para.  This mentions the term "parallel nexus".
>> I assume
>>   the equivalence of two 4-tuples is what is being implied here.  Unless
>> this term
>>   is already defined in some latest SCSI documents, I suggest defining
>> this as
>>   such.
>> <JLH>
>> It's not defined in any SCSI documents because it's never been
physically
>> possible before!  A definition in my mind would be "two nexus are
>parallel
>> if they are independent relationships between the same two SCSI ports"
>(or
>> something like this).
>> </JLH>
>>
>> - Section 1.5.2 does not comment on if iSCSI mandates the support of
>> SCSI Port names
>>   for iSCSI initiators (the requirement appears only the iSCSI targets
>> para).
>>   I assume it is mandatory.
>> <JLH>
>> I'm not sure what you're asking for here.  Perhaps this is just a
>misplaces
>> sentence.  SAM-2 now has the notion defined of SCSI port names and the
>> protocol can define what they are and if they are mandatory.  I'm sort
of
>> assumed that by defining what they are (for the initiator as iSCSI
>> Name+ISID and for the target as iSCSI Name+Portal group tag) that they
>are
>> implied to be mandatory.
>>
>> Did I miss something?
>> </JLH>
>
>Sorry, I was referring to a post-rev07 word doc on the plane for typing
>up these
>comments.  Your guess is probably right - that it is a misplaced
>sentence.  The
>document that I was referring to explicitly states that iSCSI mandates
>SCSI Device
>name support and SCSI Port name support - except it put the latter
>requirement
>in the SCSI target port discussion.
>
>>
>> - The following initiator requirement:
>> "The iSCSI Name should be configurable parameter of each initiator
>> portal group."
>>    would be more clear if stated as (if this is a correct
>> interpretation):
>> "All the initiator portal groups of one iSCSI Node MUST share the same
>>  iSCSI-Node name."
>> <JLH>
>> Yeah, that's pretty much a requirement, in that if the names are
>different,
>> then the portal groups are not in the same iSCSI node.  What this
>sentence
>> (and the related sentences) are aiming for is less of a requirement
(this
>> is a more recent understanding that hasn't made it into text yet) than a
>> prefered common API for people building hardware.  If my host has
>multiple
>> iSCSI hardware cards, in order that they coordinate the same iSCSI node
>> concept, then they should get their iSCSI name from outside -- i.e., be
>> configurable.  This is not a hard requirement because each could act on
>its
>> own as separate iSCSI node.  Unfortunately, that
management/configuration
>> nightmare in FC is what this sentence is hoping to preclude.  We need to
>> find the right words to back away from this as a hard requirement and
>more
>> as request to implementors that this be available.
>
>I completely agree with these sentiments.  My suggested sentence does
>not
>preclude implementors from defining one iSCSI Node per HBA, only that
>they
>share the same iSCSI-Name *if* they decide to act together as one iSCSI
>Node.
>I don't see that as any different from what you described above...
>
>So, I guess the question is: do you see it as a hard requirement *if*
>multiple
>portal groups are implemented as one iSCSI Node?  My take is "yes",
>hence the
>suggestion.
>
><JLH>
>Yes, I think I agree here.  But there are subtleties in how we word this.
>We have to make sure the words don't preclude a network portal functioning
>on behalf of multiple iSCSI nodes.  Perhaps if we can make it clear that a
>network portal can live in multiple portal groups, but a portal group only
>belongs to one iSCSI node, then we're OK.
>
>The other issue is the notion of an implementation requirement.  If the
>model says "portal groups are in the same node if and only if they expose
>the same iSCSI name", then there isn't any other implementation choice so
>no explicit requirement is needed.  If one says Bob and one says Alice,
>then they are in different Nodes, but if they both say Bob, then they are
>in the same node.  The questions are more of "why do they say the name
they
>say? where does the name come from? how can I get the name to live at the
>OS-image layer? ...".  So the intent of this sentence in the draft is to
>encourage configuration APIs from outside the hw so that an OS can have a
>single node image.  That's not a hard requirement really.
>
>I think we're on the same page here as far as the model is concerned.  I
>think we're both fishing for words that meet the "upper level" view of
what
>the name should be attached to, so that we get the functionality we want.
>
>I'll keep these thoughts in mind when reviewing the draft for alternative
>wording.
></JLH>
>
>
>
>Similar comments apply for other suggestions below.  Please comment.
>
>>
>> The same logic applies to the ISID and TSID partitioning, though in a
>> somewhat different way.  There are two assumptions that are at the root
>of
>> this rule: (a) no parallel nexus and (b) the session identifier for a
>> session is unique between two given iSCSI nodes.  The partitioning rules
>> (if implemented by the hw cards as an API) enable the least amount of
>> coordination required among different hw components.  For example, to
>> enforce (b), the target portal groups don't need to share the set of
SIDs
>> that are active. They each own a portion of the name space and can use
>that
>> as they wish, regardless of what's happening on the other portal groups.
>> For (a), if the ISID name space is partitioned, then no two initiator
>> portal groups would ever attempt a login with the same target portal
>group
>> reusing the same ISID (so fewer rejected login's because the target
>portal
>> group is enforcing the ISID rule).
>>
>> In short, (and I'm the first to admit this), we need very different
>> language to convey this idea.  It's more a "request to implementors" to
>> make life easy for everybody (easier management, easier target
>> implementations, fewer rejected logins, etc.) than it is a hard
>> requirement.  The two assumptions above and the resulting ISID RULE are
>> requirements.  The others are facilitators to that end.
>> </JLH>
>>
>>    Similar comments apply for the target requirement.
>> - The following initiator requirement:
>> "The ISID name space of the iSCSI Initiator should be partitioned among
>> the initiator
>>  portal groups."
>>    would be better stated as (if this is a correct interpretation):
>> "All initiator portal groups of one iSCSI Node MUST share an ISID name
>> space
>>  for sessions established to one iSCSI target node.  Sessions
>> established to
>>  multiple iSCSI target nodes MAY share one ISID name space."
>> <JLH>
>> As I've indicated above, this is only part of the equation.  The ISID
>name
>> space is already scoped by the iSCSI Name.   The issue is facilitating
>> enforcement of the ISID rule and minimal cross hw implementations.
>> </JLH>
>>
>> - The following target requirement:
>> "The TSID name space of the iSCSI Target should be partitioned among the
>> target
>> portal groups."
>>    would be better stated as (if this is a correct interpretation):
>> "All target portal groups of one iSCSI Node MUST share an TSID name
>> space for
>> sessions established to one iSCSI initiator node.  Sessions established
>> to
>> multiple iSCSI initiator nodes MAY share one TSID name space."
>> <JLH>
>> See previous two comments.
>> </JLH>
>>
>> --
>> Mallikarjun
>>
>> Mallikarjun Chadalapaka
>> Networked Storage Architecture
>> Network Storage Solutions Organization
>> MS 5668 Hewlett-Packard, Roseville.
>> cbm@rose.hp.com
>
>
>







From owner-ips@ece.cmu.edu  Wed Aug 15 16:43:53 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00760
	for <ips-archive@odin.ietf.org>; Wed, 15 Aug 2001 16:43:53 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7FJT8911688
	for ips-outgoing; Wed, 15 Aug 2001 15:29:08 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7FJT6e11678
	for <ips@ece.cmu.edu>; Wed, 15 Aug 2001 15:29:06 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id VAA257034
	for <ips@ece.cmu.edu>; Wed, 15 Aug 2001 21:28:59 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7FJSwM56278
	for <ips@ece.cmu.edu>; Wed, 15 Aug 2001 21:28:58 +0200
Importance: Normal
Subject: iSCSI Re: Questions on iSCSI 07
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF29D402EC.4B72154A-ONC2256AA9.00521DA5@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Wed, 15 Aug 2001 22:28:35 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 15/08/2001 22:28:58
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Comments in text - thanks - Julo

"Lee Xing" <lxing@Crossroads.com>@ece.cmu.edu on 15-08-2001 17:27:17

Please respond to "Lee Xing" <lxing@Crossroads.com>

Sent by:  owner-ips@ece.cmu.edu


To:   <ips@ece.cmu.edu>
cc:
Subject:  Questions on iSCSI 07



Hi All,

I have a few questions on iSCSI 07.  I would appreciate it if someone
could explain them.

Thank you.


Lee Xing
Sr. Software Engineer
Crossroads Systems, Inc.

----------------------------------------------
Q1:
Page 104: "Operational parameters MAY be negotiated outside (after) the
login phase."
Page 157: "Some session specific parameters MUST be carried only on the
leading connection and cannot be changed after the leading connection
login..."

If operational parameters are considered as session parameters, then
should we reword the sentence on page 104, such as "Some operational
parameters MAY be negotiated outside (after) the login phase."?


+++ will fix +++
----------------------------------------------
Q2:
Page 22: "Any PDU except login and text, which is sent on a TCP
connection before this connection gets into full feature phase, is a
protocol error."

Page 169: "To make use of SendTargets, an initiator must first be logged
in to one of two types of targets."

Since SendTargets is one of the keys for Text Cmds, and we can't issue
it before logging in, we probably should reword the sentence on page 22.

+++ will read:

Any PDU except login and text, which is sent on a TCP connection before
this connection gets into full feature phase, is a protocol error. Some
text command parameters also allowed only in full feature phase (e.g.,
SendTargets).

++++
----------------------------------------------
Q3: Page 169: "If it logs in to any other target, the session the
session can be either a discovery session or a normal operational
session".  Should we delete one "the session" from this sentence?
+++
??? can't find it
+++
----------------------------------------------
Q4: Why don't section 1.2.2.1 & 1.2.2.2 address where CmdSN & StatSN
should start from (0, 1, or whatever) explicitly like DataSN does?
Should we initialize the counters before start the process?
+++ third paragraph of 1.2.2.1 says now
Commands in transit from the initiator to the target layer are numbered by
iSCSI; the number is carried by the iSCSI PDU as CmdSN
(Command-Sequence-Number).  The numbering is session-wide and starts with a
value set by the initiator during the first login of a session (leading
login).

and 1.2.2.2 gstates:

   The first login response includes an initial value for status numbering.

 +++
----------------------------------------------
Q5: Page 102: "An operational parameter negotiation on a connection
SHOULD not start before the security/integrity negotiation if such a
negotiation exists.  Operational parameters negotiated inadvertently
before the security/integrity negotiation MAY be reset after the
security/integrity negotiation at the explicit request of the initiator
or target."

The question is under which circumstance do we need to negotiate
operational parameters before security/integrity negotiation?  If it's
unlikely to happen, why do we leave a potential security hole here?
+++ this will be clarified in an upcoming writeup
+++
----------------------------------------------
Q6:
Page 21: "... ... If an initiator and target are connected through more
than one session, both the initiator and target perceive the other as a
different entity on each session (a different I_T nexus in SAM-2
parlance)."

Page 69: "When a target is detecting an attempt to open a new session by
the same initiator (same InitiatorName and ISID) it MUST check if the
old session is active.  If it is not the old-session must be reset by
the target and the new session established. Otherwise the Login MUST be
terminated with a Login Response."

The sentence on page 21 tells us multi-sessions between an initiator and
a target are allowed; while the sentence on page 69 implies they are
not.  We probably need to clear it a bit.
+++ No it tells you that the target must check if the old connections are
still alive.  If they are this attempt is an error. If they are not the
target has not realized the old session has gone away (e.g. a client
reboot). I reformulate as:

   When a target is detecting an attempt to open a new session by the same
   SCSI initiator port (same InitiatorName and ISID) to the same target
   portal group it MUST check if the old session is still active.  If it is
   not active and the target has failed to realize that the old-session
   must be reset by the target and the new session established. Otherwise
   the Login MUST be terminated with a Login Response of "Session already
   open with this initiator".
   ++++

----------------------------------------------
Q7:
Page 69: "When a target is detecting an attempt to open a new session by
the same initiator (same InitiatorName and ISID) it MUST check if the
old session is active.  If it is not the old-session must be reset by
the target and the new session established. Otherwise the Login MUST be
terminated with a Login Response."

What does "reset" exactly mean here?

+++ clean its internal state - remove anything non-persistent data related
to the old session
+++
----------------------------------------------
Q8: This question is on multi-path.  Suppose two NICs are connected to
the same target, therefore we could have at least two target addresses
a1 & a2.  Suppose address a1 needs to be dedicated to a particular
initiator I1.  Is it OK if we let the target to hide a1 from (i.e. not
sending a1 with "SendTargets" cmd response to) all initiators except I1,
or do we need to modify 07 to do so?

The current Standard 07 on page 171 says "If a SendTargets response
reports an iSCSI address for a target, it SHOULD also report all other
addresses in its portal group in the same response."

+++ It is OK to hide the NIC. Portal groups are meant for groups of
physical ports that MAY share state+++
----------------------------------------------
Q9:  This is a performance-related question.

After the first (leading) connection logs into a normal operational
session, why can't the same initiator have an option to just "spawn"
more "full featured" connections with the same target without running
Login handshake processes (i.e. authenticate the parties, negotiate the
session's parameters, open security associations protocol and make
connections as belonging to a session) again.  It would be more
efficient if we could have this option.

It seems feasible because:

  - it's not necessary to authenticate both parties
    again after doing so on the first (leading)
    connection.
  - security is still possessed without running
    Login process on the following connections
    because the first (leading) connection has to
    run Login process, and no extra connections
    can be spawned without logging into the first
    one.
  - session parameters, generally, are the same
    for connections within a session.  If not, they
    can be re-negotiated later.
  - All connections within a session belong to
    the same I_T nexus.
  - Text Cmds can be used to "spawn" full-featured
    connections without adding too much stuff into
    iSCSI Standard or making it too complex.


+++  I don't understand exactly what you are suggesting here. Every TCP
connection raises the authentication issue (parties can't be sure that
simple things like IP addresses are not spoofed. More complicted things
(shared secrets) could be used and we looked at them in the past and did
not find that it is worth pursuing them. And different connections may have
different security requirements (a private line vs. a public line).
++++





From owner-ips@ece.cmu.edu  Wed Aug 15 18:02:54 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01968
	for <ips-archive@odin.ietf.org>; Wed, 15 Aug 2001 18:02:54 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7FKsha16372
	for ips-outgoing; Wed, 15 Aug 2001 16:54:43 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from va2mc.ummailbox.net (va2mc.ummailbox.net [64.210.247.23])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7FKsfe16367
	for <ips@ece.cmu.edu>; Wed, 15 Aug 2001 16:54:41 -0400 (EDT)
Received: from hqmailweb.COMMSTOR.Crossroads.com (HQMailWeb.Crossroads.com [63.237.99.250:25])
	by va2mc.ummailbox.net with ESMTP id V0815-1654-6fbd00;
	Wed, 15 Aug 2001 20:54:32 GMT
Received: from HQMAILNODE1.COMMSTOR.Crossroads.com ([10.5.1.42]) by hqmailweb.COMMSTOR.Crossroads.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Wed, 15 Aug 2001 15:54:31 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
Subject: RE: iSCSI Re: Questions on iSCSI 07
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Disposition-Notification-To: "Lee Xing" <lxing@Crossroads.com>
Date: Wed, 15 Aug 2001 15:54:31 -0500
Message-ID: <CFD808D1D39ACB47ABFF586D484CC52E341419@HQMAILNODE1.COMMSTOR.Crossroads.com>
Thread-Topic: iSCSI Re: Questions on iSCSI 07
Thread-Index: AcElxNhjuJGrZO3KTses4xAqH08B7AAArTWw
From: "Lee Xing" <lxing@Crossroads.com>
To: "Julian Satran" <Julian_Satran@il.ibm.com>
Cc: <ips@ece.cmu.edu>
X-OriginalArrivalTime: 15 Aug 2001 20:54:31.0779 (UTC) FILETIME=[7B733B30:01C125CC]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f7FKsfe16368
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit

Julian,

Thank you for the info.  It helps.
Please see my comments bellow.

Regards,


Lee Xing
Sr. Software Engineer
Crossroads Systems, Inc.


-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, August 15, 2001 2:29 PM
To: ips@ece.cmu.edu
Subject: iSCSI Re: Questions on iSCSI 07

----------------------------------------------
Q3: Page 169: "If it logs in to any other target, the session the
session can be either a discovery session or a normal operational
session".  Should we delete one "the session" from this sentence?
+++
??? can't find it
+++

I just downloaded a fresh copy from
http://www.haifa.il.ibm.com/satran/ips/
On page 169, it says:

        "To make use of SendTargets, an initiator must first be logged
in to 
        one of two types of targets.  If the initiator is logged in to
the 
        default target (target name "iSCSI"), the only session type that
it 
        can be used is a discovery session. If it logs in to any other 
        target, the session the session can be either a discovery
session or 
        a normal operational session."

There two "the session"s there.
----------------------------------------------
Q4: Why don't section 1.2.2.1 & 1.2.2.2 address where CmdSN & StatSN
should start from (0, 1, or whatever) explicitly like DataSN does?
Should we initialize the counters before start the process?
+++ third paragraph of 1.2.2.1 says now
Commands in transit from the initiator to the target layer are numbered
by
iSCSI; the number is carried by the iSCSI PDU as CmdSN
(Command-Sequence-Number).  The numbering is session-wide and starts
with a
value set by the initiator during the first login of a session (leading
login).

and 1.2.2.2 gstates:

   The first login response includes an initial value for status
numbering.

 +++

Can the initiator use any integer number during the first login of a
session (leading login)?

----------------------------------------------


From owner-ips@ece.cmu.edu  Wed Aug 15 18:03:10 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01990
	for <ips-archive@odin.ietf.org>; Wed, 15 Aug 2001 18:03:10 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7FLGCd17633
	for ips-outgoing; Wed, 15 Aug 2001 17:16:12 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from va2mc.ummailbox.net (va2mc.ummailbox.net [64.210.247.19])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7FLG9e17623
	for <ips@ece.cmu.edu>; Wed, 15 Aug 2001 17:16:09 -0400 (EDT)
Received: from hqmailweb.COMMSTOR.Crossroads.com (HQMailWeb.Crossroads.com [63.237.99.250:25])
	by va2mc.ummailbox.net with ESMTP id M0815-1716-2a1101;
	Wed, 15 Aug 2001 21:16:06 GMT
Received: from HQMAILNODE1.COMMSTOR.Crossroads.com ([10.5.1.42]) by hqmailweb.COMMSTOR.Crossroads.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Wed, 15 Aug 2001 16:16:04 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
Subject: iSCSI:  Rev 07 Comments
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Wed, 15 Aug 2001 16:16:04 -0500
Message-ID: <CFD808D1D39ACB47ABFF586D484CC52E1393B8@HQMAILNODE1.COMMSTOR.Crossroads.com>
Thread-Topic: iSCSI:  Rev 07 Comments
Thread-Index: AcElz33Sge8roh+pQy6iGq/FMCXl3Q==
From: "Bill Moody" <bmoody@Crossroads.com>
To: "IP Storage Mailing List (E-mail)" <ips@ece.cmu.edu>
Cc: "Robert Griswold" <rgriswold@Crossroads.com>,
        "Bill Moody" <bmoody@Crossroads.com>
X-OriginalArrivalTime: 15 Aug 2001 21:16:04.0649 (UTC) FILETIME=[7E0F8990:01C125CF]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f7FLGAe17624
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit

I have a couple of points I'd like to raise concerning the 07 version of
the document.

Section 1.5.3.  On page 39, under 'iSCSI Initiator Requirements' the
term initiator portal group is used multiple times.  This is the first
use of this term and led to some confusion on my part.  The 'portal
group' term was clearly defined earlier and was used repeatedly in
connection with the target but no mention has been made of the use of
initiator portal groups prior to this point.  The ISID RULE clearly
defines that only one session with a given ISID can exist between a
given iSCSI Initiator and iSCSI Target Portal Group - it doesn't mention
initiator portal groups.  It would be nice to define this 'initiator
portal group' term prior to its use.

Appendix A.  What is the meaning of the value '11EDC6F41' in the table?
Is this the generator polynomial that is discussed in the following
paragraph?  If so, it is not clear.

Thanks,

Bill Moody
Architect
Crossroads Systems, Inc.
Phone:  (512) 928-7238
Fax:  (512)-928-7402



From owner-ips@ece.cmu.edu  Wed Aug 15 18:48:12 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02411
	for <ips-archive@odin.ietf.org>; Wed, 15 Aug 2001 18:48:12 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7FM1hE20186
	for ips-outgoing; Wed, 15 Aug 2001 18:01:43 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7FM1fe20181
	for <ips@ece.cmu.edu>; Wed, 15 Aug 2001 18:01:41 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA35142;
	Wed, 15 Aug 2001 17:59:32 -0400
Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7FM1bR156418;
	Wed, 15 Aug 2001 16:01:37 -0600
Importance: Normal
Subject: Re: iSCSI: Rev 07 Comments
To: "Bill Moody" <bmoody@Crossroads.com>
Cc: ips@ece.cmu.edu
From: "Jim Hafner" <hafner@almaden.ibm.com>
Date: Wed, 15 Aug 2001 15:01:35 -0700
Message-ID: <OF5CEE8976.757877B5-ON88256AA9.0077F757@boulder.ibm.com>
X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at
 08/15/2001 03:01:36 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Bill,

As a work-in-progress, my apologies for the confusion.

The iSCSI model defines portal groups as collections of network portals
that can coordinate (at it's end) multiple connections within a session.
That's true for the initiator side and the target side.  I had thought that
the defintion was initiator/target agnostic (I'll have to go back and read
it again, in context).

Keep in mind that there are two models playing here, the iSCSI model and
the SAM/SCSI model.   Portal groups are constructs of the iSCSI model and
are symmetric with respect to initiator or target.  The only non-symmetry
at the iSCSI level is in the identifiers for network portals.  Target
network portals have to have an ipaddress AND a listening tcpport (server
socket).  Initiator network portals don't "listen", so they only have
ipaddresses.

It so happens that as we've proposed the SAM/SCSI model overlay on iSCSI
constructs, only the target portal group plays a role; the initiator portal
group is "invisible" to the SAM/SCSI model.    Hence, the lack of emphasis
on the initiator portal group.  There is definite asymmetry here and we've
tried to justify the value in that in other postings.   When we get to
"initiator requirements", we start having to mention them for other reasons
(as has been discussed in other threads);  namely, where they get there
iSCSI Name and the ISID namespace they use.

Does that help?  And yes, this whole stuff will need a couple more careful
reading/rewritings to get it all correct and clear.

Jim Hafner


"Bill Moody" <bmoody@Crossroads.com>@ece.cmu.edu on 08/15/2001 02:16:04 pm

Sent by:  owner-ips@ece.cmu.edu


To:   "IP Storage Mailing List (E-mail)" <ips@ece.cmu.edu>
cc:   "Robert Griswold" <rgriswold@Crossroads.com>, "Bill Moody"
      <bmoody@Crossroads.com>
Subject:  iSCSI:  Rev 07 Comments



I have a couple of points I'd like to raise concerning the 07 version of
the document.

Section 1.5.3.  On page 39, under 'iSCSI Initiator Requirements' the
term initiator portal group is used multiple times.  This is the first
use of this term and led to some confusion on my part.  The 'portal
group' term was clearly defined earlier and was used repeatedly in
connection with the target but no mention has been made of the use of
initiator portal groups prior to this point.  The ISID RULE clearly
defines that only one session with a given ISID can exist between a
given iSCSI Initiator and iSCSI Target Portal Group - it doesn't mention
initiator portal groups.  It would be nice to define this 'initiator
portal group' term prior to its use.

Appendix A.  What is the meaning of the value '11EDC6F41' in the table?
Is this the generator polynomial that is discussed in the following
paragraph?  If so, it is not clear.

Thanks,

Bill Moody
Architect
Crossroads Systems, Inc.
Phone:  (512) 928-7238
Fax:  (512)-928-7402






From owner-ips@ece.cmu.edu  Wed Aug 15 18:50:47 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02445
	for <ips-archive@odin.ietf.org>; Wed, 15 Aug 2001 18:50:46 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7FLqkv19761
	for ips-outgoing; Wed, 15 Aug 2001 17:52:46 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail4.tor.primus.ca (mx-backup.primus.ca [216.254.136.135])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7FLqie19756
	for <ips@ece.cmu.edu>; Wed, 15 Aug 2001 17:52:44 -0400 (EDT)
Received: from dsl-216-254-190-93.tor.primus.ca ([216.254.190.93] helo=perfisan4)
	by mail4.tor.primus.ca with smtp (Exim 2.11 #1)
	id 15X8aN-0002aa-07
	for ips@ece.cmu.edu; Wed, 15 Aug 2001 17:52:23 -0400
Reply-To: <tnguyen@perfisans.com>
From: "Trang Nguyen" <tnguyen@perfisans.com>
To: "IPS" <ips@ece.cmu.edu>
Subject: iSCSI: Multiple connections questions
Date: Wed, 15 Aug 2001 17:55:48 -0400
Message-ID: <BNEALKHNNHCOIGPENKKMOEAGCBAA.tnguyen@perfisans.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi all,

I have some questions about iSCSI multiple connections.

1.  In the iSCSI version 07, it mentions that iSCSI supports multiple
connections within a session.  In which case or condition, multiple
connections are required or necessary because I can't find any example that
I would need to make more than 1 connection between the Initiator and the
Target?

2.  Who makes the decision to add or remove the connection, iSCSI or Upper
layer?

3.  The CID appears only in the Login Command.  How does iSCSI know which
connection it should send the SCSI Command/ Data to?

I'd appreciate it very much for your answers.

Regards,

*********************************
 Trang Nguyen
 tnguyen@perfisans.com
*********************************




From owner-ips@ece.cmu.edu  Wed Aug 15 18:50:50 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02456
	for <ips-archive@odin.ietf.org>; Wed, 15 Aug 2001 18:50:50 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7FMPwL21340
	for ips-outgoing; Wed, 15 Aug 2001 18:25:58 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail4.tor.primus.ca (mx-backup.primus.ca [216.254.136.135])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7FMPue21336
	for <ips@ece.cmu.edu>; Wed, 15 Aug 2001 18:25:56 -0400 (EDT)
Received: from dsl-216-254-190-93.tor.primus.ca ([216.254.190.93] helo=perfisan4)
	by mail4.tor.primus.ca with smtp (Exim 2.11 #1)
	id 15X96k-0000Ik-07; Wed, 15 Aug 2001 18:25:50 -0400
Reply-To: <tnguyen@perfisans.com>
From: "Trang Nguyen" <tnguyen@perfisans.com>
To: "Julian Satran" <Julian_Satran@il.ibm.com>, <ips@ece.cmu.edu>
Subject: RE: iSCSI Re: Questions on iSCSI 07
Date: Wed, 15 Aug 2001 18:29:14 -0400
Message-ID: <BNEALKHNNHCOIGPENKKMAEAICBAA.tnguyen@perfisans.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
In-Reply-To: <OF29D402EC.4B72154A-ONC2256AA9.00521DA5@telaviv.ibm.com>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Julian,

I have a question on Lee's Q7 and your answer.

If the old session is still alive, does it mean that there is at least one
connection between the initiator and the target.  If it is true, then to
reset the old session the target also has to disconnect all the connections
in the old session, except the connection of the Login Command.


========================================================================
Q7:
Page 69: "When a target is detecting an attempt to open a new session by
the same initiator (same InitiatorName and ISID) it MUST check if the
old session is active.  If it is not the old-session must be reset by
the target and the new session established. Otherwise the Login MUST be
terminated with a Login Response."

What does "reset" exactly mean here?

+++ clean its internal state - remove anything non-persistent data related
to the old session
+++
============================================================================


Thanks,

*********************************
 Trang Nguyen
 tnguyen@perfisans.com
*********************************


-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Julian Satran
Sent: August 15, 2001 3:29 PM
To: ips@ece.cmu.edu
Subject: iSCSI Re: Questions on iSCSI 07



Comments in text - thanks - Julo

"Lee Xing" <lxing@Crossroads.com>@ece.cmu.edu on 15-08-2001 17:27:17

Please respond to "Lee Xing" <lxing@Crossroads.com>

Sent by:  owner-ips@ece.cmu.edu


To:   <ips@ece.cmu.edu>
cc:
Subject:  Questions on iSCSI 07



Hi All,

I have a few questions on iSCSI 07.  I would appreciate it if someone
could explain them.

Thank you.


Lee Xing
Sr. Software Engineer
Crossroads Systems, Inc.

----------------------------------------------
Q1:
Page 104: "Operational parameters MAY be negotiated outside (after) the
login phase."
Page 157: "Some session specific parameters MUST be carried only on the
leading connection and cannot be changed after the leading connection
login..."

If operational parameters are considered as session parameters, then
should we reword the sentence on page 104, such as "Some operational
parameters MAY be negotiated outside (after) the login phase."?


+++ will fix +++
----------------------------------------------
Q2:
Page 22: "Any PDU except login and text, which is sent on a TCP
connection before this connection gets into full feature phase, is a
protocol error."

Page 169: "To make use of SendTargets, an initiator must first be logged
in to one of two types of targets."

Since SendTargets is one of the keys for Text Cmds, and we can't issue
it before logging in, we probably should reword the sentence on page 22.

+++ will read:

Any PDU except login and text, which is sent on a TCP connection before
this connection gets into full feature phase, is a protocol error. Some
text command parameters also allowed only in full feature phase (e.g.,
SendTargets).

++++
----------------------------------------------
Q3: Page 169: "If it logs in to any other target, the session the
session can be either a discovery session or a normal operational
session".  Should we delete one "the session" from this sentence?
+++
??? can't find it
+++
----------------------------------------------
Q4: Why don't section 1.2.2.1 & 1.2.2.2 address where CmdSN & StatSN
should start from (0, 1, or whatever) explicitly like DataSN does?
Should we initialize the counters before start the process?
+++ third paragraph of 1.2.2.1 says now
Commands in transit from the initiator to the target layer are numbered by
iSCSI; the number is carried by the iSCSI PDU as CmdSN
(Command-Sequence-Number).  The numbering is session-wide and starts with a
value set by the initiator during the first login of a session (leading
login).

and 1.2.2.2 gstates:

   The first login response includes an initial value for status numbering.

 +++
----------------------------------------------
Q5: Page 102: "An operational parameter negotiation on a connection
SHOULD not start before the security/integrity negotiation if such a
negotiation exists.  Operational parameters negotiated inadvertently
before the security/integrity negotiation MAY be reset after the
security/integrity negotiation at the explicit request of the initiator
or target."

The question is under which circumstance do we need to negotiate
operational parameters before security/integrity negotiation?  If it's
unlikely to happen, why do we leave a potential security hole here?
+++ this will be clarified in an upcoming writeup
+++
----------------------------------------------
Q6:
Page 21: "... ... If an initiator and target are connected through more
than one session, both the initiator and target perceive the other as a
different entity on each session (a different I_T nexus in SAM-2
parlance)."

Page 69: "When a target is detecting an attempt to open a new session by
the same initiator (same InitiatorName and ISID) it MUST check if the
old session is active.  If it is not the old-session must be reset by
the target and the new session established. Otherwise the Login MUST be
terminated with a Login Response."

The sentence on page 21 tells us multi-sessions between an initiator and
a target are allowed; while the sentence on page 69 implies they are
not.  We probably need to clear it a bit.
+++ No it tells you that the target must check if the old connections are
still alive.  If they are this attempt is an error. If they are not the
target has not realized the old session has gone away (e.g. a client
reboot). I reformulate as:

   When a target is detecting an attempt to open a new session by the same
   SCSI initiator port (same InitiatorName and ISID) to the same target
   portal group it MUST check if the old session is still active.  If it is
   not active and the target has failed to realize that the old-session
   must be reset by the target and the new session established. Otherwise
   the Login MUST be terminated with a Login Response of "Session already
   open with this initiator".
   ++++

----------------------------------------------
Q7:
Page 69: "When a target is detecting an attempt to open a new session by
the same initiator (same InitiatorName and ISID) it MUST check if the
old session is active.  If it is not the old-session must be reset by
the target and the new session established. Otherwise the Login MUST be
terminated with a Login Response."

What does "reset" exactly mean here?

+++ clean its internal state - remove anything non-persistent data related
to the old session
+++
----------------------------------------------
Q8: This question is on multi-path.  Suppose two NICs are connected to
the same target, therefore we could have at least two target addresses
a1 & a2.  Suppose address a1 needs to be dedicated to a particular
initiator I1.  Is it OK if we let the target to hide a1 from (i.e. not
sending a1 with "SendTargets" cmd response to) all initiators except I1,
or do we need to modify 07 to do so?

The current Standard 07 on page 171 says "If a SendTargets response
reports an iSCSI address for a target, it SHOULD also report all other
addresses in its portal group in the same response."

+++ It is OK to hide the NIC. Portal groups are meant for groups of
physical ports that MAY share state+++
----------------------------------------------
Q9:  This is a performance-related question.

After the first (leading) connection logs into a normal operational
session, why can't the same initiator have an option to just "spawn"
more "full featured" connections with the same target without running
Login handshake processes (i.e. authenticate the parties, negotiate the
session's parameters, open security associations protocol and make
connections as belonging to a session) again.  It would be more
efficient if we could have this option.

It seems feasible because:

  - it's not necessary to authenticate both parties
    again after doing so on the first (leading)
    connection.
  - security is still possessed without running
    Login process on the following connections
    because the first (leading) connection has to
    run Login process, and no extra connections
    can be spawned without logging into the first
    one.
  - session parameters, generally, are the same
    for connections within a session.  If not, they
    can be re-negotiated later.
  - All connections within a session belong to
    the same I_T nexus.
  - Text Cmds can be used to "spawn" full-featured
    connections without adding too much stuff into
    iSCSI Standard or making it too complex.


+++  I don't understand exactly what you are suggesting here. Every TCP
connection raises the authentication issue (parties can't be sure that
simple things like IP addresses are not spoofed. More complicted things
(shared secrets) could be used and we looked at them in the past and did
not find that it is worth pursuing them. And different connections may have
different security requirements (a private line vs. a public line).
++++





From owner-ips@ece.cmu.edu  Wed Aug 15 19:32:40 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02992
	for <ips-archive@odin.ietf.org>; Wed, 15 Aug 2001 19:32:40 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7FMwX722806
	for ips-outgoing; Wed, 15 Aug 2001 18:58:33 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from smtp.alacritech.com (smtp.alacritech.com [209.10.208.82])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7FMwVe22802
	for <ips@ece.cmu.edu>; Wed, 15 Aug 2001 18:58:32 -0400 (EDT)
Received: from alacritech.com (woking.alacritech.com [10.1.1.70])
	by smtp.alacritech.com (8.11.0/8.11.0) with ESMTP id f7FMrBO23694;
	Wed, 15 Aug 2001 15:53:11 -0700
Message-ID: <3B7AFE96.ACCE14DF@alacritech.com>
Date: Wed, 15 Aug 2001 15:58:30 -0700
From: Steve Blightman <steve@alacritech.com>
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mbakke@cisco.com
CC: ips@ece.cmu.edu
Subject: Re: [Fwd: Crc-32c example in iSCSI spec]
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

I believe the examples for the ISCSI CRC  have the wrong endianness.

As yiou suugested over the phone I ran some Ethernet frames through a
simulation. I have some difficulty running the exact simulations you
wanted becuase the minimum size Ethernet frame is 64 bytes.

However using the Ethernet CRC polynomial,
Running 64 bytes of 0 onto the wire, we append "36 63 8d 75" onto the
wire for the CRC - "36" goes out first.
Running 64 bytes of all 1, we append "ba 87 61 0f" onto the wire - "ba"
goes out first.

Using the same logic for the ISCSI polynomial
Running 64 bytes of 0 I think we should append "67 eb c8 03" - "67"
going out first
and running 64 bytes of all 1 we should append "66 4e cd 2f" - "66"
going out first

And now for 32 bytes with the ISCSI polynomial

Running 32 bytes of 0 we should append "aa 36 91 8a" - "aa" going out
first
Running 32 bytes of all 1 we should append "43 ab a8 62" - "43" going
out first

I don't want to get into an endless endian debate, but I believe it is
important to get the order of these bytes in the right order, so that we
can use the same hardware to check as well as to generate CRCs.

Thanks for your help on this,
Steve Blightman





From owner-ips@ece.cmu.edu  Wed Aug 15 19:35:09 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03026
	for <ips-archive@odin.ietf.org>; Wed, 15 Aug 2001 19:35:09 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7FMstd22653
	for ips-outgoing; Wed, 15 Aug 2001 18:54:55 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail3.tor.primus.ca (mail.tor.primus.ca [216.254.136.21])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7FMsse22649
	for <ips@ece.cmu.edu>; Wed, 15 Aug 2001 18:54:54 -0400 (EDT)
Received: from dsl-216-254-190-93.tor.primus.ca ([216.254.190.93] helo=perfisan4)
	by mail3.tor.primus.ca with smtp (Exim 2.11 #1)
	id 15X9Yl-0003BX-06
	for ips@ece.cmu.edu; Wed, 15 Aug 2001 18:54:48 -0400
Reply-To: <tnguyen@perfisans.com>
From: "Trang Nguyen" <tnguyen@perfisans.com>
To: "IPS" <ips@ece.cmu.edu>
Subject: iSCSI 07:  Initiator Task Tag
Date: Wed, 15 Aug 2001 18:58:12 -0400
Message-ID: <BNEALKHNNHCOIGPENKKMIEAJCBAA.tnguyen@perfisans.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
In-Reply-To: <BNEALKHNNHCOIGPENKKMOEAICBAA.tnguyen@perfisans.com>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi all,

I am sorry.  I forgot to add the subject line.

Could you please help me with these questions?

1.  Is iSCSI task the same as SCSI task?

In section 1.1:

	"A SCSI task is a SCSI command or possibly a linked set of SCSI commands."

	"An iSCSI task is an iSCSI request for which a response is expected.

	In this document "iSCSI request", "iSCSI command", request or unqualified)
	command have the same meaning.  Also, unless specified otherwise, status,
	response or numbered response have the same meaning."

According to these definitions, they are different.  iSCSI task is an iSCSI
command.  If so, then is Initiator Task Tag the same as CmdSN?


2.  In iSCSI version 07:
	"2.2.2.8 Initiator Task Tag

        The initiator assigns a Task Tag to each iSCSI task that it issues.
        While a task exists this tag MUST uniquely identify it session-wide.
"

Is this Initiator Task Tag the same as the Task Tags defined in section
4.9.2 in SAM-2 (revision 19)?  As quoted from SAM-2: "An initiator assigns
tag values in each tagged task identifier in a way that ensures that the
identifier uniqueness requirements stated in 4.9 are met."

3.  How does the iSCSI target use the Initiator Task Tag to process the
commands?

Thanks a lot,

*********************************
 Trang Nguyen
 tnguyen@perfisans.com
 *********************************




From owner-ips@ece.cmu.edu  Wed Aug 15 19:36:24 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03060
	for <ips-archive@odin.ietf.org>; Wed, 15 Aug 2001 19:36:24 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7FMpd122514
	for ips-outgoing; Wed, 15 Aug 2001 18:51:39 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail4.tor.primus.ca (mx-backup.primus.ca [216.254.136.135])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7FMpbe22503
	for <ips@ece.cmu.edu>; Wed, 15 Aug 2001 18:51:37 -0400 (EDT)
Received: from dsl-216-254-190-93.tor.primus.ca ([216.254.190.93] helo=perfisan4)
	by mail4.tor.primus.ca with smtp (Exim 2.11 #1)
	id 15X9Vb-0004Ty-07
	for ips@ece.cmu.edu; Wed, 15 Aug 2001 18:51:31 -0400
Reply-To: <tnguyen@perfisans.com>
From: "Trang Nguyen" <tnguyen@perfisans.com>
To: "IPS" <ips@ece.cmu.edu>
Date: Wed, 15 Aug 2001 18:54:56 -0400
Message-ID: <BNEALKHNNHCOIGPENKKMOEAICBAA.tnguyen@perfisans.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi all,

Could you please help me with these questions?

1.  Is iSCSI task the same as SCSI task?

In section 1.1:

	"A SCSI task is a SCSI command or possibly a linked set of SCSI commands."

	"An iSCSI task is an iSCSI request for which a response is expected.

	In this document "iSCSI request", "iSCSI command", request or unqualified)
	command have the same meaning.  Also, unless specified otherwise, status,
	response or numbered response have the same meaning."

According to these definitions, they are different.  iSCSI task is an iSCSI
command.  If so, then is Initiator Task Tag the same as CmdSN?


2.  In iSCSI version 07:
	"2.2.2.8 Initiator Task Tag

        The initiator assigns a Task Tag to each iSCSI task that it issues.
        While a task exists this tag MUST uniquely identify it session-wide.
"

Is this Initiator Task Tag the same as the Task Tags defined in section
4.9.2 in SAM-2 (revision 19)?  As quoted from SAM-2: "An initiator assigns
tag values in each tagged task identifier in a way that ensures that the
identifier uniqueness requirements stated in 4.9 are met."

3.  How does the iSCSI target use the Initiator Task Tag to process the
commands?

Thanks a lot,

*********************************
 Trang Nguyen
 tnguyen@perfisans.com
 *********************************




From owner-ips@ece.cmu.edu  Wed Aug 15 19:39:12 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03089
	for <ips-archive@odin.ietf.org>; Wed, 15 Aug 2001 19:39:12 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7FMnTR22429
	for ips-outgoing; Wed, 15 Aug 2001 18:49:29 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f7FMnRe22425
	for <ips@ece.cmu.edu>; Wed, 15 Aug 2001 18:49:27 -0400 (EDT)
Received: from grubby.research.bell-labs.com ([135.104.2.9]) by crufty; Wed Aug 15 18:44:16 EDT 2001
Received: from aura.research.bell-labs.com ([135.104.46.10]) by grubby; Wed Aug 15 18:48:12 EDT 2001
Received: from research.bell-labs.com (IDENT:sandeepj@sandeepj-pcmh.research.bell-labs.com [135.104.47.90])
	by aura.research.bell-labs.com (8.9.1/8.9.1) with ESMTP id SAA28460;
	Wed, 15 Aug 2001 18:47:41 -0400 (EDT)
Message-ID: <3B7AFC0D.C4170901@research.bell-labs.com>
Date: Wed, 15 Aug 2001 18:47:41 -0400
From: Sandeep Joshi <sandeepj@research.bell-labs.com>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-3 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bernard Aboba <aboba@internaut.com>
CC: Black_David@emc.com, ips@ece.cmu.edu
Subject: Re: IPS: Schedule and Security Update
References: <Pine.BSF.4.21.0108151011280.6615-100000@internaut.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


Bernard,

Ok..so whoever claims compliance with iSCSI must provide the
new rekeying method as part of their iSCSI implementation.
Its possible that more than one such IPsec implementations 
(from different vendors) could co-exist on a given host/client.

As to the 2nd question, it was raised since the new rekeying 
schemes seem to be veering towards using transport mode 
(end-to-end security preferred) rather than tunnel mode.

David's email states:
> The SRP approach
> generates the keys outside the gateway, and there's no 
> standard protocol to insert the keys into the gateway, and 
> the IKE draft wants to use transport mode ESP instead of 
> tunnel mode (gateways generally use tunnel mode).
  
So does your answer imply that the iSCSI RFC status will depend 
on the result of the IPSec-NAT work item in the IPSec WG ?

thanks
-Sandeep

Bernard Aboba wrote:
> 
> > Given the newly being-proposed rekeying solutions, how does
> > "mandatory to implement" translate in terms of the iSCSI
> > clients (initiators), where the same box might have some
> > or all of the following :
> > (a) a host OS with IPSec stack from vendor A
> > (b) an iSCSI HBA from vendor B
> > (c) an IPsec accelerator from vendor C
> >
> 
> How this will work depends on how the iSCSI HBA is configured within the
> system. In some cases it may be configured as a disk driver, and therefore
> will not act as an interface withint he system. In this case it  will not
> be able to utilize the IPsec stack on the host, or the IPsec accelerator
> hardware installed on another NIC. Such HBAs would need to have their own
> IPsec and IKE implementations.
> 
> However, it is also possible to have a NIC capable of handling TCP & IPsec
> offload, as well as iSCSI. Such a NIC could utilize the IKE residing on
> the host for keying, while accelerating cryptographic operations and
> calculations such as the TCP checksum and iSCSI CRC. This effectively
> merges categories b and c above.
> 
> > Second question : how would we run iSCSI over NAT if we are
> > to use transport mode ESP, given all the problems
> > pointed out by Aboba in
> > http://www.ietf.org/internet-drafts/draft-ietf-ipsec-nat-reqts-00.txt
> >
> 
> The solution is either the IPsec/NAT functionality (in the general case
> where you have more than one initiator behind a NAT), or IPsec tunnel mode
> (which can work if there is only one initiator behind the NAT). IPsec/NAT
> compatibility is now an IPsec WG work item.


From owner-ips@ece.cmu.edu  Wed Aug 15 19:41:45 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03130
	for <ips-archive@odin.ietf.org>; Wed, 15 Aug 2001 19:41:44 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7FN1nC22902
	for ips-outgoing; Wed, 15 Aug 2001 19:01:49 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from internaut.com ([64.38.134.99])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7FN1le22897
	for <ips@ece.cmu.edu>; Wed, 15 Aug 2001 19:01:47 -0400 (EDT)
Received: from localhost (aboba@localhost)
	by internaut.com (8.9.3/8.9.3) with ESMTP id PAA06957;
	Wed, 15 Aug 2001 15:54:54 -0700 (PDT)
	(envelope-from aboba@internaut.com)
Date: Wed, 15 Aug 2001 15:54:54 -0700 (PDT)
From: Bernard Aboba <aboba@internaut.com>
To: Sandeep Joshi <sandeepj@research.bell-labs.com>
cc: Black_David@emc.com, ips@ece.cmu.edu
Subject: Re: IPS: Schedule and Security Update
In-Reply-To: <3B7AFC0D.C4170901@research.bell-labs.com>
Message-ID: <Pine.BSF.4.21.0108151552550.6909-100000@internaut.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

> So does your answer imply that the iSCSI RFC status will depend 
> on the result of the IPSec-NAT work item in the IPSec WG ?
> 

The answer depends on whether that work is cited normatively or
non-normatively. I would suggest that it is desirable to have as few
normative references as possible in a document that we hope to have done
ASAP. 



From owner-ips@ece.cmu.edu  Wed Aug 15 21:09:14 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04257
	for <ips-archive@odin.ietf.org>; Wed, 15 Aug 2001 21:09:14 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7G0L9u25838
	for ips-outgoing; Wed, 15 Aug 2001 20:21:09 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mxic2.us.dg.com (mxic2.us.dg.com [128.221.31.40])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7G0L8e25834
	for <ips@ece.cmu.edu>; Wed, 15 Aug 2001 20:21:08 -0400 (EDT)
Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19)
	id <QQ9QR51H>; Wed, 15 Aug 2001 20:19:02 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD5D3@CORPMX14>
From: Black_David@emc.com
To: dbs@acropora.rose.agilent.com, Black_David@emc.com
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: draft 7: remove S bit and Status field from the Data-i
Date: Wed, 15 Aug 2001 20:15:31 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

> > The slide I presented in London was about replacing
> > immediate data with an unsolicited data PDU immediately following the
> > command, thus removing the immediate data case in favor of reusing the
> > logic for dealing with separate Data PDUs.  Remember that this was
presented
> > as a simplification possibility.
> 
> This does help some. It eliminates the situation where a target can
receive
> an essentially unlimited number of immediate data commands prior to
receiving
> *any* data PDUs.
> 
> But, do you mean to say that *one* unsolicited data PDU would follow the
> command? Wouldn't that be unnecessarily restrictive if the PDU size is
small?
> Simply guaranteeing that the data PDUs will immediately follow the command
> seems like an adequate improvement.
> 
Dave is right - "an unsolicited data PDU" should have been "one or more
unsolicited data PDUs" - I was making the incorrect assumption that
immediate
data is always short (not necessarily the case, but perhaps common).

--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


From owner-ips@ece.cmu.edu  Wed Aug 15 22:09:37 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05699
	for <ips-archive@odin.ietf.org>; Wed, 15 Aug 2001 22:09:37 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7G14Qt28547
	for ips-outgoing; Wed, 15 Aug 2001 21:04:26 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mxic2.us.dg.com (mxic2.us.dg.com [128.221.31.40])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7G14Pe28543
	for <ips@ece.cmu.edu>; Wed, 15 Aug 2001 21:04:25 -0400 (EDT)
Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19)
	id <QQ9QR6BH>; Wed, 15 Aug 2001 21:02:19 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD5D7@CORPMX14>
From: Black_David@emc.com
To: tnguyen@perfisans.com, ips@ece.cmu.edu
Subject: RE: iSCSI 07:  Initiator Task Tag
Date: Wed, 15 Aug 2001 20:58:49 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

> 1.  Is iSCSI task the same as SCSI task?
> 
> In section 1.1:
> 
> 	"A SCSI task is a SCSI command or possibly a linked set of SCSI
commands."
> 
> 	"An iSCSI task is an iSCSI request for which a response is expected.
> 
> 	In this document "iSCSI request", "iSCSI command", request or
unqualified)
> 	command have the same meaning.  Also, unless specified otherwise,
status,
> 	response or numbered response have the same meaning."
> 
> According to these definitions, they are different.  iSCSI task is an
iSCSI
> command.  If so, then is Initiator Task Tag the same as CmdSN?

The are different.  A SCSI task is as defined in SAM-2, particularly
for task management.  There are iSCSI tasks that are not SCSI tasks.
The Initiator Task Tag is NOT the same as the CmdSN.  The primary purpose
of the former is support of SCSI task management, whereas the latter
is used to order of command delivery to SCSI at the target, control command
flow from the initiator, and control some usage of target resources.

> 2.  In iSCSI version 07:
> 	"2.2.2.8 Initiator Task Tag
> 
>         The initiator assigns a Task Tag to each iSCSI task that it
issues.
>         While a task exists this tag MUST uniquely identify it
session-wide.
> "
> 
> Is this Initiator Task Tag the same as the Task Tags defined in section
> 4.9.2 in SAM-2 (revision 19)?  As quoted from SAM-2: "An initiator assigns
> tag values in each tagged task identifier in a way that ensures that the
> identifier uniqueness requirements stated in 4.9 are met."

They fulfill that function.

> 3.  How does the iSCSI target use the Initiator Task Tag to process the
> commands?

See the iSCSI and SAM-2 discussions of SCSI task management.

--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


From owner-ips@ece.cmu.edu  Wed Aug 15 22:09:45 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05710
	for <ips-archive@odin.ietf.org>; Wed, 15 Aug 2001 22:09:45 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7G1YSO29662
	for ips-outgoing; Wed, 15 Aug 2001 21:34:28 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mxic1.isus.emc.com ([168.159.129.100])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7G1YRe29657
	for <ips@ece.cmu.edu>; Wed, 15 Aug 2001 21:34:27 -0400 (EDT)
Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <QQ9CKTXW>; Wed, 15 Aug 2001 21:36:25 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD5D8@CORPMX14>
From: Black_David@emc.com
To: Julian_Satran@il.ibm.com, ips@ece.cmu.edu
Subject: RE: CmdSN during login
Date: Wed, 15 Aug 2001 21:28:49 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

This seems too clever by half.  If I understand Julian's
example correctly, it looks like a task management command
sent for immediate delivery is being retried on the second
connection.  Retrying a command that was sent for immediate
delivery and hence does not have its own CmdSN sounds difficult;
how is the target supposed to figure out whether the original
was executed?  Clear-ACA is somewhat unique in this fashion
as unintentionally doing it twice is a cause of potential
grief - hence it needs its own CmdSN if it's ever going
to be retried, and I suspect the upshot here is to
RECOMMEND use of a CmdSN and ordered delivery for Clear ACA.

I am completely mystified about why the Login ought to be
ordered with respect to the Clear ACA on the other connection,
as there's no interaction between those two commands.
Retrying the Clear ACA seems preferable, and one then gets
some sort of reasonable interaction between the original
Clear ACA and the retry.

In contrast, I think Julian's original concern about the
LU and Target Resets is misplaced.  If the initiator is
not sure whether the reset occurred, the right thing to
do is open up a new connection and issue a new reset (i.e.,
not a retry of the one from the old connection) using
immediate delivery just to be sure.  A well-placed TCP
RST on the original connection wouldn't hurt either.
Once the target's in a known state, it becomes possible
to resume operations.

Let's keep in mind that we're dealing with error situations
in which correctness is more important than performance,
and hence the inability to issue more commands until things
settle down is acceptable.  I agree with Mark that requiring
immediate delivery on all login commands and text commands
in the login phase seems like the right approach.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------

> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Wednesday, August 15, 2001 9:28 AM
> To: ips@ece.cmu.edu
> Subject: Re: CmdSN during login
> 
> 
> Mark,
> 
> I am uneasy about mandating the I bit instead of recommending it strongly
> and I am against recommending for the CmdSN field other values than our
> "reference" CmdSN (i.e., your preferred 0).
> 
> Consider the following scenario:
> 
> Connection1:
> I->T 
> c1(lu1)c2(lu1)c3(lu1)c4(lu2)c5(lu2)c6(lu2)Clear-ACA-LU1(#7) c7(lu1)
> c8(lu1) c9(lu1)
> 
> Command are executed at target but no statuses make it hardly back.
> C2 ends in an error that blocks the execution of C3.  Clear-LU1 is meant
to
> clean the error.
> No other traffic after the error report makes it back.
> 
> Initiator starts connection 2 and issues a login+restart for connection 1
> 
> The target sees the following sequence
> 
> c1,c2,c3,c4,c5,c6, Login, Clear-LU1(#7), c7, c8, c9
> 
> Target not having a reference for the logout/login will probably not
> execute Clear-ACA-LU1(#7).
> 
> The initiator can now reissue c9,c8,c7,Clear-ACA-LU1 and all will be
> dropped (when c7 arrives)  before Clear-ACA-LU1 is executed.
> 
> Although this a "legal" sequence and actions are legal (but not optimal) I
> am afraid that there are other sequences in which the side effects are
> "non-serial" schedules.
> 
> Julo
> 
> 
> 
> 
> 
> 
> Please respond to Mark Bakke <mbakke@cisco.com>
> 
> Sent by:  mbakke@cisco.com
> 
> 
> To:   Julian Satran/Haifa/IBM@IBMIL
> cc:   ips@ece.cmu.edu
> Subject:  Re: CmdSN during login
> 
> 
> 
> Julian-
> 
> What are the specific scenarios where this would happen?  My
> assumption has been that there is exactly one login exchange
> when a connection is established, and if a connection is logged
> out for some reason, that connection is destroyed.  To do
> another login, a new connection would have to be created.  If
> a connection is joining a session already in progress, how
> would it make any difference if task management commands were
> happening in full feature phase within other connections on
> the session?  Why would the login have to wait?  You mentioned
> that there were other ways to handle this.  Can we settle on
> using the "other ways" instead?
> 
> I do think that your suggestion of mandating the I bit set
> during login and negotiation would work; if the I bit is set,
> the CmdSN is ignored and can be set to anything (I'd prefer
> zero).  This effectively means that CmdSN does not start
> incrementing until full feature phase, which is what we wanted,
> but is still in the login and text command format "just in case"
> it's needed at some other time.
> 
> However, I would like to strongly word this such that the login
> and negotiation phases always set the I bit, send CmdSN=0, and
> ignore CmdSN on receive, until full feature phase is started.
> I think that a statement like "use whenever adequate" is too
> weak and ambiguous.
> 
> --
> Mark
> 
> Julian Satran wrote:
> >
> > I can see scenarios in which you would want the login 
> request  be regular
> -
> > as when you issue it after
> > a task management clear LU or reset command and want to 
> make sure that it
> > executed after the clear and the CmdSN clearly indicates 
> that.  However
> > even this effect can be achieved by other means and the 
> discussion is
> > rather academic - should we mandate the I bit in the login 
> phase (MUST)
> or
> > just say that it should be used whenever adequate and 
> explain why (which
> I
> > prefer) as it won't be required in all cases (e.g., it is 
> not necessary
> in
> > a session establishing login).
> >
> > Julo
> >
> > "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" 
> <matthew_burbridge@hp.com>
> > @ece.cmu.edu on 13-08-2001 19:34:56
> >
> > Please respond to "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)"
> >       <matthew_burbridge@hp.com>
> >
> > Sent by:  owner-ips@ece.cmu.edu
> >
> > To:   ips@ece.cmu.edu
> > cc:
> > Subject:  RE: CmdSN during login
> >
> > Could commands sent during the login phase (ie LOGIN + 
> TEXT) be mandatory
> > to
> > be immediate and therefore MUST have the I bit set or is 
> there a reason
> why
> > non-immediate login phase commands make sense?
> >
> > Cheers
> >
> > Matthew Burbridge
> >
> > -----Original Message-----
> > From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > Sent: Saturday, August 11, 2001 4:37 PM
> > To: ips@ece.cmu.edu
> > Subject: Re: CmdSN during login
> >
> > There was ambiguity at first login that we have cleared in 
> text and as I
> > said I don't see any good reason
> > for another case of immediate when we have the immediate 
> bit available.
> > What we could do is add anothe pragraph to 8
> > recommending when to use the I bit in login.
> >
> > Julo
> >
> > "Eddy Quicksall" <ESQuicksall@hotmail.com> on 10-08-2001 18:13:32
> >
> > Please respond to "Eddy Quicksall" <ESQuicksall@hotmail.com>
> >
> > To:   Julian Satran/Haifa/IBM@IBMIL
> > cc:   <ips@ece.cmu.edu>
> > Subject:  Re: CmdSN during login
> >
> > But, what if someone does this without setting the 
> Immediate bit? What
> > would
> > one do?
> >
> > What is wrong with just making the CmdSN not run during 
> login? It seems
> > like
> > it was an arbitrary choice in the first place since it was 
> originally
> > optional and not using it actually worked.
> >
> > If CmdSN is stated as only used in FFP, then I don't see 
> any ambiguity.
> >
> > Eddy
> > ----- Original Message -----
> > From: "Julian Satran" <Julian_Satran@il.ibm.com>
> > To: <ips@ece.cmu.edu>
> > Sent: Friday, August 10, 2001 2:43 AM
> > Subject: Re: CmdSN during login
> >
> > >
> > > Sanjay,
> > >
> > > If you want to ignore CmdSN and expedite Login processing 
> you can do so
> > by
> > > having the commands being issued as immediate.
> > > This will help us keep away from creating ambiguity about 
> (or another
> > > conditional) for when CmdSN is to be used or not.
> > >
> > > Julo
> > >
> > > Mark Bakke <mbakke@cisco.com>@ece.cmu.edu on 09-08-2001 23:55:25
> > >
> > > Please respond to Mark Bakke <mbakke@cisco.com>
> > >
> > > Sent by:  owner-ips@ece.cmu.edu
> > >
> > >
> > > To:   Sanjay Goyal <sanjay_goyal@ivivity.com>
> > > cc:   "Ips (E-mail)" <ips@ece.cmu.edu>
> > > Subject:  Re: CmdSN during login
> > >
> > >
> > >
> > >
> > > Sanjay-
> > >
> > > I absolutely agree with this; CmdSN is owned by the session, and
> > > should not be used until the connection has fully joined 
> the session,
> > > which means full feature phase.
> > >
> > > This should also clean up any ambiguity on when to start
> > > using CmdSN.
> > >
> > > --
> > > Mark
> > >
> > > Sanjay Goyal wrote:
> > > >
> > > > Hi
> > > >
> > > >  Assuming Target and Initiator support multiple 
> connections and the
> > > session
> > > > is having multiple connections. Assuming out-of-order CmdSN is a
> > > possibility
> > > > for this session.
> > > >
> > > >  Connection #   1       |       2       |       3
> > > > -------------------------------------------------------
> > > > Login Cmd  CmdSN=0      |   CmdSN=8     |  CmdSN=9
> > > > Txt   Cmd  CmdSN=1      |               |
> > > >                                 |               |
> > > >                                 |               |
> > > > Login Cmd  CmdSN=7      |  CmdSN=10     |  CmdSN=11
> > > > -------------------------------------------------------
> > > > Data Cmd   CmdSN=12     | CmdSN=14      | CmdSN=15
> > > > Data Cmd   CmdSN=13     |               |
> > > >                                 |               |
> > > >
> > > > CmdSN=7 is last of the Login sequence and it is 
> acknowledged by the
> > > Target
> > > > with "accept login" response.
> > > >
> > > > Target would receive the PDUs in this CmdSN order
> > > >  0 to 7, 8, 9, 12, 10, 11, 13, 14, 15
> > > >
> > > > Now as Login and Text PDUs are being processed even 
> though you have
> > > received
> > > > Data Cmd PDUs, you can not pass them to iSCSI layer and 
> hence you are
> > > adding
> > > > latency.
> > > >
> > > > What I want to convey from this example is why not use 
> CmdSN just
> > during
> > > the
> > > > FullFeature phase only.
> > > >
> > > > Regards
> > > > Sanjay Goyal
> > > >
> > > >
> > >
> >
> --------------------------------------------------------------
> ------------
> > --------------------------
> > >
> > > >
> > > >    Part 1.2    Type: application/ms-tnef
> > > >            Encoding: base64
> > >
> > > --
> > > Mark A. Bakke
> > > Cisco Systems
> > > mbakke@cisco.com
> > > 763.398.1054
> > >
> > >
> > >
> > >
> 
> --
> Mark A. Bakke
> Cisco Systems
> mbakke@cisco.com
> 763.398.1054
> 
> 
> 


From owner-ips@ece.cmu.edu  Wed Aug 15 22:11:23 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05733
	for <ips-archive@odin.ietf.org>; Wed, 15 Aug 2001 22:11:23 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7G1H9G29035
	for ips-outgoing; Wed, 15 Aug 2001 21:17:09 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from atlrel7.hp.com (atlrel7.hp.com [192.151.27.9])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7G1H8e29031
	for <ips@ece.cmu.edu>; Wed, 15 Aug 2001 21:17:08 -0400 (EDT)
Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100])
	by atlrel7.hp.com (Postfix) with ESMTP
	id C26AA1F9DE; Wed, 15 Aug 2001 21:15:51 -0400 (EDT)
Received: (from cbm@localhost) by core.rose.hp.com (8.8.6 (PHNE_14041)/8.8.6 SMKit7.02) id SAA15118; Wed, 15 Aug 2001 18:18:15 -0700 (PDT)
Message-Id: <200108160118.SAA15118@core.rose.hp.com>
Subject: Re: iSCSI: rev07 - ISID-TSID & naming comments
To: hafner@almaden.ibm.com
Date: Wed, 15 Aug 2001 18:18:15 PDT
Cc: ips@ece.cmu.edu
In-Reply-To: <OF0608E573.03B1B416-ON88256AA9.0061F6BB@boulder.ibm.com>; from "Jim Hafner" at Aug 15, 101 12:32 (noon)
Reply-To: cbm@rose.hp.com
From: "Mallikarjun C." <cbm@rose.hp.com>
X-Mailer: Elm [revision: 212.4]
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Jim,

>Did I make any thing more clear or just muddle things up?

Thanks for the explanation, yes it does help me to see your 
thinking.  This is what I suspected you meant, but wanted to 
be sure.

Regards.
--
Mallikarjun 


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



>Mallikarjun,
>
>My "text" again isn't conveying what I'm thinking, but yours is closer.  I
>want the model to allow physical things to span multiple virtual things.
>What I was trying to convey is exactly what you're saying.  Is it more
>clear if I had said "can live in multiple portal groups *so long as each
>portal group was in a different node*"?  But I want a network portal (be it
>either physical or virtual) to "connect up" to different nodes (through
>unique portal groups on each node).
>
>If a network portal has only one ipaddress/[tcpport], it can service
>multiple nodes, but belong to only one portal group per node.  So, maybe
>this multi-node (focused on only one network portal) picture helps:
>
>    NodeA           NodeB          NodeC
>      |               |              |
>PortalGroupA1   PortalGroupB2  PortalGroupC1
>      |               |              |
>      |_________NetworkPortalX_______|
>            (Ipaddress/[tcpport])
>
>
>The picture doesn't show other portal groups that might be in any of the
>nodes nor does it show other network portals that might be in any of the
>portal groups.   This is the tree view from a given network portal up.
>The up-degree at the network portal can be anything.  The up-degree of each
>portal group is one.  There's a different view from the node down.   In the
>node-down graph, I can have any number of portal groups below a node and
>any number of network portals in each portal group.  The rule is that this
>graph is a tree.
>
>And the model allows the leaf structure of one node-down tree to be related
>in any way to the leaf structure of another node-down tree.  [I'm finding
>it hard to describe this clearly.]  By example:  suppose that PortalGroupA1
>above had another NetworkPortalY in it (within NodeA).  This network portal
>need not be in PortalGroupB2 of NodeB just because NetworkPortalX was in
>PortalGroupB2 .  So the fact that two leaves of one node-down tree are in
>one portal group (have a common parent) does not require those two leaves
>to be in the same portal group (have a common parent) of another node-down
>tree.
>
>Did I make any thing more clear or just muddle things up?
>
>And yes, the scope of the portal group tag is the node.
>
>The tricky part in this is the viewpoint.  If you think only one node at a
>time, then the node-down tree is easy enough to describe.  It's when you
>try to put more nodes in the picture that the relationships get more
>complicated.   I'm not even sure it's possible in 2D to render in one graph
>the full set of possibilities even with two nodes!
>
>Jim Hafner
>
>
>"Mallikarjun C." <cbm@rose.hp.com> on 08/15/2001 10:40:16 am
>
>Please respond to cbm@rose.hp.com
>
>To:   Jim Hafner/Almaden/IBM@IBMUS
>cc:   ips@ece.cmu.edu
>Subject:  Re: iSCSI: rev07 - ISID-TSID & naming comments
>
>
>
>Jim,
>
>As you say, I too think we are very close on this.  Let me comment
>on one sentence in your message that I didn't quite follow.
>
>>Perhaps if we can make it clear that a
>>network portal can live in multiple portal groups, but a portal group only
>>belongs to one iSCSI node, then we're OK.
>
>Two comments -
>- My understanding of portal groups has been that they are disjoint
>  sets, and that's the reason a session could not span multiple portal
>  groups.  You seem to suggest that portal groups are overlapping sets
>  with possibly common network portals, or did I misunderstand?
>
>- By saying "a portal group only belongs to one iSCSI node", if you
>  are implying that the scope of the portal group tags is per iSCSI
>  node (i.e. the tags are unique and meaningful within one iSCSI node),
>  then I am fine.  I just want to confirm that you are not excluding the
>  possibility of one *physical* portal group (say an HBA) being able
>  to get to multiple (virtual) iSCSI nodes.
>
>Regards.
>--
>Mallikarjun
>
>
>Mallikarjun Chadalapaka
>Networked Storage Architecture
>Network Storage Solutions Organization
>MS 5668   Hewlett-Packard, Roseville.
>cbm@rose.hp.com


From owner-ips@ece.cmu.edu  Wed Aug 15 22:12:03 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05745
	for <ips-archive@odin.ietf.org>; Wed, 15 Aug 2001 22:12:03 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7G1EOK28919
	for ips-outgoing; Wed, 15 Aug 2001 21:14:24 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dominoe.integrix.com ([207.171.9.89])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7FNJ9e23581
	for <ips@ece.cmu.edu>; Wed, 15 Aug 2001 19:19:09 -0400 (EDT)
Received: from integrix.com (rellis [192.9.200.208])
	by dominoe.integrix.com (8.9.1b+Sun/8.9.1) with ESMTP id QAA12389
	for <ips@ece.cmu.edu>; Wed, 15 Aug 2001 16:17:27 -0700 (PDT)
Message-ID: <3B7B042F.4A3BCCEE@integrix.com>
Date: Wed, 15 Aug 2001 16:22:23 -0700
From: Rick Ellis <rellis@integrix.com>
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: ips@ece.cmu.edu
Subject: Re: iSCSI: Rev 07 Comments 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

>The iSCSI model defines portal groups as collections of network portals
>that can coordinate (at it's end) multiple connections within a session.

Why did that happen?  Wouldn't it have been a lot simpler to not allow
multiple connections within a session?  It has really complicated the
protocol.


From owner-ips@ece.cmu.edu  Wed Aug 15 22:12:16 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05756
	for <ips-archive@odin.ietf.org>; Wed, 15 Aug 2001 22:12:16 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7G194B28708
	for ips-outgoing; Wed, 15 Aug 2001 21:09:04 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7G192e28701
	for <ips@ece.cmu.edu>; Wed, 15 Aug 2001 21:09:02 -0400 (EDT)
Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100])
	by palrel1.hp.com (Postfix) with ESMTP id 80F671AA2
	for <ips@ece.cmu.edu>; Wed, 15 Aug 2001 18:09:01 -0700 (PDT)
Received: (from cbm@localhost) by core.rose.hp.com (8.8.6 (PHNE_14041)/8.8.6 SMKit7.02) id SAA14023 for ips@ece.cmu.edu; Wed, 15 Aug 2001 18:10:17 -0700 (PDT)
Message-Id: <200108160110.SAA14023@core.rose.hp.com>
Subject: iSCSI: error recovery proposals from London
To: ips@ece.cmu.edu
Date: Wed, 15 Aug 2001 18:10:17 PDT
Reply-To: cbm@rose.hp.com
From: "Mallikarjun C." <cbm@rose.hp.com>
X-Mailer: Elm [revision: 212.4]
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

All:

During the just concluded IETF-51 in London, I made a presentation 
on error recovery status in iSCSI and made certain specific proposals 
on behalf of Julian Satran, Randy Haagens and myself.  This message 
is intended to give an overview of the presentation, and to seek
WG consensus on these issues.

The slide set that I used for the presentation is on Julian's website
at:
       http://www.haifa.il.ibm.com/satran/ips/iscsi_errsimpl_london.pdf

The first few slides summarize the challenges of error recovery design 
in iSCSI and outline the current (as of rev07) philosophy of iSCSI to 
address these challenges.

The three specific proposals that I presented are -

1. Continued definition of SNACK:  Though continuing to define SNACK in
   iSCSI does not involve any changes to the draft, I thought it is fair
   to bring up this issue since there had been much debate about the 
   need for SNACK in this forum and ERT.  

   The slides present the pros and cons of SNACK (essentially the reasoning
   for the current support of SNACK).  While the negative aspects of SNACK
   are presented with possible options to address those, the slide set 
   points out the solid positive aspects of SNACK.  In particular, following
   are the factors that swayed the decision in favor of SNACK. 

            a)There has been a disproportionate amount of focus on the 
              data recovery capability of SNACK, but a much more important 
              aspect of SNACK is the ability to recover statuses (thus 
              StatSNs), in turn preventing connection failures due to 
              status sequence holes.

            b)Philosophically, the draft supports the notion of 
              "retransmission" of PDUs by defining transparent failover 
              of commands to different connections.  SNACK merely makes 
              this implicit allowance for retransmission into an explicit 
              statement.  Remember, neither SNACK nor command failover 
              is mandatory.

            c)Partial I/O recovery has been considered a requirement for
              tape devices in the FC world.  SNACK satisfies this requirement.
              (Two tape experts present in the WG meeting strongly supported 
               this reasoning.)

There was a strong consensus in the meeting to continue defining SNACK.

2. Need for a hierarchy: The proposal here was to define the error recovery 
   capabilities as a hierarchy of recovery levels, with each layer being a 
   superset of the capabilities of the level below.  This has the benefit of
   significantly decreasing the test matrix, and requires only incremental
   capabilities for increasingly sophisticated implementations.

There was a strong consensus in the meeting to define an iSCSI error 
recovery hierarchy.

3. Proposed hierarchy: This proposal outlines a specific hierarchy of
   recovery levels.  The features of this are -

        - Four optional error recovery levels.
               *Level1:Within-connection recovery
               *Level2:Within-command recovery 
               *Level3:Connection recovery
               *Level4:Command replay
        - One mandatory recovery level 
               *Level0:Session recovery
   Following are the incremental book- keeping & resource requirements
   with going up each level.
   
   Recovery Level transition         Incremental requirement 
    0 -> 1                      Atmost one PDU retransmission per task.
    1 -> 2                      Retransmit possibilities include data PDUs.
    2 -> 3                      Retransmission across connections.
    3 -> 4                      Replaying the entire command.

The consensus call on this one was deferred in London, in favor of taking 
it to the reflector to solicit more comments.

   Let me add one comment here - the proposed hierarchy is based on what 
   I called as the "incremental aspirations" (please refer to slide 13) 
   of increasingly sophisticated implementations.  There are different 
   ways of approaching this layering (for ex., it is *not* SNACK-centric - 
   ordering layers based on their reliance on SNACK).  In the presenters' 
   opinion, the proposed approach was deemed the most reasonable.


Your comments are welcome.
--
Mallikarjun 


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


From owner-ips@ece.cmu.edu  Wed Aug 15 23:41:39 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07761
	for <ips-archive@odin.ietf.org>; Wed, 15 Aug 2001 23:41:38 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7G2SDn01582
	for ips-outgoing; Wed, 15 Aug 2001 22:28:13 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from bastion.power-x.co.uk (bastion.power-x.co.uk [62.232.19.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7G2SBe01578
	for <ips@ece.cmu.edu>; Wed, 15 Aug 2001 22:28:11 -0400 (EDT)
Received: from MELFIELD.px.uk.com (hadfield.px.uk.com [172.16.18.100])
	by bastion.power-x.co.uk (8.9.3/8.9.3) with ESMTP id DAA04477
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 03:28:06 +0100
Received: by melfield.px.uk.com with Internet Mail Service (5.5.2653.19)
	id <Q0B511VC>; Thu, 16 Aug 2001 03:28:06 +0100
Message-ID: <85F3FE9A6BF0C542B7EB5F8DC8B1720575E295@melfield.px.uk.com>
From: Matt Ahangi <matt.ahangi@powerxnetworks.com>
To: IPS <ips@ece.cmu.edu>
Subject: Remove
Date: Thu, 16 Aug 2001 03:28:05 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

remove


From owner-ips@ece.cmu.edu  Thu Aug 16 02:32:35 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25262
	for <ips-archive@odin.ietf.org>; Thu, 16 Aug 2001 02:32:35 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7G5W7X08263
	for ips-outgoing; Thu, 16 Aug 2001 01:32:07 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7G5W5e08259
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 01:32:05 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id HAA99536
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 07:31:58 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7G5VrB143538
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 07:31:58 +0200
Importance: Normal
Subject: Re: iSCSI: error recovery proposals from London
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFCFD00CDB.9DB3F71D-ONC2256AAA.001D57A7@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Thu, 16 Aug 2001 08:31:30 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 16/08/2001 08:31:57
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Needless to say up-front that I am strongly in favor of this recovery
hierachy.

The only point I would like to make is that I would like to reduce the
implementation options to 2 (or maximum 3) levels by
combining the levels in a reasonable view.

By this we could simplify testing and interoperability.

The levels would be:

0 - session recovery
1 - your current level 4

I would also suggest reexamining the introduction of a data-ack (using the
F bit of the input sequences) and a special form of SNACK for ACK to limit
the resources a tape target will have to dedicate to recovery.

Julo

"Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on 16-08-2001 04:10:17

Please respond to cbm@rose.hp.com

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  iSCSI: error recovery proposals from London



All:

During the just concluded IETF-51 in London, I made a presentation
on error recovery status in iSCSI and made certain specific proposals
on behalf of Julian Satran, Randy Haagens and myself.  This message
is intended to give an overview of the presentation, and to seek
WG consensus on these issues.

The slide set that I used for the presentation is on Julian's website
at:
       http://www.haifa.il.ibm.com/satran/ips/iscsi_errsimpl_london.pdf

The first few slides summarize the challenges of error recovery design
in iSCSI and outline the current (as of rev07) philosophy of iSCSI to
address these challenges.

The three specific proposals that I presented are -

1. Continued definition of SNACK:  Though continuing to define SNACK in
   iSCSI does not involve any changes to the draft, I thought it is fair
   to bring up this issue since there had been much debate about the
   need for SNACK in this forum and ERT.

   The slides present the pros and cons of SNACK (essentially the reasoning
   for the current support of SNACK).  While the negative aspects of SNACK
   are presented with possible options to address those, the slide set
   points out the solid positive aspects of SNACK.  In particular,
following
   are the factors that swayed the decision in favor of SNACK.

            a)There has been a disproportionate amount of focus on the
              data recovery capability of SNACK, but a much more important
              aspect of SNACK is the ability to recover statuses (thus
              StatSNs), in turn preventing connection failures due to
              status sequence holes.

            b)Philosophically, the draft supports the notion of
              "retransmission" of PDUs by defining transparent failover
              of commands to different connections.  SNACK merely makes
              this implicit allowance for retransmission into an explicit
              statement.  Remember, neither SNACK nor command failover
              is mandatory.

            c)Partial I/O recovery has been considered a requirement for
              tape devices in the FC world.  SNACK satisfies this
requirement.
              (Two tape experts present in the WG meeting strongly
supported
               this reasoning.)

There was a strong consensus in the meeting to continue defining SNACK.

2. Need for a hierarchy: The proposal here was to define the error recovery
   capabilities as a hierarchy of recovery levels, with each layer being a
   superset of the capabilities of the level below.  This has the benefit
of
   significantly decreasing the test matrix, and requires only incremental
   capabilities for increasingly sophisticated implementations.

There was a strong consensus in the meeting to define an iSCSI error
recovery hierarchy.

3. Proposed hierarchy: This proposal outlines a specific hierarchy of
   recovery levels.  The features of this are -

        - Four optional error recovery levels.
               *Level1:Within-connection recovery
               *Level2:Within-command recovery
               *Level3:Connection recovery
               *Level4:Command replay
        - One mandatory recovery level
               *Level0:Session recovery
   Following are the incremental book- keeping & resource requirements
   with going up each level.

   Recovery Level transition         Incremental requirement
    0 -> 1                      Atmost one PDU retransmission per task.
    1 -> 2                      Retransmit possibilities include data PDUs.
    2 -> 3                      Retransmission across connections.
    3 -> 4                      Replaying the entire command.

The consensus call on this one was deferred in London, in favor of taking
it to the reflector to solicit more comments.

   Let me add one comment here - the proposed hierarchy is based on what
   I called as the "incremental aspirations" (please refer to slide 13)
   of increasingly sophisticated implementations.  There are different
   ways of approaching this layering (for ex., it is *not* SNACK-centric -
   ordering layers based on their reliance on SNACK).  In the presenters'
   opinion, the proposed approach was deemed the most reasonable.


Your comments are welcome.
--
Mallikarjun


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





From owner-ips@ece.cmu.edu  Thu Aug 16 04:04:51 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25869
	for <ips-archive@odin.ietf.org>; Thu, 16 Aug 2001 04:04:51 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7G6qgU10842
	for ips-outgoing; Thu, 16 Aug 2001 02:52:42 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail.san.yahoo.com (mail.san.yahoo.com [209.132.1.30])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7G6qfe10838
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 02:52:41 -0400 (EDT)
Received: from bursar.muttsnuts.com (193.120.246.22) by mail.san.yahoo.com (5.5.041.1)
        id 3B79788100070476 for ips@ece.cmu.edu; Wed, 15 Aug 2001 23:51:18 -0700
Message-Id: <5.1.0.14.2.20010816074717.01dfe078@mail.muttsnuts.com>
X-Sender: markemuttsnuts@mail.muttsnuts.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 16 Aug 2001 07:50:08 +0100
To: ips@ece.cmu.edu
From: "Mark S. Edwards" <marke@muttsnuts.com>
Subject: Fwd: RE: iSCSI: Support Alias in the protocol
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


>Importance: Normal
>Subject: RE: iSCSI: Support Alias in the protocol
>To: "Mark S. Edwards" <marke@muttsnuts.com>
>X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
>From: "John Hufferd" <hufferd@us.ibm.com>
>Date: Wed, 15 Aug 2001 12:15:13 -0700
>X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 
>18, 2001) at
>  08/15/2001 01:15:56 PM
>
>
>Mark,
>I understand what you are saying.  You will be setting up LUN "Sets"  which
>you want the initiators to think of as iSCSI Targets that just happen to
>have the exact same LUNs that you are virtualizing to that Initiator.  You
>are also saying that this approach finds Alias very useful.  OK, I can buy
>what you said, just as long as people do not think that Alias and LUNs
>somehow map together, with out such a virtualizing layer.
>
>I think this needs to be posted to the main list.  So if you would, since
>you sent this to just me, please post you statement and my reply to the IPS
>iSCSI Reflector.
>
>.
>.
>.
>John L. Hufferd
>Senior Technical Staff Member (STSM)
>IBM/SSG San Jose Ca
>Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
>Home Office (408) 997-6136
>Internet address: hufferd@us.ibm.com
>
>
>"Mark S. Edwards" <marke@muttsnuts.com> on 08/14/2001 10:44:33 PM
>
>To:   John Hufferd/San Jose/IBM@IBMUS
>cc:
>Subject:  RE: iSCSI: Support Alias in the protocol
>
>
>
>John,
>
>Perhaps a loose use of terminology, but we are implementing a virtual SCSI
>layer on the target.  In this case, people tend to view a single exported
>LU as a target in its own right and the primary way of understanding it's
>identity is with the alias.  Multiple LUN's behind a virtual target are a
>slightly different matter.
>
>I know the spec does not address issues such as virtualisation, and at this
>stage it is a complication it can well do without.  Perhaps I tossed the
>note off thinking in local terminology and should be more careful to filter
>to terminology to where the group thinks it's at.  However, we have found
>that the group does tend to discuss matters either from the perspective of
>the initiator or by assuming that the protocol is relatively symmetric.
>
>Since we are only producing a target, we seem to have encountered
>a lot of the complicated target issues ahead of many others
>realising how different the initiator and target environments really are.
>
>Cheers,
>
>Mark.
>
>
>At 02:47 AM 8/14/2001 -0700, John Hufferd wrote:
>
> >Mark,
> >Perhaps I misunderstood your note, however, even though you wisely support
> >Alias :-), they do not supply any help with LU/LUNs.  They only permit the
> >customer to have names for his iSCSI Targets (think Raid Controllers, not
> >LUs), however, that is still very useful.
> >
> >.
> >.
> >.
> >John L. Hufferd
> >Senior Technical Staff Member (STSM)
> >IBM/SSG San Jose Ca
> >Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
> >Home Office (408) 997-6136
> >Internet address: hufferd@us.ibm.com
> >
> >
> >"Mark S. Edwards" <marke@muttsnuts.com>@ece.cmu.edu on 08/13/2001 10:46:35
> >PM
> >
> >Sent by:  owner-ips@ece.cmu.edu
> >
> >
> >To:   ips@ece.cmu.edu
> >cc:
> >Subject:  RE: iSCSI: Support Alias in the protocol
> >
> >
> >
> >At 09:09 PM 8/13/2001 -0400, Black_David@emc.com wrote:
> >
> > >Let me also acknowledge as valid Marj's opinion that anything of
> > >this sort belongs in a management tool rather than the protocol.
> >
> >But it only works if everyone uses the same management tool, or the tools
> >agree upon the location and storage format of the information --  Somebody
> >dig me up from my grave when Tivoli and OpenView merge.
> >
> >As a way of easily identifying virtual LUN's or LU's within a Target Space
> >of potential hundreds or thousands the alias is very valuable.
> >
> >Mark.



From owner-ips@ece.cmu.edu  Thu Aug 16 04:30:00 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26048
	for <ips-archive@odin.ietf.org>; Thu, 16 Aug 2001 04:29:59 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7G7ROP11978
	for ips-outgoing; Thu, 16 Aug 2001 03:27:24 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d06lmsgate-2.uk.ibm.com (d06lmsgate-2.uk.ibm.com [195.212.29.2])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7G7RNe11973
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 03:27:23 -0400 (EDT)
Received: from d06relay01.portsmouth.uk.ibm.com (d06relay01.portsmouth.uk.ibm.com [9.166.84.147])
	by d06lmsgate-2.uk.ibm.com (1.0.0) with ESMTP id IAA68264
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 08:10:24 +0100
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d06relay01.portsmouth.uk.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7G7RAH176972
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 08:27:12 +0100
Importance: Normal
Subject: Re: iSCSI: Ping Data,CmdSN
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF3B452BA3.BF79E682-ONC2256AAA.0028B9D9@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Thu, 16 Aug 2001 10:26:36 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 16/08/2001 10:27:13
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


I am rewriting NOP according to my proposal agreed in London.  It will be
out today.
I will answer you after that if you still need it.

Julo

"Asai Thambi S P" <sp_asai@ctd.hcltech.com> on 16-08-2001 10:19:11

Please respond to "Asai Thambi S P" <sp_asai@ctd.hcltech.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:
Subject:  iSCSI: Ping Data,CmdSN



hi,

I have some queries. I thought I can get solutions in IPS. I've already
sent this to IPS. nobody replied. So I'm mailing u personnally. Can u help
me on this?


 * NOP-Out can be sent in response to NOP-In or to test the target or to
        test the connection.

        Section 2.12:

        "The NOP-Out may be useful in the case where an initiator has been
        waiting a long time for the response to some command, and the
        initiator suspects that there is some problem with the connection."

        "A NOP-Out should also be used to confirm a changed ExpStatSN if
there is no other PDU to carry it for a long time. "

      The draft also says that the timeout value is outside the scope of
the
document.

        In the former case, how do we know that we've been waiting for a
long time?
        In the latter case, how do we know that there is no other PDU's to
carry this for a long time?

* Similarly  for NOP-In,
        NOP-In can be sent
                        * in response to NOP-In
                        * to test the initiator
                        * to test the connection

        When to test the initiator or connection? How to decide it?

In case of target/initiator issuing NOP-In/NOP-Out on its own, what will be
the Ping Data?


* if CmdSN  is not equal to ExpCmdSN, what should the target do?
        suppose CmdSN > ExpCmdSN,  whether the target should assume that it
missed the commands in between and ask for retransmission of commands.
If so, how the target asks for command retransmission.
        If not, what the target should  do?

    The initiator asks for retransmission of status or data through SNACK
request.

Is there anything similar to this for target?

    One more regarding CmdSN,

    if CmdSN is not equal to ExpCmdSN in Task Management Command, what to
do?

 - asai.







From owner-ips@ece.cmu.edu  Thu Aug 16 04:30:42 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26065
	for <ips-archive@odin.ietf.org>; Thu, 16 Aug 2001 04:30:42 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7G7gMA12437
	for ips-outgoing; Thu, 16 Aug 2001 03:42:22 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from kodos.tinet.ie (mail1.tinet.ie [159.134.237.22])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7G7gKe12432
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 03:42:20 -0400 (EDT)
Received: from [159.134.199.212] (helo=methode_nt.methode.ie)
	by kodos.tinet.ie with smtp (Exim 2.05 #1)
	id 15XHnA-0004wr-00
	for ips@ece.cmu.edu; Thu, 16 Aug 2001 08:42:12 +0100
Received: from SMTP agent by mail gateway 
 Thu, 16 Aug 2001 08:38:16 -0000
Received: by METHODE_NT with Internet Mail Service (5.5.2653.19)
	id <PV3J6QNQ>; Thu, 16 Aug 2001 08:41:00 +0100
Message-ID: <4448BB382D71D511A4380002A551921E055870@METHODE_NT>
From: Tom Allen <Tom.Allen@Methode.ie>
To: "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
Subject: REMOVE
Date: Thu, 16 Aug 2001 08:40:59 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk




From owner-ips@ece.cmu.edu  Thu Aug 16 04:32:05 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26089
	for <ips-archive@odin.ietf.org>; Thu, 16 Aug 2001 04:32:04 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7G7i1X12514
	for ips-outgoing; Thu, 16 Aug 2001 03:44:01 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7G7hxe12508
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 03:44:00 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id JAA82794;
	Thu, 16 Aug 2001 09:43:52 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7G7hpB145120;
	Thu, 16 Aug 2001 09:43:51 +0200
Importance: Normal
Subject: RE: iSCSI Re: Questions on iSCSI 07
To: "Lee Xing" <lxing@Crossroads.com>
Cc: <ips@ece.cmu.edu>
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF6FEA419F.5C08FACE-ONC2256AAA.002A41BE@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Thu, 16 Aug 2001 10:42:30 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 16/08/2001 10:43:52
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk



"Lee Xing" <lxing@crossroads.com> on 15-08-2001 23:54:31

Please respond to "Lee Xing" <lxing@crossroads.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   <ips@ece.cmu.edu>
Subject:  RE: iSCSI Re: Questions on iSCSI 07



Julian,

Thank you for the info.  It helps.
Please see my comments bellow.

Regards,





 +++

Can the initiator use any integer number during the first login of a
session (leading login)?

+++ yes
----------------------------------------------





From owner-ips@ece.cmu.edu  Thu Aug 16 08:56:59 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03666
	for <ips-archive@odin.ietf.org>; Thu, 16 Aug 2001 08:56:59 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7GBmnA00810
	for ips-outgoing; Thu, 16 Aug 2001 07:48:49 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from va2mc.ummailbox.net (va2mc.ummailbox.net [64.210.247.22])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7GBmme00803
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 07:48:48 -0400 (EDT)
Received: from hqmailweb.COMMSTOR.Crossroads.com (HQMailWeb.Crossroads.com [63.237.99.250:25])
	by va2mc.ummailbox.net with ESMTP id V0816-0748-5cab02;
	Thu, 16 Aug 2001 11:48:31 GMT
Received: from HQMAILNODE1.COMMSTOR.Crossroads.com ([10.5.1.42]) by hqmailweb.COMMSTOR.Crossroads.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 16 Aug 2001 06:48:28 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: iSCSI: Rev 07 Comments
Date: Thu, 16 Aug 2001 06:45:45 -0500
Message-ID: <CFD808D1D39ACB47ABFF586D484CC52E1393B9@HQMAILNODE1.COMMSTOR.Crossroads.com>
Thread-Topic: iSCSI: Rev 07 Comments
Thread-Index: AcEl1eEBpo2+vE2YSbGCYM4ziGw1EQAcRw1Q
From: "Bill Moody" <bmoody@Crossroads.com>
To: "Jim Hafner" <hafner@almaden.ibm.com>
Cc: <ips@ece.cmu.edu>
X-OriginalArrivalTime: 16 Aug 2001 11:48:28.0094 (UTC) FILETIME=[5D2F65E0:01C12649]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f7GBmme00804
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit

Jim,

Thanks for the clarification.  You're right in that the definition of
Portal Groups is initiator/target agnostic.  I was able to resolve my
own confusion after re-reading the definition and considering the
implications a few times.  I just thought you might avoid any such
confusion by explicitly mentioning the notion of initiator portal groups
sooner.  Although the definition is agnostic, the diagram that follows
the definition is target specific and no mention of initiator portal
groups occurs until the discussion following the ISID RULE.

Bill
-----Original Message-----
From: Jim Hafner [mailto:hafner@almaden.ibm.com]
Sent: Wednesday, August 15, 2001 5:02 PM
To: Bill Moody
Cc: ips@ece.cmu.edu
Subject: Re: iSCSI: Rev 07 Comments



Bill,

As a work-in-progress, my apologies for the confusion.

The iSCSI model defines portal groups as collections of network portals
that can coordinate (at it's end) multiple connections within a session.
That's true for the initiator side and the target side.  I had thought
that
the defintion was initiator/target agnostic (I'll have to go back and
read
it again, in context).

Keep in mind that there are two models playing here, the iSCSI model and
the SAM/SCSI model.   Portal groups are constructs of the iSCSI model
and
are symmetric with respect to initiator or target.  The only
non-symmetry
at the iSCSI level is in the identifiers for network portals.  Target
network portals have to have an ipaddress AND a listening tcpport
(server
socket).  Initiator network portals don't "listen", so they only have
ipaddresses.

It so happens that as we've proposed the SAM/SCSI model overlay on iSCSI
constructs, only the target portal group plays a role; the initiator
portal
group is "invisible" to the SAM/SCSI model.    Hence, the lack of
emphasis
on the initiator portal group.  There is definite asymmetry here and
we've
tried to justify the value in that in other postings.   When we get to
"initiator requirements", we start having to mention them for other
reasons
(as has been discussed in other threads);  namely, where they get there
iSCSI Name and the ISID namespace they use.

Does that help?  And yes, this whole stuff will need a couple more
careful
reading/rewritings to get it all correct and clear.

Jim Hafner


"Bill Moody" <bmoody@Crossroads.com>@ece.cmu.edu on 08/15/2001 02:16:04
pm

Sent by:  owner-ips@ece.cmu.edu


To:   "IP Storage Mailing List (E-mail)" <ips@ece.cmu.edu>
cc:   "Robert Griswold" <rgriswold@Crossroads.com>, "Bill Moody"
      <bmoody@Crossroads.com>
Subject:  iSCSI:  Rev 07 Comments



I have a couple of points I'd like to raise concerning the 07 version of
the document.

Section 1.5.3.  On page 39, under 'iSCSI Initiator Requirements' the
term initiator portal group is used multiple times.  This is the first
use of this term and led to some confusion on my part.  The 'portal
group' term was clearly defined earlier and was used repeatedly in
connection with the target but no mention has been made of the use of
initiator portal groups prior to this point.  The ISID RULE clearly
defines that only one session with a given ISID can exist between a
given iSCSI Initiator and iSCSI Target Portal Group - it doesn't mention
initiator portal groups.  It would be nice to define this 'initiator
portal group' term prior to its use.

Appendix A.  What is the meaning of the value '11EDC6F41' in the table?
Is this the generator polynomial that is discussed in the following
paragraph?  If so, it is not clear.

Thanks,

Bill Moody
Architect
Crossroads Systems, Inc.
Phone:  (512) 928-7238
Fax:  (512)-928-7402






From owner-ips@ece.cmu.edu  Thu Aug 16 10:16:53 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08416
	for <ips-archive@odin.ietf.org>; Thu, 16 Aug 2001 10:16:53 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7GD6Jc03641
	for ips-outgoing; Thu, 16 Aug 2001 09:06:19 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7GD6He03636
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 09:06:17 -0400 (EDT)
Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA04342; Thu, 16 Aug 2001 09:06:10 -0400 (EDT)
Message-ID: <3B7BC3B5.D75F6122@cisco.com>
Date: Thu, 16 Aug 2001 07:59:33 -0500
From: Mark Bakke <mbakke@cisco.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686)
X-Accept-Language: en, de
MIME-Version: 1.0
To: Steve Blightman <steve@alacritech.com>
CC: ips@ece.cmu.edu
Subject: Re: [Fwd: Crc-32c example in iSCSI spec]
References: <3B7AFE96.ACCE14DF@alacritech.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Steve-

I just ran some Ethernet packets with known CRCs through
my iSCSI/Ethernet CRC generator, and found the same thing
as you did.

All of my examples need to be byte-swapped, along with the
fix I already posted for the all-ones example.  Here is a
new set of examples, which will be in -08.  I also ran
64 bytes of zeroes and ones, which now agree with your
numbers as well.

Thanks again for bringing this up.

--
Mark


     07 CRC Examples 
         
        N.B. all Values are Hexadecimal 
         
          Byte:        0  1  2  3 
         
             0:       01 a0 00 00 
             4:       00 00 00 00 
             8:       00 00 00 00 
            12:       00 00 00 00 
            16:       04 05 00 00 
            20:       00 01 00 00 
            24:       00 00 00 05 
            28:       00 00 00 04 
            32:       2a 00 00 00 
            36:       00 00 00 00 
            40:       80 00 00 00 
            44:       00 00 00 00 
         
           CRC:       93 70 51 db 
         
        32 bytes of zeroes: 
         
          Byte:        0  1  2  3 
         
             0:       00 00 00 00 
           ... 
            28:       00 00 00 00 
         
           CRC:       aa 36 91 8a 
         
        32 bytes of ones: 
  
          Byte:        0  1  2  3 
         
             0:       ff ff ff ff 
           ... 
            28:       ff ff ff ff 
         
           CRC:       43 ab a8 62 
         
        32 bytes of incrementing 00..1f: 
         
          Byte:        0  1  2  3 
         
             0:       00 01 02 03 
           ... 
            28:       1c 1d 1e 1f 
         
           CRC:       4e 79 dd 46 
 



Steve Blightman wrote:
> 
> I believe the examples for the ISCSI CRC  have the wrong endianness.
> 
> As yiou suugested over the phone I ran some Ethernet frames through a
> simulation. I have some difficulty running the exact simulations you
> wanted becuase the minimum size Ethernet frame is 64 bytes.
> 
> However using the Ethernet CRC polynomial,
> Running 64 bytes of 0 onto the wire, we append "36 63 8d 75" onto the
> wire for the CRC - "36" goes out first.
> Running 64 bytes of all 1, we append "ba 87 61 0f" onto the wire - "ba"
> goes out first.
> 
> Using the same logic for the ISCSI polynomial
> Running 64 bytes of 0 I think we should append "67 eb c8 03" - "67"
> going out first
> and running 64 bytes of all 1 we should append "66 4e cd 2f" - "66"
> going out first
> 
> And now for 32 bytes with the ISCSI polynomial
> 
> Running 32 bytes of 0 we should append "aa 36 91 8a" - "aa" going out
> first
> Running 32 bytes of all 1 we should append "43 ab a8 62" - "43" going
> out first
> 
> I don't want to get into an endless endian debate, but I believe it is
> important to get the order of these bytes in the right order, so that we
> can use the same hardware to check as well as to generate CRCs.
> 
> Thanks for your help on this,
> Steve Blightman

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054


From owner-ips@ece.cmu.edu  Thu Aug 16 12:10:35 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14666
	for <ips-archive@odin.ietf.org>; Thu, 16 Aug 2001 12:10:35 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7GFOBd10254
	for ips-outgoing; Thu, 16 Aug 2001 11:24:11 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7GFO9e10247
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 11:24:09 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA43700;
	Thu, 16 Aug 2001 11:21:58 -0400
Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7GFO3E27968;
	Thu, 16 Aug 2001 09:24:03 -0600
Importance: Normal
Subject: Re: iSCSI: Rev 07 Comments
To: Rick Ellis <rellis@integrix.com>
Cc: ips@ece.cmu.edu
From: "Jim Hafner" <hafner@almaden.ibm.com>
Date: Thu, 16 Aug 2001 08:24:01 -0700
Message-ID: <OF979FB230.A4237F71-ON88256AAA.00540C70@boulder.ibm.com>
X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at
 08/16/2001 08:24:03 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Rick,

There is no doubt that limiting to one connection per session would have
made this whole thing a lot simpler.  However, the consensus was declared
to be that the value of multiple connections dominated the extra complexity
involved.    Consequently, the model has to reflect what is reasonable
given the possible implementation choices for such a complex environment.
That led us to where we are with the model....

Jim Hafner


Rick Ellis <rellis@integrix.com>@ece.cmu.edu on 08/15/2001 04:22:23 pm

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  Re: iSCSI: Rev 07 Comments



>The iSCSI model defines portal groups as collections of network portals
>that can coordinate (at it's end) multiple connections within a session.

Why did that happen?  Wouldn't it have been a lot simpler to not allow
multiple connections within a session?  It has really complicated the
protocol.





From owner-ips@ece.cmu.edu  Thu Aug 16 12:11:22 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14737
	for <ips-archive@odin.ietf.org>; Thu, 16 Aug 2001 12:11:22 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7GFA1p09451
	for ips-outgoing; Thu, 16 Aug 2001 11:10:01 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7GF9we09446
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 11:09:58 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id RAA223062
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 17:09:27 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7GF9SS94276
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 17:09:28 +0200
Importance: Normal
Subject: iSCSI Change - New NOP-Out/In text
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF3B8DF8E1.C6FA971A-ONC2256AAA.002EF268@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Thu, 16 Aug 2001 18:09:03 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 16/08/2001 18:09:27
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Here  is the new NOP-Out/In text (2.12 & 2.13):

1.1  NOP-Out


   Byte /    0       |       1       |       2       |       3       |
      /              |               |               |               |
     |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
     +---------------+---------------+---------------+---------------+
    0|X|I| 0x00      |1| Reserved (0)                                |
     +---------------+---------------+---------------+---------------+
    4| Reserved (0)  | DataSegmentLength                             |
     +---------------+---------------+---------------+---------------+
    8| LUN or Reserved (0)                                           |
     +                                                               +
   12|                                                               |
     +---------------+---------------+---------------+---------------+
   16| Initiator Task Tag or Reserved (0xffffffff)                   |
     +---------------+---------------+---------------+---------------+
   20| Target Transfer Tag or Reserved (0xffffffff)                  |
     +---------------+---------------+---------------+---------------+
   24| CmdSN                                                         |
     +---------------+---------------+---------------+---------------+
   28| ExpStatSN                                                     |
     +---------------+---------------+---------------+---------------+
   32/ Reserved (0)                                                  /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
   48| Digests if any...                                             |
     +---------------+---------------+---------------+---------------+
     / DataSegment - Ping Data (optional)                            /
    +/                                                               /
     +---------------+---------------+---------------+---------------+

   The NOP-Out with the Initiator Task Tag set to valid value (not the
   reserved 0xffffffff) acts as a "ping command".

   This form of the NOP-Out can be used to verify that a connection is
   still active and all its components are operational. This command MAY
   use in-order delivery or immediate delivery. The NOP-Out may be useful
   in the case where an initiator has been waiting a long time for the
   response to some command, and the initiator suspects that there is some
   problem with the connection.  When a target receives the NOP-Out with a
   valid Initiator Task Tag, it should respond with a Nop-In Response,
   duplicating the data that was provided in the NOP-Out (if any) as much
   as possible.  If the initiator does not receive the NOP-In within some
   time (determined by the initiator), or if the data returned by the
   NOP-In is different from the data that was in the NOP-Out, the initiator
   may conclude that there is a problem with the connection. The initiator
   then closes the connection and may try to establish a new connection.

   A NOP-Out should also be used to confirm a changed ExpStatSN if there is
   no other PDU to carry it for a long time.

   The NOP-Out can be sent by an initiator because of a NOP-In with the
   Target Transfer Tag set to a valid value (not the reserved 0xffffffff).
   In this case the NOP-Out Target Transfer Tag must contain a copy of
   NOP-In Target Task Tag.


1.1.1     Initiator Task Tag

   An initiator assigned identifier for the operation.

   The NOP-Out must have the Initiator Task Tag set to a valid value only
   if a response in the form of NOP-In is requested.
   If the Initiator Task Tag does not contain a valid value, the CmdSN
   field contains as usual the next CmdSN but CmdSN is not advanced and the
   I bit must be set to 1.

1.1.2     Target Transfer Tag

   A target assigned identifier for the operation.

   The NOP-Out MUST have the Target Transfer Tag set only if it is issued
   in response to a NOP-In with a valid Target Transfer Tag, in which case
   it copies the Target Transfer Tag from the NOP-In PDU.

   When the Target Transfer Tag is set, the LUN field MUST be also copied
   from the NOP-In.

1.1.3     Ping Data

   Ping data is reflected in the NOP-In Response. Note that the length of
   the reflected data is limited to 4096 bytes and the initiator should
   avoid sending more than 4096 bytes. The length of ping data is indicated
   by the Data Segment Length.  0 is a valid value for the Data Segment
   Length - and indicates the absence of ping data.



1.2  NOP-In


   Byte /    0       |       1       |       2       |       3       |
      /              |               |               |               |
     |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
     +---------------+---------------+---------------+---------------+
    0|1|1| 0x20      |1| Reserved (0)                                |
     +---------------+---------------+---------------+---------------+
    4| Reserved (0)  | DataSegmentLength                             |
     +---------------+---------------+---------------+---------------+
    8| LUN or Reserved (0)                                           |
     +                                                               +
   12|                                                               |
     +---------------+---------------+---------------+---------------+
   16| Initiator Task Tag or Reserved (0xffffffff)                   |
     +---------------+---------------+---------------+---------------+
   20| Target Transfer Tag or Reserved (0xffffffff)                  |
     +---------------+---------------+---------------+---------------+
   24| StatSN                                                        |
     +---------------+---------------+---------------+---------------+
   28| ExpCmdSN                                                      |
     +---------------+---------------+---------------+---------------+
   32| MaxCmdSN                                                      |
     +---------------+---------------+---------------+---------------+
   36/ Reserved (0)                                                  /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
   48| Digests if any...                                             |
     +---------------+---------------+---------------+---------------+
     / DataSegment - Return Ping Data                                /
    +/                                                               /
     +---------------+---------------+---------------+---------------+


   When a target receives the NOP-Out with a valid Initiator Task Tag (not
   the reserved value 0xffffffff), it MUST respond with a NOP-In with the
   same Initiator Task Tag that was provided in the NOP-Out Command. It
   SHOULD also duplicate up to first 4096 bytes of the initiator provided
   Ping Data. For such a response, the Target Transfer Tag MUST be
   0xffffffff.

1.2.1     Target Transfer Tag

   A target assigned identifier for the operation.

   A target may issue a NOP-In on its own to test the connection and the
   state of the initiator. If the target wants to test the initiator, it
   sets the Target Task Tag to a valid value (not the reserved 0xffffffff)
   in order to ask for an answer from the initiator. In this case the
   Initiator Task Tag MUST be 0xffffffff and the LUN field MUST contain a
   valid LUN. If the target wants only to test the connection, both tags
   MUST hold the reserved value 0xffffffff and the LUN field is reserved.

   A target may also issue a NOP-In on its own to carry a changed ExpCmdSN
   and/or MaxCmdSN if there is no other PDU to carry them for a long time.

   Whenever the NOP-In is not issued in response to a NOP-Out the StatSN
   field will contain as usual the next StatSN but StatSN for this
   connection is not advanced.


1.2.2     LUN

   A LUN MUST be set to a correct value when the Target Transfer Tag is
   valid (not the reserved value 0xffffffff).




From owner-ips@ece.cmu.edu  Thu Aug 16 12:13:16 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14782
	for <ips-archive@odin.ietf.org>; Thu, 16 Aug 2001 12:13:15 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7GFZW012009
	for ips-outgoing; Thu, 16 Aug 2001 11:35:32 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7GFZVe12005
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 11:35:31 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id RAA285098
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 17:35:23 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7GFZOB221926
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 17:35:24 +0200
Importance: Normal
Subject: Re: iSCSI: Multiple connections questions
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF9EEC7DC3.57FE94DA-ONC2256AAA.00555425@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Thu, 16 Aug 2001 18:35:00 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 16/08/2001 18:35:23
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Trang,

Multiple connectiosn are used to improve bandwidth and/or availability.
Connection selection for a command is done by the iSCSI initiator and after
that everything related to the command goes on the same connection.

Julo



"Trang Nguyen" <tnguyen@perfisans.com>@ece.cmu.edu on 16-08-2001 00:55:48

Please respond to <tnguyen@perfisans.com>

Sent by:  owner-ips@ece.cmu.edu


To:   "IPS" <ips@ece.cmu.edu>
cc:
Subject:  iSCSI: Multiple connections questions



Hi all,

I have some questions about iSCSI multiple connections.

1.  In the iSCSI version 07, it mentions that iSCSI supports multiple
connections within a session.  In which case or condition, multiple
connections are required or necessary because I can't find any example that
I would need to make more than 1 connection between the Initiator and the
Target?

2.  Who makes the decision to add or remove the connection, iSCSI or Upper
layer?

3.  The CID appears only in the Login Command.  How does iSCSI know which
connection it should send the SCSI Command/ Data to?

I'd appreciate it very much for your answers.

Regards,

*********************************
 Trang Nguyen
 tnguyen@perfisans.com
*********************************







From owner-ips@ece.cmu.edu  Thu Aug 16 12:14:27 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14799
	for <ips-archive@odin.ietf.org>; Thu, 16 Aug 2001 12:14:27 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7GFfTa12390
	for ips-outgoing; Thu, 16 Aug 2001 11:41:29 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f7GFfSe12386
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 11:41:28 -0400 (EDT)
Received: from grubby.research.bell-labs.com ([135.104.2.9]) by crufty; Thu Aug 16 11:36:10 EDT 2001
Received: from aura.research.bell-labs.com ([135.104.46.10]) by grubby; Thu Aug 16 11:40:06 EDT 2001
Received: from research.bell-labs.com (IDENT:sandeepj@sandeepj-pcmh.research.bell-labs.com [135.104.47.90])
	by aura.research.bell-labs.com (8.9.1/8.9.1) with ESMTP id LAA09777;
	Thu, 16 Aug 2001 11:39:34 -0400 (EDT)
Message-ID: <3B7BE936.E12BB68A@research.bell-labs.com>
Date: Thu, 16 Aug 2001 11:39:34 -0400
From: Sandeep Joshi <sandeepj@research.bell-labs.com>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-3 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Julian Satran <Julian_Satran@il.ibm.com>
CC: ips@ece.cmu.edu
Subject: Re: iSCSI Change - New NOP-Out/In text
References: <OF3B8DF8E1.C6FA971A-ONC2256AAA.002EF268@telaviv.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


Julian,

Two comments

(1) Sec 1.1.1 should state that the initiator task tag is also valid 
    when the initiator sends a NOP-Out on its own.
    The word "only" below is misleading (and perhaps misplaced)

  >  The NOP-Out must have the Initiator Task Tag set to a valid value
only
  >  if a response in the form of NOP-In is requested.

(2) does "as much as possible" imply zero is value (i.e. duplicate
nothing?)
  >    duplicating the data that was provided in the NOP-Out 
  >    (if any) as much as possible.
   
-Sandeep
  

Julian Satran wrote:
> 
> Here  is the new NOP-Out/In text (2.12 & 2.13):
> 
> 1.1  NOP-Out
> 
>    Byte /    0       |       1       |       2       |       3       |
>       /              |               |               |               |
>      |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
>      +---------------+---------------+---------------+---------------+
>     0|X|I| 0x00      |1| Reserved (0)                                |
>      +---------------+---------------+---------------+---------------+
>     4| Reserved (0)  | DataSegmentLength                             |
>      +---------------+---------------+---------------+---------------+
>     8| LUN or Reserved (0)                                           |
>      +                                                               +
>    12|                                                               |
>      +---------------+---------------+---------------+---------------+
>    16| Initiator Task Tag or Reserved (0xffffffff)                   |
>      +---------------+---------------+---------------+---------------+
>    20| Target Transfer Tag or Reserved (0xffffffff)                  |
>      +---------------+---------------+---------------+---------------+
>    24| CmdSN                                                         |
>      +---------------+---------------+---------------+---------------+
>    28| ExpStatSN                                                     |
>      +---------------+---------------+---------------+---------------+
>    32/ Reserved (0)                                                  /
>     +/                                                               /
>      +---------------+---------------+---------------+---------------+
>    48| Digests if any...                                             |
>      +---------------+---------------+---------------+---------------+
>      / DataSegment - Ping Data (optional)                            /
>     +/                                                               /
>      +---------------+---------------+---------------+---------------+
> 
>    The NOP-Out with the Initiator Task Tag set to valid value (not the
>    reserved 0xffffffff) acts as a "ping command".
> 
>    This form of the NOP-Out can be used to verify that a connection is
>    still active and all its components are operational. This command MAY
>    use in-order delivery or immediate delivery. The NOP-Out may be useful
>    in the case where an initiator has been waiting a long time for the
>    response to some command, and the initiator suspects that there is some
>    problem with the connection.  When a target receives the NOP-Out with a
>    valid Initiator Task Tag, it should respond with a Nop-In Response,
>    duplicating the data that was provided in the NOP-Out (if any) as much
>    as possible.  If the initiator does not receive the NOP-In within some
>    time (determined by the initiator), or if the data returned by the
>    NOP-In is different from the data that was in the NOP-Out, the initiator
>    may conclude that there is a problem with the connection. The initiator
>    then closes the connection and may try to establish a new connection.
> 
>    A NOP-Out should also be used to confirm a changed ExpStatSN if there is
>    no other PDU to carry it for a long time.
> 
>    The NOP-Out can be sent by an initiator because of a NOP-In with the
>    Target Transfer Tag set to a valid value (not the reserved 0xffffffff).
>    In this case the NOP-Out Target Transfer Tag must contain a copy of
>    NOP-In Target Task Tag.
> 
> 1.1.1     Initiator Task Tag
> 
>    An initiator assigned identifier for the operation.
> 
>    The NOP-Out must have the Initiator Task Tag set to a valid value only
>    if a response in the form of NOP-In is requested.
>    If the Initiator Task Tag does not contain a valid value, the CmdSN
>    field contains as usual the next CmdSN but CmdSN is not advanced and the
>    I bit must be set to 1.
> 
> 1.1.2     Target Transfer Tag
> 
>    A target assigned identifier for the operation.
> 
>    The NOP-Out MUST have the Target Transfer Tag set only if it is issued
>    in response to a NOP-In with a valid Target Transfer Tag, in which case
>    it copies the Target Transfer Tag from the NOP-In PDU.
> 
>    When the Target Transfer Tag is set, the LUN field MUST be also copied
>    from the NOP-In.
> 
> 1.1.3     Ping Data
> 
>    Ping data is reflected in the NOP-In Response. Note that the length of
>    the reflected data is limited to 4096 bytes and the initiator should
>    avoid sending more than 4096 bytes. The length of ping data is indicated
>    by the Data Segment Length.  0 is a valid value for the Data Segment
>    Length - and indicates the absence of ping data.
> 
> 1.2  NOP-In
> 
>    Byte /    0       |       1       |       2       |       3       |
>       /              |               |               |               |
>      |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
>      +---------------+---------------+---------------+---------------+
>     0|1|1| 0x20      |1| Reserved (0)                                |
>      +---------------+---------------+---------------+---------------+
>     4| Reserved (0)  | DataSegmentLength                             |
>      +---------------+---------------+---------------+---------------+
>     8| LUN or Reserved (0)                                           |
>      +                                                               +
>    12|                                                               |
>      +---------------+---------------+---------------+---------------+
>    16| Initiator Task Tag or Reserved (0xffffffff)                   |
>      +---------------+---------------+---------------+---------------+
>    20| Target Transfer Tag or Reserved (0xffffffff)                  |
>      +---------------+---------------+---------------+---------------+
>    24| StatSN                                                        |
>      +---------------+---------------+---------------+---------------+
>    28| ExpCmdSN                                                      |
>      +---------------+---------------+---------------+---------------+
>    32| MaxCmdSN                                                      |
>      +---------------+---------------+---------------+---------------+
>    36/ Reserved (0)                                                  /
>     +/                                                               /
>      +---------------+---------------+---------------+---------------+
>    48| Digests if any...                                             |
>      +---------------+---------------+---------------+---------------+
>      / DataSegment - Return Ping Data                                /
>     +/                                                               /
>      +---------------+---------------+---------------+---------------+
> 
>    When a target receives the NOP-Out with a valid Initiator Task Tag (not
>    the reserved value 0xffffffff), it MUST respond with a NOP-In with the
>    same Initiator Task Tag that was provided in the NOP-Out Command. It
>    SHOULD also duplicate up to first 4096 bytes of the initiator provided
>    Ping Data. For such a response, the Target Transfer Tag MUST be
>    0xffffffff.
> 
> 1.2.1     Target Transfer Tag
> 
>    A target assigned identifier for the operation.
> 
>    A target may issue a NOP-In on its own to test the connection and the
>    state of the initiator. If the target wants to test the initiator, it
>    sets the Target Task Tag to a valid value (not the reserved 0xffffffff)
>    in order to ask for an answer from the initiator. In this case the
>    Initiator Task Tag MUST be 0xffffffff and the LUN field MUST contain a
>    valid LUN. If the target wants only to test the connection, both tags
>    MUST hold the reserved value 0xffffffff and the LUN field is reserved.
> 
>    A target may also issue a NOP-In on its own to carry a changed ExpCmdSN
>    and/or MaxCmdSN if there is no other PDU to carry them for a long time.
> 
>    Whenever the NOP-In is not issued in response to a NOP-Out the StatSN
>    field will contain as usual the next StatSN but StatSN for this
>    connection is not advanced.
> 
> 1.2.2     LUN
> 
>    A LUN MUST be set to a correct value when the Target Transfer Tag is
>    valid (not the reserved value 0xffffffff).


From owner-ips@ece.cmu.edu  Thu Aug 16 12:15:55 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14874
	for <ips-archive@odin.ietf.org>; Thu, 16 Aug 2001 12:15:55 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7GFcMq12207
	for ips-outgoing; Thu, 16 Aug 2001 11:38:22 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7GFcKe12202
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 11:38:20 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id RAA251070
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 17:38:13 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7GFcDB152726
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 17:38:13 +0200
Importance: Normal
Subject: RE: iSCSI Re: Questions on iSCSI 07
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF48B37D67.5CFD0F8A-ONC2256AAA.0055B062@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Thu, 16 Aug 2001 18:37:48 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 16/08/2001 18:38:12
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Answers in text - Julo

"Trang Nguyen" <tnguyen@perfisans.com> on 16-08-2001 01:29:14

Please respond to <tnguyen@perfisans.com>

To:   Julian Satran/Haifa/IBM@IBMIL, <ips@ece.cmu.edu>
cc:
Subject:  RE: iSCSI Re: Questions on iSCSI 07



Hi Julian,

I have a question on Lee's Q7 and your answer.

If the old session is still alive, does it mean that there is at least one
connection between the initiator and the target.  If it is true, then to
reset the old session the target also has to disconnect all the connections
in the old session, except the connection of the Login Command.

+++ If it is alive then a new session will not be established - nor the old
reset
+++
========================================================================
Q7:
Page 69: "When a target is detecting an attempt to open a new session by
the same initiator (same InitiatorName and ISID) it MUST check if the
old session is active.  If it is not the old-session must be reset by
the target and the new session established. Otherwise the Login MUST be
terminated with a Login Response."

What does "reset" exactly mean here?

+++ clean its internal state - remove anything non-persistent data related
to the old session
+++
============================================================================



Thanks,

*********************************
 Trang Nguyen
 tnguyen@perfisans.com
*********************************


-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Julian Satran
Sent: August 15, 2001 3:29 PM
To: ips@ece.cmu.edu
Subject: iSCSI Re: Questions on iSCSI 07



Comments in text - thanks - Julo

"Lee Xing" <lxing@Crossroads.com>@ece.cmu.edu on 15-08-2001 17:27:17

Please respond to "Lee Xing" <lxing@Crossroads.com>

Sent by:  owner-ips@ece.cmu.edu


To:   <ips@ece.cmu.edu>
cc:
Subject:  Questions on iSCSI 07



Hi All,

I have a few questions on iSCSI 07.  I would appreciate it if someone
could explain them.

Thank you.


Lee Xing
Sr. Software Engineer
Crossroads Systems, Inc.

----------------------------------------------
Q1:
Page 104: "Operational parameters MAY be negotiated outside (after) the
login phase."
Page 157: "Some session specific parameters MUST be carried only on the
leading connection and cannot be changed after the leading connection
login..."

If operational parameters are considered as session parameters, then
should we reword the sentence on page 104, such as "Some operational
parameters MAY be negotiated outside (after) the login phase."?


+++ will fix +++
----------------------------------------------
Q2:
Page 22: "Any PDU except login and text, which is sent on a TCP
connection before this connection gets into full feature phase, is a
protocol error."

Page 169: "To make use of SendTargets, an initiator must first be logged
in to one of two types of targets."

Since SendTargets is one of the keys for Text Cmds, and we can't issue
it before logging in, we probably should reword the sentence on page 22.

+++ will read:

Any PDU except login and text, which is sent on a TCP connection before
this connection gets into full feature phase, is a protocol error. Some
text command parameters also allowed only in full feature phase (e.g.,
SendTargets).

++++
----------------------------------------------
Q3: Page 169: "If it logs in to any other target, the session the
session can be either a discovery session or a normal operational
session".  Should we delete one "the session" from this sentence?
+++
??? can't find it
+++
----------------------------------------------
Q4: Why don't section 1.2.2.1 & 1.2.2.2 address where CmdSN & StatSN
should start from (0, 1, or whatever) explicitly like DataSN does?
Should we initialize the counters before start the process?
+++ third paragraph of 1.2.2.1 says now
Commands in transit from the initiator to the target layer are numbered by
iSCSI; the number is carried by the iSCSI PDU as CmdSN
(Command-Sequence-Number).  The numbering is session-wide and starts with a
value set by the initiator during the first login of a session (leading
login).

and 1.2.2.2 gstates:

   The first login response includes an initial value for status numbering.

 +++
----------------------------------------------
Q5: Page 102: "An operational parameter negotiation on a connection
SHOULD not start before the security/integrity negotiation if such a
negotiation exists.  Operational parameters negotiated inadvertently
before the security/integrity negotiation MAY be reset after the
security/integrity negotiation at the explicit request of the initiator
or target."

The question is under which circumstance do we need to negotiate
operational parameters before security/integrity negotiation?  If it's
unlikely to happen, why do we leave a potential security hole here?
+++ this will be clarified in an upcoming writeup
+++
----------------------------------------------
Q6:
Page 21: "... ... If an initiator and target are connected through more
than one session, both the initiator and target perceive the other as a
different entity on each session (a different I_T nexus in SAM-2
parlance)."

Page 69: "When a target is detecting an attempt to open a new session by
the same initiator (same InitiatorName and ISID) it MUST check if the
old session is active.  If it is not the old-session must be reset by
the target and the new session established. Otherwise the Login MUST be
terminated with a Login Response."

The sentence on page 21 tells us multi-sessions between an initiator and
a target are allowed; while the sentence on page 69 implies they are
not.  We probably need to clear it a bit.
+++ No it tells you that the target must check if the old connections are
still alive.  If they are this attempt is an error. If they are not the
target has not realized the old session has gone away (e.g. a client
reboot). I reformulate as:

   When a target is detecting an attempt to open a new session by the same
   SCSI initiator port (same InitiatorName and ISID) to the same target
   portal group it MUST check if the old session is still active.  If it is
   not active and the target has failed to realize that the old-session
   must be reset by the target and the new session established. Otherwise
   the Login MUST be terminated with a Login Response of "Session already
   open with this initiator".
   ++++

----------------------------------------------
Q7:
Page 69: "When a target is detecting an attempt to open a new session by
the same initiator (same InitiatorName and ISID) it MUST check if the
old session is active.  If it is not the old-session must be reset by
the target and the new session established. Otherwise the Login MUST be
terminated with a Login Response."

What does "reset" exactly mean here?

+++ clean its internal state - remove anything non-persistent data related
to the old session
+++
----------------------------------------------
Q8: This question is on multi-path.  Suppose two NICs are connected to
the same target, therefore we could have at least two target addresses
a1 & a2.  Suppose address a1 needs to be dedicated to a particular
initiator I1.  Is it OK if we let the target to hide a1 from (i.e. not
sending a1 with "SendTargets" cmd response to) all initiators except I1,
or do we need to modify 07 to do so?

The current Standard 07 on page 171 says "If a SendTargets response
reports an iSCSI address for a target, it SHOULD also report all other
addresses in its portal group in the same response."

+++ It is OK to hide the NIC. Portal groups are meant for groups of
physical ports that MAY share state+++
----------------------------------------------
Q9:  This is a performance-related question.

After the first (leading) connection logs into a normal operational
session, why can't the same initiator have an option to just "spawn"
more "full featured" connections with the same target without running
Login handshake processes (i.e. authenticate the parties, negotiate the
session's parameters, open security associations protocol and make
connections as belonging to a session) again.  It would be more
efficient if we could have this option.

It seems feasible because:

  - it's not necessary to authenticate both parties
    again after doing so on the first (leading)
    connection.
  - security is still possessed without running
    Login process on the following connections
    because the first (leading) connection has to
    run Login process, and no extra connections
    can be spawned without logging into the first
    one.
  - session parameters, generally, are the same
    for connections within a session.  If not, they
    can be re-negotiated later.
  - All connections within a session belong to
    the same I_T nexus.
  - Text Cmds can be used to "spawn" full-featured
    connections without adding too much stuff into
    iSCSI Standard or making it too complex.


+++  I don't understand exactly what you are suggesting here. Every TCP
connection raises the authentication issue (parties can't be sure that
simple things like IP addresses are not spoofed. More complicted things
(shared secrets) could be used and we looked at them in the past and did
not find that it is worth pursuing them. And different connections may have
different security requirements (a private line vs. a public line).
++++








From owner-ips@ece.cmu.edu  Thu Aug 16 12:16:01 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14885
	for <ips-archive@odin.ietf.org>; Thu, 16 Aug 2001 12:16:01 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7GFmQT12779
	for ips-outgoing; Thu, 16 Aug 2001 11:48:26 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7GFmOe12774
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 11:48:25 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id RAA250534
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 17:48:17 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7GFmHB176780
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 17:48:17 +0200
Importance: Normal
Subject: Re:
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF8FB02066.8A9F1ADB-ONC2256AAA.0055F6E1@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Thu, 16 Aug 2001 18:47:54 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 16/08/2001 18:48:17
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

answers in text - Julo

"Trang Nguyen" <tnguyen@perfisans.com>@ece.cmu.edu on 16-08-2001 01:54:56

Please respond to <tnguyen@perfisans.com>

Sent by:  owner-ips@ece.cmu.edu


To:   "IPS" <ips@ece.cmu.edu>
cc:
Subject:



Hi all,

Could you please help me with these questions?

1.  Is iSCSI task the same as SCSI task?

+++++
A SCSI task is also an iSCSI task. An iSCSI task may not involve a SCSI
task (e.g., a text exchange).

++++

In section 1.1:

     "A SCSI task is a SCSI command or possibly a linked set of SCSI
commands."

     "An iSCSI task is an iSCSI request for which a response is expected.

     In this document "iSCSI request", "iSCSI command", request or
unqualified)
     command have the same meaning.  Also, unless specified otherwise,
status,
     response or numbered response have the same meaning."

According to these definitions, they are different.  iSCSI task is an iSCSI
command.  If so, then is Initiator Task Tag the same as CmdSN?
++++ no and that is clearly stated in text - CmdSN is irrelent after the
command/request starts executing ++++

2.  In iSCSI version 07:
     "2.2.2.8 Initiator Task Tag

        The initiator assigns a Task Tag to each iSCSI task that it issues.
        While a task exists this tag MUST uniquely identify it
session-wide.
"

Is this Initiator Task Tag the same as the Task Tags defined in section
4.9.2 in SAM-2 (revision 19)?  As quoted from SAM-2: "An initiator assigns
tag values in each tagged task identifier in a way that ensures that the
identifier uniqueness requirements stated in 4.9 are met."
+++ yes +++
3.  How does the iSCSI target use the Initiator Task Tag to process the
commands?
+++ the initiator task tag identifies the command while executing. It
relates data, status etc. to the task. I assume that targets will use it to
tag an internal control block while the command is active +++
Thanks a lot,

*********************************
 Trang Nguyen
 tnguyen@perfisans.com
 *********************************







From owner-ips@ece.cmu.edu  Thu Aug 16 12:18:06 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14958
	for <ips-archive@odin.ietf.org>; Thu, 16 Aug 2001 12:18:06 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7GFUth11721
	for ips-outgoing; Thu, 16 Aug 2001 11:30:55 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7GFUse11716
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 11:30:54 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id RAA137114
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 17:30:46 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7GFUkB83418
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 17:30:46 +0200
Importance: Normal
Subject: Re: iSCSI: Rev 07 Comments
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFD3BB0F28.EC571522-ONC2256AAA.00550D6E@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Thu, 16 Aug 2001 18:30:22 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 16/08/2001 18:30:45
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


will fix - thanks - Julo

"Bill Moody" <bmoody@Crossroads.com>@ece.cmu.edu on 16-08-2001 00:16:04

Please respond to "Bill Moody" <bmoody@Crossroads.com>

Sent by:  owner-ips@ece.cmu.edu


To:   "IP Storage Mailing List (E-mail)" <ips@ece.cmu.edu>
cc:   "Robert Griswold" <rgriswold@Crossroads.com>, "Bill Moody"
      <bmoody@Crossroads.com>
Subject:  iSCSI:  Rev 07 Comments



I have a couple of points I'd like to raise concerning the 07 version of
the document.

Section 1.5.3.  On page 39, under 'iSCSI Initiator Requirements' the
term initiator portal group is used multiple times.  This is the first
use of this term and led to some confusion on my part.  The 'portal
group' term was clearly defined earlier and was used repeatedly in
connection with the target but no mention has been made of the use of
initiator portal groups prior to this point.  The ISID RULE clearly
defines that only one session with a given ISID can exist between a
given iSCSI Initiator and iSCSI Target Portal Group - it doesn't mention
initiator portal groups.  It would be nice to define this 'initiator
portal group' term prior to its use.

Appendix A.  What is the meaning of the value '11EDC6F41' in the table?
Is this the generator polynomial that is discussed in the following
paragraph?  If so, it is not clear.

Thanks,

Bill Moody
Architect
Crossroads Systems, Inc.
Phone:  (512) 928-7238
Fax:  (512)-928-7402






From owner-ips@ece.cmu.edu  Thu Aug 16 12:46:48 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15716
	for <ips-archive@odin.ietf.org>; Thu, 16 Aug 2001 12:46:47 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7GG0RV13461
	for ips-outgoing; Thu, 16 Aug 2001 12:00:27 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mxic1.isus.emc.com ([168.159.129.100])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7GG0Qe13455
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 12:00:26 -0400 (EDT)
Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <QQ9CLQB3>; Thu, 16 Aug 2001 12:02:24 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD5E1@CORPMX14>
From: Black_David@emc.com
To: ips@ece.cmu.edu
Subject: IPS: Well-known ports
Date: Thu, 16 Aug 2001 11:54:39 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

One of the things on my to-do list from the Nashua interim
meeting was to look into assignment of well-known port numbers
for iSCSI, FCIP and iFCP.  IANA requires that an application
be submitted - I would recommend the usage of System ports
for our protocols, see:

http://www.iana.org/cgi-bin/sys-port-number.pl

User ports are an alternative if the above doesn't work
for some reason:

http://www.iana.org/cgi-bin/usr-port-number.pl

I would ask the Technical Coordinators and draft authors
to find a volunteer to complete the application for each
protocol and report the resulting assignment to the list.
This needs to be done in fairly short order to get iSCSI
in particular away from using port 5003 as its well-known
port, which it SHOULD NOT be doing (so sayeth the ADs).

Sorry for the delay on this, and many thanks to whomever
the volunteers/victims are who take care of these applications.

Thanks,
--David (overworked WG co-chair)

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


From owner-ips@ece.cmu.edu  Thu Aug 16 12:47:05 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15733
	for <ips-archive@odin.ietf.org>; Thu, 16 Aug 2001 12:47:05 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7GGAda14113
	for ips-outgoing; Thu, 16 Aug 2001 12:10:39 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7GGAbe14108
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 12:10:37 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id SAA159006
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 18:10:31 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7GGAUS46178
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 18:10:30 +0200
Importance: Normal
Subject: Re: iSCSI Change - New NOP-Out/In text
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF9C1BB142.7601C932-ONC2256AAA.00580AB1@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Thu, 16 Aug 2001 19:10:05 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 16/08/2001 19:10:30
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Sandeep,

ITT is the only indicator now that a response is expected.

As much as possible means 4096 (I'll try to put it in here too).

Julo


Sandeep Joshi <sandeepj@research.bell-labs.com>@research.bell-labs.com on
16-08-2001 18:39:34

Please respond to Sandeep Joshi <sandeepj@research.bell-labs.com>

Sent by:  sandeepj@research.bell-labs.com


To:   Julian Satran/Haifa/IBM@IBMIL
cc:   ips@ece.cmu.edu
Subject:  Re: iSCSI Change - New NOP-Out/In text




Julian,

Two comments

(1) Sec 1.1.1 should state that the initiator task tag is also valid
    when the initiator sends a NOP-Out on its own.
    The word "only" below is misleading (and perhaps misplaced)

  >  The NOP-Out must have the Initiator Task Tag set to a valid value
only
  >  if a response in the form of NOP-In is requested.

(2) does "as much as possible" imply zero is value (i.e. duplicate
nothing?)
  >    duplicating the data that was provided in the NOP-Out
  >    (if any) as much as possible.

-Sandeep


Julian Satran wrote:
>
> Here  is the new NOP-Out/In text (2.12 & 2.13):
>
> 1.1  NOP-Out
>
>    Byte /    0       |       1       |       2       |       3       |
>       /              |               |               |               |
>      |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
>      +---------------+---------------+---------------+---------------+
>     0|X|I| 0x00      |1| Reserved (0)                                |
>      +---------------+---------------+---------------+---------------+
>     4| Reserved (0)  | DataSegmentLength                             |
>      +---------------+---------------+---------------+---------------+
>     8| LUN or Reserved (0)                                           |
>      +                                                               +
>    12|                                                               |
>      +---------------+---------------+---------------+---------------+
>    16| Initiator Task Tag or Reserved (0xffffffff)                   |
>      +---------------+---------------+---------------+---------------+
>    20| Target Transfer Tag or Reserved (0xffffffff)                  |
>      +---------------+---------------+---------------+---------------+
>    24| CmdSN                                                         |
>      +---------------+---------------+---------------+---------------+
>    28| ExpStatSN                                                     |
>      +---------------+---------------+---------------+---------------+
>    32/ Reserved (0)                                                  /
>     +/                                                               /
>      +---------------+---------------+---------------+---------------+
>    48| Digests if any...                                             |
>      +---------------+---------------+---------------+---------------+
>      / DataSegment - Ping Data (optional)                            /
>     +/                                                               /
>      +---------------+---------------+---------------+---------------+
>
>    The NOP-Out with the Initiator Task Tag set to valid value (not the
>    reserved 0xffffffff) acts as a "ping command".
>
>    This form of the NOP-Out can be used to verify that a connection is
>    still active and all its components are operational. This command MAY
>    use in-order delivery or immediate delivery. The NOP-Out may be useful
>    in the case where an initiator has been waiting a long time for the
>    response to some command, and the initiator suspects that there is
some
>    problem with the connection.  When a target receives the NOP-Out with
a
>    valid Initiator Task Tag, it should respond with a Nop-In Response,
>    duplicating the data that was provided in the NOP-Out (if any) as much
>    as possible.  If the initiator does not receive the NOP-In within some
>    time (determined by the initiator), or if the data returned by the
>    NOP-In is different from the data that was in the NOP-Out, the
initiator
>    may conclude that there is a problem with the connection. The
initiator
>    then closes the connection and may try to establish a new connection.
>
>    A NOP-Out should also be used to confirm a changed ExpStatSN if there
is
>    no other PDU to carry it for a long time.
>
>    The NOP-Out can be sent by an initiator because of a NOP-In with the
>    Target Transfer Tag set to a valid value (not the reserved
0xffffffff).
>    In this case the NOP-Out Target Transfer Tag must contain a copy of
>    NOP-In Target Task Tag.
>
> 1.1.1     Initiator Task Tag
>
>    An initiator assigned identifier for the operation.
>
>    The NOP-Out must have the Initiator Task Tag set to a valid value only
>    if a response in the form of NOP-In is requested.
>    If the Initiator Task Tag does not contain a valid value, the CmdSN
>    field contains as usual the next CmdSN but CmdSN is not advanced and
the
>    I bit must be set to 1.
>
> 1.1.2     Target Transfer Tag
>
>    A target assigned identifier for the operation.
>
>    The NOP-Out MUST have the Target Transfer Tag set only if it is issued
>    in response to a NOP-In with a valid Target Transfer Tag, in which
case
>    it copies the Target Transfer Tag from the NOP-In PDU.
>
>    When the Target Transfer Tag is set, the LUN field MUST be also copied
>    from the NOP-In.
>
> 1.1.3     Ping Data
>
>    Ping data is reflected in the NOP-In Response. Note that the length of
>    the reflected data is limited to 4096 bytes and the initiator should
>    avoid sending more than 4096 bytes. The length of ping data is
indicated
>    by the Data Segment Length.  0 is a valid value for the Data Segment
>    Length - and indicates the absence of ping data.
>
> 1.2  NOP-In
>
>    Byte /    0       |       1       |       2       |       3       |
>       /              |               |               |               |
>      |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
>      +---------------+---------------+---------------+---------------+
>     0|1|1| 0x20      |1| Reserved (0)                                |
>      +---------------+---------------+---------------+---------------+
>     4| Reserved (0)  | DataSegmentLength                             |
>      +---------------+---------------+---------------+---------------+
>     8| LUN or Reserved (0)                                           |
>      +                                                               +
>    12|                                                               |
>      +---------------+---------------+---------------+---------------+
>    16| Initiator Task Tag or Reserved (0xffffffff)                   |
>      +---------------+---------------+---------------+---------------+
>    20| Target Transfer Tag or Reserved (0xffffffff)                  |
>      +---------------+---------------+---------------+---------------+
>    24| StatSN                                                        |
>      +---------------+---------------+---------------+---------------+
>    28| ExpCmdSN                                                      |
>      +---------------+---------------+---------------+---------------+
>    32| MaxCmdSN                                                      |
>      +---------------+---------------+---------------+---------------+
>    36/ Reserved (0)                                                  /
>     +/                                                               /
>      +---------------+---------------+---------------+---------------+
>    48| Digests if any...                                             |
>      +---------------+---------------+---------------+---------------+
>      / DataSegment - Return Ping Data                                /
>     +/                                                               /
>      +---------------+---------------+---------------+---------------+
>
>    When a target receives the NOP-Out with a valid Initiator Task Tag
(not
>    the reserved value 0xffffffff), it MUST respond with a NOP-In with the
>    same Initiator Task Tag that was provided in the NOP-Out Command. It
>    SHOULD also duplicate up to first 4096 bytes of the initiator provided
>    Ping Data. For such a response, the Target Transfer Tag MUST be
>    0xffffffff.
>
> 1.2.1     Target Transfer Tag
>
>    A target assigned identifier for the operation.
>
>    A target may issue a NOP-In on its own to test the connection and the
>    state of the initiator. If the target wants to test the initiator, it
>    sets the Target Task Tag to a valid value (not the reserved
0xffffffff)
>    in order to ask for an answer from the initiator. In this case the
>    Initiator Task Tag MUST be 0xffffffff and the LUN field MUST contain a
>    valid LUN. If the target wants only to test the connection, both tags
>    MUST hold the reserved value 0xffffffff and the LUN field is reserved.
>
>    A target may also issue a NOP-In on its own to carry a changed
ExpCmdSN
>    and/or MaxCmdSN if there is no other PDU to carry them for a long
time.
>
>    Whenever the NOP-In is not issued in response to a NOP-Out the StatSN
>    field will contain as usual the next StatSN but StatSN for this
>    connection is not advanced.
>
> 1.2.2     LUN
>
>    A LUN MUST be set to a correct value when the Target Transfer Tag is
>    valid (not the reserved value 0xffffffff).





From owner-ips@ece.cmu.edu  Thu Aug 16 12:50:48 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15829
	for <ips-archive@odin.ietf.org>; Thu, 16 Aug 2001 12:50:48 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7GGA3W14079
	for ips-outgoing; Thu, 16 Aug 2001 12:10:03 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7GGA1e14074
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 12:10:01 -0400 (EDT)
Received: from ahganemw2k (dhcp-161-44-68-168.cisco.com [161.44.68.168]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id MAA03439 for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 12:09:55 -0400 (EDT)
From: "Ayman Ghanem" <aghanem@cisco.com>
To: <ips@ece.cmu.edu>
Subject: RE: iSCSI Change - New NOP-Out/In text
Date: Thu, 16 Aug 2001 11:08:59 -0500
Message-ID: <LOEPJENHBHAHEABBNDAJKEPDCCAA.aghanem@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
In-Reply-To: <3B7BE936.E12BB68A@research.bell-labs.com>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

From reading the new text, the initiator/target task tags are used to
indicate what the poll-bit used to do. If the task tag is valid, then a
response is requested, otherwise its a one-way message. The way I understand
1.1.1 is that the initiator can send a NOP-Out on its own and set the itt to
valid/reserved value depending on whether it is requesting a NOP-In or not.

-Ayman


> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Sandeep Joshi
> Sent: Thursday, August 16, 2001 10:40 AM
> To: Julian Satran
> Cc: ips@ece.cmu.edu
> Subject: Re: iSCSI Change - New NOP-Out/In text
>
>
>
> Julian,
>
> Two comments
>
> (1) Sec 1.1.1 should state that the initiator task tag is also valid
>     when the initiator sends a NOP-Out on its own.
>     The word "only" below is misleading (and perhaps misplaced)
>
>   >  The NOP-Out must have the Initiator Task Tag set to a valid value
> only
>   >  if a response in the form of NOP-In is requested.
>
> (2) does "as much as possible" imply zero is value (i.e. duplicate
> nothing?)
>   >    duplicating the data that was provided in the NOP-Out
>   >    (if any) as much as possible.
>
> -Sandeep
>
>
> Julian Satran wrote:
> >
> > Here  is the new NOP-Out/In text (2.12 & 2.13):
> >
> > 1.1  NOP-Out
> >
> >    Byte /    0       |       1       |       2       |       3       |
> >       /              |               |               |               |
> >      |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
> >      +---------------+---------------+---------------+---------------+
> >     0|X|I| 0x00      |1| Reserved (0)                                |
> >      +---------------+---------------+---------------+---------------+
> >     4| Reserved (0)  | DataSegmentLength                             |
> >      +---------------+---------------+---------------+---------------+
> >     8| LUN or Reserved (0)                                           |
> >      +                                                               +
> >    12|                                                               |
> >      +---------------+---------------+---------------+---------------+
> >    16| Initiator Task Tag or Reserved (0xffffffff)                   |
> >      +---------------+---------------+---------------+---------------+
> >    20| Target Transfer Tag or Reserved (0xffffffff)                  |
> >      +---------------+---------------+---------------+---------------+
> >    24| CmdSN                                                         |
> >      +---------------+---------------+---------------+---------------+
> >    28| ExpStatSN                                                     |
> >      +---------------+---------------+---------------+---------------+
> >    32/ Reserved (0)                                                  /
> >     +/                                                               /
> >      +---------------+---------------+---------------+---------------+
> >    48| Digests if any...                                             |
> >      +---------------+---------------+---------------+---------------+
> >      / DataSegment - Ping Data (optional)                            /
> >     +/                                                               /
> >      +---------------+---------------+---------------+---------------+
> >
> >    The NOP-Out with the Initiator Task Tag set to valid value (not the
> >    reserved 0xffffffff) acts as a "ping command".
> >
> >    This form of the NOP-Out can be used to verify that a connection is
> >    still active and all its components are operational. This command MAY
> >    use in-order delivery or immediate delivery. The NOP-Out may
> be useful
> >    in the case where an initiator has been waiting a long time for the
> >    response to some command, and the initiator suspects that
> there is some
> >    problem with the connection.  When a target receives the
> NOP-Out with a
> >    valid Initiator Task Tag, it should respond with a Nop-In Response,
> >    duplicating the data that was provided in the NOP-Out (if
> any) as much
> >    as possible.  If the initiator does not receive the NOP-In
> within some
> >    time (determined by the initiator), or if the data returned by the
> >    NOP-In is different from the data that was in the NOP-Out,
> the initiator
> >    may conclude that there is a problem with the connection.
> The initiator
> >    then closes the connection and may try to establish a new connection.
> >
> >    A NOP-Out should also be used to confirm a changed ExpStatSN
> if there is
> >    no other PDU to carry it for a long time.
> >
> >    The NOP-Out can be sent by an initiator because of a NOP-In with the
> >    Target Transfer Tag set to a valid value (not the reserved
> 0xffffffff).
> >    In this case the NOP-Out Target Transfer Tag must contain a copy of
> >    NOP-In Target Task Tag.
> >
> > 1.1.1     Initiator Task Tag
> >
> >    An initiator assigned identifier for the operation.
> >
> >    The NOP-Out must have the Initiator Task Tag set to a valid
> value only
> >    if a response in the form of NOP-In is requested.
> >    If the Initiator Task Tag does not contain a valid value, the CmdSN
> >    field contains as usual the next CmdSN but CmdSN is not
> advanced and the
> >    I bit must be set to 1.
> >
> > 1.1.2     Target Transfer Tag
> >
> >    A target assigned identifier for the operation.
> >
> >    The NOP-Out MUST have the Target Transfer Tag set only if it
> is issued
> >    in response to a NOP-In with a valid Target Transfer Tag, in
> which case
> >    it copies the Target Transfer Tag from the NOP-In PDU.
> >
> >    When the Target Transfer Tag is set, the LUN field MUST be
> also copied
> >    from the NOP-In.
> >
> > 1.1.3     Ping Data
> >
> >    Ping data is reflected in the NOP-In Response. Note that the
> length of
> >    the reflected data is limited to 4096 bytes and the initiator should
> >    avoid sending more than 4096 bytes. The length of ping data
> is indicated
> >    by the Data Segment Length.  0 is a valid value for the Data Segment
> >    Length - and indicates the absence of ping data.
> >
> > 1.2  NOP-In
> >
> >    Byte /    0       |       1       |       2       |       3       |
> >       /              |               |               |               |
> >      |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
> >      +---------------+---------------+---------------+---------------+
> >     0|1|1| 0x20      |1| Reserved (0)                                |
> >      +---------------+---------------+---------------+---------------+
> >     4| Reserved (0)  | DataSegmentLength                             |
> >      +---------------+---------------+---------------+---------------+
> >     8| LUN or Reserved (0)                                           |
> >      +                                                               +
> >    12|                                                               |
> >      +---------------+---------------+---------------+---------------+
> >    16| Initiator Task Tag or Reserved (0xffffffff)                   |
> >      +---------------+---------------+---------------+---------------+
> >    20| Target Transfer Tag or Reserved (0xffffffff)                  |
> >      +---------------+---------------+---------------+---------------+
> >    24| StatSN                                                        |
> >      +---------------+---------------+---------------+---------------+
> >    28| ExpCmdSN                                                      |
> >      +---------------+---------------+---------------+---------------+
> >    32| MaxCmdSN                                                      |
> >      +---------------+---------------+---------------+---------------+
> >    36/ Reserved (0)                                                  /
> >     +/                                                               /
> >      +---------------+---------------+---------------+---------------+
> >    48| Digests if any...                                             |
> >      +---------------+---------------+---------------+---------------+
> >      / DataSegment - Return Ping Data                                /
> >     +/                                                               /
> >      +---------------+---------------+---------------+---------------+
> >
> >    When a target receives the NOP-Out with a valid Initiator
> Task Tag (not
> >    the reserved value 0xffffffff), it MUST respond with a
> NOP-In with the
> >    same Initiator Task Tag that was provided in the NOP-Out Command. It
> >    SHOULD also duplicate up to first 4096 bytes of the
> initiator provided
> >    Ping Data. For such a response, the Target Transfer Tag MUST be
> >    0xffffffff.
> >
> > 1.2.1     Target Transfer Tag
> >
> >    A target assigned identifier for the operation.
> >
> >    A target may issue a NOP-In on its own to test the connection and the
> >    state of the initiator. If the target wants to test the initiator, it
> >    sets the Target Task Tag to a valid value (not the reserved
> 0xffffffff)
> >    in order to ask for an answer from the initiator. In this case the
> >    Initiator Task Tag MUST be 0xffffffff and the LUN field MUST
> contain a
> >    valid LUN. If the target wants only to test the connection, both tags
> >    MUST hold the reserved value 0xffffffff and the LUN field is
> reserved.
> >
> >    A target may also issue a NOP-In on its own to carry a
> changed ExpCmdSN
> >    and/or MaxCmdSN if there is no other PDU to carry them for a
> long time.
> >
> >    Whenever the NOP-In is not issued in response to a NOP-Out the StatSN
> >    field will contain as usual the next StatSN but StatSN for this
> >    connection is not advanced.
> >
> > 1.2.2     LUN
> >
> >    A LUN MUST be set to a correct value when the Target Transfer Tag is
> >    valid (not the reserved value 0xffffffff).
>



From owner-ips@ece.cmu.edu  Thu Aug 16 12:54:13 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15889
	for <ips-archive@odin.ietf.org>; Thu, 16 Aug 2001 12:54:13 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7GG9a314054
	for ips-outgoing; Thu, 16 Aug 2001 12:09:36 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7GG9Ye14050
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 12:09:34 -0400 (EDT)
Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id QAA18426
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 16:09:33 GMT
Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29])
 by fmsmsxvs043.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001081609085312925
 ; Thu, 16 Aug 2001 09:08:53 -0700
Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <QVMRNNMV>; Thu, 16 Aug 2001 09:09:32 -0700
Message-ID: <638EC1B28663D211AC3E00A0C96B78A8086ABB11@orsmsx40.jf.intel.com>
From: "Wheat, Stephen R" <stephen.r.wheat@intel.com>
To: "'Julian Satran'" <Julian_Satran@il.ibm.com>, ips@ece.cmu.edu
Subject: RE: iSCSI Change - New NOP-Out/In text
Date: Thu, 16 Aug 2001 09:09:30 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Julian,

As a relatively new reader of all this good material, perhaps some "new
eyes" editorial questions/suggestions are of value.  My apologies up front
if this doesn't meet with the WG protocol for such suggestions.

Stephen

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, August 16, 2001 8:09 AM
To: ips@ece.cmu.edu
Subject: iSCSI Change - New NOP-Out/In text
   
+++ srw
The first two paragraphs intermix rational and specification for a "ping
command".
Rational is also repeated.
For brevity and clarity, I suggest striving to keep rational segregated from
semantic definition.

Also, the target's semantics are inconsistent between the NOP-out and NOP-in
paragraphs.

I offer the following text update.

I am willing to do such editorial changes for the rest, but am awaiting
whether the suggestions are valuable.
+++ srw

   A NOP-Out may be sent by an initiator as a "ping command".  This form of
the NOP-Out
   can be used to verify that a connection is still active and all its
components are
   operational.  Based upon whether a corresponding NOP-In is received, this
   provides an initiator a way to determine whether it may be necessary to
   close the connection and try to establish a new connection.

   A NOP-Out is also sent by an initiator in response to a NOP-In.

   A NOP-Out may also be used to confirm a changed ExpStatSN if there is
   no other PDU to carry it for a long time.

   This command MAY use in-order delivery or immediate delivery.

   When used as a ping command, the Initiator Task Tag MUST be set to valid
value (not the
   reserved 0xffffffff).

   Upon receipt of a NOP-In with the
   Target Transfer Tag set to a valid value (not the reserved 0xffffffff),
   the initiator MUST respond with a NOP-Out. In this case the NOP-Out
Target Transfer
   Tag MUST contain a copy of NOP-In Target Task Tag.

   When a target receives the NOP-Out with a
   valid Initiator Task Tag, it MUST respond with a Nop-In Response (see
NOP-in).
                                ^^^^ consider MUST???

1.1.1     Initiator Task Tag

   An initiator assigned identifier for the operation.

   The NOP-Out MUST have the Initiator Task Tag set to a valid value only
   if a response in the form of NOP-In is requested.
   If the Initiator Task Tag does not contain a valid value, the CmdSN
   field contains as usual the next CmdSN but CmdSN is not advanced and the
   I bit must be set to 1.

1.1.2     Target Transfer Tag

   A target assigned identifier for the operation.

   The NOP-Out MUST have the Target Transfer Tag set only if it is issued
   in response to a NOP-In with a valid Target Transfer Tag, in which case
   it copies the Target Transfer Tag from the NOP-In PDU.

   When the Target Transfer Tag is set, the LUN field MUST be also copied
   from the NOP-In.


From owner-ips@ece.cmu.edu  Thu Aug 16 12:58:41 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16026
	for <ips-archive@odin.ietf.org>; Thu, 16 Aug 2001 12:58:40 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7GGKXV14694
	for ips-outgoing; Thu, 16 Aug 2001 12:20:33 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7GGKVe14684
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 12:20:31 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id SAA24814
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 18:20:24 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7GGKOB204654
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 18:20:24 +0200
Importance: Normal
Subject: Re: IPS: Well-known ports
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF2508F386.8E00CF1F-ONC2256AAA.0059A3CA@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Thu, 16 Aug 2001 19:20:00 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 16/08/2001 19:20:23
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

I did submit an application for an iSCSI-target system port.

Julo

Black_David@emc.com@ece.cmu.edu on 16-08-2001 18:54:39

Please respond to Black_David@emc.com

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  IPS: Well-known ports



One of the things on my to-do list from the Nashua interim
meeting was to look into assignment of well-known port numbers
for iSCSI, FCIP and iFCP.  IANA requires that an application
be submitted - I would recommend the usage of System ports
for our protocols, see:

http://www.iana.org/cgi-bin/sys-port-number.pl

User ports are an alternative if the above doesn't work
for some reason:

http://www.iana.org/cgi-bin/usr-port-number.pl

I would ask the Technical Coordinators and draft authors
to find a volunteer to complete the application for each
protocol and report the resulting assignment to the list.
This needs to be done in fairly short order to get iSCSI
in particular away from using port 5003 as its well-known
port, which it SHOULD NOT be doing (so sayeth the ADs).

Sorry for the delay on this, and many thanks to whomever
the volunteers/victims are who take care of these applications.

Thanks,
--David (overworked WG co-chair)

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------





From owner-ips@ece.cmu.edu  Thu Aug 16 15:02:06 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19958
	for <ips-archive@odin.ietf.org>; Thu, 16 Aug 2001 15:02:06 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7GHnQg20593
	for ips-outgoing; Thu, 16 Aug 2001 13:49:26 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7GHnOe20585
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 13:49:24 -0400 (EDT)
Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA09670; Thu, 16 Aug 2001 13:49:17 -0400 (EDT)
Message-ID: <3B7C0610.783A33CC@cisco.com>
Date: Thu, 16 Aug 2001 12:42:40 -0500
From: Mark Bakke <mbakke@cisco.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686)
X-Accept-Language: en, de
MIME-Version: 1.0
To: Steve Blightman <steve@alacritech.com>, ips@ece.cmu.edu
Subject: Re: [Fwd: Crc-32c example in iSCSI spec]
References: <3B7AFE96.ACCE14DF@alacritech.com> <3B7BC3B5.D75F6122@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


One more thing that might be helpful.  When the Ethernet
polynomial is used in SCSI to generate its CRC, the T10
doc specifies the remainder polynomial that one should see
after running the data with a valid CRC through.  For
the Ethernet CRC, this was specified as 0xc704dd7b.  This
remainder polynomial is taken before the CRC is complemented
and bit-reflected.  For iSCSI, I came up with a remainder of
0x1c2d19ed.  Can anyone verify this result?

--
Mark

Mark Bakke wrote:
> 
> Steve-
> 
> I just ran some Ethernet packets with known CRCs through
> my iSCSI/Ethernet CRC generator, and found the same thing
> as you did.
> 
> All of my examples need to be byte-swapped, along with the
> fix I already posted for the all-ones example.  Here is a
> new set of examples, which will be in -08.  I also ran
> 64 bytes of zeroes and ones, which now agree with your
> numbers as well.
> 
> Thanks again for bringing this up.
> 
> --
> Mark
> 
>      07 CRC Examples
> 
>         N.B. all Values are Hexadecimal
> 
>           Byte:        0  1  2  3
> 
>              0:       01 a0 00 00
>              4:       00 00 00 00
>              8:       00 00 00 00
>             12:       00 00 00 00
>             16:       04 05 00 00
>             20:       00 01 00 00
>             24:       00 00 00 05
>             28:       00 00 00 04
>             32:       2a 00 00 00
>             36:       00 00 00 00
>             40:       80 00 00 00
>             44:       00 00 00 00
> 
>            CRC:       93 70 51 db
> 
>         32 bytes of zeroes:
> 
>           Byte:        0  1  2  3
> 
>              0:       00 00 00 00
>            ...
>             28:       00 00 00 00
> 
>            CRC:       aa 36 91 8a
> 
>         32 bytes of ones:
> 
>           Byte:        0  1  2  3
> 
>              0:       ff ff ff ff
>            ...
>             28:       ff ff ff ff
> 
>            CRC:       43 ab a8 62
> 
>         32 bytes of incrementing 00..1f:
> 
>           Byte:        0  1  2  3
> 
>              0:       00 01 02 03
>            ...
>             28:       1c 1d 1e 1f
> 
>            CRC:       4e 79 dd 46
> 
> 
> Steve Blightman wrote:
> >
> > I believe the examples for the ISCSI CRC  have the wrong endianness.
> >
> > As yiou suugested over the phone I ran some Ethernet frames through a
> > simulation. I have some difficulty running the exact simulations you
> > wanted becuase the minimum size Ethernet frame is 64 bytes.
> >
> > However using the Ethernet CRC polynomial,
> > Running 64 bytes of 0 onto the wire, we append "36 63 8d 75" onto the
> > wire for the CRC - "36" goes out first.
> > Running 64 bytes of all 1, we append "ba 87 61 0f" onto the wire - "ba"
> > goes out first.
> >
> > Using the same logic for the ISCSI polynomial
> > Running 64 bytes of 0 I think we should append "67 eb c8 03" - "67"
> > going out first
> > and running 64 bytes of all 1 we should append "66 4e cd 2f" - "66"
> > going out first
> >
> > And now for 32 bytes with the ISCSI polynomial
> >
> > Running 32 bytes of 0 we should append "aa 36 91 8a" - "aa" going out
> > first
> > Running 32 bytes of all 1 we should append "43 ab a8 62" - "43" going
> > out first
> >
> > I don't want to get into an endless endian debate, but I believe it is
> > important to get the order of these bytes in the right order, so that we
> > can use the same hardware to check as well as to generate CRCs.
> >
> > Thanks for your help on this,
> > Steve Blightman
> 
> --
> Mark A. Bakke
> Cisco Systems
> mbakke@cisco.com
> 763.398.1054

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054


From owner-ips@ece.cmu.edu  Thu Aug 16 16:05:23 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21674
	for <ips-archive@odin.ietf.org>; Thu, 16 Aug 2001 16:05:23 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7GIx0124422
	for ips-outgoing; Thu, 16 Aug 2001 14:59:00 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from smtp.alacritech.com (smtp.alacritech.com [209.10.208.82])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7GIwve24417
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 14:58:57 -0400 (EDT)
Received: from alacritech.com (woking.alacritech.com [10.1.1.70])
	by smtp.alacritech.com (8.11.0/8.11.0) with ESMTP id f7GIrbO20450;
	Thu, 16 Aug 2001 11:53:37 -0700
Message-ID: <3B7C17F0.E1149BED@alacritech.com>
Date: Thu, 16 Aug 2001 11:58:56 -0700
From: Steve Blightman <steve@alacritech.com>
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Mark Bakke <mbakke@cisco.com>
CC: ips@ece.cmu.edu
Subject: Re: [Fwd: Crc-32c example in iSCSI spec]
References: <3B7AFE96.ACCE14DF@alacritech.com> <3B7BC3B5.D75F6122@cisco.com> <3B7C0610.783A33CC@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


Looks right to me, Mark - thanks for all your help on this.

Mark Bakke wrote:

> One more thing that might be helpful.  When the Ethernet
> polynomial is used in SCSI to generate its CRC, the T10
> doc specifies the remainder polynomial that one should see
> after running the data with a valid CRC through.  For
> the Ethernet CRC, this was specified as 0xc704dd7b.  This
> remainder polynomial is taken before the CRC is complemented
> and bit-reflected.  For iSCSI, I came up with a remainder of
> 0x1c2d19ed.  Can anyone verify this result?
>
> --
> Mark
>
> Mark Bakke wrote:
> >
> > Steve-
> >
> > I just ran some Ethernet packets with known CRCs through
> > my iSCSI/Ethernet CRC generator, and found the same thing
> > as you did.
> >
> > All of my examples need to be byte-swapped, along with the
> > fix I already posted for the all-ones example.  Here is a
> > new set of examples, which will be in -08.  I also ran
> > 64 bytes of zeroes and ones, which now agree with your
> > numbers as well.
> >
> > Thanks again for bringing this up.
> >
> > --
> > Mark
> >
> >      07 CRC Examples
> >
> >         N.B. all Values are Hexadecimal
> >
> >           Byte:        0  1  2  3
> >
> >              0:       01 a0 00 00
> >              4:       00 00 00 00
> >              8:       00 00 00 00
> >             12:       00 00 00 00
> >             16:       04 05 00 00
> >             20:       00 01 00 00
> >             24:       00 00 00 05
> >             28:       00 00 00 04
> >             32:       2a 00 00 00
> >             36:       00 00 00 00
> >             40:       80 00 00 00
> >             44:       00 00 00 00
> >
> >            CRC:       93 70 51 db
> >
> >         32 bytes of zeroes:
> >
> >           Byte:        0  1  2  3
> >
> >              0:       00 00 00 00
> >            ...
> >             28:       00 00 00 00
> >
> >            CRC:       aa 36 91 8a
> >
> >         32 bytes of ones:
> >
> >           Byte:        0  1  2  3
> >
> >              0:       ff ff ff ff
> >            ...
> >             28:       ff ff ff ff
> >
> >            CRC:       43 ab a8 62
> >
> >         32 bytes of incrementing 00..1f:
> >
> >           Byte:        0  1  2  3
> >
> >              0:       00 01 02 03
> >            ...
> >             28:       1c 1d 1e 1f
> >
> >            CRC:       4e 79 dd 46
> >
> >
> > Steve Blightman wrote:
> > >
> > > I believe the examples for the ISCSI CRC  have the wrong endianness.
> > >
> > > As yiou suugested over the phone I ran some Ethernet frames through a
> > > simulation. I have some difficulty running the exact simulations you
> > > wanted becuase the minimum size Ethernet frame is 64 bytes.
> > >
> > > However using the Ethernet CRC polynomial,
> > > Running 64 bytes of 0 onto the wire, we append "36 63 8d 75" onto the
> > > wire for the CRC - "36" goes out first.
> > > Running 64 bytes of all 1, we append "ba 87 61 0f" onto the wire - "ba"
> > > goes out first.
> > >
> > > Using the same logic for the ISCSI polynomial
> > > Running 64 bytes of 0 I think we should append "67 eb c8 03" - "67"
> > > going out first
> > > and running 64 bytes of all 1 we should append "66 4e cd 2f" - "66"
> > > going out first
> > >
> > > And now for 32 bytes with the ISCSI polynomial
> > >
> > > Running 32 bytes of 0 we should append "aa 36 91 8a" - "aa" going out
> > > first
> > > Running 32 bytes of all 1 we should append "43 ab a8 62" - "43" going
> > > out first
> > >
> > > I don't want to get into an endless endian debate, but I believe it is
> > > important to get the order of these bytes in the right order, so that we
> > > can use the same hardware to check as well as to generate CRCs.
> > >
> > > Thanks for your help on this,
> > > Steve Blightman
> >
> > --
> > Mark A. Bakke
> > Cisco Systems
> > mbakke@cisco.com
> > 763.398.1054
>
> --
> Mark A. Bakke
> Cisco Systems
> mbakke@cisco.com
> 763.398.1054



From owner-ips@ece.cmu.edu  Thu Aug 16 16:07:24 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21724
	for <ips-archive@odin.ietf.org>; Thu, 16 Aug 2001 16:07:24 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7GJ2Ea24629
	for ips-outgoing; Thu, 16 Aug 2001 15:02:14 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from ariel.nishansystems.com (smtp.nishansystems.com [216.217.36.162])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7GJ2De24623
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 15:02:13 -0400 (EDT)
Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19)
	id <351LH6FG>; Thu, 16 Aug 2001 12:02:07 -0700
Message-ID: <B300BD9620BCD411A366009027C21D9B5BADE0@ariel.nishansystems.com>
From: Joshua Tseng <jtseng@NishanSystems.com>
To: "'Theodore Tso'" <tytso@mit.edu>
Cc: "'Williams, Jim'" <Jim.Williams@emulex.com>,
        "'Black_David@emc.com'"
	 <Black_David@emc.com>, ips@ece.cmu.edu
Subject: RE: saag whyenc draft (was RE: Security Gateways)
Date: Thu, 16 Aug 2001 12:02:06 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Ted,

> ... and when someone takes their infected Windows 2000 laptop back
> behind the corporate firewall, viruses such as Code Red generally
> rampage completely out of control, since people behind the firewall
> get careless and assume that they don't need to worry about security
> or applying the latest security patches or service packs behind the
> firewall.

Protection against viruses and hackers comes from firewalls and
virus-detection software, not IPSec.  An IPSec-equipped host can
be just as vulnerable to Code Red as one without IPSec.

Maintaining adequate defensive measures to protect against viruses
and hackers is an extremely administratively intensive process.  It
involves buttoning down your host to make sure there are no open
unused TCP ports, and that each new application you install doesn't
open up new weaknesses.  Any security administrator knows this isn't
easy to maintain for even a single host.  That is why the bastion
host/security gateway architecture is practical for a large enterprise.
You only have to do it for your 3-4 security gateways, not your 1000+
hosts.

> 
> This has happened to at least three companies, according to reports
> from IETF'ers.  One of them at last count hadn't been able to read
> e-mail for the last 48+ hours because Code Red was disrupting the
> internal network so badly that he wasn't able to get to his corporate
> mail servers.

What they need is not necessarily IPSec, but a personal firewall with
virus detection capability for their notebook.  There are many of
these commercially available.

> 
> If you think that administrators only need to monitor the few security
> gateways, in order to assure the security of the enterprise, you're
> beeing hopelessly optimistic.

The first axiom of security is that NOTHING is 100% secure.  What I
said is that we know the strengths and weaknesses of the security
gateway architecture, and while I agree that it is not invulnerable,
I would rather go with that than trade the known for the unknown.

> 
> That being said, no one is saying that security firewalls should be
> thrown out; first of all, by saying that security should be mandatory
> to implement, it gives the choice of whether or not the encryption
> should be turned on to the user.  Mantory to implement != manadatory
> to use.  Secondly, defense in depth is important.  

Agreed.  End-to-end IPSec is good to have, but in many cases I
would turn it off, especially if I wanted to leverage the firewall
services of a security gateway.  If end-to-end IPSec is turned
on, then I would need to ensure each host has a personal firewall
and up-to-date virus detection capability.

> 
> Even behind my corporate firewall of my company, I maintain my
> personal machines as if there were no firewall, and use encrypted
> connections for everything.  This meant that after we got badly
> attacked by hackers who were able to pierce the corporate firewalls, I
> wasn't affected.  However the naive folks who assumed they didn't need
> to worry about security because the firewall would protect them were
> very badly affected indeed.

I didn't necessarily mean rely on the corporate firewall.  I believe
an internal isolated subnet within a corporate network, accessed
only through a dedicated iSCSI security gateway, would provide
equivalent if not superior security in many cases.  For sure, it would
be far easier to administer and monitor than end-to-end encryption,
virus-detection software, and host-based firewalls on every individual
iSCSI host.

The point I'm trying to make is that end-to-end IPSec doesn't solve
all the security issues.  There have been statements made about how
end-to-end IPSec provides security so that the end user doesn't have
to worry about it.  I believe this is not only false, but that there
are situations where end-to-end encryption will actually increase your
overall security exposure, because it prevents you from leveraging
firewall available from a generic security gateway.  We need to make
sure expectations are set correctly.  I don't think there is anything
that this working group can do to address every possible security
threat ever known to mankind, and I certainly hope we don't try to.

Josh

> 
> 							- Ted
> 


From owner-ips@ece.cmu.edu  Thu Aug 16 17:06:23 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22836
	for <ips-archive@odin.ietf.org>; Thu, 16 Aug 2001 17:06:23 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7GKBGx28387
	for ips-outgoing; Thu, 16 Aug 2001 16:11:16 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7GKBEe28383
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 16:11:15 -0400 (EDT)
Received: from fmsmsxvs043.fm.intel.com (fmsmsxv043-1.fm.intel.com [132.233.48.128])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id UAA26166
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 20:11:10 GMT
Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29])
 by fmsmsxvs043.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001081613103111442
 ; Thu, 16 Aug 2001 13:10:31 -0700
Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <QVMRNWS2>; Thu, 16 Aug 2001 13:11:10 -0700
Message-ID: <638EC1B28663D211AC3E00A0C96B78A8086ABB14@orsmsx40.jf.intel.com>
From: "Wheat, Stephen R" <stephen.r.wheat@intel.com>
To: "'Julian Satran'" <Julian_Satran@il.ibm.com>, ips@ece.cmu.edu
Subject: RE: iSCSI Change - New NOP-Out/In text
Date: Thu, 16 Aug 2001 13:10:53 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Here is a (maybe partial) draft of the suggested NOP-In rewording.  Whether
this type of commentary is worthwhile, please let me know.

Embedded are some questions I have from the original writing this morning.

As a commentary/question, shouldn't all fields be documented, rather than
having their semantics covered in other field documentation???

At the very least, I'd appreciate the text to be changed to answer my
questions embedded below.

BTW, since a NOP-In could result in a corresponding NOP-Out, the name of the
ping data fields is kind of lopsided.  I.e., for NOP-Out, it is "Ping Data",
and for NOP-In, it is "Return Ping Data."  A NOP-Out's ping data is "return
ping data" when sent as a response to a NOP-In.  So, how about just calling
it "Ping Data" in both messages??

Stephen

==================

1.2  NOP-In

   NOP-In is either sent by a target as a response to having received a
NOP-Out,
   as a "ping" to an initiator, or a means to carry a changed ExpCmdSN
   and/or MaxCmdSN if there is no other PDU to carry them for a long time.

   When a target receives the NOP-Out with a valid Initiator Task Tag (not
   the reserved value 0xffffffff), it MUST respond with a NOP-In with the
   same Initiator Task Tag that was provided in the NOP-Out Command. It
   SHOULD also duplicate up to first 4096 bytes of the initiator provided
   Ping Data.

1.2.1     Target Transfer Tag

   A target assigned identifier for the operation.

   If the target is responding to a NOP-Out, this is set to ?????????

   If the target is initiating a NOP-Out as a Ping (intending to receive a
corresponding
   NOP-Out), this field is set to a valid value (not the reserved
0xffffffff).

   If the target is initiating a NOP-Out without wanting to receive a
corresponding
   NOP-In, this field MUST hold the reserved value of 0xffffffff.

1.2.2   Initiator Task Tag
   When the NOP-Out is in response to a NOP-In, this is the same value as
found in the NOP-Out.

   Otherwise, this field MUST be 0xffffffff.

1.2.3     LUN

   A LUN MUST be set to a correct value when the Target Transfer Tag is
   valid (not the reserved value 0xffffffff).  Otherwise, it SHOULD be set
to the
   reserved value of 0.

1.2.4  StatSN
   Whenever the NOP-In is not issued in response to a NOP-Out the, StatSN
   field will contain the next StatSN but StatSN for this
   connection is not advanced.  Otherwise, it will be set to ????????.

1.2.5  Data Segment Length
   The number of bytes in the Return Ping Data.  The range is [0..4096].


From owner-ips@ece.cmu.edu  Thu Aug 16 17:09:06 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22900
	for <ips-archive@odin.ietf.org>; Thu, 16 Aug 2001 17:09:02 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7GKQwi29216
	for ips-outgoing; Thu, 16 Aug 2001 16:26:58 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7GKQue29209
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 16:26:56 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id WAA339820
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 22:26:49 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7GKQnB70234
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 22:26:49 +0200
Importance: Normal
Subject: RE: iSCSI Change - New NOP-Out/In text
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF234B5FB3.858017D5-ONC2256AAA.00700F79@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Thu, 16 Aug 2001 23:25:50 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 16/08/2001 23:26:49
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Correct. In addition the CmdSN is not advanced if ITT is invalid. and the
loop is broken by not leeting the target ship
a NOP-In with both tags valid.

Julo

"Ayman Ghanem" <aghanem@cisco.com>@ece.cmu.edu on 16-08-2001 19:08:59

Please respond to "Ayman Ghanem" <aghanem@cisco.com>

Sent by:  owner-ips@ece.cmu.edu


To:   <ips@ece.cmu.edu>
cc:
Subject:  RE: iSCSI Change - New NOP-Out/In text



From reading the new text, the initiator/target task tags are used to
indicate what the poll-bit used to do. If the task tag is valid, then a
response is requested, otherwise its a one-way message. The way I
understand
1.1.1 is that the initiator can send a NOP-Out on its own and set the itt
to
valid/reserved value depending on whether it is requesting a NOP-In or not.

-Ayman


> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Sandeep Joshi
> Sent: Thursday, August 16, 2001 10:40 AM
> To: Julian Satran
> Cc: ips@ece.cmu.edu
> Subject: Re: iSCSI Change - New NOP-Out/In text
>
>
>
> Julian,
>
> Two comments
>
> (1) Sec 1.1.1 should state that the initiator task tag is also valid
>     when the initiator sends a NOP-Out on its own.
>     The word "only" below is misleading (and perhaps misplaced)
>
>   >  The NOP-Out must have the Initiator Task Tag set to a valid value
> only
>   >  if a response in the form of NOP-In is requested.
>
> (2) does "as much as possible" imply zero is value (i.e. duplicate
> nothing?)
>   >    duplicating the data that was provided in the NOP-Out
>   >    (if any) as much as possible.
>
> -Sandeep
>
>
> Julian Satran wrote:
> >
> > Here  is the new NOP-Out/In text (2.12 & 2.13):
> >
> > 1.1  NOP-Out
> >
> >    Byte /    0       |       1       |       2       |       3       |
> >       /              |               |               |               |
> >      |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
> >      +---------------+---------------+---------------+---------------+
> >     0|X|I| 0x00      |1| Reserved (0)                                |
> >      +---------------+---------------+---------------+---------------+
> >     4| Reserved (0)  | DataSegmentLength                             |
> >      +---------------+---------------+---------------+---------------+
> >     8| LUN or Reserved (0)                                           |
> >      +                                                               +
> >    12|                                                               |
> >      +---------------+---------------+---------------+---------------+
> >    16| Initiator Task Tag or Reserved (0xffffffff)                   |
> >      +---------------+---------------+---------------+---------------+
> >    20| Target Transfer Tag or Reserved (0xffffffff)                  |
> >      +---------------+---------------+---------------+---------------+
> >    24| CmdSN                                                         |
> >      +---------------+---------------+---------------+---------------+
> >    28| ExpStatSN                                                     |
> >      +---------------+---------------+---------------+---------------+
> >    32/ Reserved (0)                                                  /
> >     +/                                                               /
> >      +---------------+---------------+---------------+---------------+
> >    48| Digests if any...                                             |
> >      +---------------+---------------+---------------+---------------+
> >      / DataSegment - Ping Data (optional)                            /
> >     +/                                                               /
> >      +---------------+---------------+---------------+---------------+
> >
> >    The NOP-Out with the Initiator Task Tag set to valid value (not the
> >    reserved 0xffffffff) acts as a "ping command".
> >
> >    This form of the NOP-Out can be used to verify that a connection is
> >    still active and all its components are operational. This command
MAY
> >    use in-order delivery or immediate delivery. The NOP-Out may
> be useful
> >    in the case where an initiator has been waiting a long time for the
> >    response to some command, and the initiator suspects that
> there is some
> >    problem with the connection.  When a target receives the
> NOP-Out with a
> >    valid Initiator Task Tag, it should respond with a Nop-In Response,
> >    duplicating the data that was provided in the NOP-Out (if
> any) as much
> >    as possible.  If the initiator does not receive the NOP-In
> within some
> >    time (determined by the initiator), or if the data returned by the
> >    NOP-In is different from the data that was in the NOP-Out,
> the initiator
> >    may conclude that there is a problem with the connection.
> The initiator
> >    then closes the connection and may try to establish a new
connection.
> >
> >    A NOP-Out should also be used to confirm a changed ExpStatSN
> if there is
> >    no other PDU to carry it for a long time.
> >
> >    The NOP-Out can be sent by an initiator because of a NOP-In with the
> >    Target Transfer Tag set to a valid value (not the reserved
> 0xffffffff).
> >    In this case the NOP-Out Target Transfer Tag must contain a copy of
> >    NOP-In Target Task Tag.
> >
> > 1.1.1     Initiator Task Tag
> >
> >    An initiator assigned identifier for the operation.
> >
> >    The NOP-Out must have the Initiator Task Tag set to a valid
> value only
> >    if a response in the form of NOP-In is requested.
> >    If the Initiator Task Tag does not contain a valid value, the CmdSN
> >    field contains as usual the next CmdSN but CmdSN is not
> advanced and the
> >    I bit must be set to 1.
> >
> > 1.1.2     Target Transfer Tag
> >
> >    A target assigned identifier for the operation.
> >
> >    The NOP-Out MUST have the Target Transfer Tag set only if it
> is issued
> >    in response to a NOP-In with a valid Target Transfer Tag, in
> which case
> >    it copies the Target Transfer Tag from the NOP-In PDU.
> >
> >    When the Target Transfer Tag is set, the LUN field MUST be
> also copied
> >    from the NOP-In.
> >
> > 1.1.3     Ping Data
> >
> >    Ping data is reflected in the NOP-In Response. Note that the
> length of
> >    the reflected data is limited to 4096 bytes and the initiator should
> >    avoid sending more than 4096 bytes. The length of ping data
> is indicated
> >    by the Data Segment Length.  0 is a valid value for the Data Segment
> >    Length - and indicates the absence of ping data.
> >
> > 1.2  NOP-In
> >
> >    Byte /    0       |       1       |       2       |       3       |
> >       /              |               |               |               |
> >      |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
> >      +---------------+---------------+---------------+---------------+
> >     0|1|1| 0x20      |1| Reserved (0)                                |
> >      +---------------+---------------+---------------+---------------+
> >     4| Reserved (0)  | DataSegmentLength                             |
> >      +---------------+---------------+---------------+---------------+
> >     8| LUN or Reserved (0)                                           |
> >      +                                                               +
> >    12|                                                               |
> >      +---------------+---------------+---------------+---------------+
> >    16| Initiator Task Tag or Reserved (0xffffffff)                   |
> >      +---------------+---------------+---------------+---------------+
> >    20| Target Transfer Tag or Reserved (0xffffffff)                  |
> >      +---------------+---------------+---------------+---------------+
> >    24| StatSN                                                        |
> >      +---------------+---------------+---------------+---------------+
> >    28| ExpCmdSN                                                      |
> >      +---------------+---------------+---------------+---------------+
> >    32| MaxCmdSN                                                      |
> >      +---------------+---------------+---------------+---------------+
> >    36/ Reserved (0)                                                  /
> >     +/                                                               /
> >      +---------------+---------------+---------------+---------------+
> >    48| Digests if any...                                             |
> >      +---------------+---------------+---------------+---------------+
> >      / DataSegment - Return Ping Data                                /
> >     +/                                                               /
> >      +---------------+---------------+---------------+---------------+
> >
> >    When a target receives the NOP-Out with a valid Initiator
> Task Tag (not
> >    the reserved value 0xffffffff), it MUST respond with a
> NOP-In with the
> >    same Initiator Task Tag that was provided in the NOP-Out Command. It
> >    SHOULD also duplicate up to first 4096 bytes of the
> initiator provided
> >    Ping Data. For such a response, the Target Transfer Tag MUST be
> >    0xffffffff.
> >
> > 1.2.1     Target Transfer Tag
> >
> >    A target assigned identifier for the operation.
> >
> >    A target may issue a NOP-In on its own to test the connection and
the
> >    state of the initiator. If the target wants to test the initiator,
it
> >    sets the Target Task Tag to a valid value (not the reserved
> 0xffffffff)
> >    in order to ask for an answer from the initiator. In this case the
> >    Initiator Task Tag MUST be 0xffffffff and the LUN field MUST
> contain a
> >    valid LUN. If the target wants only to test the connection, both
tags
> >    MUST hold the reserved value 0xffffffff and the LUN field is
> reserved.
> >
> >    A target may also issue a NOP-In on its own to carry a
> changed ExpCmdSN
> >    and/or MaxCmdSN if there is no other PDU to carry them for a
> long time.
> >
> >    Whenever the NOP-In is not issued in response to a NOP-Out the
StatSN
> >    field will contain as usual the next StatSN but StatSN for this
> >    connection is not advanced.
> >
> > 1.2.2     LUN
> >
> >    A LUN MUST be set to a correct value when the Target Transfer Tag is
> >    valid (not the reserved value 0xffffffff).
>






From owner-ips@ece.cmu.edu  Thu Aug 16 17:12:10 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22996
	for <ips-archive@odin.ietf.org>; Thu, 16 Aug 2001 17:12:10 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7GKVcK29486
	for ips-outgoing; Thu, 16 Aug 2001 16:31:38 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7GKVae29481
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 16:31:37 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id WAA259510
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 22:31:30 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7GKVTS40804
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 22:31:30 +0200
Importance: Normal
Subject: Application for port-number
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFE9F75703.95993466-ONC2256AAA.0070AFA1@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Thu, 16 Aug 2001 23:31:06 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 16/08/2001 23:31:30
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

FYI
---------------------- Forwarded by Julian Satran/Haifa/IBM on 16-08-2001
23:30 ---------------------------

Julian Satran/Haifa/IBM@IBMIL@IBMIL on 16-08-2001 19:16:55

Please respond to Julian Satran/Haifa/IBM@IBMIL

To:   iana@iana.org, Julian Satran/Haifa/IBM@IBMIL
cc:
Subject:  Application for port-number



Application for System (Well-Known) Port Number

Name :
Julian Satran

E-mail :
Julian_Satran@il.ibm.com

Protocol Number :
TCP

Message Formats :
BasicHeader+AuxiliaryHeader+Data

Message Types :
Request/Reply

Message opcodes :
Over 20 types

Message Sequences :
request/response

Protocol functions :
Carries SCSI commands

Broadcast or Multicast used ?
no

How and what for Broadcast or Multicast is used (if used):


Description :
 draft-ietf-ips-iscsi-07.txt

Name of the port :
iSCSI Target Access

Short name of the port :
iSCSI-target







From owner-ips@ece.cmu.edu  Thu Aug 16 17:12:27 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23013
	for <ips-archive@odin.ietf.org>; Thu, 16 Aug 2001 17:12:26 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7GKjKC00103
	for ips-outgoing; Thu, 16 Aug 2001 16:45:20 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7GKjJe00099
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 16:45:19 -0400 (EDT)
Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA23185; Thu, 16 Aug 2001 16:45:11 -0400 (EDT)
Message-ID: <3B7C2F49.4D52E75A@cisco.com>
Date: Thu, 16 Aug 2001 15:38:33 -0500
From: Mark Bakke <mbakke@cisco.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686)
X-Accept-Language: en, de
MIME-Version: 1.0
To: Jim Hafner <hafner@almaden.ibm.com>
CC: ips@ece.cmu.edu
Subject: Re: iSCSI: Status'es (clause 2.11.6)
References: <OF55314842.211D8AD6-ON88256A94.00648923@boulder.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


Jim and I talked on the phone about this, and here's pretty
much what we came up with for status code changes.

After thinking about the Proxy Required message, I agree that
we no longer need it.  Since all iSCSI targets have unique
names, which are not tied to addresses as in HTTP, the client
does not need to be aware of a proxy for it to work.

Also, since the main definition of the 030X codes is "my bad"
from the target's point of view, and 020X is "your bad", this
means that login requests causing an 030X should be re-tryable
by the initiator at some point in the future, and that 020X
requests won't get anywhere if they keep trying.  This caused
us to want to move a few status codes around.

So here are some proposed changes to the iSCSI status codes
that should clean things up:


In the status class definitions, add the following sentence
to "2 - Initiator error":

  The request should not be tried again as-is.

And change "3 - Target Error" to:

  indicates that the target sees no errors in the initiator's
  login request, but is currently incapable of fulfilling the
  requesst.  The client may re-try the same login request at
  a later time.


Remove code 0103 "Proxy Required".

Rename 0201 "Security Negotiation Failed" to "Authentication Failure".

  Change its description to:

  The initiator could not be successfully authenticated by the target.

Rename 0202 "Forbidden Target" to "Authorization Failure".

  Change its description to:

  The initiator was authenticated, but is not authorized to access
  the target.

Remove 0205 "Target Conflict".

  This one had specified that the target would not accept another
  connection, but since this may be a temporary and re-tryable
  condition, it should really belong in the 0300s.

Move 0302 "Unsupported Version" to 0205, since this is not a login
request that the client has any hope of re-trying, so it belongs
in the 0200s.

Add new 030X codes to be somewhat more precise as to the reason
the target might be unavailable.

0300 - Target Error - Miscellaneous target error

0301 - Service Unavailable - The current target is not operational.

0302 - Out of Resources - The target currently has insufficient
connection or session resources.

0303 - Not Ready - The target is not yet ready to accept connections.

0304 - Software Failure - The target has experienced a software
failure.

0305 - Hardware Failure - The target has experienced a hardware
failure.

Note that none of the 030X status codes should require different
treatment; they are mainly broken out to allow the client to
complain more precisely to its user or administrator.

--
Mark


Jim Hafner wrote:
> 
> Mark,
> 
> Comments in line.  But for closure on some things and to tagged the still
> open issues, I'll summarize my comments.
> 
> There are three independent issues (and a few minor ones I'll skip):
> 1) Proxy Required - I think this is just a placeholder and need not be
> there -- save it for generation 2 (still open).
> 2) Security Negotiation Failed and Forbidden Target - thanks for the
> clarification, I think I like the name changes (closed)
> 3) Target Conflict - what about "n->n+1" -- we have no status code for
> that.  I suggest alternate names for this and that it cover not just the
> 1->2 problem but the n->n+1 (still open).
> 
> All other issues are agreed.
> 
> Jim Hafner
> 
> Mark Bakke <mbakke@cisco.com>@ece.cmu.edu on 07-25-2001 08:53:23 AM
> 
> Sent by:  owner-ips@ece.cmu.edu
> 
> To:   Jim Hafner/Almaden/IBM@IBMUS
> cc:   ips@ece.cmu.edu
> Subject:  Re: iSCSI: Status'es (clause 2.11.6)
> 
> Jim-
> 
> Comments are below.
> 
> --
> Mark
> 
> Jim Hafner wrote:
> >
> > Folks,
> >
> > I have some questions, recommendations and editorial comments about the
> > status codes for iSCSI in clause 2.11.6.
> >
> > Proxy Required is defined as the response when "the initiator must use an
> > ISCSI proxy for this target".  But that isn't defined anywhere in the
> > document, so I recommend deleting this status code.
> 
> We should define this, then.  If a target is accessible only through
> an iSCSI proxy, perhaps for security purposes, an initiator attempting
> to log in to it directly should get an error.  If the target is aware
> of the proxy, it can return the proxy's address in this type of redirect
> response.  This is similar to what was done in HTTP/1.1.
> <JLH>
> If the target is aware of this (undefined) thing, then a simple redirect
> would suffice and we don't need the status code.  If the target is not
> aware, then how can it know to return this status code?   Does it just know
> that there should be one but doesn't know the address?  How can it know
> whether to accept the login from any old initiator vs the initiator that
> lives in the proxy?  It will be configured (I assume) to allow login by the
> proxy and reject all other logins.  It doesn't really help the initiator to
> get back "can't login in here, use a proxy but it's up to you (the
> initiator) to find the right address".
> 
> Until we define this, I strongly suggest we take it out the status code --
> it adds no value to the protocol.  We can't have placeholders for things
> that are undefined (except perhaps reserved values or keywords).   You
> clearly have an idea in your mind of what an iSCSI Proxy is, but I searched
> for "proxy" in the document and the ONLY occurrances are in this clause.
> 
> My suggestion then is (a) take it out for now (and reserve the code value)
> and (b) table the whole definition/description/model, etc for an iSCSI
> proxy is to "iSCSI-the sequel".   I expect that this will be a complex
> issue (as I've hinted at above), and I don't want it to delay this draft.
> </JLH>
> 
> Although this status code likely won't be used right away, it does
> have utility long-term when we start building larger storage networks
> with this stuff.  I still don't believe that all iSCSI devices will
> provide all of their own security code; other devices may have to
> provide this on their behalf, which was why we had added iSCSI proxy
> capabilities in the first place.
> <JLH>
> This is yet to be proven and in the meantime, we don't need the
> placeholder.
> </JLH>
> 
> > What's the functional difference between the following: "Security
> > negotiation failed" and "Forbidden Target"?  In both cases, the initiator
> > doesn't get to use what it thinks is there.  I would think that
> "Forbidden
> > Target" might be a security leak as it admits the fact that the target is
> > there, whereas if the initiator only got back failed security, that
> > admission wouldn't be made.
> 
> Security Negotiation Failed means that the initiator could not
> be successfully authenticated.
> 
> Forbidden Target means that the initiator was authenticated, but
> is not authorized to access the target.
> 
> These are two different reasons for an initiator not to be able
> to get to a target, and would more useful to someone configuring
> an initiator than simply returning "not found".
> 
> Keep in mind that when returning Forbidden Target, the initiator
> has been authenticated, so it's likely to be somewhere within
> the realm of things that the target trusts.  If the target wants
> to be more tight-lipped about this one, it could certainly return
> "Not Found" instead.  This adds a bit more security at the expense
> of making it easier to troubleshoot a mis-configured initiator.
> 
> The names for these two status codes are perhaps a bit clumsy; perhaps
> renaming them will help.  How about:
> 
> Authentication Failure instead of Security Negotiation Failed
> 
> and
> 
> Authorization Failure instead of Forbidden Target?
> 
> <JLH>
> Thanks for the explanation.  I can live with this; the alternative wording
> might be more clear.
> </JLH>
> 
> > "Target Conflict" and "Service Unavailable" both look more like
> > "insufficient resources".  In particular, "Target Conflict" should not be
> > limited to a response in the 1->2 or more initiators case but in the
> n->n+1
> > initiators case.  That is, if the target has resources for 'n' logins, it
> > can reject another login with "insufficient resources", whether n=1 or
> > n=10.   So, I'd suggest that "insufficient resources" is a better
> catch-all
> > for both of these cases.
> 
> We had this discussion on the list a long time ago.  Target Conflict
> is the initiator's problem; it should not be asking to connect to
> a target that someone else is using (assuming it supports only one
> initiator at a time).  Service Unavailable is the target's problem;
> it is used when the target is not working at all.
> 
> <JLH>
> Apologies if I didn't follow or absorb all of that previous thread.
> 
> I can see the subtle difference between Target Conflict and Service
> Unavailable.  But what do we do if the target supports "n" logins (only)
> and an "n+1" guy tries to login?  We have no status code for that.  I also
> don't see how the name "Target Conflict" carries the meaning you want.  I
> would suggest "Insufficient Login Resources" or "Target In Use" and use
> this for anytime the target can't support an additional login (either from
> 1 to 2 or from n to n+1).
> </JLH>
> 
> > We need to clarify the "Session already open" to include language that
> says
> > "with this initiator to this target portal group".
> 
> Agree.
> 
> > The sentence immediately after the table says that "accept" means the
> > initiator may proceed to issue SCSI commands.  This is only true in a
> > Normal session type and is not true for the Discovery session type.  This
> > should be clarified.
> 
> Agree here, too.
> 
> > Jim Hafner
> 
> --
> Mark A. Bakke
> Cisco Systems
> mbakke@cisco.com
> 763.398.1054

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054


From owner-ips@ece.cmu.edu  Thu Aug 16 18:26:28 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26649
	for <ips-archive@odin.ietf.org>; Thu, 16 Aug 2001 18:26:28 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7GLQbG02172
	for ips-outgoing; Thu, 16 Aug 2001 17:26:37 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7GLQZe02167
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 17:26:35 -0400 (EDT)
Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA00399; Thu, 16 Aug 2001 17:26:29 -0400 (EDT)
Message-ID: <3B7C38F7.116EB444@cisco.com>
Date: Thu, 16 Aug 2001 16:19:51 -0500
From: Mark Bakke <mbakke@cisco.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686)
X-Accept-Language: en, de
MIME-Version: 1.0
To: Kaladhar Voruganti <kaladhar@us.ibm.com>, IPS <ips@ece.cmu.edu>
Subject: iSCSI NDT: Nameprep additions
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


Kaladhar-

Here are some modifications to make to the NDT doc to
add nameprep.  For now, these changes will assume that
nameprep will become an RFC before we do; if this is
a problem, we will do some more cut-and-paste later.

--
Mark


Replace:

    3. iSCSI names must be transcribable by humans.  iSCSI names should  
       be kept as simple as possible, and should not use more than a  
       few special characters.  They must also be case-insensitive, and  
       cannot include white space.   

With:

    3. iSCSI names must be transcribable by humans.  iSCSI names should  
       be kept as simple as possible, and should not use more than a  
       few special characters.  They must provide for the use of
       international character sets, and must not allow the use of
       different names that would be identical except for their case.
       Whitespace characters must not be allowed.

Replace:

   The iSCSI Name may be displayed by user interfaces, but is generally  
   uninterpreted and used as an opaque, case-sensitive string for  
   comparison with other iSCSI Name values.

With:  

   The iSCSI Name may be displayed by user interfaces, but is generally  
   uninterpreted and used as an opaque string for comparison with other
   iSCSI Name values.   
 
Replace:


   An iSCSI name can be any Unicode character string with the following  
   properties:   
     
    - it is in Normalization Form C (see Unicode Standard Annex #15,  
       "Unicode Normalization Forms" at  
       http://www.unicode.org/unicode/reports/15)   
      
    - it contains only the ASCII dash character ('-'=U+002d) or the   
    ASCII dot character ('.'=U+002e) or is in one of the following   
    Unicode General Categories:   
     
             a) Lu (Letter, Uppercase)   
             b) Ll (Letter, Lowercase)   
             c) Lt (Letter, Titlecase)   
             d) Lm (Letter, Modifier)   
             e) Lo (Letter, Other)   
             f) Nd (Number, Decimal Digit)   
             g) Nl (Number, Letter)   
     
             h) No (Number, Other)   
         
    - when encoded in UTF-8, it is no more than 255 bytes   
     
   In particular, white space, punctuation (except as noted), marks and  
   symbols are not allowed. 



With:

   An iSCSI name can be any Unicode character string with the following  
   properties:   
     
    - it is in Normalization Form C (see Unicode Standard Annex #15,  
       "Unicode Normalization Forms" at  
       http://www.unicode.org/unicode/reports/15)   

    - it contains only the following types of characters:

         - ASCII dash character ('-'=U+002d)  
         - ASCII dot character ('.'=U+002e)
         - Any character allowed by the output of the nameprep
           process

    - when encoded in UTF-8, it is no more than 255 bytes   

   The output of the nameprep process is described in [NAMEPREP].  Nameprep
   is a method designed by the Internationalized Domain Name (IDN) working
   group to translate human-typed strings into a format that can be compared
   as opaque strings, and does not include punctuation, spacing, dicritical
   marks, or other characters that could get in the way of transcribability.
   It also converts everything into its equivalent of lower case.

   Note that in most cases, the nameprep process does not need to be
   implemented:

   - If the names are just generated using lower-case (in any
     character set) plus digits, no normalization is required.

   - If the names are generated from some other all-ASCII string,
     tolower() normalizes and isalnum() verifies.

   - If the names are generated from more general, internationalized
     text, either the equivalent of tolower() and isalnum() appropriate
     to the character set may be used, or the full nameprep procedure
     can be used.


From owner-ips@ece.cmu.edu  Thu Aug 16 22:41:00 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01331
	for <ips-archive@odin.ietf.org>; Thu, 16 Aug 2001 22:41:00 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7H1WNp11837
	for ips-outgoing; Thu, 16 Aug 2001 21:32:23 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from siaar1aa.compuserve.com (siaar1aa.compuserve.com [149.174.40.9])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7H1WLe11833
	for <ips@ece.cmu.edu>; Thu, 16 Aug 2001 21:32:21 -0400 (EDT)
Received: (from mailgate@localhost)
	by siaar1aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id VAA27793
	for ips@ece.cmu.edu; Thu, 16 Aug 2001 21:32:15 -0400 (EDT)
Received: from compuserve.com (dal-tgn-tlw-vty20.as.wcom.net [216.192.237.20])
	by siaar1aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id VAA27668;
	Thu, 16 Aug 2001 21:32:06 -0400 (EDT)
Message-ID: <3B7C69A3.CAF4273E@compuserve.com>
Date: Thu, 16 Aug 2001 19:47:31 -0500
From: Ralph Weber <ralphoweber@compuserve.com>
Reply-To: ENDL_TX@computer.org
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47  (Win95; I)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: ips@ece.cmu.edu
CC: Black_David@emc.com
Subject: Re: FCIP -03 comments
References: <277DD60FB639D511AC0400B0D068B71E070A5F@corpmx14.us.dg.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

David,

On 7/18 you wrote:

..snip..

> -- Section 6.4
>
>    An FC Fabric to IP Network interface product SHALL
>    contain one FCIP Entity for each IP Address assigned to the product.
>
> This looks overspecified for a couple of reasons -- it prevents
> multiple FCIP entities on different TCP ports at the same IP
> address and it appears to force implementation of an FCIP entity
> on an interface intended solely for management traffic.  Needless
> to say, this is overspecified - I'm guessing that the real requirement
> is that an FCIP entity MUST NOT span multiple IP addresses, but
> more than one FCIP entity MAY share an IP address by using
> different TCP ports.  This has some slight effects on wording
> elsewhere, but I fail to see the reason for forbidding two FCIP
> entities behind a single IP address.

..snip..

I responded by promising to put this question to the FCIP authors.
Here is their response (more or less faithfully transcribed, owing 
for interpretations and flourishes).

The statement that ..."there SHALL be one FCIP Entity for each IP
Address assigned to the product..." correctly reflects the intentions
of the FCIP authors.  The requirement represents the results of about
three hours of debate among the authors that occurred during the
face-to-face meeting in Denver in June.

The agreed opinion is that, particularly in the manually configured
case, the IP Address represents the FCIP Entity and as such having
multiple FCIP Entities sharing an IP Address causes confusion.

A couple of the FCIP authors have volunteered to walk you through
their PowerPoint, Visio, and PDF presentations on the subject in
Orange County, but they have refused to convert their drawings to 
ASCII stick figures.

The FCIP Authors have requested that you consider viewing their
non-ASCII presentations personally and offline.  Should you wish
to subject the meeting to this agony (I speak from experience here),
please be sure the FCIP TD is notified of the agenda change.

Thanks.

Ralph...




From owner-ips@ece.cmu.edu  Fri Aug 17 04:11:50 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21541
	for <ips-archive@odin.ietf.org>; Fri, 17 Aug 2001 04:11:49 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7H7UEA24779
	for ips-outgoing; Fri, 17 Aug 2001 03:30:14 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from yamuna.ctd.hcltech.com ([202.140.153.6])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7H7UAe24774
	for <ips@ece.cmu.edu>; Fri, 17 Aug 2001 03:30:10 -0400 (EDT)
Received: from kaveri.ctd.hcltech.com (KAVERI [192.168.102.25]) by yamuna.ctd.hcltech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id Q1C5CQJM; Fri, 17 Aug 2001 13:03:46 +0530
Received: from ASAI ([192.168.201.159]) by kaveri.ctd.hcltech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id Q1CWWT74; Fri, 17 Aug 2001 13:01:02 +0530
Message-ID: <004501c126ee$1bfe3100$9fc9a8c0@techmas.hcltech.com>
Reply-To: "Asai Thambi S P" <sp_asai@ctd.hcltech.com>
From: "Asai Thambi S P" <sp_asai@ctd.hcltech.com>
To: <ips@ece.cmu.edu>, "Julian Satran" <Julian_Satran@il.ibm.com>
References: <OF3B8DF8E1.C6FA971A-ONC2256AAA.002EF268@telaviv.ibm.com>
Subject: Re: iSCSI Change - New NOP-Out/In text
Date: Fri, 17 Aug 2001 12:57:42 +0530
Organization: HCL Technologies Ltd
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f7H7UCe24775
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit

Sorry for the previous mail, which was sent accidentally.

Julian,

I have some questions.

* Section 1.1  NOP-Out

                                            The NOP-Out may be useful
   in the case where an initiator has been waiting a long time for the
   response to some command, and the initiator suspects that there is some
   problem with the connection. .....
   
   If the initiator does not receive the NOP-In within some
   time (determined by the initiator),
        
      A NOP-Out should also be used to confirm a changed ExpStatSN if there is
   no other PDU to carry it for a long time.

    ? The draft doesn't say what a long time is? 
    
    Section 7.11.1 says as follows:

         The timeout value to be used by a target is outside the scope 
           of this document.  
    and
         The timeout value to be used by an initiator is outside the 
           scope of this document. 

    ? How the initiator/target times out is not defined? Then what that long time refers 
    to?

* Section 1.1.3     Ping Data

   Ping data is reflected in the NOP-In Response. Note that the length of
   the reflected data is limited to 4096 bytes and the initiator should
   avoid sending more than 4096 bytes. The length of ping data is indicated
   by the Data Segment Length.  0 is a valid value for the Data Segment
   Length - and indicates the absence of ping data.

    ? The text starts abruptly that ping data is reflected....
       It doesn't say what the ping data is?


- asai.



----- Original Message ----- 
From: Julian Satran <Julian_Satran@il.ibm.com>
To: <ips@ece.cmu.edu>
Sent: Thursday, August 16, 2001 08:39 PM
Subject: iSCSI Change - New NOP-Out/In text


Here  is the new NOP-Out/In text (2.12 & 2.13):

1.1  NOP-Out


   Byte /    0       |       1       |       2       |       3       |
      /              |               |               |               |
     |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
     +---------------+---------------+---------------+---------------+
    0|X|I| 0x00      |1| Reserved (0)                                |
     +---------------+---------------+---------------+---------------+
    4| Reserved (0)  | DataSegmentLength                             |
     +---------------+---------------+---------------+---------------+
    8| LUN or Reserved (0)                                           |
     +                                                               +
   12|                                                               |
     +---------------+---------------+---------------+---------------+
   16| Initiator Task Tag or Reserved (0xffffffff)                   |
     +---------------+---------------+---------------+---------------+
   20| Target Transfer Tag or Reserved (0xffffffff)                  |
     +---------------+---------------+---------------+---------------+
   24| CmdSN                                                         |
     +---------------+---------------+---------------+---------------+
   28| ExpStatSN                                                     |
     +---------------+---------------+---------------+---------------+
   32/ Reserved (0)                                                  /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
   48| Digests if any...                                             |
     +---------------+---------------+---------------+---------------+
     / DataSegment - Ping Data (optional)                            /
    +/                                                               /
     +---------------+---------------+---------------+---------------+

   The NOP-Out with the Initiator Task Tag set to valid value (not the
   reserved 0xffffffff) acts as a "ping command".

   This form of the NOP-Out can be used to verify that a connection is
   still active and all its components are operational. This command MAY
   use in-order delivery or immediate delivery. The NOP-Out may be useful
   in the case where an initiator has been waiting a long time for the
   response to some command, and the initiator suspects that there is some
   problem with the connection.  When a target receives the NOP-Out with a
   valid Initiator Task Tag, it should respond with a Nop-In Response,
   duplicating the data that was provided in the NOP-Out (if any) as much
   as possible.  If the initiator does not receive the NOP-In within some
   time (determined by the initiator), or if the data returned by the
   NOP-In is different from the data that was in the NOP-Out, the initiator
   may conclude that there is a problem with the connection. The initiator
   then closes the connection and may try to establish a new connection.

   A NOP-Out should also be used to confirm a changed ExpStatSN if there is
   no other PDU to carry it for a long time.

   The NOP-Out can be sent by an initiator because of a NOP-In with the
   Target Transfer Tag set to a valid value (not the reserved 0xffffffff).
   In this case the NOP-Out Target Transfer Tag must contain a copy of
   NOP-In Target Task Tag.


1.1.1     Initiator Task Tag

   An initiator assigned identifier for the operation.

   The NOP-Out must have the Initiator Task Tag set to a valid value only
   if a response in the form of NOP-In is requested.
   If the Initiator Task Tag does not contain a valid value, the CmdSN
   field contains as usual the next CmdSN but CmdSN is not advanced and the
   I bit must be set to 1.

1.1.2     Target Transfer Tag

   A target assigned identifier for the operation.

   The NOP-Out MUST have the Target Transfer Tag set only if it is issued
   in response to a NOP-In with a valid Target Transfer Tag, in which case
   it copies the Target Transfer Tag from the NOP-In PDU.

   When the Target Transfer Tag is set, the LUN field MUST be also copied
   from the NOP-In.

1.1.3     Ping Data

   Ping data is reflected in the NOP-In Response. Note that the length of
   the reflected data is limited to 4096 bytes and the initiator should
   avoid sending more than 4096 bytes. The length of ping data is indicated
   by the Data Segment Length.  0 is a valid value for the Data Segment
   Length - and indicates the absence of ping data.



1.2  NOP-In


   Byte /    0       |       1       |       2       |       3       |
      /              |               |               |               |
     |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
     +---------------+---------------+---------------+---------------+
    0|1|1| 0x20      |1| Reserved (0)                                |
     +---------------+---------------+---------------+---------------+
    4| Reserved (0)  | DataSegmentLength                             |
     +---------------+---------------+---------------+---------------+
    8| LUN or Reserved (0)                                           |
     +                                                               +
   12|                                                               |
     +---------------+---------------+---------------+---------------+
   16| Initiator Task Tag or Reserved (0xffffffff)                   |
     +---------------+---------------+---------------+---------------+
   20| Target Transfer Tag or Reserved (0xffffffff)                  |
     +---------------+---------------+---------------+---------------+
   24| StatSN                                                        |
     +---------------+---------------+---------------+---------------+
   28| ExpCmdSN                                                      |
     +---------------+---------------+---------------+---------------+
   32| MaxCmdSN                                                      |
     +---------------+---------------+---------------+---------------+
   36/ Reserved (0)                                                  /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
   48| Digests if any...                                             |
     +---------------+---------------+---------------+---------------+
     / DataSegment - Return Ping Data                                /
    +/                                                               /
     +---------------+---------------+---------------+---------------+


   When a target receives the NOP-Out with a valid Initiator Task Tag (not
   the reserved value 0xffffffff), it MUST respond with a NOP-In with the
   same Initiator Task Tag that was provided in the NOP-Out Command. It
   SHOULD also duplicate up to first 4096 bytes of the initiator provided
   Ping Data. For such a response, the Target Transfer Tag MUST be
   0xffffffff.

1.2.1     Target Transfer Tag

   A target assigned identifier for the operation.

   A target may issue a NOP-In on its own to test the connection and the
   state of the initiator. If the target wants to test the initiator, it
   sets the Target Task Tag to a valid value (not the reserved 0xffffffff)
   in order to ask for an answer from the initiator. In this case the
   Initiator Task Tag MUST be 0xffffffff and the LUN field MUST contain a
   valid LUN. If the target wants only to test the connection, both tags
   MUST hold the reserved value 0xffffffff and the LUN field is reserved.

   A target may also issue a NOP-In on its own to carry a changed ExpCmdSN
   and/or MaxCmdSN if there is no other PDU to carry them for a long time.

   Whenever the NOP-In is not issued in response to a NOP-Out the StatSN
   field will contain as usual the next StatSN but StatSN for this
   connection is not advanced.


1.2.2     LUN

   A LUN MUST be set to a correct value when the Target Transfer Tag is
   valid (not the reserved value 0xffffffff).




From owner-ips@ece.cmu.edu  Fri Aug 17 04:22:47 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21658
	for <ips-archive@odin.ietf.org>; Fri, 17 Aug 2001 04:22:47 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7H7IKH24339
	for ips-outgoing; Fri, 17 Aug 2001 03:18:20 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from yamuna.ctd.hcltech.com ([202.140.153.6])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7H7IHe24334
	for <ips@ece.cmu.edu>; Fri, 17 Aug 2001 03:18:17 -0400 (EDT)
Received: from kaveri.ctd.hcltech.com (KAVERI [192.168.102.25]) by yamuna.ctd.hcltech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id Q1C5CQHD; Fri, 17 Aug 2001 12:51:52 +0530
Received: from ASAI ([192.168.201.159]) by kaveri.ctd.hcltech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id Q1CWWT6N; Fri, 17 Aug 2001 12:49:07 +0530
Message-ID: <003b01c126ec$763b0000$9fc9a8c0@techmas.hcltech.com>
Reply-To: "Asai Thambi S P" <sp_asai@ctd.hcltech.com>
From: "Asai Thambi S P" <sp_asai@ctd.hcltech.com>
To: <ips@ece.cmu.edu>, "Julian Satran" <Julian_Satran@il.ibm.com>
References: <OF3B8DF8E1.C6FA971A-ONC2256AAA.002EF268@telaviv.ibm.com>
Subject: Re: iSCSI Change - New NOP-Out/In text
Date: Fri, 17 Aug 2001 12:45:54 +0530
Organization: HCL Technologies Ltd
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f7H7IJe24336
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit

I have some questions.


* Section 1.1
    The NOP-Out may be useful in the case where an initiator has been waiting a long time for the
   response to some command, and the initiator suspects that there is some
   problem with the connection.
----- Original Message ----- 
From: Julian Satran <Julian_Satran@il.ibm.com>
To: <ips@ece.cmu.edu>
Sent: Thursday, August 16, 2001 08:39 PM
Subject: iSCSI Change - New NOP-Out/In text


Here  is the new NOP-Out/In text (2.12 & 2.13):

1.1  NOP-Out


   Byte /    0       |       1       |       2       |       3       |
      /              |               |               |               |
     |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
     +---------------+---------------+---------------+---------------+
    0|X|I| 0x00      |1| Reserved (0)                                |
     +---------------+---------------+---------------+---------------+
    4| Reserved (0)  | DataSegmentLength                             |
     +---------------+---------------+---------------+---------------+
    8| LUN or Reserved (0)                                           |
     +                                                               +
   12|                                                               |
     +---------------+---------------+---------------+---------------+
   16| Initiator Task Tag or Reserved (0xffffffff)                   |
     +---------------+---------------+---------------+---------------+
   20| Target Transfer Tag or Reserved (0xffffffff)                  |
     +---------------+---------------+---------------+---------------+
   24| CmdSN                                                         |
     +---------------+---------------+---------------+---------------+
   28| ExpStatSN                                                     |
     +---------------+---------------+---------------+---------------+
   32/ Reserved (0)                                                  /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
   48| Digests if any...                                             |
     +---------------+---------------+---------------+---------------+
     / DataSegment - Ping Data (optional)                            /
    +/                                                               /
     +---------------+---------------+---------------+---------------+

   The NOP-Out with the Initiator Task Tag set to valid value (not the
   reserved 0xffffffff) acts as a "ping command".

   This form of the NOP-Out can be used to verify that a connection is
   still active and all its components are operational. This command MAY
   use in-order delivery or immediate delivery. The NOP-Out may be useful
   in the case where an initiator has been waiting a long time for the
   response to some command, and the initiator suspects that there is some
   problem with the connection.  When a target receives the NOP-Out with a
   valid Initiator Task Tag, it should respond with a Nop-In Response,
   duplicating the data that was provided in the NOP-Out (if any) as much
   as possible.  If the initiator does not receive the NOP-In within some
   time (determined by the initiator), or if the data returned by the
   NOP-In is different from the data that was in the NOP-Out, the initiator
   may conclude that there is a problem with the connection. The initiator
   then closes the connection and may try to establish a new connection.

   A NOP-Out should also be used to confirm a changed ExpStatSN if there is
   no other PDU to carry it for a long time.

   The NOP-Out can be sent by an initiator because of a NOP-In with the
   Target Transfer Tag set to a valid value (not the reserved 0xffffffff).
   In this case the NOP-Out Target Transfer Tag must contain a copy of
   NOP-In Target Task Tag.


1.1.1     Initiator Task Tag

   An initiator assigned identifier for the operation.

   The NOP-Out must have the Initiator Task Tag set to a valid value only
   if a response in the form of NOP-In is requested.
   If the Initiator Task Tag does not contain a valid value, the CmdSN
   field contains as usual the next CmdSN but CmdSN is not advanced and the
   I bit must be set to 1.

1.1.2     Target Transfer Tag

   A target assigned identifier for the operation.

   The NOP-Out MUST have the Target Transfer Tag set only if it is issued
   in response to a NOP-In with a valid Target Transfer Tag, in which case
   it copies the Target Transfer Tag from the NOP-In PDU.

   When the Target Transfer Tag is set, the LUN field MUST be also copied
   from the NOP-In.

1.1.3     Ping Data

   Ping data is reflected in the NOP-In Response. Note that the length of
   the reflected data is limited to 4096 bytes and the initiator should
   avoid sending more than 4096 bytes. The length of ping data is indicated
   by the Data Segment Length.  0 is a valid value for the Data Segment
   Length - and indicates the absence of ping data.



1.2  NOP-In


   Byte /    0       |       1       |       2       |       3       |
      /              |               |               |               |
     |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
     +---------------+---------------+---------------+---------------+
    0|1|1| 0x20      |1| Reserved (0)                                |
     +---------------+---------------+---------------+---------------+
    4| Reserved (0)  | DataSegmentLength                             |
     +---------------+---------------+---------------+---------------+
    8| LUN or Reserved (0)                                           |
     +                                                               +
   12|                                                               |
     +---------------+---------------+---------------+---------------+
   16| Initiator Task Tag or Reserved (0xffffffff)                   |
     +---------------+---------------+---------------+---------------+
   20| Target Transfer Tag or Reserved (0xffffffff)                  |
     +---------------+---------------+---------------+---------------+
   24| StatSN                                                        |
     +---------------+---------------+---------------+---------------+
   28| ExpCmdSN                                                      |
     +---------------+---------------+---------------+---------------+
   32| MaxCmdSN                                                      |
     +---------------+---------------+---------------+---------------+
   36/ Reserved (0)                                                  /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
   48| Digests if any...                                             |
     +---------------+---------------+---------------+---------------+
     / DataSegment - Return Ping Data                                /
    +/                                                               /
     +---------------+---------------+---------------+---------------+


   When a target receives the NOP-Out with a valid Initiator Task Tag (not
   the reserved value 0xffffffff), it MUST respond with a NOP-In with the
   same Initiator Task Tag that was provided in the NOP-Out Command. It
   SHOULD also duplicate up to first 4096 bytes of the initiator provided
   Ping Data. For such a response, the Target Transfer Tag MUST be
   0xffffffff.

1.2.1     Target Transfer Tag

   A target assigned identifier for the operation.

   A target may issue a NOP-In on its own to test the connection and the
   state of the initiator. If the target wants to test the initiator, it
   sets the Target Task Tag to a valid value (not the reserved 0xffffffff)
   in order to ask for an answer from the initiator. In this case the
   Initiator Task Tag MUST be 0xffffffff and the LUN field MUST contain a
   valid LUN. If the target wants only to test the connection, both tags
   MUST hold the reserved value 0xffffffff and the LUN field is reserved.

   A target may also issue a NOP-In on its own to carry a changed ExpCmdSN
   and/or MaxCmdSN if there is no other PDU to carry them for a long time.

   Whenever the NOP-In is not issued in response to a NOP-Out the StatSN
   field will contain as usual the next StatSN but StatSN for this
   connection is not advanced.


1.2.2     LUN

   A LUN MUST be set to a correct value when the Target Transfer Tag is
   valid (not the reserved value 0xffffffff).




From owner-ips@ece.cmu.edu  Fri Aug 17 05:37:45 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22370
	for <ips-archive@odin.ietf.org>; Fri, 17 Aug 2001 05:37:44 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7H8gEC27238
	for ips-outgoing; Fri, 17 Aug 2001 04:42:14 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7H8gDe27233
	for <ips@ece.cmu.edu>; Fri, 17 Aug 2001 04:42:13 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id KAA225690
	for <ips@ece.cmu.edu>; Fri, 17 Aug 2001 10:42:06 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7H8g6H07312
	for <ips@ece.cmu.edu>; Fri, 17 Aug 2001 10:42:06 +0200
Importance: Normal
Subject: Re: iSCSI: Ping Data,CmdSN
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFF66BA09C.40AF600E-ONC2256AAB.002F78F8@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Fri, 17 Aug 2001 11:41:41 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 17/08/2001 11:42:06
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

CmdSN - is meant to order commands (recall they are comming on different
connections and may have digest errors and be discarded).  Initiator is
responsible for filling in the gaps when commands are missing. Part 7
explains how and the appendix explains it in more detail.

Julo

"Asai Thambi S P" <sp_asai@ctd.hcltech.com> on 16-08-2001 11:51:57

Please respond to "Asai Thambi S P" <sp_asai@ctd.hcltech.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:
Subject:  Re: iSCSI: Ping Data,CmdSN



ok. regarding CmdSN?

asai.

----- Original Message -----
From: Julian Satran <Julian_Satran@il.ibm.com>
To: <ips@ece.cmu.edu>
Sent: Thursday, August 16, 2001 12:56 PM
Subject: Re: iSCSI: Ping Data,CmdSN



I am rewriting NOP according to my proposal agreed in London.  It will be
out today.
I will answer you after that if you still need it.

Julo

"Asai Thambi S P" <sp_asai@ctd.hcltech.com> on 16-08-2001 10:19:11

Please respond to "Asai Thambi S P" <sp_asai@ctd.hcltech.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:
Subject:  iSCSI: Ping Data,CmdSN



hi,

I have some queries. I thought I can get solutions in IPS. I've already
sent this to IPS. nobody replied. So I'm mailing u personnally. Can u help
me on this?


 * NOP-Out can be sent in response to NOP-In or to test the target or to
        test the connection.

        Section 2.12:

        "The NOP-Out may be useful in the case where an initiator has been
        waiting a long time for the response to some command, and the
        initiator suspects that there is some problem with the connection."

        "A NOP-Out should also be used to confirm a changed ExpStatSN if
there is no other PDU to carry it for a long time. "

      The draft also says that the timeout value is outside the scope of
the
document.

        In the former case, how do we know that we've been waiting for a
long time?
        In the latter case, how do we know that there is no other PDU's to
carry this for a long time?

* Similarly  for NOP-In,
        NOP-In can be sent
                        * in response to NOP-In
                        * to test the initiator
                        * to test the connection

        When to test the initiator or connection? How to decide it?

In case of target/initiator issuing NOP-In/NOP-Out on its own, what will be
the Ping Data?


* if CmdSN  is not equal to ExpCmdSN, what should the target do?
        suppose CmdSN > ExpCmdSN,  whether the target should assume that it
missed the commands in between and ask for retransmission of commands.
If so, how the target asks for command retransmission.
        If not, what the target should  do?

    The initiator asks for retransmission of status or data through SNACK
request.

Is there anything similar to this for target?

    One more regarding CmdSN,

    if CmdSN is not equal to ExpCmdSN in Task Management Command, what to
do?

 - asai.










From owner-ips@ece.cmu.edu  Fri Aug 17 07:07:52 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23546
	for <ips-archive@odin.ietf.org>; Fri, 17 Aug 2001 07:07:52 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7HAHLK12190
	for ips-outgoing; Fri, 17 Aug 2001 06:17:21 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7HAHJe12186
	for <ips@ece.cmu.edu>; Fri, 17 Aug 2001 06:17:19 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id MAA177216
	for <ips@ece.cmu.edu>; Fri, 17 Aug 2001 12:17:12 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7HAHBV20536
	for <ips@ece.cmu.edu>; Fri, 17 Aug 2001 12:17:11 +0200
Importance: Normal
Subject: RE: iSCSI Change - New NOP-Out/In text
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF789D103C.06834F75-ONC2256AAB.00358B9A@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Fri, 17 Aug 2001 13:16:44 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 17/08/2001 13:17:11
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Stephen,

Here is an edited version of the text. As you can see I am not a fan of
verbosity in a standard.
I hope it is a bit clearer.
The are no other changes than editorials.

Please feel free to send me or any other author any changes you propose.
If those are purely editorial you may want to refrain from sending them to
the list.
However you may want to send them to the list if you are somehow not
satisfied with either the answers you got
or think that the list should know about it anyhow.

And as I said there will be an editorial revision coming after 08.

Julo

1.1  NOP-Out


   Byte /    0       |       1       |       2       |       3       |
      /              |               |               |               |
     |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
     +---------------+---------------+---------------+---------------+
    0|X|I| 0x00      |1| Reserved (0)                                |
     +---------------+---------------+---------------+---------------+
    4| Reserved (0)  | DataSegmentLength                             |
     +---------------+---------------+---------------+---------------+
    8| LUN or Reserved (0)                                           |
     +                                                               +
   12|                                                               |
     +---------------+---------------+---------------+---------------+
   16| Initiator Task Tag or Reserved (0xffffffff)                   |
     +---------------+---------------+---------------+---------------+
   20| Target Transfer Tag or Reserved (0xffffffff)                  |
     +---------------+---------------+---------------+---------------+
   24| CmdSN                                                         |
     +---------------+---------------+---------------+---------------+
   28| ExpStatSN                                                     |
     +---------------+---------------+---------------+---------------+
   32/ Reserved (0)                                                  /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
   48| Digests if any...                                             |
     +---------------+---------------+---------------+---------------+
     / DataSegment - Ping Data (optional)                            /
    +/                                                               /
     +---------------+---------------+---------------+---------------+

   A NOP-Out may be used by an initiator as a "ping command", to verify
   that a connection/session is still active and all its components are
   operational.  The NOP-In response is the "ping echo".

   A NOP-Out is also sent by an initiator in response to a NOP-In.

   A NOP-Out may also be used to confirm a changed ExpStatSN if there is no
   other PDU to carry it for a long time.

   When used as a ping command, the Initiator Task Tag MUST be set to valid
   value (not the reserved 0xffffffff).

   Upon receipt of a NOP-In with the Target Transfer Tag set to a valid
   value (not the reserved 0xffffffff), the initiator MUST respond with a
   NOP-Out. In this case, the NOP-Out Target Transfer Tag MUST contain a
   copy of NOP-In Target Task Tag.

   When a target receives the NOP-Out with a valid Initiator Task Tag, it
   MUST respond with a Nop-In Response (see NOP-In).

1.1.1     Initiator Task Tag

   An initiator assigned identifier for the operation.

   The NOP-Out must have the Initiator Task Tag set to a valid value only
   if a response in the form of NOP-In is requested.

   If the Initiator Task Tag does not contain a valid value, the CmdSN
   field contains as usual the next CmdSN but CmdSN is not advanced and the
   I bit must be set to 1.

1.1.2     Target Transfer Tag

   A target assigned identifier for the operation.

   The NOP-Out MUST have the Target Transfer Tag set only if it is issued
   in response to a NOP-In with a valid Target Transfer Tag, in which case
   it copies the Target Transfer Tag from the NOP-In PDU.

   When the Target Transfer Tag is set, the LUN field MUST be also copied
   from the NOP-In.

1.1.3     Ping Data

   Ping data is reflected in the NOP-In Response. Note that the length of
   the reflected data is limited to 4096 bytes and the initiator should
   avoid sending more than 4096 bytes. The length of ping data is indicated
   by the Data Segment Length.  0 is a valid value for the Data Segment
   Length - and indicates the absence of ping data.



1.2  NOP-In


   Byte /    0       |       1       |       2       |       3       |
      /              |               |               |               |
     |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
     +---------------+---------------+---------------+---------------+
    0|1|1| 0x20      |1| Reserved (0)                                |
     +---------------+---------------+---------------+---------------+
    4| Reserved (0)  | DataSegmentLength                             |
     +---------------+---------------+---------------+---------------+
    8| LUN or Reserved (0)                                           |
     +                                                               +
   12|                                                               |
     +---------------+---------------+---------------+---------------+
   16| Initiator Task Tag or Reserved (0xffffffff)                   |
     +---------------+---------------+---------------+---------------+
   20| Target Transfer Tag or Reserved (0xffffffff)                  |
     +---------------+---------------+---------------+---------------+
   24| StatSN                                                        |
     +---------------+---------------+---------------+---------------+
   28| ExpCmdSN                                                      |
     +---------------+---------------+---------------+---------------+
   32| MaxCmdSN                                                      |
     +---------------+---------------+---------------+---------------+
   36/ Reserved (0)                                                  /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
   48| Digests if any...                                             |
     +---------------+---------------+---------------+---------------+
     / DataSegment - Return Ping Data                                /
    +/                                                               /
     +---------------+---------------+---------------+---------------+


   NOP-In is either sent by a target as a response to a NOP-Out, as a
   "ping" to an initiator, or a means to carry a changed ExpCmdSN and/or
   MaxCmdSN if there is no other PDU to carry them for a long time.

   When a target receives the NOP-Out with a valid Initiator Task Tag (not
   the reserved value 0xffffffff), it MUST respond with a NOP-In with the
   same Initiator Task Tag that was provided in the NOP-Out Command. It
   MUST also duplicate up to first 4096 bytes of the initiator provided
   Ping Data.  For such a response, the Target Transfer Tag MUST be
   0xffffffff.


1.2.1     Target Transfer Tag

   A target assigned identifier for the operation.

   If the target is responding to a NOP-Out, this is set to the reserved
   value 0xffffffff.

   If the target is sending a NOP-In as a Ping (intending to receive a
   corresponding NOP-Out), this field is set to a valid value (not the
   reserved 0xffffffff).

   If the target is initiating a NOP-In without wanting to receive a
   corresponding NOP-Out, this field MUST hold the reserved value of
   0xffffffff.

   Whenever the NOP-In is not issued in response to a NOP-Out the StatSN
   field will contain as usual the next StatSN but StatSN for this
   connection is not advanced.


1.2.2     LUN

   A LUN MUST be set to a correct value when the Target Transfer Tag is
   valid (not the reserved value 0xffffffff).

---------------------- Forwarded by Julian Satran/Haifa/IBM on 17-08-2001
12:44 ---------------------------





"Wheat, Stephen R" <stephen.r.wheat@intel.com> on 16-08-2001 19:09:30

Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>

To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
cc:

Subject:  RE: iSCSI Change - New NOP-Out/In text




Julian,

As a relatively new reader of all this good material, perhaps some "new
eyes" editorial questions/suggestions are of value.  My apologies up front
if this doesn't meet with the WG protocol for such suggestions.

Stephen

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, August 16, 2001 8:09 AM
To: ips@ece.cmu.edu
Subject: iSCSI Change - New NOP-Out/In text

+++ srw
The first two paragraphs intermix rational and specification for a "ping
command".
Rational is also repeated.
For brevity and clarity, I suggest striving to keep rational segregated
from
semantic definition.

Also, the target's semantics are inconsistent between the NOP-out and
NOP-in
paragraphs.

I offer the following text update.

I am willing to do such editorial changes for the rest, but am awaiting
whether the suggestions are valuable.
+++ srw

   A NOP-Out may be sent by an initiator as a "ping command".  This form of
the NOP-Out
   can be used to verify that a connection is still active and all its
components are
   operational.  Based upon whether a corresponding NOP-In is received,
this
   provides an initiator a way to determine whether it may be necessary to
   close the connection and try to establish a new connection.

   A NOP-Out is also sent by an initiator in response to a NOP-In.

   A NOP-Out may also be used to confirm a changed ExpStatSN if there is
   no other PDU to carry it for a long time.

   This command MAY use in-order delivery or immediate delivery.

   When used as a ping command, the Initiator Task Tag MUST be set to valid
value (not the
   reserved 0xffffffff).

   Upon receipt of a NOP-In with the
   Target Transfer Tag set to a valid value (not the reserved 0xffffffff),
   the initiator MUST respond with a NOP-Out. In this case the NOP-Out
Target Transfer
   Tag MUST contain a copy of NOP-In Target Task Tag.

   When a target receives the NOP-Out with a
   valid Initiator Task Tag, it MUST respond with a Nop-In Response (see
NOP-in).
                                ^^^^ consider MUST???

1.1.1     Initiator Task Tag

   An initiator assigned identifier for the operation.

   The NOP-Out MUST have the Initiator Task Tag set to a valid value only
   if a response in the form of NOP-In is requested.
   If the Initiator Task Tag does not contain a valid value, the CmdSN
   field contains as usual the next CmdSN but CmdSN is not advanced and the
   I bit must be set to 1.

1.1.2     Target Transfer Tag

   A target assigned identifier for the operation.

   The NOP-Out MUST have the Target Transfer Tag set only if it is issued
   in response to a NOP-In with a valid Target Transfer Tag, in which case
   it copies the Target Transfer Tag from the NOP-In PDU.

   When the Target Transfer Tag is set, the LUN field MUST be also copied
   from the NOP-In.






"Wheat, Stephen R" <stephen.r.wheat@intel.com> on 16-08-2001 23:10:53

Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>

To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
cc:

Subject:  RE: iSCSI Change - New NOP-Out/In text




Here is a (maybe partial) draft of the suggested NOP-In rewording.  Whether
this type of commentary is worthwhile, please let me know.

Embedded are some questions I have from the original writing this morning.

As a commentary/question, shouldn't all fields be documented, rather than
having their semantics covered in other field documentation???

At the very least, I'd appreciate the text to be changed to answer my
questions embedded below.

BTW, since a NOP-In could result in a corresponding NOP-Out, the name of
the
ping data fields is kind of lopsided.  I.e., for NOP-Out, it is "Ping
Data",
and for NOP-In, it is "Return Ping Data."  A NOP-Out's ping data is "return
ping data" when sent as a response to a NOP-In.  So, how about just calling
it "Ping Data" in both messages??

Stephen

==================

1.2  NOP-In

   NOP-In is either sent by a target as a response to having received a
NOP-Out,
   as a "ping" to an initiator, or a means to carry a changed ExpCmdSN
   and/or MaxCmdSN if there is no other PDU to carry them for a long time.

   When a target receives the NOP-Out with a valid Initiator Task Tag (not
   the reserved value 0xffffffff), it MUST respond with a NOP-In with the
   same Initiator Task Tag that was provided in the NOP-Out Command. It
   SHOULD also duplicate up to first 4096 bytes of the initiator provided
   Ping Data.

1.2.1     Target Transfer Tag

   A target assigned identifier for the operation.

   If the target is responding to a NOP-Out, this is set to ?????????

   If the target is initiating a NOP-Out as a Ping (intending to receive a
corresponding
   NOP-Out), this field is set to a valid value (not the reserved
0xffffffff).

   If the target is initiating a NOP-Out without wanting to receive a
corresponding
   NOP-In, this field MUST hold the reserved value of 0xffffffff.

1.2.2   Initiator Task Tag
   When the NOP-Out is in response to a NOP-In, this is the same value as
found in the NOP-Out.

   Otherwise, this field MUST be 0xffffffff.

1.2.3     LUN

   A LUN MUST be set to a correct value when the Target Transfer Tag is
   valid (not the reserved value 0xffffffff).  Otherwise, it SHOULD be set
to the
   reserved value of 0.

1.2.4  StatSN
   Whenever the NOP-In is not issued in response to a NOP-Out the, StatSN
   field will contain the next StatSN but StatSN for this
   connection is not advanced.  Otherwise, it will be set to ????????.

1.2.5  Data Segment Length
   The number of bytes in the Return Ping Data.  The range is [0..4096].






"Wheat, Stephen R" <stephen.r.wheat@intel.com> on 16-08-2001 23:41:33

Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:

Subject:  RE: iSCSI Change - New NOP-Out/In text




Ooops, this paragraph should have been changed

   When a target receives the NOP-Out with a valid Initiator Task Tag (not
   the reserved value 0xffffffff), it MUST respond with a NOP-In with the
   same Initiator Task Tag that was provided in the NOP-Out Command. It
   SHOULD also duplicate up to first 4096 bytes of the initiator provided
   Ping Data.

to

   When a target receives the NOP-Out with a valid Initiator Task Tag (not
   the reserved value 0xffffffff), it MUST respond with a NOP-In.


Where the particular fields of the response are covered in their sections.



Seriously, are you wanting editorial comments about clarity, readability,
and consistency?

Stephen






From owner-ips@ece.cmu.edu  Fri Aug 17 08:31:16 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26924
	for <ips-archive@odin.ietf.org>; Fri, 17 Aug 2001 08:31:16 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7HBUIR14433
	for ips-outgoing; Fri, 17 Aug 2001 07:30:18 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7HBUGe14429
	for <ips@ece.cmu.edu>; Fri, 17 Aug 2001 07:30:16 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id NAA10934
	for <ips@ece.cmu.edu>; Fri, 17 Aug 2001 13:30:09 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7HBU8H183476
	for <ips@ece.cmu.edu>; Fri, 17 Aug 2001 13:30:08 +0200
Importance: Normal
Subject: Re: iSCSI Change - New NOP-Out/In text
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF52DEB9C9.D6F8C9F1-ONC2256AAB.003EFC86@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Fri, 17 Aug 2001 14:29:42 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 17/08/2001 14:30:08
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Time is depending on the target and link. As customary in TCP/IP based
networks the timeouts have to be determined based on the link
characteristics.

Julo

"Asai Thambi S P" <sp_asai@ctd.hcltech.com> on 17-08-2001 10:27:42

Please respond to "Asai Thambi S P" <sp_asai@ctd.hcltech.com>

To:   <ips@ece.cmu.edu>, Julian Satran/Haifa/IBM@IBMIL
cc:
Subject:  Re: iSCSI Change - New NOP-Out/In text



Sorry for the previous mail, which was sent accidentally.

Julian,

I have some questions.

* Section 1.1  NOP-Out

                                            The NOP-Out may be useful
   in the case where an initiator has been waiting a long time for the
   response to some command, and the initiator suspects that there is some
   problem with the connection. .....

   If the initiator does not receive the NOP-In within some
   time (determined by the initiator),

      A NOP-Out should also be used to confirm a changed ExpStatSN if there
is
   no other PDU to carry it for a long time.

    ? The draft doesn't say what a long time is?

    Section 7.11.1 says as follows:

         The timeout value to be used by a target is outside the scope
           of this document.
    and
         The timeout value to be used by an initiator is outside the
           scope of this document.

    ? How the initiator/target times out is not defined? Then what that
long time refers
    to?

* Section 1.1.3     Ping Data

   Ping data is reflected in the NOP-In Response. Note that the length of
   the reflected data is limited to 4096 bytes and the initiator should
   avoid sending more than 4096 bytes. The length of ping data is indicated
   by the Data Segment Length.  0 is a valid value for the Data Segment
   Length - and indicates the absence of ping data.

    ? The text starts abruptly that ping data is reflected....
       It doesn't say what the ping data is?


- asai.



----- Original Message -----
From: Julian Satran <Julian_Satran@il.ibm.com>
To: <ips@ece.cmu.edu>
Sent: Thursday, August 16, 2001 08:39 PM
Subject: iSCSI Change - New NOP-Out/In text


Here  is the new NOP-Out/In text (2.12 & 2.13):

1.1  NOP-Out


   Byte /    0       |       1       |       2       |       3       |
      /              |               |               |               |
     |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
     +---------------+---------------+---------------+---------------+
    0|X|I| 0x00      |1| Reserved (0)                                |
     +---------------+---------------+---------------+---------------+
    4| Reserved (0)  | DataSegmentLength                             |
     +---------------+---------------+---------------+---------------+
    8| LUN or Reserved (0)                                           |
     +                                                               +
   12|                                                               |
     +---------------+---------------+---------------+---------------+
   16| Initiator Task Tag or Reserved (0xffffffff)                   |
     +---------------+---------------+---------------+---------------+
   20| Target Transfer Tag or Reserved (0xffffffff)                  |
     +---------------+---------------+---------------+---------------+
   24| CmdSN                                                         |
     +---------------+---------------+---------------+---------------+
   28| ExpStatSN                                                     |
     +---------------+---------------+---------------+---------------+
   32/ Reserved (0)                                                  /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
   48| Digests if any...                                             |
     +---------------+---------------+---------------+---------------+
     / DataSegment - Ping Data (optional)                            /
    +/                                                               /
     +---------------+---------------+---------------+---------------+

   The NOP-Out with the Initiator Task Tag set to valid value (not the
   reserved 0xffffffff) acts as a "ping command".

   This form of the NOP-Out can be used to verify that a connection is
   still active and all its components are operational. This command MAY
   use in-order delivery or immediate delivery. The NOP-Out may be useful
   in the case where an initiator has been waiting a long time for the
   response to some command, and the initiator suspects that there is some
   problem with the connection.  When a target receives the NOP-Out with a
   valid Initiator Task Tag, it should respond with a Nop-In Response,
   duplicating the data that was provided in the NOP-Out (if any) as much
   as possible.  If the initiator does not receive the NOP-In within some
   time (determined by the initiator), or if the data returned by the
   NOP-In is different from the data that was in the NOP-Out, the initiator
   may conclude that there is a problem with the connection. The initiator
   then closes the connection and may try to establish a new connection.

   A NOP-Out should also be used to confirm a changed ExpStatSN if there is
   no other PDU to carry it for a long time.

   The NOP-Out can be sent by an initiator because of a NOP-In with the
   Target Transfer Tag set to a valid value (not the reserved 0xffffffff).
   In this case the NOP-Out Target Transfer Tag must contain a copy of
   NOP-In Target Task Tag.


1.1.1     Initiator Task Tag

   An initiator assigned identifier for the operation.

   The NOP-Out must have the Initiator Task Tag set to a valid value only
   if a response in the form of NOP-In is requested.
   If the Initiator Task Tag does not contain a valid value, the CmdSN
   field contains as usual the next CmdSN but CmdSN is not advanced and the
   I bit must be set to 1.

1.1.2     Target Transfer Tag

   A target assigned identifier for the operation.

   The NOP-Out MUST have the Target Transfer Tag set only if it is issued
   in response to a NOP-In with a valid Target Transfer Tag, in which case
   it copies the Target Transfer Tag from the NOP-In PDU.

   When the Target Transfer Tag is set, the LUN field MUST be also copied
   from the NOP-In.

1.1.3     Ping Data

   Ping data is reflected in the NOP-In Response. Note that the length of
   the reflected data is limited to 4096 bytes and the initiator should
   avoid sending more than 4096 bytes. The length of ping data is indicated
   by the Data Segment Length.  0 is a valid value for the Data Segment
   Length - and indicates the absence of ping data.



1.2  NOP-In


   Byte /    0       |       1       |       2       |       3       |
      /              |               |               |               |
     |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
     +---------------+---------------+---------------+---------------+
    0|1|1| 0x20      |1| Reserved (0)                                |
     +---------------+---------------+---------------+---------------+
    4| Reserved (0)  | DataSegmentLength                             |
     +---------------+---------------+---------------+---------------+
    8| LUN or Reserved (0)                                           |
     +                                                               +
   12|                                                               |
     +---------------+---------------+---------------+---------------+
   16| Initiator Task Tag or Reserved (0xffffffff)                   |
     +---------------+---------------+---------------+---------------+
   20| Target Transfer Tag or Reserved (0xffffffff)                  |
     +---------------+---------------+---------------+---------------+
   24| StatSN                                                        |
     +---------------+---------------+---------------+---------------+
   28| ExpCmdSN                                                      |
     +---------------+---------------+---------------+---------------+
   32| MaxCmdSN                                                      |
     +---------------+---------------+---------------+---------------+
   36/ Reserved (0)                                                  /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
   48| Digests if any...                                             |
     +---------------+---------------+---------------+---------------+
     / DataSegment - Return Ping Data                                /
    +/                                                               /
     +---------------+---------------+---------------+---------------+


   When a target receives the NOP-Out with a valid Initiator Task Tag (not
   the reserved value 0xffffffff), it MUST respond with a NOP-In with the
   same Initiator Task Tag that was provided in the NOP-Out Command. It
   SHOULD also duplicate up to first 4096 bytes of the initiator provided
   Ping Data. For such a response, the Target Transfer Tag MUST be
   0xffffffff.

1.2.1     Target Transfer Tag

   A target assigned identifier for the operation.

   A target may issue a NOP-In on its own to test the connection and the
   state of the initiator. If the target wants to test the initiator, it
   sets the Target Task Tag to a valid value (not the reserved 0xffffffff)
   in order to ask for an answer from the initiator. In this case the
   Initiator Task Tag MUST be 0xffffffff and the LUN field MUST contain a
   valid LUN. If the target wants only to test the connection, both tags
   MUST hold the reserved value 0xffffffff and the LUN field is reserved.

   A target may also issue a NOP-In on its own to carry a changed ExpCmdSN
   and/or MaxCmdSN if there is no other PDU to carry them for a long time.

   Whenever the NOP-In is not issued in response to a NOP-Out the StatSN
   field will contain as usual the next StatSN but StatSN for this
   connection is not advanced.


1.2.2     LUN

   A LUN MUST be set to a correct value when the Target Transfer Tag is
   valid (not the reserved value 0xffffffff).







From owner-ips@ece.cmu.edu  Fri Aug 17 11:54:14 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06138
	for <ips-archive@odin.ietf.org>; Fri, 17 Aug 2001 11:54:14 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7HEkTk22827
	for ips-outgoing; Fri, 17 Aug 2001 10:46:29 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7HEkSe22822
	for <ips@ece.cmu.edu>; Fri, 17 Aug 2001 10:46:28 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id QAA116522;
	Fri, 17 Aug 2001 16:46:13 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7HEkDV50336;
	Fri, 17 Aug 2001 16:46:13 +0200
Importance: Normal
Subject: Re: Application for port-number
To: "Julian Satran" <Julian_Satran@il.ibm.com>
Cc: ips@ece.cmu.edu, Allison Mankin <mankin@east.isi.edu>
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFFBA87651.2DC841D5-ONC2256AAB.00506CD8@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Fri, 17 Aug 2001 17:45:49 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 17/08/2001 17:46:13
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Please accept the following revised application taht includes SCTP as an
additional protocol.


Thanks,
Julo

----------------------------------------------------------------------------------------------

Application for System (Well-Known) Port Number

Name :
Julian Satran

E-mail :
Julian_Satran@il.ibm.com

Protocol Number :
TCP,SCTP

Message Formats :
BasicHeader+AuxiliaryHeader+Data

Message Types :
Request/Reply

Message opcodes :
Over 20 types

Message Sequences :
request/response

Protocol functions :
Carries SCSI commands

Broadcast or Multicast used ?
no

How and what for Broadcast or Multicast is used (if used):


Description :
 draft-ietf-ips-iscsi-07.txt

Name of the port :
iSCSI Target Access

Short name of the port :
iSCSI-target

Justfication for multiple protocols:
iSCSI is expected to use TCP for initial deployments
but transition to SCTP in future






From owner-ips@ece.cmu.edu  Fri Aug 17 13:06:05 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08511
	for <ips-archive@odin.ietf.org>; Fri, 17 Aug 2001 13:06:05 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7HG0VJ26393
	for ips-outgoing; Fri, 17 Aug 2001 12:00:31 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7HG0Re26387
	for <ips@ece.cmu.edu>; Fri, 17 Aug 2001 12:00:28 -0400 (EDT)
Received: by ATLOPS with Internet Mail Service (5.5.2448.0)
	id <QMJCND8M>; Fri, 17 Aug 2001 12:00:20 -0400
Message-ID: <25369470B6F0D41194820002B328BDD2116240@ATLOPS>
From: Sanjay Goyal <sanjay_goyal@ivivity.com>
To: "'Mark Bakke'" <mbakke@cisco.com>
Cc: "Ips (E-mail)" <ips@ece.cmu.edu>,
        Sanjay Goyal
	 <sanjay_goyal@ivivity.com>
Subject: RE: iSCSI: [Fwd: Crc-32c example in iSCSI spec]
Date: Fri, 17 Aug 2001 12:00:18 -0400
X-MS-TNEF-Correlator: <25369470B6F0D41194820002B328BDD2116240@ATLOPS>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C12735.B67020DA"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C12735.B67020DA
Content-Type: text/plain;
	charset="iso-8859-1"

Hi
 I get the remainder for iSCSI as 0x1c2d19ed if I complement my CRC and then
pass it through the CRC engine.
 
 As per CRC generation for data: the thing which is not clear to me is 
   why do we need to bit-swap the CRC reminader as is done in all your
examples. 

We can just complement it and append it after the DATA bytes.
 The other side also can just pass it through the CRC engine to check it.

Regards
Sanjay Goyal

-----Original Message-----
From: Mark Bakke [mailto:mbakke@cisco.com]
Sent: Thursday, August 16, 2001 1:43 PM
To: Steve Blightman; ips@ece.cmu.edu
Subject: Re: [Fwd: Crc-32c example in iSCSI spec]



One more thing that might be helpful.  When the Ethernet
polynomial is used in SCSI to generate its CRC, the T10
doc specifies the remainder polynomial that one should see
after running the data with a valid CRC through.  For
the Ethernet CRC, this was specified as 0xc704dd7b.  This
remainder polynomial is taken before the CRC is complemented
and bit-reflected.  For iSCSI, I came up with a remainder of
0x1c2d19ed.  Can anyone verify this result?

--
Mark

Mark Bakke wrote:
> 
> Steve-
> 
> I just ran some Ethernet packets with known CRCs through
> my iSCSI/Ethernet CRC generator, and found the same thing
> as you did.
> 
> All of my examples need to be byte-swapped, along with the
> fix I already posted for the all-ones example.  Here is a
> new set of examples, which will be in -08.  I also ran
> 64 bytes of zeroes and ones, which now agree with your
> numbers as well.
> 
> Thanks again for bringing this up.
> 
> --
> Mark
> 
>      07 CRC Examples
> 
>         N.B. all Values are Hexadecimal
> 
>           Byte:        0  1  2  3
> 
>              0:       01 a0 00 00
>              4:       00 00 00 00
>              8:       00 00 00 00
>             12:       00 00 00 00
>             16:       04 05 00 00
>             20:       00 01 00 00
>             24:       00 00 00 05
>             28:       00 00 00 04
>             32:       2a 00 00 00
>             36:       00 00 00 00
>             40:       80 00 00 00
>             44:       00 00 00 00
> 
>            CRC:       93 70 51 db
> 
>         32 bytes of zeroes:
> 
>           Byte:        0  1  2  3
> 
>              0:       00 00 00 00
>            ...
>             28:       00 00 00 00
> 
>            CRC:       aa 36 91 8a
> 
>         32 bytes of ones:
> 
>           Byte:        0  1  2  3
> 
>              0:       ff ff ff ff
>            ...
>             28:       ff ff ff ff
> 
>            CRC:       43 ab a8 62
> 
>         32 bytes of incrementing 00..1f:
> 
>           Byte:        0  1  2  3
> 
>              0:       00 01 02 03
>            ...
>             28:       1c 1d 1e 1f
> 
>            CRC:       4e 79 dd 46
> 
> 
> Steve Blightman wrote:
> >
> > I believe the examples for the ISCSI CRC  have the wrong endianness.
> >
> > As yiou suugested over the phone I ran some Ethernet frames through a
> > simulation. I have some difficulty running the exact simulations you
> > wanted becuase the minimum size Ethernet frame is 64 bytes.
> >
> > However using the Ethernet CRC polynomial,
> > Running 64 bytes of 0 onto the wire, we append "36 63 8d 75" onto the
> > wire for the CRC - "36" goes out first.
> > Running 64 bytes of all 1, we append "ba 87 61 0f" onto the wire - "ba"
> > goes out first.
> >
> > Using the same logic for the ISCSI polynomial
> > Running 64 bytes of 0 I think we should append "67 eb c8 03" - "67"
> > going out first
> > and running 64 bytes of all 1 we should append "66 4e cd 2f" - "66"
> > going out first
> >
> > And now for 32 bytes with the ISCSI polynomial
> >
> > Running 32 bytes of 0 we should append "aa 36 91 8a" - "aa" going out
> > first
> > Running 32 bytes of all 1 we should append "43 ab a8 62" - "43" going
> > out first
> >
> > I don't want to get into an endless endian debate, but I believe it is
> > important to get the order of these bytes in the right order, so that we
> > can use the same hardware to check as well as to generate CRCs.
> >
> > Thanks for your help on this,
> > Steve Blightman
> 
> --
> Mark A. Bakke
> Cisco Systems
> mbakke@cisco.com
> 763.398.1054

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054

------_=_NextPart_000_01C12735.B67020DA
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64

eJ8+IhUQAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQWAAwAOAAAA0QcIABEADAAAABIABQAUAQEggAMADgAAANEHCAAR
AAwAAAATAAUAFQEBCYABACEAAABDMzUyODMxODcwOTJENTExOTRCMzAwMDJCMzI4QkREMgDdBgEE
gAEAMAAAAFJFOiBpU0NTSTogW0Z3ZDogQ3JjLTMyYyBleGFtcGxlIGluIGlTQ1NJIHNwZWNdAK8O
AQ2ABAACAAAAAgACAAEDkAYAPA4AADAAAAADAAlZAQAAAAMA3j/kBAAAAwA2AAAAAAADAFuACCAG
AAAAAADAAAAAAAAARgAAAABShQAAfW4BAB4AXIAIIAYAAAAAAMAAAAAAAABGAAAAAFSFAAABAAAA
BAAAADkuMAALAIWACCAGAAAAAADAAAAAAAAARgAAAAAGhQAAAAAAAAMADoAIIAYAAAAAAMAAAAAA
AABGAAAAAAGFAAAAAAAACwAQgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAALABGACCAGAAAA
AADAAAAAAAAARgAAAAAOhQAAAAAAAAMAN4AIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwA4
gAggBgAAAAAAwAAAAAAAAEYAAAAAEYUAAAAAAAADAD6ACCAGAAAAAADAAAAAAAAARgAAAAAYhQAA
AAAAAAIBCRABAAAAGwkAABcJAAB7FAAATFpGdRLlLoEDAAoAcmNwZzEyNeIyA0N0ZXgFQQEDAff/
CoACpAPkBxMCgA/zAFAEVj8IVQeyESUOUQMBAgBjaOEKwHNldDIGAAbDESX2MwRGE7cwEiwRMwjv
Cfe2OxgfDjA1ESIMYGMAUDMLCQFkMzYWUAumIEiHAKAKsQqAIEkgZxQg4CB0aGUgGCAAwAuADQSB
IAIQBcBpU0NTBR2AYQQgMHgxYzLYZDE5CYAe8GYdcQWgnm0LUB4wCfAFQG15EiD8UkMfUB5wHdID
oAqwBBHGaR3CA2B1Z2gd0yFyZQnwZwuAZS4dFR0VQT0EIHASgSFyHaAkAHJhLHRpAiAes2QmEGE6
xx3THeALgGcgdydgE9DTHvAEIG5vBUBjINAKwfx0byEwHgAoER0VKdAnsPUhUGQo8HceACQAIBEo
4cpiIpAtA+BhcCM3HiH9C4BhHoIfYSgRKkAkAB7wNwOgB0ADIHkIYSOweGFZILJzLiSVHRRXHgBj
8QORanVzKGEgqCKRIbJ/K4AlQCHBMRIBgBKBHeJE6EFUQSsQeQ6wLrAdFf5UHfEoUB3wBcAAkAEA
LaH+cyjwL9ciTyNbKNIT0AWQjms18SQlHRRSZWcLESZzHRQGEWphIVBHb9Z5B0Au6i07ck8FECPh
5wdABdAHkHNhHaA7cx0UNkYDYSbwTQrAOBBCYVRrax4AWx5BbCjgOrMG0D4yQGMEAAWgLiCRvl05
lSEBJvAz4AhwcyawnHksEMA2cDAiMTZBUAkB0DAxQdA6NDMgdFBNHRRUPuAGAA6wdkkeAEJsO+Bo
dAOBOzEe8HBzQAWQJBBjbRx1LgmADHA5pHViag8FkEChOSAm8FtGd2QBJvBDcmMtMzJj1y42LXIf
BHMlQGNABUj//ApPLVEEYBggJ0Ud4CYQHyEwRAIrEB4AHfBscGZkdWwuwCBXIgId4kWrNDIkAHQd
FHAG8HkoQP8sUDwhKBEwICASA6AfEyjheyXFKSF0BCAhcUFQHeJU/jEBQB0jKkBHcEiiBpAIkJ8E
IB3sTllLYy1Cc2gIYDZsICAUEGUdFDIkcnX+bgMASzMeACayJ6A2ACMgfVdwdgdANJAhYzY1TLFG
/wWwHRRNOlD2KBErcAQgUmYDMWEfcmM3MDRkZPw3YkyxM+AEAB0UU09Oxf8BkD5QA6BMEB7BJzIj
ZCgRvyCYCYBVxSHBKyIYIGYg0P9GMAmAWRQe9EFQIHEuYB4AznUrkFeVHihvZh0UH5j9TLFDA5EA
cC3wLVFDsAaBlyFQWvMYIHNMkHQ/OrxvHRQ90i7qPdl3A2AOsDr9HRQ+JJVsYEODPQVsaB2A/zAT
JgADoDTwKRFaFwqwOADXFCBbIVeiayhAdxIRIYDfUuI2U2wGIUEfAy9aGiW2/wWwQVAhsgIQVpAh
0zRwZAL/J1NsBh9hLfEmoDSQJCVsaP5BLcFlgCEyLkYqmB4AMxL7K1MlQGR0URewJ4JXoh3h+2wG
UrB4HXEHQBggLIAhUL9OUDAwIBEewh3iLbEtLUG3BCAuRUyxSASQKSNhbAb/JAAH4BQReFIuRkFQ
J7QD8MctwUwRLYEtMDhMsXyCZzTxbtFsBjY0MwR4Unr9BJBvB5Ehsn5SgYZw0R9Q7wnCV4Qt8n/X
dQbQBJB/ob9bIUxQTKBsDjPgAHBrf6H3OUAtgR7CYgUQI9JLQk8CfnCJDzz2bGBp+GxojwMwOjch
Y0UuVY4fkUVOLvZCLsAtslYHQApQf6FK0X9/QC5QBYEHcDqWkL8p0UJ/MyEm8JFFFlBB0CnQFEAg
txUwk9+UuTCVpkJBYRZQ70IwmYGXX48CNJi3mXWZv/2RRTibT5xfjwMOIJ3fnu/Nn/Q2mLeEQDA1
oT+RR/8B0KBqQlCj36Tnmz+jkaa/f6Uync+jYalPKdFHUJWmMn9XcKEfrGqi6KD/mmyYpzj/sF+a
bKgPs1mzj2axIYCVpqY5QqBcgCA1QlBkDDD/ti+stoRea/+Uz5Xfu++X//u1P7+eLsMgwf+qX7Wv
w3+9t8lhV3AcILhgQlA4f8f/ua+6uX5Su8+8373vy5/AD/8p0QEg0OfPH8MPxB/Q787v77d+QpEB
oB9QOIQgDlDVr3/KHy1xBQAg4ydyQjDS0DH+Zst/zI/Nn9w/z7+l2BRA/jDfJ9Iv3+/EmB+wQdAg
IH4xHgDb8N8/1q+a8x4AN+Y5JqAgIDQ2bA5si0PY/WudPuwnHXFMEEPwQ6Id4rt4x32WSR8TIXJM
MGHtxf9roSeBMbEHMFagPGGMJ+yp/SUReSYwdsBoYDZwB5B9UvZvZ4Ed03BVMC1RHYBu3/8esCYA
B4I2Nn/HbGAAkEUg/wtgJiIuwB2A7/NvE3bgASD/DeBocSFQVoouQUYw96l2g//suCtwYUJMAfmA
H2Bf9CxR/ffBbTRxhPD1fSgChDbxj/3tIUhw4EOhBcAwIFbGcvv1Tlgs7LhSVpWEOhZQD5F7KPDw
Q2kYIIGBNLExlCIVyHE2QqA4ICA3NSLfBgf7+QaxfYchci0Hkghg/meFIhJA9fEGsDAwADgEr3t4
Ui2yMQbrPxCdsI9wNr2mQWYIaAmUCrE/ECLsuPsLLwBvVQIHdVMXsCPgR3D/7sxOWAwfBS1P4Sdh
OBAqcatVJQc2No9wZdgwY9hg/+IgCGAKsRpQERsnchIX7Lh/IbJWhg0/GS8aMciA6JFj/U9gMg+x
GyIK8BuPHJ/yKf8xUYZiiuK6p3tGFa8jfxc497qq3pAfnyLISRsDyEALAv8ipey4HM0ovx8PGbjX
+RsDP0KQLFXsuCLv7KtSIG4n/0HA/JJP9EHAPAAQAWbhB2F/kCF+gfDzuPAagFCBQVBifxIh7Vhi
MF8B7Lj3wE5Qcv9fQDXoUwKK8GVEUvL9UYRk/4qxUwNLwzuTQVCDUUtjMDD/7Lhj8GbwTzF1CEtw
O6D8kP9K0oNghjBGIBkQiJVcElAK/3EiEq/tIYoViuKHUkwzVNH/WuMECerNjD+NS/KwkgBrQ13p
xkP/gGDA6rB5fUFtt5BHiDBrUkBbsErxLmDBxenGNwfgLjM5gtBRoP41q8VpFualSY9WAErfVgAn
TC9pI02vCn1UoAAeAHAAAQAAACUAAABbRndkOiBDcmMtMzJjIGV4YW1wbGUgaW4gaVNDU0kgc3Bl
Y10AAAAAAgFxAAEAAAAbAAAAAcEmhgRSGINKwJJwEdWUswACsyi90gArkZtQAAMAJgAAAAAAAwAu
AAAAAAALAAIAAQAAAB4AQhABAAAAHgAAADwzQjdDMDYxMC43ODNBMzNDQ0BjaXNjby5jb20+AAAA
AwD9P+QEAABAADkAoNz4tTUnwQEDAPE/CQQAAB4AMUABAAAACAAAAFNBTkpBWUcAAwAaQAAAAAAe
ADBAAQAAAAgAAABTQU5KQVlHAAMAGUAAAAAAAwCAEP////8LAPIQAQAAAAIBRwABAAAALwAAAGM9
VVM7YT0gO3A9SVZJVklUWTtsPUFUTE9QUy0wMTA4MTcxNjAwMThaLTEzNjcAAAIB+T8BAAAASgAA
AAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAAAAAAvTz1JVklWSVRZL09VPUFUTE9QUy9DTj1SRUNJ
UElFTlRTL0NOPVNBTkpBWUcAAAAeAPg/AQAAAA0AAABTYW5qYXkgR295YWwAAAAAHgA4QAEAAAAI
AAAAU0FOSkFZRwACAfs/AQAAAEoAAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAAL089SVZJ
VklUWS9PVT1BVExPUFMvQ049UkVDSVBJRU5UUy9DTj1TQU5KQVlHAAAAHgD6PwEAAAANAAAAU2Fu
amF5IEdveWFsAAAAAB4AOUABAAAACAAAAFNBTkpBWUcAQAAHMJIm9LU1J8EBQAAIMNogcLY1J8EB
HgA9AAEAAAAFAAAAUkU6IAAAAAAeAB0OAQAAACwAAABpU0NTSTogW0Z3ZDogQ3JjLTMyYyBleGFt
cGxlIGluIGlTQ1NJIHNwZWNdAB4ANRABAAAAMAAAADwyNTM2OTQ3MEI2RjBENDExOTQ4MjAwMDJC
MzI4QkREMjExNjI0MEBBVExPUFM+AAsAKQAAAAAACwAjAAAAAAADAAYQDsN7owMABxBNCgAAAwAQ
EAAAAAADABEQAAAAAB4ACBABAAAAZQAAAEhJSUdFVFRIRVJFTUFJTkRFUkZPUklTQ1NJQVMwWDFD
MkQxOUVESUZJQ09NUExFTUVOVE1ZQ1JDQU5EVEhFTlBBU1NJVFRIUk9VR0hUSEVDUkNFTkdJTkVB
U1BFUkNSQ0dFTkUAAAAAAgF/AAEAAAAwAAAAPDI1MzY5NDcwQjZGMEQ0MTE5NDgyMDAwMkIzMjhC
REQyMTE2MjQwQEFUTE9QUz4A+V4=

------_=_NextPart_000_01C12735.B67020DA--


From owner-ips@ece.cmu.edu  Fri Aug 17 14:08:44 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10548
	for <ips-archive@odin.ietf.org>; Fri, 17 Aug 2001 14:08:44 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7HHD7c29921
	for ips-outgoing; Fri, 17 Aug 2001 13:13:07 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7HHD5e29916
	for <ips@ece.cmu.edu>; Fri, 17 Aug 2001 13:13:05 -0400 (EDT)
Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA19962; Fri, 17 Aug 2001 13:12:44 -0400 (EDT)
Message-ID: <3B7D4EFC.EA454505@cisco.com>
Date: Fri, 17 Aug 2001 12:06:04 -0500
From: Mark Bakke <mbakke@cisco.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686)
X-Accept-Language: en, de
MIME-Version: 1.0
To: Sanjay Goyal <sanjay_goyal@ivivity.com>
CC: "Ips (E-mail)" <ips@ece.cmu.edu>
Subject: Re: iSCSI: [Fwd: Crc-32c example in iSCSI spec]
References: <25369470B6F0D41194820002B328BDD2116240@ATLOPS>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Sanjay Goyal wrote:
> 
> Hi
>  I get the remainder for iSCSI as 0x1c2d19ed if I complement my CRC and then
> pass it through the CRC engine.
>
>  As per CRC generation for data: the thing which is not clear to me is
>    why do we need to bit-swap the CRC reminader as is done in all your
> examples.

As far as I can tell, bit-swapping does nothing to help or hurt
the effectiveness of the CRC.  When I ran my examples, I thought
that it would be the simplest for our CRC to different from the
Ethernet CRC only in the polynomial.  Ethernet, FDDI, FC, and SCSI
all do this, so I figured it would cause the least confusion if
we did the same.

> We can just complement it and append it after the DATA bytes.
>  The other side also can just pass it through the CRC engine to check it.
> 
> Regards
> Sanjay Goyal
> 
> -----Original Message-----
> From: Mark Bakke [mailto:mbakke@cisco.com]
> Sent: Thursday, August 16, 2001 1:43 PM
> To: Steve Blightman; ips@ece.cmu.edu
> Subject: Re: [Fwd: Crc-32c example in iSCSI spec]
> 
> One more thing that might be helpful.  When the Ethernet
> polynomial is used in SCSI to generate its CRC, the T10
> doc specifies the remainder polynomial that one should see
> after running the data with a valid CRC through.  For
> the Ethernet CRC, this was specified as 0xc704dd7b.  This
> remainder polynomial is taken before the CRC is complemented
> and bit-reflected.  For iSCSI, I came up with a remainder of
> 0x1c2d19ed.  Can anyone verify this result?
> 
> --
> Mark
> 
> Mark Bakke wrote:
> >
> > Steve-
> >
> > I just ran some Ethernet packets with known CRCs through
> > my iSCSI/Ethernet CRC generator, and found the same thing
> > as you did.
> >
> > All of my examples need to be byte-swapped, along with the
> > fix I already posted for the all-ones example.  Here is a
> > new set of examples, which will be in -08.  I also ran
> > 64 bytes of zeroes and ones, which now agree with your
> > numbers as well.
> >
> > Thanks again for bringing this up.
> >
> > --
> > Mark
> >
> >      07 CRC Examples
> >
> >         N.B. all Values are Hexadecimal
> >
> >           Byte:        0  1  2  3
> >
> >              0:       01 a0 00 00
> >              4:       00 00 00 00
> >              8:       00 00 00 00
> >             12:       00 00 00 00
> >             16:       04 05 00 00
> >             20:       00 01 00 00
> >             24:       00 00 00 05
> >             28:       00 00 00 04
> >             32:       2a 00 00 00
> >             36:       00 00 00 00
> >             40:       80 00 00 00
> >             44:       00 00 00 00
> >
> >            CRC:       93 70 51 db
> >
> >         32 bytes of zeroes:
> >
> >           Byte:        0  1  2  3
> >
> >              0:       00 00 00 00
> >            ...
> >             28:       00 00 00 00
> >
> >            CRC:       aa 36 91 8a
> >
> >         32 bytes of ones:
> >
> >           Byte:        0  1  2  3
> >
> >              0:       ff ff ff ff
> >            ...
> >             28:       ff ff ff ff
> >
> >            CRC:       43 ab a8 62
> >
> >         32 bytes of incrementing 00..1f:
> >
> >           Byte:        0  1  2  3
> >
> >              0:       00 01 02 03
> >            ...
> >             28:       1c 1d 1e 1f
> >
> >            CRC:       4e 79 dd 46
> >
> >
> > Steve Blightman wrote:
> > >
> > > I believe the examples for the ISCSI CRC  have the wrong endianness.
> > >
> > > As yiou suugested over the phone I ran some Ethernet frames through a
> > > simulation. I have some difficulty running the exact simulations you
> > > wanted becuase the minimum size Ethernet frame is 64 bytes.
> > >
> > > However using the Ethernet CRC polynomial,
> > > Running 64 bytes of 0 onto the wire, we append "36 63 8d 75" onto the
> > > wire for the CRC - "36" goes out first.
> > > Running 64 bytes of all 1, we append "ba 87 61 0f" onto the wire - "ba"
> > > goes out first.
> > >
> > > Using the same logic for the ISCSI polynomial
> > > Running 64 bytes of 0 I think we should append "67 eb c8 03" - "67"
> > > going out first
> > > and running 64 bytes of all 1 we should append "66 4e cd 2f" - "66"
> > > going out first
> > >
> > > And now for 32 bytes with the ISCSI polynomial
> > >
> > > Running 32 bytes of 0 we should append "aa 36 91 8a" - "aa" going out
> > > first
> > > Running 32 bytes of all 1 we should append "43 ab a8 62" - "43" going
> > > out first
> > >
> > > I don't want to get into an endless endian debate, but I believe it is
> > > important to get the order of these bytes in the right order, so that we
> > > can use the same hardware to check as well as to generate CRCs.
> > >
> > > Thanks for your help on this,
> > > Steve Blightman
> >
> > --
> > Mark A. Bakke
> > Cisco Systems
> > mbakke@cisco.com
> > 763.398.1054
> 
> --
> Mark A. Bakke
> Cisco Systems
> mbakke@cisco.com
> 763.398.1054
> 
>   ----------------------------------------------------------------------------------------------------
> 
>    Part 1.2    Type: application/ms-tnef
>            Encoding: base64

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054


From owner-ips@ece.cmu.edu  Fri Aug 17 15:23:13 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13294
	for <ips-archive@odin.ietf.org>; Fri, 17 Aug 2001 15:23:13 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7HIDHA03069
	for ips-outgoing; Fri, 17 Aug 2001 14:13:17 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from ariel.nishansystems.com (smtp.nishansystems.com [216.217.36.162])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7HIDFe03065
	for <ips@ece.cmu.edu>; Fri, 17 Aug 2001 14:13:15 -0400 (EDT)
Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19)
	id <351LH6SQ>; Fri, 17 Aug 2001 11:13:09 -0700
Message-ID: <B300BD9620BCD411A366009027C21D9B551F99@ariel.nishansystems.com>
From: Charles Monia <cmonia@NishanSystems.com>
To: "Ips (E-mail)" <ips@ece.cmu.edu>
Cc: "David Black (E-mail)" <Black_David@emc.com>,
        "Elizabeth Rodgriguez (E-mail)" <egrodriguez@lucent.com>
Subject: iFCP: iFCP Revision 4 released
Date: Fri, 17 Aug 2001 11:13:09 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Hi:

iFCP Revision 4 has been submitted to the IETF archive.  In order to
expedite availability, it is also available from one of the following URLs:

Ascii text file:

http://www.nishansystems.com/ietf/draft-ietf-ips-iFCP-04.txt

PDF File:

http://www.nishansystems.com/ietf/draft-ietf-ips-iFCP-04.pdf

Thanks,
Charles
Charles Monia
Senior Technology Consultant
Nishan Systems
email: cmonia@nishansystems.com
voice: (408) 519-3986
fax:   (408) 435-8385
 


From owner-ips@ece.cmu.edu  Fri Aug 17 16:25:11 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14648
	for <ips-archive@odin.ietf.org>; Fri, 17 Aug 2001 16:25:10 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7HItZP05202
	for ips-outgoing; Fri, 17 Aug 2001 14:55:35 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from c007.snv.cp.net (c007-h011.c007.snv.cp.net [209.228.33.217])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f7HItXe05196
	for <ips@ece.cmu.edu>; Fri, 17 Aug 2001 14:55:33 -0400 (EDT)
Received: (cpmta 22244 invoked from network); 17 Aug 2001 11:55:27 -0700
Received: from adsl-63-202-160-80.dsl.snfc21.pacbell.net (HELO littlejoy) (63.202.160.80)
  by smtp.telocity.com (209.228.33.217) with SMTP; 17 Aug 2001 11:55:27 -0700
X-Sent: 17 Aug 2001 18:55:27 GMT
From: "Douglas Otis" <dotis@sanlight.net>
To: "Mark Bakke" <mbakke@cisco.com>, "Sanjay Goyal" <sanjay_goyal@ivivity.com>
Cc: "Ips \(E-mail\)" <ips@ece.cmu.edu>
Subject: RE: iSCSI: [Fwd: Crc-32c example in iSCSI spec]
Date: Fri, 17 Aug 2001 11:53:40 -0700
Message-ID: <NEBBJGDMMLHHCIKHGBEJOEHLCKAA.dotis@sanlight.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <3B7D4EFC.EA454505@cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Mark,

The reason for the bit swap within the table is to allow a serial hardware
scheme as CRC is processed ms to ls over the entire stream as if a single
number.  Ethernet sends the byte out least significant bit first.  The
entire table is also swapped ls to ms and actually reduces the operations
needed within the table calculations.  This reflects the method used for
Ethernet as it is being stored inverted and the initial value is started as
all ones.  The reason for the initial value being set to all ones is clear
for leading zero interaction, but I do not understand the value in storing
the CRC inverted.  I thought to include my ignorance to the mix.

Doug

> Sanjay Goyal wrote:
> >
> > Hi
> >  I get the remainder for iSCSI as 0x1c2d19ed if I complement my
> CRC and then
> > pass it through the CRC engine.
> >
> >  As per CRC generation for data: the thing which is not clear to me is
> >    why do we need to bit-swap the CRC reminader as is done in all your
> > examples.
>
> As far as I can tell, bit-swapping does nothing to help or hurt
> the effectiveness of the CRC.  When I ran my examples, I thought
> that it would be the simplest for our CRC to different from the
> Ethernet CRC only in the polynomial.  Ethernet, FDDI, FC, and SCSI
> all do this, so I figured it would cause the least confusion if
> we did the same.
>
> > We can just complement it and append it after the DATA bytes.
> >  The other side also can just pass it through the CRC engine to
> check it.
> >
> > Regards
> > Sanjay Goyal
> >
> > -----Original Message-----
> > From: Mark Bakke [mailto:mbakke@cisco.com]
> > Sent: Thursday, August 16, 2001 1:43 PM
> > To: Steve Blightman; ips@ece.cmu.edu
> > Subject: Re: [Fwd: Crc-32c example in iSCSI spec]
> >
> > One more thing that might be helpful.  When the Ethernet
> > polynomial is used in SCSI to generate its CRC, the T10
> > doc specifies the remainder polynomial that one should see
> > after running the data with a valid CRC through.  For
> > the Ethernet CRC, this was specified as 0xc704dd7b.  This
> > remainder polynomial is taken before the CRC is complemented
> > and bit-reflected.  For iSCSI, I came up with a remainder of
> > 0x1c2d19ed.  Can anyone verify this result?
> >
> > --
> > Mark
> >
> > Mark Bakke wrote:
> > >
> > > Steve-
> > >
> > > I just ran some Ethernet packets with known CRCs through
> > > my iSCSI/Ethernet CRC generator, and found the same thing
> > > as you did.
> > >
> > > All of my examples need to be byte-swapped, along with the
> > > fix I already posted for the all-ones example.  Here is a
> > > new set of examples, which will be in -08.  I also ran
> > > 64 bytes of zeroes and ones, which now agree with your
> > > numbers as well.
> > >
> > > Thanks again for bringing this up.
> > >
> > > --
> > > Mark
> > >
> > >      07 CRC Examples
> > >
> > >         N.B. all Values are Hexadecimal
> > >
> > >           Byte:        0  1  2  3
> > >
> > >              0:       01 a0 00 00
> > >              4:       00 00 00 00
> > >              8:       00 00 00 00
> > >             12:       00 00 00 00
> > >             16:       04 05 00 00
> > >             20:       00 01 00 00
> > >             24:       00 00 00 05
> > >             28:       00 00 00 04
> > >             32:       2a 00 00 00
> > >             36:       00 00 00 00
> > >             40:       80 00 00 00
> > >             44:       00 00 00 00
> > >
> > >            CRC:       93 70 51 db
> > >
> > >         32 bytes of zeroes:
> > >
> > >           Byte:        0  1  2  3
> > >
> > >              0:       00 00 00 00
> > >            ...
> > >             28:       00 00 00 00
> > >
> > >            CRC:       aa 36 91 8a
> > >
> > >         32 bytes of ones:
> > >
> > >           Byte:        0  1  2  3
> > >
> > >              0:       ff ff ff ff
> > >            ...
> > >             28:       ff ff ff ff
> > >
> > >            CRC:       43 ab a8 62
> > >
> > >         32 bytes of incrementing 00..1f:
> > >
> > >           Byte:        0  1  2  3
> > >
> > >              0:       00 01 02 03
> > >            ...
> > >             28:       1c 1d 1e 1f
> > >
> > >            CRC:       4e 79 dd 46
> > >
> > >
> > > Steve Blightman wrote:
> > > >
> > > > I believe the examples for the ISCSI CRC  have the wrong endianness.
> > > >
> > > > As yiou suugested over the phone I ran some Ethernet frames
> through a
> > > > simulation. I have some difficulty running the exact simulations you
> > > > wanted becuase the minimum size Ethernet frame is 64 bytes.
> > > >
> > > > However using the Ethernet CRC polynomial,
> > > > Running 64 bytes of 0 onto the wire, we append "36 63 8d
> 75" onto the
> > > > wire for the CRC - "36" goes out first.
> > > > Running 64 bytes of all 1, we append "ba 87 61 0f" onto the
> wire - "ba"
> > > > goes out first.
> > > >
> > > > Using the same logic for the ISCSI polynomial
> > > > Running 64 bytes of 0 I think we should append "67 eb c8 03" - "67"
> > > > going out first
> > > > and running 64 bytes of all 1 we should append "66 4e cd 2f" - "66"
> > > > going out first
> > > >
> > > > And now for 32 bytes with the ISCSI polynomial
> > > >
> > > > Running 32 bytes of 0 we should append "aa 36 91 8a" - "aa"
> going out
> > > > first
> > > > Running 32 bytes of all 1 we should append "43 ab a8 62" -
> "43" going
> > > > out first
> > > >
> > > > I don't want to get into an endless endian debate, but I
> believe it is
> > > > important to get the order of these bytes in the right
> order, so that we
> > > > can use the same hardware to check as well as to generate CRCs.
> > > >
> > > > Thanks for your help on this,
> > > > Steve Blightman
> > >
> > > --
> > > Mark A. Bakke
> > > Cisco Systems
> > > mbakke@cisco.com
> > > 763.398.1054
> >
> > --
> > Mark A. Bakke
> > Cisco Systems
> > mbakke@cisco.com
> > 763.398.1054
> >
> >
> ------------------------------------------------------------------
> ----------------------------------
> >
> >    Part 1.2    Type: application/ms-tnef
> >            Encoding: base64
>
> --
> Mark A. Bakke
> Cisco Systems
> mbakke@cisco.com
> 763.398.1054
>



From owner-ips@ece.cmu.edu  Fri Aug 17 17:10:46 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15326
	for <ips-archive@odin.ietf.org>; Fri, 17 Aug 2001 17:10:45 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7HKnY611189
	for ips-outgoing; Fri, 17 Aug 2001 16:49:34 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from siaar2aa.compuserve.com (siaar2aa.compuserve.com [149.174.40.137])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7HKnWe11185
	for <ips@ece.cmu.edu>; Fri, 17 Aug 2001 16:49:32 -0400 (EDT)
Received: (from mailgate@localhost)
	by siaar2aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id QAA22142
	for ips@ece.cmu.edu; Fri, 17 Aug 2001 16:48:13 -0400 (EDT)
Received: from compuserve.com (dal-tgn-tkx-vty6.as.wcom.net [216.192.233.6])
	by siaar2aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id QAA22113
	for <ips@ece.cmu.edu>; Fri, 17 Aug 2001 16:48:05 -0400 (EDT)
Message-ID: <3B7D835D.D46C4362@compuserve.com>
Date: Fri, 17 Aug 2001 15:49:33 -0500
From: Ralph Weber <ralphoweber@compuserve.com>
Reply-To: ENDL_TX@computer.org
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47  (Win98; I)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: IPS Reflector <ips@ece.cmu.edu>
Subject: FCIP: Revision 5 available
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Julian has provided access to the latest revision of the
FC over IP draft at:

 http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-fcovertcpip-05.txt

and

 http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-fcovertcpip-05.pdf

The draft was submitted to the Internet Drafts office a couple
of days ago, but has yet to be announced.

The PDF file contains the same text as the regular file but
has bookmarks and change bars (with respect to revision 4)
for your added convenience.

FYI

Ralph...




From owner-ips@ece.cmu.edu  Fri Aug 17 17:12:21 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15347
	for <ips-archive@odin.ietf.org>; Fri, 17 Aug 2001 17:12:21 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7HKQIP10026
	for ips-outgoing; Fri, 17 Aug 2001 16:26:18 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from ganymede.or.intel.com (jffdns01.or.intel.com [134.134.248.3])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7HKQGe10022
	for <ips@ece.cmu.edu>; Fri, 17 Aug 2001 16:26:17 -0400 (EDT)
Received: from SMTP (orsmsxvs02-1.jf.intel.com [192.168.65.201])
	by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id UAA14922;
	Fri, 17 Aug 2001 20:25:52 GMT
Received: from orsmsx26.jf.intel.com ([192.168.70.26]) by 192.168.70.201
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Fri, 17 Aug 2001 20:25:52 0000 (GMT)
Received: by orsmsx26.jf.intel.com with Internet Mail Service (5.5.2653.19)
	id <RB0J3KDP>; Fri, 17 Aug 2001 13:25:50 -0700
Message-ID: <638EC1B28663D211AC3E00A0C96B78A8086ABB2B@orsmsx40.jf.intel.com>
From: "Wheat, Stephen R" <stephen.r.wheat@intel.com>
To: "'Douglas Otis'" <dotis@sanlight.net>, Mark Bakke <mbakke@cisco.com>,
        Sanjay Goyal <sanjay_goyal@ivivity.com>
Cc: "Ips (E-mail)" <ips@ece.cmu.edu>
Subject: RE: iSCSI: [Fwd: Crc-32c example in iSCSI spec]
Date: Fri, 17 Aug 2001 13:25:45 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Quoting from Richard Black,
www.cl.cam.ac.uk/Research/SRG/bluebook/21/crc/node2.html
the inversion of the CRC before sending it precludes erroneous addition of
trailing zeros.

Without complementing the remainder, the result of a checked message would
be 0x00000000.  If the message, for some reason, had any number of zero bits
appended to it (after the crc word), the result would still be 0x00000000.

Thus, it seems that complementing the remainder is a relic from the bit
serial days where the end of the message was not determined beforehand, as
is the case for iSCSI PDUs.

As Mark originally opined, keeping with the reflected/complemented algorithm
has a certain consistency to it.

So, it appears that complementing the result for iSCSI CRC is an arbitrary
decision, that consistency seems to have won out.

Does anyone have an opinion as to whether checking for a zero result, versus
a non-zero result, has a performance implication?

Stephen

-----Original Message-----
From: Douglas Otis [mailto:dotis@sanlight.net]
Sent: Friday, August 17, 2001 11:54 AM
To: Mark Bakke; Sanjay Goyal
Cc: Ips (E-mail)
Subject: RE: iSCSI: [Fwd: Crc-32c example in iSCSI spec]


Mark,

The reason for the bit swap within the table is to allow a serial hardware
scheme as CRC is processed ms to ls over the entire stream as if a single
number.  Ethernet sends the byte out least significant bit first.  The
entire table is also swapped ls to ms and actually reduces the operations
needed within the table calculations.  This reflects the method used for
Ethernet as it is being stored inverted and the initial value is started as
all ones.  The reason for the initial value being set to all ones is clear
for leading zero interaction, but I do not understand the value in storing
the CRC inverted.  I thought to include my ignorance to the mix.

Doug

> Sanjay Goyal wrote:
> >
> > Hi
> >  I get the remainder for iSCSI as 0x1c2d19ed if I complement my
> CRC and then
> > pass it through the CRC engine.
> >
> >  As per CRC generation for data: the thing which is not clear to me is
> >    why do we need to bit-swap the CRC reminader as is done in all your
> > examples.
>
> As far as I can tell, bit-swapping does nothing to help or hurt
> the effectiveness of the CRC.  When I ran my examples, I thought
> that it would be the simplest for our CRC to different from the
> Ethernet CRC only in the polynomial.  Ethernet, FDDI, FC, and SCSI
> all do this, so I figured it would cause the least confusion if
> we did the same.
>
> > We can just complement it and append it after the DATA bytes.
> >  The other side also can just pass it through the CRC engine to
> check it.
> >
> > Regards
> > Sanjay Goyal
> >
> > -----Original Message-----
> > From: Mark Bakke [mailto:mbakke@cisco.com]
> > Sent: Thursday, August 16, 2001 1:43 PM
> > To: Steve Blightman; ips@ece.cmu.edu
> > Subject: Re: [Fwd: Crc-32c example in iSCSI spec]
> >
> > One more thing that might be helpful.  When the Ethernet
> > polynomial is used in SCSI to generate its CRC, the T10
> > doc specifies the remainder polynomial that one should see
> > after running the data with a valid CRC through.  For
> > the Ethernet CRC, this was specified as 0xc704dd7b.  This
> > remainder polynomial is taken before the CRC is complemented
> > and bit-reflected.  For iSCSI, I came up with a remainder of
> > 0x1c2d19ed.  Can anyone verify this result?
> >
> > --
> > Mark
> >
> > Mark Bakke wrote:
> > >
> > > Steve-
> > >
> > > I just ran some Ethernet packets with known CRCs through
> > > my iSCSI/Ethernet CRC generator, and found the same thing
> > > as you did.
> > >
> > > All of my examples need to be byte-swapped, along with the
> > > fix I already posted for the all-ones example.  Here is a
> > > new set of examples, which will be in -08.  I also ran
> > > 64 bytes of zeroes and ones, which now agree with your
> > > numbers as well.
> > >
> > > Thanks again for bringing this up.
> > >
> > > --
> > > Mark
> > >
> > >      07 CRC Examples
> > >
> > >         N.B. all Values are Hexadecimal
> > >
> > >           Byte:        0  1  2  3
> > >
> > >              0:       01 a0 00 00
> > >              4:       00 00 00 00
> > >              8:       00 00 00 00
> > >             12:       00 00 00 00
> > >             16:       04 05 00 00
> > >             20:       00 01 00 00
> > >             24:       00 00 00 05
> > >             28:       00 00 00 04
> > >             32:       2a 00 00 00
> > >             36:       00 00 00 00
> > >             40:       80 00 00 00
> > >             44:       00 00 00 00
> > >
> > >            CRC:       93 70 51 db
> > >
> > >         32 bytes of zeroes:
> > >
> > >           Byte:        0  1  2  3
> > >
> > >              0:       00 00 00 00
> > >            ...
> > >             28:       00 00 00 00
> > >
> > >            CRC:       aa 36 91 8a
> > >
> > >         32 bytes of ones:
> > >
> > >           Byte:        0  1  2  3
> > >
> > >              0:       ff ff ff ff
> > >            ...
> > >             28:       ff ff ff ff
> > >
> > >            CRC:       43 ab a8 62
> > >
> > >         32 bytes of incrementing 00..1f:
> > >
> > >           Byte:        0  1  2  3
> > >
> > >              0:       00 01 02 03
> > >            ...
> > >             28:       1c 1d 1e 1f
> > >
> > >            CRC:       4e 79 dd 46
> > >
> > >
> > > Steve Blightman wrote:
> > > >
> > > > I believe the examples for the ISCSI CRC  have the wrong endianness.
> > > >
> > > > As yiou suugested over the phone I ran some Ethernet frames
> through a
> > > > simulation. I have some difficulty running the exact simulations you
> > > > wanted becuase the minimum size Ethernet frame is 64 bytes.
> > > >
> > > > However using the Ethernet CRC polynomial,
> > > > Running 64 bytes of 0 onto the wire, we append "36 63 8d
> 75" onto the
> > > > wire for the CRC - "36" goes out first.
> > > > Running 64 bytes of all 1, we append "ba 87 61 0f" onto the
> wire - "ba"
> > > > goes out first.
> > > >
> > > > Using the same logic for the ISCSI polynomial
> > > > Running 64 bytes of 0 I think we should append "67 eb c8 03" - "67"
> > > > going out first
> > > > and running 64 bytes of all 1 we should append "66 4e cd 2f" - "66"
> > > > going out first
> > > >
> > > > And now for 32 bytes with the ISCSI polynomial
> > > >
> > > > Running 32 bytes of 0 we should append "aa 36 91 8a" - "aa"
> going out
> > > > first
> > > > Running 32 bytes of all 1 we should append "43 ab a8 62" -
> "43" going
> > > > out first
> > > >
> > > > I don't want to get into an endless endian debate, but I
> believe it is
> > > > important to get the order of these bytes in the right
> order, so that we
> > > > can use the same hardware to check as well as to generate CRCs.
> > > >
> > > > Thanks for your help on this,
> > > > Steve Blightman
> > >
> > > --
> > > Mark A. Bakke
> > > Cisco Systems
> > > mbakke@cisco.com
> > > 763.398.1054
> >
> > --
> > Mark A. Bakke
> > Cisco Systems
> > mbakke@cisco.com
> > 763.398.1054
> >
> >
> ------------------------------------------------------------------
> ----------------------------------
> >
> >    Part 1.2    Type: application/ms-tnef
> >            Encoding: base64
>
> --
> Mark A. Bakke
> Cisco Systems
> mbakke@cisco.com
> 763.398.1054
>




From owner-ips@ece.cmu.edu  Fri Aug 17 17:13:19 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15363
	for <ips-archive@odin.ietf.org>; Fri, 17 Aug 2001 17:13:14 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7HKHHp09475
	for ips-outgoing; Fri, 17 Aug 2001 16:17:17 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7HKHFe09469
	for <ips@ece.cmu.edu>; Fri, 17 Aug 2001 16:17:15 -0400 (EDT)
Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA19095; Fri, 17 Aug 2001 16:17:02 -0400 (EDT)
Message-ID: <3B7D7A2E.6A73A665@cisco.com>
Date: Fri, 17 Aug 2001 15:10:22 -0500
From: Mark Bakke <mbakke@cisco.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686)
X-Accept-Language: en, de
MIME-Version: 1.0
To: Douglas Otis <dotis@sanlight.net>
CC: Sanjay Goyal <sanjay_goyal@ivivity.com>, "Ips (E-mail)" <ips@ece.cmu.edu>
Subject: Re: iSCSI: [Fwd: Crc-32c example in iSCSI spec]
References: <NEBBJGDMMLHHCIKHGBEJOEHLCKAA.dotis@sanlight.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

OK.  I don't see any reason for sending the CRC inverted either
(we would just have a different remainder poly), but since Ethernet
does it that way, and it doesn't cost anything, we might as well
do it, too.

--
Mark

Douglas Otis wrote:
> 
> Mark,
> 
> The reason for the bit swap within the table is to allow a serial hardware
> scheme as CRC is processed ms to ls over the entire stream as if a single
> number.  Ethernet sends the byte out least significant bit first.  The
> entire table is also swapped ls to ms and actually reduces the operations
> needed within the table calculations.  This reflects the method used for
> Ethernet as it is being stored inverted and the initial value is started as
> all ones.  The reason for the initial value being set to all ones is clear
> for leading zero interaction, but I do not understand the value in storing
> the CRC inverted.  I thought to include my ignorance to the mix.
> 
> Doug
> 
> > Sanjay Goyal wrote:
> > >
> > > Hi
> > >  I get the remainder for iSCSI as 0x1c2d19ed if I complement my
> > CRC and then
> > > pass it through the CRC engine.
> > >
> > >  As per CRC generation for data: the thing which is not clear to me is
> > >    why do we need to bit-swap the CRC reminader as is done in all your
> > > examples.
> >
> > As far as I can tell, bit-swapping does nothing to help or hurt
> > the effectiveness of the CRC.  When I ran my examples, I thought
> > that it would be the simplest for our CRC to different from the
> > Ethernet CRC only in the polynomial.  Ethernet, FDDI, FC, and SCSI
> > all do this, so I figured it would cause the least confusion if
> > we did the same.
> >
> > > We can just complement it and append it after the DATA bytes.
> > >  The other side also can just pass it through the CRC engine to
> > check it.
> > >
> > > Regards
> > > Sanjay Goyal
> > >
> > > -----Original Message-----
> > > From: Mark Bakke [mailto:mbakke@cisco.com]
> > > Sent: Thursday, August 16, 2001 1:43 PM
> > > To: Steve Blightman; ips@ece.cmu.edu
> > > Subject: Re: [Fwd: Crc-32c example in iSCSI spec]
> > >
> > > One more thing that might be helpful.  When the Ethernet
> > > polynomial is used in SCSI to generate its CRC, the T10
> > > doc specifies the remainder polynomial that one should see
> > > after running the data with a valid CRC through.  For
> > > the Ethernet CRC, this was specified as 0xc704dd7b.  This
> > > remainder polynomial is taken before the CRC is complemented
> > > and bit-reflected.  For iSCSI, I came up with a remainder of
> > > 0x1c2d19ed.  Can anyone verify this result?
> > >
> > > --
> > > Mark
> > >
> > > Mark Bakke wrote:
> > > >
> > > > Steve-
> > > >
> > > > I just ran some Ethernet packets with known CRCs through
> > > > my iSCSI/Ethernet CRC generator, and found the same thing
> > > > as you did.
> > > >
> > > > All of my examples need to be byte-swapped, along with the
> > > > fix I already posted for the all-ones example.  Here is a
> > > > new set of examples, which will be in -08.  I also ran
> > > > 64 bytes of zeroes and ones, which now agree with your
> > > > numbers as well.
> > > >
> > > > Thanks again for bringing this up.
> > > >
> > > > --
> > > > Mark
> > > >
> > > >      07 CRC Examples
> > > >
> > > >         N.B. all Values are Hexadecimal
> > > >
> > > >           Byte:        0  1  2  3
> > > >
> > > >              0:       01 a0 00 00
> > > >              4:       00 00 00 00
> > > >              8:       00 00 00 00
> > > >             12:       00 00 00 00
> > > >             16:       04 05 00 00
> > > >             20:       00 01 00 00
> > > >             24:       00 00 00 05
> > > >             28:       00 00 00 04
> > > >             32:       2a 00 00 00
> > > >             36:       00 00 00 00
> > > >             40:       80 00 00 00
> > > >             44:       00 00 00 00
> > > >
> > > >            CRC:       93 70 51 db
> > > >
> > > >         32 bytes of zeroes:
> > > >
> > > >           Byte:        0  1  2  3
> > > >
> > > >              0:       00 00 00 00
> > > >            ...
> > > >             28:       00 00 00 00
> > > >
> > > >            CRC:       aa 36 91 8a
> > > >
> > > >         32 bytes of ones:
> > > >
> > > >           Byte:        0  1  2  3
> > > >
> > > >              0:       ff ff ff ff
> > > >            ...
> > > >             28:       ff ff ff ff
> > > >
> > > >            CRC:       43 ab a8 62
> > > >
> > > >         32 bytes of incrementing 00..1f:
> > > >
> > > >           Byte:        0  1  2  3
> > > >
> > > >              0:       00 01 02 03
> > > >            ...
> > > >             28:       1c 1d 1e 1f
> > > >
> > > >            CRC:       4e 79 dd 46
> > > >
> > > >
> > > > Steve Blightman wrote:
> > > > >
> > > > > I believe the examples for the ISCSI CRC  have the wrong endianness.
> > > > >
> > > > > As yiou suugested over the phone I ran some Ethernet frames
> > through a
> > > > > simulation. I have some difficulty running the exact simulations you
> > > > > wanted becuase the minimum size Ethernet frame is 64 bytes.
> > > > >
> > > > > However using the Ethernet CRC polynomial,
> > > > > Running 64 bytes of 0 onto the wire, we append "36 63 8d
> > 75" onto the
> > > > > wire for the CRC - "36" goes out first.
> > > > > Running 64 bytes of all 1, we append "ba 87 61 0f" onto the
> > wire - "ba"
> > > > > goes out first.
> > > > >
> > > > > Using the same logic for the ISCSI polynomial
> > > > > Running 64 bytes of 0 I think we should append "67 eb c8 03" - "67"
> > > > > going out first
> > > > > and running 64 bytes of all 1 we should append "66 4e cd 2f" - "66"
> > > > > going out first
> > > > >
> > > > > And now for 32 bytes with the ISCSI polynomial
> > > > >
> > > > > Running 32 bytes of 0 we should append "aa 36 91 8a" - "aa"
> > going out
> > > > > first
> > > > > Running 32 bytes of all 1 we should append "43 ab a8 62" -
> > "43" going
> > > > > out first
> > > > >
> > > > > I don't want to get into an endless endian debate, but I
> > believe it is
> > > > > important to get the order of these bytes in the right
> > order, so that we
> > > > > can use the same hardware to check as well as to generate CRCs.
> > > > >
> > > > > Thanks for your help on this,
> > > > > Steve Blightman
> > > >
> > > > --
> > > > Mark A. Bakke
> > > > Cisco Systems
> > > > mbakke@cisco.com
> > > > 763.398.1054
> > >
> > > --
> > > Mark A. Bakke
> > > Cisco Systems
> > > mbakke@cisco.com
> > > 763.398.1054
> > >
> > >
> > ------------------------------------------------------------------
> > ----------------------------------
> > >
> > >    Part 1.2    Type: application/ms-tnef
> > >            Encoding: base64
> >
> > --
> > Mark A. Bakke
> > Cisco Systems
> > mbakke@cisco.com
> > 763.398.1054
> >

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054


From owner-ips@ece.cmu.edu  Fri Aug 17 17:18:28 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15436
	for <ips-archive@odin.ietf.org>; Fri, 17 Aug 2001 17:18:27 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7HKJtC09613
	for ips-outgoing; Fri, 17 Aug 2001 16:19:55 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7HKJre09608
	for <ips@ece.cmu.edu>; Fri, 17 Aug 2001 16:19:53 -0400 (EDT)
Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA23658; Fri, 17 Aug 2001 16:19:45 -0400 (EDT)
Message-ID: <3B7D7AD1.3064A800@cisco.com>
Date: Fri, 17 Aug 2001 15:13:05 -0500
From: Mark Bakke <mbakke@cisco.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686)
X-Accept-Language: en, de
MIME-Version: 1.0
To: Julian Satran <julian_satran@il.ibm.com>, IPS <ips@ece.cmu.edu>
Subject: iSCSI CRC: A CRC-checking example
Content-Type: multipart/mixed;
 boundary="------------28D0F3B82CDAA5FB10D3ACAE"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

This is a multi-part message in MIME format.
--------------28D0F3B82CDAA5FB10D3ACAE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Julian and CRC enthusiasts-

After several people ran the iSCSI CRC through their
hardware and software implementations, we've found that
there are a few important things to add to the CRC spec;
that the bit order must be flipped, and the CRC bytes
must be sent in network order.

We should also specify that when running the CRC check
on an iSCSI PDU with its CRC, that the remainder (before
complement and bit-reversal) is a constant 0x1c2d19ed.


How about replacing:

The generator polynomial selected is evaluated in [Castagnioli93].
When using the CRC the CRC register must be initialized to all 1s
(0xFFFFFFFF) and the CRC bits must be complemented before
transmission. Padding bytes, when present, in a segment covered by a
CRC, should be set to 0 and are included in the CRC.

With:

The generator polynomial selected is evaluated in [Castagnioli93].
When using the CRC the CRC register must be initialized to all 1s
(0xFFFFFFFF).  Input bytes are processed with bit 7 being the most
significant bit.  Before transmission, the CRC bits must be
reflected (bit 31 swapped with bit 0, bit 30 swapped with bit 1,
etc.), and complemented.  The CRC bytes must be transmitted in
network order.  Padding bytes, when present, in a segment covered
by a CRC, should be set to 0 and are included in the CRC.

Running the CRC-32C generator on an input stream that includes a
valid CRC-32C will result in the constant remainder 0x1c2d19ed,
(without being reversed and complemented).


-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054
--------------28D0F3B82CDAA5FB10D3ACAE
Content-Type: message/rfc822
Content-Disposition: inline

Return-Path: stephen.r.wheat@intel.com
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA13149 for <mbakke@dogwood.cisco.com>; Fri, 17 Aug 2001 14:31:30 -0400 (EDT)
Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f7HITbD04150
	for <mbakke@cisco.com>; Fri, 17 Aug 2001 11:29:38 -0700 (PDT)
Received: from proxy3.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f7HIVdW25226
	for <mbakke@sj-av.cisco.com>; Fri, 17 Aug 2001 11:31:39 -0700 (PDT)
Received: from baucis.sc.intel.com (ns3.intel.com [143.183.152.22])
	by proxy3.cisco.com (8.11.2/8.11.2) with ESMTP id f7HIW3Q20439
	for <mbakke@cisco.com>; Fri, 17 Aug 2001 11:32:03 -0700 (PDT)
Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203])
	by baucis.sc.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id SAA03408
	for <mbakke@cisco.com>; Fri, 17 Aug 2001 18:31:16 GMT
Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.203
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Fri, 17 Aug 2001 18:31:15 0000 (GMT)
Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <RBZ4BF1K>; Fri, 17 Aug 2001 11:31:14 -0700
Message-ID: <638EC1B28663D211AC3E00A0C96B78A8086ABB28@orsmsx40.jf.intel.com>
From: "Wheat, Stephen R" <stephen.r.wheat@intel.com>
To: "'Mark Bakke'" <mbakke@cisco.com>
Subject: RE: iSCSI: [Fwd: Crc-32c example in iSCSI spec]
Date: Fri, 17 Aug 2001 11:31:10 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Mozilla-Status2: 00000000

Mark,

OK, we're cooking with fire now.  Yup, the reflected-complemented result
matches yours.



Thanks,
Stephen

-----Original Message-----
From: Mark Bakke [mailto:mbakke@cisco.com]
Sent: Friday, August 17, 2001 10:53 AM
To: Wheat, Stephen R
Subject: Re: iSCSI: [Fwd: Crc-32c example in iSCSI spec]


Stephen-

The remainder was from running an entire test case through
the CRC generator, including the CRC itself.  I then had to
complement and bit-flip the remainder to make it work out the
same as the documented Ethernet remainder.  So here's how
I get the remainder for the 32-bytes of ones example:

Run

       0:        ff ff ff ff
       4:        ff ff ff ff
       8:        ff ff ff ff
      12:        ff ff ff ff
      16:        ff ff ff ff
      20:        ff ff ff ff
      24:        ff ff ff ff
      28:        ff ff ff ff

      32:        43 ab a8 62

Through the generator to get the CRC of the whole thing,
including the CRC that was sent.

In all cases, if the CRC is correct for the data, the CRC
will be 0x48674bc7.  Since the CRC that came out of my
generator was not really the remainder, it was the bit-flipped,
complemented remainder, I have to reverse both of these to
get 0x1c2d19ed.

--
Mark

"Wheat, Stephen R" wrote:
> 
> OK, until now, I was matching everything you posted (after the
correction).
> Now, I cannot get the same result as you on the remainder, either with a
> simple engine, or a table driven.
> 
> So, what exactly are you passing through the engine for this latest
> confirmation calculation?
> 
> I have been assuming you've been passing a 4-byte stream to the
crc-engine,
> where the 4-byte stream consists of the generation polynomial, byte order
> 0x41 0x6f 0xdc 0x1e
> 
> I'm not looking for you to help debug my engine; just to confirm the input
> to it.
> 
> Thanks,
> Stephen
> 
> -----Original Message-----
> From: Mark Bakke [mailto:mbakke@cisco.com]
> Sent: Friday, August 17, 2001 10:06 AM
> To: Sanjay Goyal
> Cc: Ips (E-mail)
> Subject: Re: iSCSI: [Fwd: Crc-32c example in iSCSI spec]
> 
> Sanjay Goyal wrote:
> >
> > Hi
> >  I get the remainder for iSCSI as 0x1c2d19ed if I complement my CRC and
> then
> > pass it through the CRC engine.
> >
> >  As per CRC generation for data: the thing which is not clear to me is
> >    why do we need to bit-swap the CRC reminader as is done in all your
> > examples.
> 
> As far as I can tell, bit-swapping does nothing to help or hurt
> the effectiveness of the CRC.  When I ran my examples, I thought
> that it would be the simplest for our CRC to different from the
> Ethernet CRC only in the polynomial.  Ethernet, FDDI, FC, and SCSI
> all do this, so I figured it would cause the least confusion if
> we did the same.
> 
> > We can just complement it and append it after the DATA bytes.
> >  The other side also can just pass it through the CRC engine to check
it.
> >
> > Regards
> > Sanjay Goyal
> >
> > -----Original Message-----
> > From: Mark Bakke [mailto:mbakke@cisco.com]
> > Sent: Thursday, August 16, 2001 1:43 PM
> > To: Steve Blightman; ips@ece.cmu.edu
> > Subject: Re: [Fwd: Crc-32c example in iSCSI spec]
> >
> > One more thing that might be helpful.  When the Ethernet
> > polynomial is used in SCSI to generate its CRC, the T10
> > doc specifies the remainder polynomial that one should see
> > after running the data with a valid CRC through.  For
> > the Ethernet CRC, this was specified as 0xc704dd7b.  This
> > remainder polynomial is taken before the CRC is complemented
> > and bit-reflected.  For iSCSI, I came up with a remainder of
> > 0x1c2d19ed.  Can anyone verify this result?
> >
> > --
> > Mark
> >
> > Mark Bakke wrote:
> > >
> > > Steve-
> > >
> > > I just ran some Ethernet packets with known CRCs through
> > > my iSCSI/Ethernet CRC generator, and found the same thing
> > > as you did.
> > >
> > > All of my examples need to be byte-swapped, along with the
> > > fix I already posted for the all-ones example.  Here is a
> > > new set of examples, which will be in -08.  I also ran
> > > 64 bytes of zeroes and ones, which now agree with your
> > > numbers as well.
> > >
> > > Thanks again for bringing this up.
> > >
> > > --
> > > Mark
> > >
> > >      07 CRC Examples
> > >
> > >         N.B. all Values are Hexadecimal
> > >
> > >           Byte:        0  1  2  3
> > >
> > >              0:       01 a0 00 00
> > >              4:       00 00 00 00
> > >              8:       00 00 00 00
> > >             12:       00 00 00 00
> > >             16:       04 05 00 00
> > >             20:       00 01 00 00
> > >             24:       00 00 00 05
> > >             28:       00 00 00 04
> > >             32:       2a 00 00 00
> > >             36:       00 00 00 00
> > >             40:       80 00 00 00
> > >             44:       00 00 00 00
> > >
> > >            CRC:       93 70 51 db
> > >
> > >         32 bytes of zeroes:
> > >
> > >           Byte:        0  1  2  3
> > >
> > >              0:       00 00 00 00
> > >            ...
> > >             28:       00 00 00 00
> > >
> > >            CRC:       aa 36 91 8a
> > >
> > >         32 bytes of ones:
> > >
> > >           Byte:        0  1  2  3
> > >
> > >              0:       ff ff ff ff
> > >            ...
> > >             28:       ff ff ff ff
> > >
> > >            CRC:       43 ab a8 62
> > >
> > >         32 bytes of incrementing 00..1f:
> > >
> > >           Byte:        0  1  2  3
> > >
> > >              0:       00 01 02 03
> > >            ...
> > >             28:       1c 1d 1e 1f
> > >
> > >            CRC:       4e 79 dd 46
> > >
> > >
> > > Steve Blightman wrote:
> > > >
> > > > I believe the examples for the ISCSI CRC  have the wrong endianness.
> > > >
> > > > As yiou suugested over the phone I ran some Ethernet frames through
a
> > > > simulation. I have some difficulty running the exact simulations you
> > > > wanted becuase the minimum size Ethernet frame is 64 bytes.
> > > >
> > > > However using the Ethernet CRC polynomial,
> > > > Running 64 bytes of 0 onto the wire, we append "36 63 8d 75" onto
the
> > > > wire for the CRC - "36" goes out first.
> > > > Running 64 bytes of all 1, we append "ba 87 61 0f" onto the wire -
> "ba"
> > > > goes out first.
> > > >
> > > > Using the same logic for the ISCSI polynomial
> > > > Running 64 bytes of 0 I think we should append "67 eb c8 03" - "67"
> > > > going out first
> > > > and running 64 bytes of all 1 we should append "66 4e cd 2f" - "66"
> > > > going out first
> > > >
> > > > And now for 32 bytes with the ISCSI polynomial
> > > >
> > > > Running 32 bytes of 0 we should append "aa 36 91 8a" - "aa" going
out
> > > > first
> > > > Running 32 bytes of all 1 we should append "43 ab a8 62" - "43"
going
> > > > out first
> > > >
> > > > I don't want to get into an endless endian debate, but I believe it
is
> > > > important to get the order of these bytes in the right order, so
that
> we
> > > > can use the same hardware to check as well as to generate CRCs.
> > > >
> > > > Thanks for your help on this,
> > > > Steve Blightman
> > >
> > > --
> > > Mark A. Bakke
> > > Cisco Systems
> > > mbakke@cisco.com
> > > 763.398.1054
> >
> > --
> > Mark A. Bakke
> > Cisco Systems
> > mbakke@cisco.com
> > 763.398.1054
> >
> >
>
----------------------------------------------------------------------------
> ------------------------
> >
> >    Part 1.2    Type: application/ms-tnef
> >            Encoding: base64
> 
> --
> Mark A. Bakke
> Cisco Systems
> mbakke@cisco.com
> 763.398.1054

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054



--------------28D0F3B82CDAA5FB10D3ACAE--



From owner-ips@ece.cmu.edu  Fri Aug 17 17:19:07 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15449
	for <ips-archive@odin.ietf.org>; Fri, 17 Aug 2001 17:19:06 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7HKRle10079
	for ips-outgoing; Fri, 17 Aug 2001 16:27:47 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mxic1.isus.emc.com ([168.159.129.100])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7HKRke10074
	for <ips@ece.cmu.edu>; Fri, 17 Aug 2001 16:27:46 -0400 (EDT)
Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <QQ9CNK7A>; Fri, 17 Aug 2001 16:29:45 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD5EE@CORPMX14>
From: Black_David@emc.com
To: ENDL_TX@computer.org, ips@ece.cmu.edu
Subject: RE: FCIP -03 comments
Date: Fri, 17 Aug 2001 16:22:03 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

There are actually two issues in here, one major and one minor.

The major issue is that the FCIP authors want to prohibit two
FCIP entities from sharing the same IP address.  That's ok provided
that the rationale for this design choice is clearly stated in
the (next version of) the FCIP draft.  One of the reasons why
that rationale is necessary is that this prohibition prevents
FCIP from working correctly through a NAPT (Network Address
Port Translator, see RFC 2663), and the IPS WG charter requires
operation through such entities to be considered by the WG.
It's fair to argue that this lack of support is a "feature"
(e.g., there's a significant portion of the IETF community
that regards NAPT and all other forms of NAT as "bugs"), but
the argument needs to be explicitly made in the draft.

While I'm at it, it appears to me that the FCIP authors are
reverting to the unfortunate habit of holding technical
discussions off-line and not sharing them with the list.  This
is not a good thing to do, and risks an interminable WG Last
Call process, as "the authors discussed this offline and
came to a different conclusion" is NOT an acceptable response
to a Last Call comment/objection.  Getting these technical
discussions onto the list so everyone can see them is important.

The minor issue is that the phrase "for each IP address assigned
to the product" requires an FCIP entity for IP interfaces on which
FCIP is not intended to be used.  This should be reworded as a
prohibition on FCIP entities sharing an IP address, which 
seems to be the intention.

--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------

> -----Original Message-----
> From: Ralph Weber [mailto:ralphoweber@compuserve.com]
> Sent: Thursday, August 16, 2001 8:48 PM
> To: ips@ece.cmu.edu
> Cc: Black_David@emc.com
> Subject: Re: FCIP -03 comments
> 
> 
> David,
> 
> On 7/18 you wrote:
> 
> ..snip..
> 
> > -- Section 6.4
> >
> >    An FC Fabric to IP Network interface product SHALL
> >    contain one FCIP Entity for each IP Address assigned to 
> the product.
> >
> > This looks overspecified for a couple of reasons -- it prevents
> > multiple FCIP entities on different TCP ports at the same IP
> > address and it appears to force implementation of an FCIP entity
> > on an interface intended solely for management traffic.  Needless
> > to say, this is overspecified - I'm guessing that the real 
> requirement
> > is that an FCIP entity MUST NOT span multiple IP addresses, but
> > more than one FCIP entity MAY share an IP address by using
> > different TCP ports.  This has some slight effects on wording
> > elsewhere, but I fail to see the reason for forbidding two FCIP
> > entities behind a single IP address.
> 
> ..snip..
> 
> I responded by promising to put this question to the FCIP authors.
> Here is their response (more or less faithfully transcribed, owing 
> for interpretations and flourishes).
> 
> The statement that ..."there SHALL be one FCIP Entity for each IP
> Address assigned to the product..." correctly reflects the intentions
> of the FCIP authors.  The requirement represents the results of about
> three hours of debate among the authors that occurred during the
> face-to-face meeting in Denver in June.
> 
> The agreed opinion is that, particularly in the manually configured
> case, the IP Address represents the FCIP Entity and as such having
> multiple FCIP Entities sharing an IP Address causes confusion.
> 
> A couple of the FCIP authors have volunteered to walk you through
> their PowerPoint, Visio, and PDF presentations on the subject in
> Orange County, but they have refused to convert their drawings to 
> ASCII stick figures.
> 
> The FCIP Authors have requested that you consider viewing their
> non-ASCII presentations personally and offline.  Should you wish
> to subject the meeting to this agony (I speak from experience here),
> please be sure the FCIP TD is notified of the agenda change.
> 
> Thanks.
> 
> Ralph...
> 
> 


From owner-ips@ece.cmu.edu  Fri Aug 17 18:00:59 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15856
	for <ips-archive@odin.ietf.org>; Fri, 17 Aug 2001 18:00:59 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7HLVcB13124
	for ips-outgoing; Fri, 17 Aug 2001 17:31:38 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from lightsand.com ([64.214.104.163])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7HLVXe13116
	for <ips@ece.cmu.edu>; Fri, 17 Aug 2001 17:31:33 -0400 (EDT)
Received: from muralipc ([192.168.2.38])
	by lightsand.com (8.9.3+Sun/8.9.1) with SMTP id OAA05815;
	Fri, 17 Aug 2001 14:31:18 -0700 (PDT)
From: "Murali Rajagopal" <muralir@lightsand.com>
To: <Black_David@emc.com>, <ENDL_TX@computer.org>, <ips@ece.cmu.edu>
Subject: RE: FCIP -03 comments
Date: Fri, 17 Aug 2001 14:32:13 -0700
Message-ID: <MABBKAENHGDNNGLLHCPKMENGCJAA.muralir@lightsand.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
Importance: Normal
In-Reply-To: <277DD60FB639D511AC0400B0D068B71ECAD5EE@CORPMX14>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

See comments ...

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Black_David@emc.com
Sent: Friday, August 17, 2001 1:22 PM
To: ENDL_TX@computer.org; ips@ece.cmu.edu
Subject: RE: FCIP -03 comments

There are actually two issues in here, one major and one minor.

The major issue is that the FCIP authors want to prohibit two
FCIP entities from sharing the same IP address.  That's ok provided
that the rationale for this design choice is clearly stated in
the (next version of) the FCIP draft.  One of the reasons why
that rationale is necessary is that this prohibition prevents
FCIP from working correctly through a NAPT (Network Address
Port Translator, see RFC 2663), and the IPS WG charter requires
operation through such entities to be considered by the WG.
It's fair to argue that this lack of support is a "feature"
(e.g., there's a significant portion of the IETF community
that regards NAPT and all other forms of NAT as "bugs"), but
the argument needs to be explicitly made in the draft.

While I'm at it, it appears to me that the FCIP authors are
reverting to the unfortunate habit of holding technical
discussions off-line and not sharing them with the list.  This
is not a good thing to do, and risks an interminable WG Last
Call process, as "the authors discussed this offline and
came to a different conclusion" is NOT an acceptable response
to a Last Call comment/objection.  Getting these technical
discussions onto the list so everyone can see them is important.
MR >> Point well taken on this but this method is not without benefits.
Given that the authorship is now shared by a good many companies who truly
care, there are two levels of consensus here. This removes some of the
uncontrolled flooding of responses and questions if done completely on the
reflector. I believe that the authors are completely open to comments and
suggestions from others on these types of issues on the reflector. Since we
have some degree of stability in many parts of the draft now we will in
future make an effort to bring this to the mailist and discuss such items.in
advance <<MR

The minor issue is that the phrase "for each IP address assigned
to the product" requires an FCIP entity for IP interfaces on which
FCIP is not intended to be used.  This should be reworded as a
prohibition on FCIP entities sharing an IP address, which
seems to be the intention.

--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------

> -----Original Message-----
> From: Ralph Weber [mailto:ralphoweber@compuserve.com]
> Sent: Thursday, August 16, 2001 8:48 PM
> To: ips@ece.cmu.edu
> Cc: Black_David@emc.com
> Subject: Re: FCIP -03 comments
>
>
> David,
>
> On 7/18 you wrote:
>
> ..snip..
>
> > -- Section 6.4
> >
> >    An FC Fabric to IP Network interface product SHALL
> >    contain one FCIP Entity for each IP Address assigned to
> the product.
> >
> > This looks overspecified for a couple of reasons -- it prevents
> > multiple FCIP entities on different TCP ports at the same IP
> > address and it appears to force implementation of an FCIP entity
> > on an interface intended solely for management traffic.  Needless
> > to say, this is overspecified - I'm guessing that the real
> requirement
> > is that an FCIP entity MUST NOT span multiple IP addresses, but
> > more than one FCIP entity MAY share an IP address by using
> > different TCP ports.  This has some slight effects on wording
> > elsewhere, but I fail to see the reason for forbidding two FCIP
> > entities behind a single IP address.
>
> ..snip..
>
> I responded by promising to put this question to the FCIP authors.
> Here is their response (more or less faithfully transcribed, owing
> for interpretations and flourishes).
>
> The statement that ..."there SHALL be one FCIP Entity for each IP
> Address assigned to the product..." correctly reflects the intentions
> of the FCIP authors.  The requirement represents the results of about
> three hours of debate among the authors that occurred during the
> face-to-face meeting in Denver in June.
>
> The agreed opinion is that, particularly in the manually configured
> case, the IP Address represents the FCIP Entity and as such having
> multiple FCIP Entities sharing an IP Address causes confusion.
>
> A couple of the FCIP authors have volunteered to walk you through
> their PowerPoint, Visio, and PDF presentations on the subject in
> Orange County, but they have refused to convert their drawings to
> ASCII stick figures.
>
> The FCIP Authors have requested that you consider viewing their
> non-ASCII presentations personally and offline.  Should you wish
> to subject the meeting to this agony (I speak from experience here),
> please be sure the FCIP TD is notified of the agenda change.
>
> Thanks.
>
> Ralph...
>
>



From owner-ips@ece.cmu.edu  Fri Aug 17 18:03:09 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15896
	for <ips-archive@odin.ietf.org>; Fri, 17 Aug 2001 18:03:08 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7HKpec11304
	for ips-outgoing; Fri, 17 Aug 2001 16:51:40 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from siaar2aa.compuserve.com (siaar2aa.compuserve.com [149.174.40.137])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7HKpce11298
	for <ips@ece.cmu.edu>; Fri, 17 Aug 2001 16:51:38 -0400 (EDT)
Received: (from mailgate@localhost)
	by siaar2aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id QAA23011
	for ips@ece.cmu.edu; Fri, 17 Aug 2001 16:51:33 -0400 (EDT)
Received: from compuserve.com (dal-tgn-tkx-vty6.as.wcom.net [216.192.233.6])
	by siaar2aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id QAA22993
	for <ips@ece.cmu.edu>; Fri, 17 Aug 2001 16:51:30 -0400 (EDT)
Message-ID: <3B7D84AC.12D4A408@compuserve.com>
Date: Fri, 17 Aug 2001 15:55:08 -0500
From: Ralph Weber <ralphoweber@compuserve.com>
Reply-To: ENDL_TX@computer.org
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47  (Win98; I)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: IPS Reflector <ips@ece.cmu.edu>
Subject: FCencap: Revision 2 is available
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Julian has provided access to the latest revision of the
FC Encapsulation draft at:

 http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-fcencapsulation-02.txt

and

 http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-fcencapsulation-02.pdf

This revision contains the changes proposed by Charles
Monia in draft-monia-ips-fcpropdelay-02.pdf.

The draft was submitted to the Internet Drafts office a couple
of days ago, but has yet to be announced.

The PDF file contains the same text as the regular file but
has bookmarks and change bars (with respect to revision 1)
for your added convenience.

FYI

Ralph...




From owner-ips@ece.cmu.edu  Fri Aug 17 18:26:41 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16215
	for <ips-archive@odin.ietf.org>; Fri, 17 Aug 2001 18:26:40 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7HLwqj14285
	for ips-outgoing; Fri, 17 Aug 2001 17:58:52 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7HLwpe14281
	for <ips@ece.cmu.edu>; Fri, 17 Aug 2001 17:58:51 -0400 (EDT)
Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <QSSYF02W>; Fri, 17 Aug 2001 17:58:45 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD5F3@CORPMX14>
From: Black_David@emc.com
To: VAHUJA@aol.com, ips@ece.cmu.edu
Subject: RE: Open Questions on iSCSI 07 security
Date: Fri, 17 Aug 2001 17:53:09 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

For SRP, check the associated text key definitions in the -07 draft.
The one issue I know of is that the current specification allows
arbitrary groups, and we probably need to select a few for which
support is REQUIRED.

Algorithms for confidentiality and integrity, along with selection
of a keying/rekeying approach are on the Orange County agenda.

Thanks,
--David

> -----Original Message-----
> From: VAHUJA@aol.com [mailto:VAHUJA@aol.com]
> Sent: Friday, August 17, 2001 5:48 PM
> To: ips@ece.cmu.edu
> Cc: vahuja@aol.com
> Subject: Open Questions on iSCSI 07 security
> 
> 
> I have been reading the iSCSI security in the drafts s (06, 
> 07) and David's paper on the iSCSI security issues. I have a 
> few questions that seem to (me to) remain unaswered. If they 
> are already answered, I'd welcome the answers; if not - I 
> suggest we include these in the discussions on 8/28th at Irvine.
> 
> AUTHENTICATION: The 06 level states authentication is a MUST 
> and the 07 level states that SRP is a MUST. But the SRP RFC 
> does not provide sufficient details on formats and protocols 
> that will be needed to allow 
> interoperability among different implementation.
> 
> A related development is the SLAP protocol from Brocade that 
> uses PKI for authentication and possibly other use. Any 
> suggestions on converging the two approaches for 
> authenticating storage devices: iSCSI or otherwise.
> 
> DATA INTEGRITY: This is a MUST in 06 level. But no algorithm 
> has been identified. The draft does state that IPSec can be 
> used here - and IPSec requires use of HMAC-MD5 and HMAC-SHA 
> 1, and a few optional. It'd perhaps be better to state in the 
> iSCSI standard the specific chosen algorithms for iSCSI Data 
> Integrity. 
> 
> CONFIDENTIALITY: I agree with David that we must specify the 
> algorithm, whther that's OPT or a MUST.
> And what about key exchange (IKE, D-H etc.)? Also, IPSec, as 
> far as I can tell, not yet blessed AES - perhaps we should 
> address this.
> 
> Thanks, Vijay
> 


From owner-ips@ece.cmu.edu  Fri Aug 17 18:27:55 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16273
	for <ips-archive@odin.ietf.org>; Fri, 17 Aug 2001 18:27:55 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7HLZLr13271
	for ips-outgoing; Fri, 17 Aug 2001 17:35:21 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7HLZKe13266
	for <ips@ece.cmu.edu>; Fri, 17 Aug 2001 17:35:20 -0400 (EDT)
Received: by ATLOPS with Internet Mail Service (5.5.2448.0)
	id <QMJCN1AR>; Fri, 17 Aug 2001 17:35:11 -0400
Message-ID: <25369470B6F0D41194820002B328BDD2116244@ATLOPS>
From: Sanjay Goyal <sanjay_goyal@ivivity.com>
To: "'Mark Bakke'" <mbakke@cisco.com>,
        Julian Satran
	 <julian_satran@il.ibm.com>, IPS <ips@ece.cmu.edu>
Cc: Sanjay Goyal <sanjay_goyal@ivivity.com>
Subject: RE: iSCSI CRC: A CRC-checking example
Date: Fri, 17 Aug 2001 17:35:03 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Hi
 For all zeros the value after complementing the CRC result is 0x556c8951.
If it is bit-swapped it becomes  0x8a9136aa.
 
 The way you will get the constant remainder 0x1c2d19ed is that you append
 0x556c8951 and not 0xaa36918a to the all-zero data bytes. The crc-check
engine would assume as if it is processing 4 more bytes. If we bit-swap the
CRC while transmitting, don't we have to again swap it at the receive side
and then pass it through the crc-check engine.

Sanjay Goyal                                  
www.ivivity.com



From owner-ips@ece.cmu.edu  Fri Aug 17 18:38:47 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16374
	for <ips-archive@odin.ietf.org>; Fri, 17 Aug 2001 18:38:47 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7HMBEU14828
	for ips-outgoing; Fri, 17 Aug 2001 18:11:14 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from ariel.nishansystems.com (smtp.nishansystems.com [216.217.36.162])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7HMBDe14824
	for <ips@ece.cmu.edu>; Fri, 17 Aug 2001 18:11:13 -0400 (EDT)
Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19)
	id <RDTY63S3>; Fri, 17 Aug 2001 15:11:06 -0700
Message-ID: <B300BD9620BCD411A366009027C21D9B551FA0@ariel.nishansystems.com>
From: Charles Monia <cmonia@NishanSystems.com>
To: "Ips (E-mail)" <ips@ece.cmu.edu>
Cc: "David Black (E-mail)" <Black_David@emc.com>,
        "Elizabeth Rodgriguez (E-mail)" <egrodriguez@lucent.com>
Subject: iFCP: Application for port-number
Date: Fri, 17 Aug 2001 15:11:05 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk



-----Original Message-----
From: cmonia@nishansystems.com [mailto:cmonia@nishansystems.com]
Sent: Friday, August 17, 2001 3:04 PM
To: iana@iana.org; cmonia@nishansystems.com
Subject: Application for port-number


Application for System (Well-Known) Port Number
    
Name :
Charles Monia
    
E-mail :
cmonia@nishansystems.com
        
Protocol Number :
TCP & UDP
    
Message Formats :
Mesage formats consist of encapsulated fibre channel frames each containing
a header and frame image as defined in draft-ietf-ips-iFCP-04.txt and
draft-ietf-ips-fcencapsulation.txt.


Message Types :  
Per draft-ietf-ips-iFCP-04.txt, messages consist of:

Requests and replies to start (CBIND) and terminate (UNBIND) an iFCP session

iFCP steady-state session traffic consists of Fibre Channel protocol
transactions carried by the stream of encapsulated fibre channel frames.

    
Message opcodes :
Op Codes for:
CBIND,
UNBIND

All other traffic contains fibre channel opcodes carried in the encapsulated
fibre channel frames.

     
Message Sequences :
A CBIND is issued to start an iFCP session.  A session is started when an
accept response is received.  Thereafter, the sending and receivind devices
use iFCP as a transport medium for fibre channel frames.

An UNBIND message is used to gracefully terminate an iFCP session.

    
Protocol functions :
Internetwork of legacy Fibre Channel devices via a TCP/IP transport.

     
Broadcast or Multicast used ?
no
    
How and what for Broadcast or Multicast is used (if used):

                
Description :
http://www.ietf.org/internet-drafts/draft-ietf-ips-ifcp-03.txt
(latest posted version)
http://www.ietf.org/internet-drafts/draft-ietf-ips-ifcp-04.txt
(Submitted but not posted as of 8/17/2001)

    
Name of the port :
iFCP System Port

Short name of the port :
iFCP-port



From owner-ips@ece.cmu.edu  Fri Aug 17 18:39:02 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16387
	for <ips-archive@odin.ietf.org>; Fri, 17 Aug 2001 18:39:01 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7HLshC14119
	for ips-outgoing; Fri, 17 Aug 2001 17:54:43 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from c007.snv.cp.net (c007-h013.c007.snv.cp.net [209.228.33.220])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f7HLsfe14114
	for <ips@ece.cmu.edu>; Fri, 17 Aug 2001 17:54:41 -0400 (EDT)
Received: (cpmta 18499 invoked from network); 17 Aug 2001 14:54:34 -0700
Received: from adsl-63-202-160-80.dsl.snfc21.pacbell.net (HELO littlejoy) (63.202.160.80)
  by smtp.telocity.com (209.228.33.220) with SMTP; 17 Aug 2001 14:54:34 -0700
X-Sent: 17 Aug 2001 21:54:34 GMT
From: "Douglas Otis" <dotis@sanlight.net>
To: <mbakke@cisco.com>
Cc: "Sanjay Goyal" <sanjay_goyal@ivivity.com>,
        "Ips \(E-mail\)" <ips@ece.cmu.edu>
Subject: RE: iSCSI: [Fwd: Crc-32c example in iSCSI spec]
Date: Fri, 17 Aug 2001 14:52:47 -0700
Message-ID: <NEBBJGDMMLHHCIKHGBEJOEHOCKAA.dotis@sanlight.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <3B7D7A2E.6A73A665@cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Mark,

You save a step in handling the table by doing it this way as well as
keeping the possibility of implementing a serial hardware implementation
without special handling.  Those seem to be good things and can easily
justify the reason for the reflected table.  Be aware the entire table is
reflected but that this only affects byte placement as bytes remain
reflected where the ms result is stored in the ls position as this position
is the first bit shipped.

As the initialization is set to ones, there is no danger of the remainder
being zero except in extremely rare cases.  This would seem to also negate
the advantage from doing an inversion before storing.  In addition, with the
initialization set to all ones, the result is also all ones and not zero.
To do a check, the inverted remainder needs to be un-inverted before entered
into the calculation.  This requires two additional instructions for little
benefit other than keeping with tradition.  It would seem if the
initialization is set to all ones, then the inverted store is not needed.
The check however can be made by just comparing results without a full
processing of the CRC.

Doug

> OK.  I don't see any reason for sending the CRC inverted either
> (we would just have a different remainder poly), but since Ethernet
> does it that way, and it doesn't cost anything, we might as well
> do it, too.
>
> --
> Mark
>
> Douglas Otis wrote:
> >
> > Mark,
> >
> > The reason for the bit swap within the table is to allow a
> serial hardware
> > scheme as CRC is processed ms to ls over the entire stream as
> if a single
> > number.  Ethernet sends the byte out least significant bit first.  The
> > entire table is also swapped ls to ms and actually reduces the
> operations
> > needed within the table calculations.  This reflects the method used for
> > Ethernet as it is being stored inverted and the initial value
> is started as
> > all ones.  The reason for the initial value being set to all
> ones is clear
> > for leading zero interaction, but I do not understand the value
> in storing
> > the CRC inverted.  I thought to include my ignorance to the mix.
> >
> > Doug
> >
> > > Sanjay Goyal wrote:
> > > >
> > > > Hi
> > > >  I get the remainder for iSCSI as 0x1c2d19ed if I complement my
> > > CRC and then
> > > > pass it through the CRC engine.
> > > >
> > > >  As per CRC generation for data: the thing which is not
> clear to me is
> > > >    why do we need to bit-swap the CRC reminader as is done
> in all your
> > > > examples.
> > >
> > > As far as I can tell, bit-swapping does nothing to help or hurt
> > > the effectiveness of the CRC.  When I ran my examples, I thought
> > > that it would be the simplest for our CRC to different from the
> > > Ethernet CRC only in the polynomial.  Ethernet, FDDI, FC, and SCSI
> > > all do this, so I figured it would cause the least confusion if
> > > we did the same.
> > >
> > > > We can just complement it and append it after the DATA bytes.
> > > >  The other side also can just pass it through the CRC engine to
> > > check it.
> > > >
> > > > Regards
> > > > Sanjay Goyal
> > > >
> > > > -----Original Message-----
> > > > From: Mark Bakke [mailto:mbakke@cisco.com]
> > > > Sent: Thursday, August 16, 2001 1:43 PM
> > > > To: Steve Blightman; ips@ece.cmu.edu
> > > > Subject: Re: [Fwd: Crc-32c example in iSCSI spec]
> > > >
> > > > One more thing that might be helpful.  When the Ethernet
> > > > polynomial is used in SCSI to generate its CRC, the T10
> > > > doc specifies the remainder polynomial that one should see
> > > > after running the data with a valid CRC through.  For
> > > > the Ethernet CRC, this was specified as 0xc704dd7b.  This
> > > > remainder polynomial is taken before the CRC is complemented
> > > > and bit-reflected.  For iSCSI, I came up with a remainder of
> > > > 0x1c2d19ed.  Can anyone verify this result?
> > > >
> > > > --
> > > > Mark
> > > >
> > > > Mark Bakke wrote:
> > > > >
> > > > > Steve-
> > > > >
> > > > > I just ran some Ethernet packets with known CRCs through
> > > > > my iSCSI/Ethernet CRC generator, and found the same thing
> > > > > as you did.
> > > > >
> > > > > All of my examples need to be byte-swapped, along with the
> > > > > fix I already posted for the all-ones example.  Here is a
> > > > > new set of examples, which will be in -08.  I also ran
> > > > > 64 bytes of zeroes and ones, which now agree with your
> > > > > numbers as well.
> > > > >
> > > > > Thanks again for bringing this up.
> > > > >
> > > > > --
> > > > > Mark
> > > > >
> > > > >      07 CRC Examples
> > > > >
> > > > >         N.B. all Values are Hexadecimal
> > > > >
> > > > >           Byte:        0  1  2  3
> > > > >
> > > > >              0:       01 a0 00 00
> > > > >              4:       00 00 00 00
> > > > >              8:       00 00 00 00
> > > > >             12:       00 00 00 00
> > > > >             16:       04 05 00 00
> > > > >             20:       00 01 00 00
> > > > >             24:       00 00 00 05
> > > > >             28:       00 00 00 04
> > > > >             32:       2a 00 00 00
> > > > >             36:       00 00 00 00
> > > > >             40:       80 00 00 00
> > > > >             44:       00 00 00 00
> > > > >
> > > > >            CRC:       93 70 51 db
> > > > >
> > > > >         32 bytes of zeroes:
> > > > >
> > > > >           Byte:        0  1  2  3
> > > > >
> > > > >              0:       00 00 00 00
> > > > >            ...
> > > > >             28:       00 00 00 00
> > > > >
> > > > >            CRC:       aa 36 91 8a
> > > > >
> > > > >         32 bytes of ones:
> > > > >
> > > > >           Byte:        0  1  2  3
> > > > >
> > > > >              0:       ff ff ff ff
> > > > >            ...
> > > > >             28:       ff ff ff ff
> > > > >
> > > > >            CRC:       43 ab a8 62
> > > > >
> > > > >         32 bytes of incrementing 00..1f:
> > > > >
> > > > >           Byte:        0  1  2  3
> > > > >
> > > > >              0:       00 01 02 03
> > > > >            ...
> > > > >             28:       1c 1d 1e 1f
> > > > >
> > > > >            CRC:       4e 79 dd 46
> > > > >
> > > > >
> > > > > Steve Blightman wrote:
> > > > > >
> > > > > > I believe the examples for the ISCSI CRC  have the
> wrong endianness.
> > > > > >
> > > > > > As yiou suugested over the phone I ran some Ethernet frames
> > > through a
> > > > > > simulation. I have some difficulty running the exact
> simulations you
> > > > > > wanted becuase the minimum size Ethernet frame is 64 bytes.
> > > > > >
> > > > > > However using the Ethernet CRC polynomial,
> > > > > > Running 64 bytes of 0 onto the wire, we append "36 63 8d
> > > 75" onto the
> > > > > > wire for the CRC - "36" goes out first.
> > > > > > Running 64 bytes of all 1, we append "ba 87 61 0f" onto the
> > > wire - "ba"
> > > > > > goes out first.
> > > > > >
> > > > > > Using the same logic for the ISCSI polynomial
> > > > > > Running 64 bytes of 0 I think we should append "67 eb
> c8 03" - "67"
> > > > > > going out first
> > > > > > and running 64 bytes of all 1 we should append "66 4e
> cd 2f" - "66"
> > > > > > going out first
> > > > > >
> > > > > > And now for 32 bytes with the ISCSI polynomial
> > > > > >
> > > > > > Running 32 bytes of 0 we should append "aa 36 91 8a" - "aa"
> > > going out
> > > > > > first
> > > > > > Running 32 bytes of all 1 we should append "43 ab a8 62" -
> > > "43" going
> > > > > > out first
> > > > > >
> > > > > > I don't want to get into an endless endian debate, but I
> > > believe it is
> > > > > > important to get the order of these bytes in the right
> > > order, so that we
> > > > > > can use the same hardware to check as well as to generate CRCs.
> > > > > >
> > > > > > Thanks for your help on this,
> > > > > > Steve Blightman
> > > > >
> > > > > --
> > > > > Mark A. Bakke
> > > > > Cisco Systems
> > > > > mbakke@cisco.com
> > > > > 763.398.1054
> > > >
> > > > --
> > > > Mark A. Bakke
> > > > Cisco Systems
> > > > mbakke@cisco.com
> > > > 763.398.1054
> > > >
> > > >
> > > ------------------------------------------------------------------
> > > ----------------------------------
> > > >
> > > >    Part 1.2    Type: application/ms-tnef
> > > >            Encoding: base64
> > >
> > > --
> > > Mark A. Bakke
> > > Cisco Systems
> > > mbakke@cisco.com
> > > 763.398.1054
> > >
>
> --
> Mark A. Bakke
> Cisco Systems
> mbakke@cisco.com
> 763.398.1054
>



From owner-ips@ece.cmu.edu  Fri Aug 17 18:39:21 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16398
	for <ips-archive@odin.ietf.org>; Fri, 17 Aug 2001 18:39:20 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7HLeov13523
	for ips-outgoing; Fri, 17 Aug 2001 17:40:50 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7HLele13518
	for <ips@ece.cmu.edu>; Fri, 17 Aug 2001 17:40:48 -0400 (EDT)
Received: by ATLOPS with Internet Mail Service (5.5.2448.0)
	id <QMJCN1AV>; Fri, 17 Aug 2001 17:40:41 -0400
Message-ID: <25369470B6F0D41194820002B328BDD2116245@ATLOPS>
From: Sanjay Goyal <sanjay_goyal@ivivity.com>
To: "'Wheat, Stephen R'" <stephen.r.wheat@intel.com>,
        "'Douglas Otis'"
	 <dotis@sanlight.net>, Mark Bakke <mbakke@cisco.com>,
        Sanjay Goyal
	 <sanjay_goyal@ivivity.com>
Cc: "Ips (E-mail)" <ips@ece.cmu.edu>
Subject: RE: iSCSI: [Fwd: Crc-32c example in iSCSI spec]
Date: Fri, 17 Aug 2001 17:40:37 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Stephen
 I would agree that checking for all zeros is always faster.

Regards
Sanjay G

-----Original Message-----
From: Wheat, Stephen R [mailto:stephen.r.wheat@intel.com]
Sent: Friday, August 17, 2001 4:26 PM
To: 'Douglas Otis'; Mark Bakke; Sanjay Goyal
Cc: Ips (E-mail)
Subject: RE: iSCSI: [Fwd: Crc-32c example in iSCSI spec]


Quoting from Richard Black,
www.cl.cam.ac.uk/Research/SRG/bluebook/21/crc/node2.html
the inversion of the CRC before sending it precludes erroneous addition of
trailing zeros.

Without complementing the remainder, the result of a checked message would
be 0x00000000.  If the message, for some reason, had any number of zero bits
appended to it (after the crc word), the result would still be 0x00000000.

Thus, it seems that complementing the remainder is a relic from the bit
serial days where the end of the message was not determined beforehand, as
is the case for iSCSI PDUs.

As Mark originally opined, keeping with the reflected/complemented algorithm
has a certain consistency to it.

So, it appears that complementing the result for iSCSI CRC is an arbitrary
decision, that consistency seems to have won out.

Does anyone have an opinion as to whether checking for a zero result, versus
a non-zero result, has a performance implication?

Stephen

-----Original Message-----
From: Douglas Otis [mailto:dotis@sanlight.net]
Sent: Friday, August 17, 2001 11:54 AM
To: Mark Bakke; Sanjay Goyal
Cc: Ips (E-mail)
Subject: RE: iSCSI: [Fwd: Crc-32c example in iSCSI spec]


Mark,

The reason for the bit swap within the table is to allow a serial hardware
scheme as CRC is processed ms to ls over the entire stream as if a single
number.  Ethernet sends the byte out least significant bit first.  The
entire table is also swapped ls to ms and actually reduces the operations
needed within the table calculations.  This reflects the method used for
Ethernet as it is being stored inverted and the initial value is started as
all ones.  The reason for the initial value being set to all ones is clear
for leading zero interaction, but I do not understand the value in storing
the CRC inverted.  I thought to include my ignorance to the mix.

Doug

> Sanjay Goyal wrote:
> >
> > Hi
> >  I get the remainder for iSCSI as 0x1c2d19ed if I complement my
> CRC and then
> > pass it through the CRC engine.
> >
> >  As per CRC generation for data: the thing which is not clear to me is
> >    why do we need to bit-swap the CRC reminader as is done in all your
> > examples.
>
> As far as I can tell, bit-swapping does nothing to help or hurt
> the effectiveness of the CRC.  When I ran my examples, I thought
> that it would be the simplest for our CRC to different from the
> Ethernet CRC only in the polynomial.  Ethernet, FDDI, FC, and SCSI
> all do this, so I figured it would cause the least confusion if
> we did the same.
>
> > We can just complement it and append it after the DATA bytes.
> >  The other side also can just pass it through the CRC engine to
> check it.
> >
> > Regards
> > Sanjay Goyal
> >
> > -----Original Message-----
> > From: Mark Bakke [mailto:mbakke@cisco.com]
> > Sent: Thursday, August 16, 2001 1:43 PM
> > To: Steve Blightman; ips@ece.cmu.edu
> > Subject: Re: [Fwd: Crc-32c example in iSCSI spec]
> >
> > One more thing that might be helpful.  When the Ethernet
> > polynomial is used in SCSI to generate its CRC, the T10
> > doc specifies the remainder polynomial that one should see
> > after running the data with a valid CRC through.  For
> > the Ethernet CRC, this was specified as 0xc704dd7b.  This
> > remainder polynomial is taken before the CRC is complemented
> > and bit-reflected.  For iSCSI, I came up with a remainder of
> > 0x1c2d19ed.  Can anyone verify this result?
> >
> > --
> > Mark
> >
> > Mark Bakke wrote:
> > >
> > > Steve-
> > >
> > > I just ran some Ethernet packets with known CRCs through
> > > my iSCSI/Ethernet CRC generator, and found the same thing
> > > as you did.
> > >
> > > All of my examples need to be byte-swapped, along with the
> > > fix I already posted for the all-ones example.  Here is a
> > > new set of examples, which will be in -08.  I also ran
> > > 64 bytes of zeroes and ones, which now agree with your
> > > numbers as well.
> > >
> > > Thanks again for bringing this up.
> > >
> > > --
> > > Mark
> > >
> > >      07 CRC Examples
> > >
> > >         N.B. all Values are Hexadecimal
> > >
> > >           Byte:        0  1  2  3
> > >
> > >              0:       01 a0 00 00
> > >              4:       00 00 00 00
> > >              8:       00 00 00 00
> > >             12:       00 00 00 00
> > >             16:       04 05 00 00
> > >             20:       00 01 00 00
> > >             24:       00 00 00 05
> > >             28:       00 00 00 04
> > >             32:       2a 00 00 00
> > >             36:       00 00 00 00
> > >             40:       80 00 00 00
> > >             44:       00 00 00 00
> > >
> > >            CRC:       93 70 51 db
> > >
> > >         32 bytes of zeroes:
> > >
> > >           Byte:        0  1  2  3
> > >
> > >              0:       00 00 00 00
> > >            ...
> > >             28:       00 00 00 00
> > >
> > >            CRC:       aa 36 91 8a
> > >
> > >         32 bytes of ones:
> > >
> > >           Byte:        0  1  2  3
> > >
> > >              0:       ff ff ff ff
> > >            ...
> > >             28:       ff ff ff ff
> > >
> > >            CRC:       43 ab a8 62
> > >
> > >         32 bytes of incrementing 00..1f:
> > >
> > >           Byte:        0  1  2  3
> > >
> > >              0:       00 01 02 03
> > >            ...
> > >             28:       1c 1d 1e 1f
> > >
> > >            CRC:       4e 79 dd 46
> > >
> > >
> > > Steve Blightman wrote:
> > > >
> > > > I believe the examples for the ISCSI CRC  have the wrong endianness.
> > > >
> > > > As yiou suugested over the phone I ran some Ethernet frames
> through a
> > > > simulation. I have some difficulty running the exact simulations you
> > > > wanted becuase the minimum size Ethernet frame is 64 bytes.
> > > >
> > > > However using the Ethernet CRC polynomial,
> > > > Running 64 bytes of 0 onto the wire, we append "36 63 8d
> 75" onto the
> > > > wire for the CRC - "36" goes out first.
> > > > Running 64 bytes of all 1, we append "ba 87 61 0f" onto the
> wire - "ba"
> > > > goes out first.
> > > >
> > > > Using the same logic for the ISCSI polynomial
> > > > Running 64 bytes of 0 I think we should append "67 eb c8 03" - "67"
> > > > going out first
> > > > and running 64 bytes of all 1 we should append "66 4e cd 2f" - "66"
> > > > going out first
> > > >
> > > > And now for 32 bytes with the ISCSI polynomial
> > > >
> > > > Running 32 bytes of 0 we should append "aa 36 91 8a" - "aa"
> going out
> > > > first
> > > > Running 32 bytes of all 1 we should append "43 ab a8 62" -
> "43" going
> > > > out first
> > > >
> > > > I don't want to get into an endless endian debate, but I
> believe it is
> > > > important to get the order of these bytes in the right
> order, so that we
> > > > can use the same hardware to check as well as to generate CRCs.
> > > >
> > > > Thanks for your help on this,
> > > > Steve Blightman
> > >
> > > --
> > > Mark A. Bakke
> > > Cisco Systems
> > > mbakke@cisco.com
> > > 763.398.1054
> >
> > --
> > Mark A. Bakke
> > Cisco Systems
> > mbakke@cisco.com
> > 763.398.1054
> >
> >
> ------------------------------------------------------------------
> ----------------------------------
> >
> >    Part 1.2    Type: application/ms-tnef
> >            Encoding: base64
>
> --
> Mark A. Bakke
> Cisco Systems
> mbakke@cisco.com
> 763.398.1054
>



From owner-ips@ece.cmu.edu  Fri Aug 17 18:40:23 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16433
	for <ips-archive@odin.ietf.org>; Fri, 17 Aug 2001 18:40:22 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7HLmD313844
	for ips-outgoing; Fri, 17 Aug 2001 17:48:13 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from imo-d03.mx.aol.com (imo-d03.mx.aol.com [205.188.157.35])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7HLmCe13840
	for <ips@ece.cmu.edu>; Fri, 17 Aug 2001 17:48:12 -0400 (EDT)
Received: from VAHUJA@aol.com
	by imo-d03.mx.aol.com (mail_out_v31_r1.4.) id 3.138.2b96a4 (15911);
	Fri, 17 Aug 2001 17:48:05 -0400 (EDT)
Received: from  web33.aolmail.aol.com (web33.aolmail.aol.com [205.188.222.9]) by air-id09.mx.aol.com (v79.27) with ESMTP id MAILINID910-0817174805; Fri, 17 Aug 2001 17:48:05 -0400
Date: Fri, 17 Aug 2001 17:48:05 EDT
From: VAHUJA@aol.com
Subject: Open Questions on iSCSI 07 security
To: <ips@ece.cmu.edu>
Cc: <vahuja@aol.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Mailer: Unknown (No Version)
Message-ID: <138.2b96a4.28aeeb15@aol.com>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

I have been reading the iSCSI security in the drafts s (06, 07) and David's paper on the iSCSI security issues. I have a few questions that seem to (me to) remain unaswered. If they are already answered, I'd welcome the answers; if not - I suggest we include these in the discussions on 8/28th at Irvine.

AUTHENTICATION: The 06 level states authentication is a MUST and the 07 level states that SRP is a MUST. But the SRP RFC does not provide sufficient details on formats and protocols that will be needed to allow 
interoperability among different implementation.

A related development is the SLAP protocol from Brocade that uses PKI for authentication and possibly other use. Any suggestions on converging the two approaches for authenticating storage devices: iSCSI or otherwise.

DATA INTEGRITY: This is a MUST in 06 level. But no algorithm has been identified. The draft does state that IPSec can be used here - and IPSec requires use of HMAC-MD5 and HMAC-SHA 1, and a few optional. It'd perhaps be better to state in the iSCSI standard the specific chosen algorithms for iSCSI Data Integrity. 

CONFIDENTIALITY: I agree with David that we must specify the algorithm, whther that's OPT or a MUST.
And what about key exchange (IKE, D-H etc.)? Also, IPSec, as far as I can tell, not yet blessed AES - perhaps we should address this.

Thanks, Vijay


From owner-ips@ece.cmu.edu  Fri Aug 17 19:12:13 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16896
	for <ips-archive@odin.ietf.org>; Fri, 17 Aug 2001 19:12:12 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7HMsVj16582
	for ips-outgoing; Fri, 17 Aug 2001 18:54:31 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from msgbas1t.cos.agilent.com (msgbas1tx.cos.agilent.com [192.6.9.34])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7HMsUe16577
	for <ips@ece.cmu.edu>; Fri, 17 Aug 2001 18:54:30 -0400 (EDT)
Received: from msgrel1t.cos.agilent.com (msgrel1t.cos.agilent.com [130.29.152.157])
	by msgbas1t.cos.agilent.com (Postfix) with ESMTP
	id 9C6F8663; Fri, 17 Aug 2001 16:54:29 -0600 (MDT)
Received: from axandbh3.and.agilent.com (axandbh3.and.agilent.com [130.30.32.200])
	by msgrel1t.cos.agilent.com (Postfix) with ESMTP
	id 140F25D7; Fri, 17 Aug 2001 16:54:29 -0600 (MDT)
Received: by axandbh3.and.agilent.com with Internet Mail Service (5.5.2653.19)
	id <Q941XP4H>; Fri, 17 Aug 2001 18:54:28 -0400
Message-ID: <1BEBA5E8600DD4119A50009027AF54A0078112C4@axcs04.cos.agilent.com>
From: "THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>
To: Mark Bakke <mbakke@cisco.com>, Sanjay Goyal <sanjay_goyal@ivivity.com>
Cc: "Ips (E-mail)" <ips@ece.cmu.edu>
Subject: RE: iSCSI: [Fwd: Crc-32c example in iSCSI spec]
Date: Fri, 17 Aug 2001 18:54:25 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Mark,

I agree that for iSCSI there is no technical advantage to the bit order
chosen for the CRC. Bit order through the CRC checker helps in serial data
transmission such as over an Ethernet. If the bits are checked in the same
order as they are transmitted, then they will get the full length of burst
error detection. If they aren't, then burst error protection can shrink
about in half. When iSCSI packets are on an Ethernet, the Ethernet CRC
provides this protection. The iSCSI CRC protects the packet when it isn't on
the LAN and, in that case, it is often moving byte parallel and when it is
moving serial the bytes might be sent in either order. 

The important thing is that the order be specified clearly so everyone does
the same thing.

Regards,
Pat

-----Original Message-----
From: Mark Bakke [mailto:mbakke@cisco.com]
Sent: Friday, August 17, 2001 10:06 AM
To: Sanjay Goyal
Cc: Ips (E-mail)
Subject: Re: iSCSI: [Fwd: Crc-32c example in iSCSI spec]


Sanjay Goyal wrote:
> 
> Hi
>  I get the remainder for iSCSI as 0x1c2d19ed if I complement my CRC and
then
> pass it through the CRC engine.
>
>  As per CRC generation for data: the thing which is not clear to me is
>    why do we need to bit-swap the CRC reminader as is done in all your
> examples.

As far as I can tell, bit-swapping does nothing to help or hurt
the effectiveness of the CRC.  When I ran my examples, I thought
that it would be the simplest for our CRC to different from the
Ethernet CRC only in the polynomial.  Ethernet, FDDI, FC, and SCSI
all do this, so I figured it would cause the least confusion if
we did the same.

> We can just complement it and append it after the DATA bytes.
>  The other side also can just pass it through the CRC engine to check it.
> 
> Regards
> Sanjay Goyal
> 
> -----Original Message-----
> From: Mark Bakke [mailto:mbakke@cisco.com]
> Sent: Thursday, August 16, 2001 1:43 PM
> To: Steve Blightman; ips@ece.cmu.edu
> Subject: Re: [Fwd: Crc-32c example in iSCSI spec]
> 
> One more thing that might be helpful.  When the Ethernet
> polynomial is used in SCSI to generate its CRC, the T10
> doc specifies the remainder polynomial that one should see
> after running the data with a valid CRC through.  For
> the Ethernet CRC, this was specified as 0xc704dd7b.  This
> remainder polynomial is taken before the CRC is complemented
> and bit-reflected.  For iSCSI, I came up with a remainder of
> 0x1c2d19ed.  Can anyone verify this result?
> 
> --
> Mark
> 
> Mark Bakke wrote:
> >
> > Steve-
> >
> > I just ran some Ethernet packets with known CRCs through
> > my iSCSI/Ethernet CRC generator, and found the same thing
> > as you did.
> >
> > All of my examples need to be byte-swapped, along with the
> > fix I already posted for the all-ones example.  Here is a
> > new set of examples, which will be in -08.  I also ran
> > 64 bytes of zeroes and ones, which now agree with your
> > numbers as well.
> >
> > Thanks again for bringing this up.
> >
> > --
> > Mark
> >
> >      07 CRC Examples
> >
> >         N.B. all Values are Hexadecimal
> >
> >           Byte:        0  1  2  3
> >
> >              0:       01 a0 00 00
> >              4:       00 00 00 00
> >              8:       00 00 00 00
> >             12:       00 00 00 00
> >             16:       04 05 00 00
> >             20:       00 01 00 00
> >             24:       00 00 00 05
> >             28:       00 00 00 04
> >             32:       2a 00 00 00
> >             36:       00 00 00 00
> >             40:       80 00 00 00
> >             44:       00 00 00 00
> >
> >            CRC:       93 70 51 db
> >
> >         32 bytes of zeroes:
> >
> >           Byte:        0  1  2  3
> >
> >              0:       00 00 00 00
> >            ...
> >             28:       00 00 00 00
> >
> >            CRC:       aa 36 91 8a
> >
> >         32 bytes of ones:
> >
> >           Byte:        0  1  2  3
> >
> >              0:       ff ff ff ff
> >            ...
> >             28:       ff ff ff ff
> >
> >            CRC:       43 ab a8 62
> >
> >         32 bytes of incrementing 00..1f:
> >
> >           Byte:        0  1  2  3
> >
> >              0:       00 01 02 03
> >            ...
> >             28:       1c 1d 1e 1f
> >
> >            CRC:       4e 79 dd 46
> >
> >
> > Steve Blightman wrote:
> > >
> > > I believe the examples for the ISCSI CRC  have the wrong endianness.
> > >
> > > As yiou suugested over the phone I ran some Ethernet frames through a
> > > simulation. I have some difficulty running the exact simulations you
> > > wanted becuase the minimum size Ethernet frame is 64 bytes.
> > >
> > > However using the Ethernet CRC polynomial,
> > > Running 64 bytes of 0 onto the wire, we append "36 63 8d 75" onto the
> > > wire for the CRC - "36" goes out first.
> > > Running 64 bytes of all 1, we append "ba 87 61 0f" onto the wire -
"ba"
> > > goes out first.
> > >
> > > Using the same logic for the ISCSI polynomial
> > > Running 64 bytes of 0 I think we should append "67 eb c8 03" - "67"
> > > going out first
> > > and running 64 bytes of all 1 we should append "66 4e cd 2f" - "66"
> > > going out first
> > >
> > > And now for 32 bytes with the ISCSI polynomial
> > >
> > > Running 32 bytes of 0 we should append "aa 36 91 8a" - "aa" going out
> > > first
> > > Running 32 bytes of all 1 we should append "43 ab a8 62" - "43" going
> > > out first
> > >
> > > I don't want to get into an endless endian debate, but I believe it is
> > > important to get the order of these bytes in the right order, so that
we
> > > can use the same hardware to check as well as to generate CRCs.
> > >
> > > Thanks for your help on this,
> > > Steve Blightman
> >
> > --
> > Mark A. Bakke
> > Cisco Systems
> > mbakke@cisco.com
> > 763.398.1054
> 
> --
> Mark A. Bakke
> Cisco Systems
> mbakke@cisco.com
> 763.398.1054
> 
>
----------------------------------------------------------------------------
------------------------
> 
>    Part 1.2    Type: application/ms-tnef
>            Encoding: base64

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054


From owner-ips@ece.cmu.edu  Fri Aug 17 19:15:29 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16935
	for <ips-archive@odin.ietf.org>; Fri, 17 Aug 2001 19:15:28 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7HMNhX15329
	for ips-outgoing; Fri, 17 Aug 2001 18:23:43 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7HMNfe15324
	for <ips@ece.cmu.edu>; Fri, 17 Aug 2001 18:23:41 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id AAA163328;
	Sat, 18 Aug 2001 00:23:34 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7HMNUH215008;
	Sat, 18 Aug 2001 00:23:30 +0200
Importance: Normal
Subject: Re: iSCSI: [Fwd: Crc-32c example in iSCSI spec]
To: Mark Bakke <mbakke@cisco.com>
Cc: Douglas Otis <dotis@sanlight.net>, Sanjay Goyal <sanjay_goyal@ivivity.com>,
        "Ips (E-mail)" <ips@ece.cmu.edu>
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF633F936E.C6D51EFD-ONC2256AAB.0076DFA9@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Sat, 18 Aug 2001 01:23:03 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 18/08/2001 01:23:32
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Mark & all,

The 2 "additions" you will find in the CRC calculation:

   initializing the "remainder" field with all ones (instead of the implied
   shifting in of 0's) and
   XORing the result with a mask (usually "full house")


are done to improve the error correction capabilities of CRCs.
CRCs are weak in detecting the spurious addition of leading 0s (that can
result from clocking errors) and the deletion of initial 1 with spurious
insertion of a 1 at the end.

Julo

Mark Bakke <mbakke@cisco.com>@ece.cmu.edu on 17-08-2001 23:10:22

Please respond to Mark Bakke <mbakke@cisco.com>

Sent by:  owner-ips@ece.cmu.edu


To:   Douglas Otis <dotis@sanlight.net>
cc:   Sanjay Goyal <sanjay_goyal@ivivity.com>, "Ips (E-mail)"
      <ips@ece.cmu.edu>
Subject:  Re: iSCSI: [Fwd: Crc-32c example in iSCSI spec]



OK.  I don't see any reason for sending the CRC inverted either
(we would just have a different remainder poly), but since Ethernet
does it that way, and it doesn't cost anything, we might as well
do it, too.

--
Mark

Douglas Otis wrote:
>
> Mark,
>
> The reason for the bit swap within the table is to allow a serial
hardware
> scheme as CRC is processed ms to ls over the entire stream as if a single
> number.  Ethernet sends the byte out least significant bit first.  The
> entire table is also swapped ls to ms and actually reduces the operations
> needed within the table calculations.  This reflects the method used for
> Ethernet as it is being stored inverted and the initial value is started
as
> all ones.  The reason for the initial value being set to all ones is
clear
> for leading zero interaction, but I do not understand the value in
storing
> the CRC inverted.  I thought to include my ignorance to the mix.
>
> Doug
>
> > Sanjay Goyal wrote:
> > >
> > > Hi
> > >  I get the remainder for iSCSI as 0x1c2d19ed if I complement my
> > CRC and then
> > > pass it through the CRC engine.
> > >
> > >  As per CRC generation for data: the thing which is not clear to me
is
> > >    why do we need to bit-swap the CRC reminader as is done in all
your
> > > examples.
> >
> > As far as I can tell, bit-swapping does nothing to help or hurt
> > the effectiveness of the CRC.  When I ran my examples, I thought
> > that it would be the simplest for our CRC to different from the
> > Ethernet CRC only in the polynomial.  Ethernet, FDDI, FC, and SCSI
> > all do this, so I figured it would cause the least confusion if
> > we did the same.
> >
> > > We can just complement it and append it after the DATA bytes.
> > >  The other side also can just pass it through the CRC engine to
> > check it.
> > >
> > > Regards
> > > Sanjay Goyal
> > >
> > > -----Original Message-----
> > > From: Mark Bakke [mailto:mbakke@cisco.com]
> > > Sent: Thursday, August 16, 2001 1:43 PM
> > > To: Steve Blightman; ips@ece.cmu.edu
> > > Subject: Re: [Fwd: Crc-32c example in iSCSI spec]
> > >
> > > One more thing that might be helpful.  When the Ethernet
> > > polynomial is used in SCSI to generate its CRC, the T10
> > > doc specifies the remainder polynomial that one should see
> > > after running the data with a valid CRC through.  For
> > > the Ethernet CRC, this was specified as 0xc704dd7b.  This
> > > remainder polynomial is taken before the CRC is complemented
> > > and bit-reflected.  For iSCSI, I came up with a remainder of
> > > 0x1c2d19ed.  Can anyone verify this result?
> > >
> > > --
> > > Mark
> > >
> > > Mark Bakke wrote:
> > > >
> > > > Steve-
> > > >
> > > > I just ran some Ethernet packets with known CRCs through
> > > > my iSCSI/Ethernet CRC generator, and found the same thing
> > > > as you did.
> > > >
> > > > All of my examples need to be byte-swapped, along with the
> > > > fix I already posted for the all-ones example.  Here is a
> > > > new set of examples, which will be in -08.  I also ran
> > > > 64 bytes of zeroes and ones, which now agree with your
> > > > numbers as well.
> > > >
> > > > Thanks again for bringing this up.
> > > >
> > > > --
> > > > Mark
> > > >
> > > >      07 CRC Examples
> > > >
> > > >         N.B. all Values are Hexadecimal
> > > >
> > > >           Byte:        0  1  2  3
> > > >
> > > >              0:       01 a0 00 00
> > > >              4:       00 00 00 00
> > > >              8:       00 00 00 00
> > > >             12:       00 00 00 00
> > > >             16:       04 05 00 00
> > > >             20:       00 01 00 00
> > > >             24:       00 00 00 05
> > > >             28:       00 00 00 04
> > > >             32:       2a 00 00 00
> > > >             36:       00 00 00 00
> > > >             40:       80 00 00 00
> > > >             44:       00 00 00 00
> > > >
> > > >            CRC:       93 70 51 db
> > > >
> > > >         32 bytes of zeroes:
> > > >
> > > >           Byte:        0  1  2  3
> > > >
> > > >              0:       00 00 00 00
> > > >            ...
> > > >             28:       00 00 00 00
> > > >
> > > >            CRC:       aa 36 91 8a
> > > >
> > > >         32 bytes of ones:
> > > >
> > > >           Byte:        0  1  2  3
> > > >
> > > >              0:       ff ff ff ff
> > > >            ...
> > > >             28:       ff ff ff ff
> > > >
> > > >            CRC:       43 ab a8 62
> > > >
> > > >         32 bytes of incrementing 00..1f:
> > > >
> > > >           Byte:        0  1  2  3
> > > >
> > > >              0:       00 01 02 03
> > > >            ...
> > > >             28:       1c 1d 1e 1f
> > > >
> > > >            CRC:       4e 79 dd 46
> > > >
> > > >
> > > > Steve Blightman wrote:
> > > > >
> > > > > I believe the examples for the ISCSI CRC  have the wrong
endianness.
> > > > >
> > > > > As yiou suugested over the phone I ran some Ethernet frames
> > through a
> > > > > simulation. I have some difficulty running the exact simulations
you
> > > > > wanted becuase the minimum size Ethernet frame is 64 bytes.
> > > > >
> > > > > However using the Ethernet CRC polynomial,
> > > > > Running 64 bytes of 0 onto the wire, we append "36 63 8d
> > 75" onto the
> > > > > wire for the CRC - "36" goes out first.
> > > > > Running 64 bytes of all 1, we append "ba 87 61 0f" onto the
> > wire - "ba"
> > > > > goes out first.
> > > > >
> > > > > Using the same logic for the ISCSI polynomial
> > > > > Running 64 bytes of 0 I think we should append "67 eb c8 03" -
"67"
> > > > > going out first
> > > > > and running 64 bytes of all 1 we should append "66 4e cd 2f" -
"66"
> > > > > going out first
> > > > >
> > > > > And now for 32 bytes with the ISCSI polynomial
> > > > >
> > > > > Running 32 bytes of 0 we should append "aa 36 91 8a" - "aa"
> > going out
> > > > > first
> > > > > Running 32 bytes of all 1 we should append "43 ab a8 62" -
> > "43" going
> > > > > out first
> > > > >
> > > > > I don't want to get into an endless endian debate, but I
> > believe it is
> > > > > important to get the order of these bytes in the right
> > order, so that we
> > > > > can use the same hardware to check as well as to generate CRCs.
> > > > >
> > > > > Thanks for your help on this,
> > > > > Steve Blightman
> > > >
> > > > --
> > > > Mark A. Bakke
> > > > Cisco Systems
> > > > mbakke@cisco.com
> > > > 763.398.1054
> > >
> > > --
> > > Mark A. Bakke
> > > Cisco Systems
> > > mbakke@cisco.com
> > > 763.398.1054
> > >
> > >
> > ------------------------------------------------------------------
> > ----------------------------------
> > >
> > >    Part 1.2    Type: application/ms-tnef
> > >            Encoding: base64
> >
> > --
> > Mark A. Bakke
> > Cisco Systems
> > mbakke@cisco.com
> > 763.398.1054
> >

--
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054





From owner-ips@ece.cmu.edu  Fri Aug 17 19:16:12 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16947
	for <ips-archive@odin.ietf.org>; Fri, 17 Aug 2001 19:16:12 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7HMSj815542
	for ips-outgoing; Fri, 17 Aug 2001 18:28:45 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from c007.snv.cp.net (c007-h011.c007.snv.cp.net [209.228.33.217])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f7HMShe15537
	for <ips@ece.cmu.edu>; Fri, 17 Aug 2001 18:28:43 -0400 (EDT)
Received: (cpmta 3906 invoked from network); 17 Aug 2001 15:28:37 -0700
Received: from adsl-63-202-160-80.dsl.snfc21.pacbell.net (HELO littlejoy) (63.202.160.80)
  by smtp.telocity.com (209.228.33.217) with SMTP; 17 Aug 2001 15:28:37 -0700
X-Sent: 17 Aug 2001 22:28:37 GMT
From: "Douglas Otis" <dotis@sanlight.net>
To: "Mark Bakke" <mbakke@cisco.com>,
        "Julian Satran" <julian_satran@il.ibm.com>, "IPS" <ips@ece.cmu.edu>
Subject: RE: iSCSI CRC: A CRC-checking example
Date: Fri, 17 Aug 2001 15:26:51 -0700
Message-ID: <NEBBJGDMMLHHCIKHGBEJMEIACKAA.dotis@sanlight.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <3B7D7AD1.3064A800@cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Mark,

You appear to be incorrect about which bit is processed first.  The table is
reflected and therefore there should be no need to do any reflection as you
describe except within building the table.  Here is some example code for
generating this reflected table.

/* Example CRC32 reflected table creation */

#include <stdio.h>
#include <stdlib.h>

#define OUTPUT_FILE   "crc32_tab.h"
#define CRC32_POLY			0x1EDC6F41L
#define CRC_TYPE  "\
/* Castagnoli93                                                        */\n\
/* x^32+x^28+x^27+x^26+x^25+x^23+x^22+x^20+x^19+x^18+x^14+x^13+x^11+   */\n\
/* x^10+* x^9+x^8+x^6+x^0                                              */\n\
/* Guy Castagnoli Stefan Braeuer and Martin Herrman                    */\n\
/* \"Optimization of Cyclic Redundancy-Check Codes
*/\n\
/* with 24 and 32 Parity Bits\",
*/\n\
/* IEEE Transactions on Communications, Vol. 41, No. 6, June 1993      */\n"


FILE *tf;

unsigned long
  reflect_32 (unsigned long b)
{
  int i;
  unsigned long rw = 0;

  for (i = 0; i < 32; i++)
    {
      if (b & 1)
        rw |= 1 << (31 - i);
      b >>= 1;
    }
  return (rw);
}


unsigned long
  build_crc_table (int index)
{
  int i;
  unsigned long rb;

  rb = reflect_32 (index);

  for (i = 0; i < 8; i++)
    {
      if (rb & 0x80000000L)
	rb = (rb << 1) ^ CRC32_POLY;
      else
	rb <<= 1;
    }
  return (reflect_32 (rb));
}


/* here is a means to verify the bype order via serial equivalent */

unsigned long
  serial_gen (unsigned char buf[], int length)
{
  int i;
  int j = 0;
  unsigned char d;
  unsigned long crc = 0;

  while (j < length)
    {
      d = buf[j++];
      for (i = 0; i < 8; i++)
	  {
	  if ((crc >> 31) ^ (d & 1))
	      crc = (crc << 1) ^ CRC32_POLY;
	  else
	      crc <<= 1;
	  d >>= 1;
	  }
    }

  return (crc);
}

main ()
{
  int i;

  printf ("\nGenerating CRC32 Table file <%s>\n", OUTPUT_FILE);
  if ((tf = fopen (OUTPUT_FILE, "w")) == NULL)
    {
      printf ("Unable to open %s\n", OUTPUT_FILE);
      exit (1);
    }
  fprintf (tf, "#ifndef __crc32_table_h__\n");
  fprintf (tf, "#define __crc32_table_h__\n\n");
  fprintf (tf, "#define CRC32_POLY 0x%08lX\n", CRC32_POLY);
  fprintf (tf, "#define CRC32(c,d) (c=(c>>8)^crc32tab[(c^(d))&0xFF])\n");
  fprintf (tf, "\
/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */\n\
/* 32 Bit Reflected CRC table generation for SCTP.                     */\n\
/* To accomodate serial byte data being shifted out least              */\n\
/* significant bit first, the table's 32 bit words are reflected       */\n\
/* which flips both byte and bit MS and LS positions.  The CRC         */\n\
/* is calculated MS bits first from the perspective of the serial      */\n\
/* stream.  The x^32 term is implied and the x^0 term may also         */\n\
/* be shown as +1.  The polynomial code used is 0x%08lX.            */\n%s\
/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */\n"
	   , CRC32_POLY, CRC_TYPE);

  fprintf (tf, "\nunsigned long  crc32tab[256] =\n{\n");
  for (i = 0; i < 256; i++)
    {
      fprintf (tf, "0x%08lXL, ", build_crc_table (i));
      if ((i & 3) == 3)
        fprintf (tf, "\n");
    }

  fprintf (tf, "};\n\n#endif\n");

  if (fclose (tf) != 0)
    printf ("Unable to close <%s>." OUTPUT_FILE);
  else
    printf ("\nThe CRC32 table has been written to <%s>.\n", OUTPUT_FILE);
}


Doug


> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Mark Bakke
> Sent: Friday, August 17, 2001 1:13 PM
> To: Julian Satran; IPS
> Subject: iSCSI CRC: A CRC-checking example
>
>
>
> Julian and CRC enthusiasts-
>
> After several people ran the iSCSI CRC through their
> hardware and software implementations, we've found that
> there are a few important things to add to the CRC spec;
> that the bit order must be flipped, and the CRC bytes
> must be sent in network order.
>
> We should also specify that when running the CRC check
> on an iSCSI PDU with its CRC, that the remainder (before
> complement and bit-reversal) is a constant 0x1c2d19ed.
>
>
> How about replacing:
>
> The generator polynomial selected is evaluated in [Castagnioli93].
> When using the CRC the CRC register must be initialized to all 1s
> (0xFFFFFFFF) and the CRC bits must be complemented before
> transmission. Padding bytes, when present, in a segment covered by a
> CRC, should be set to 0 and are included in the CRC.
>
> With:
>
> The generator polynomial selected is evaluated in [Castagnioli93].
> When using the CRC the CRC register must be initialized to all 1s
> (0xFFFFFFFF).  Input bytes are processed with bit 7 being the most
> significant bit.  Before transmission, the CRC bits must be
> reflected (bit 31 swapped with bit 0, bit 30 swapped with bit 1,
> etc.), and complemented.  The CRC bytes must be transmitted in
> network order.  Padding bytes, when present, in a segment covered
> by a CRC, should be set to 0 and are included in the CRC.
>
> Running the CRC-32C generator on an input stream that includes a
> valid CRC-32C will result in the constant remainder 0x1c2d19ed,
> (without being reversed and complemented).
>
>
> --
> Mark A. Bakke
> Cisco Systems
> mbakke@cisco.com
> 763.398.1054



From owner-ips@ece.cmu.edu  Fri Aug 17 19:18:18 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16982
	for <ips-archive@odin.ietf.org>; Fri, 17 Aug 2001 19:18:17 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7HMdMm16011
	for ips-outgoing; Fri, 17 Aug 2001 18:39:22 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7HMdKe16007
	for <ips@ece.cmu.edu>; Fri, 17 Aug 2001 18:39:20 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id AAA339918
	for <ips@ece.cmu.edu>; Sat, 18 Aug 2001 00:39:12 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7HMdCH152940
	for <ips@ece.cmu.edu>; Sat, 18 Aug 2001 00:39:12 +0200
Importance: Normal
Subject: Re: iSCSI CRC: A CRC-checking example
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF54DBD82E.C2644097-ONC2256AAB.007BFC63@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Sat, 18 Aug 2001 01:38:45 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 18/08/2001 01:39:12
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Mark,

I will get this out when we have it right.
As for the endian - it looks to me that the CRC is not different to the
rest - it is sent in network order (and calculated this way).

Regards,
Julo

Please respond to Mark Bakke <mbakke@cisco.com>

Sent by:  mbakke@cisco.com


To:   Julian Satran/Haifa/IBM@IBMIL, IPS <ips@ece.cmu.edu>
cc:
Subject:  iSCSI CRC: A CRC-checking example




Julian and CRC enthusiasts-

After several people ran the iSCSI CRC through their
hardware and software implementations, we've found that
there are a few important things to add to the CRC spec;
that the bit order must be flipped, and the CRC bytes
must be sent in network order.

We should also specify that when running the CRC check
on an iSCSI PDU with its CRC, that the remainder (before
complement and bit-reversal) is a constant 0x1c2d19ed.


How about replacing:

The generator polynomial selected is evaluated in [Castagnioli93].
When using the CRC the CRC register must be initialized to all 1s
(0xFFFFFFFF) and the CRC bits must be complemented before
transmission. Padding bytes, when present, in a segment covered by a
CRC, should be set to 0 and are included in the CRC.

With:

The generator polynomial selected is evaluated in [Castagnioli93].
When using the CRC the CRC register must be initialized to all 1s
(0xFFFFFFFF).  Input bytes are processed with bit 7 being the most
significant bit.  Before transmission, the CRC bits must be
reflected (bit 31 swapped with bit 0, bit 30 swapped with bit 1,
etc.), and complemented.  The CRC bytes must be transmitted in
network order.  Padding bytes, when present, in a segment covered
by a CRC, should be set to 0 and are included in the CRC.

Running the CRC-32C generator on an input stream that includes a
valid CRC-32C will result in the constant remainder 0x1c2d19ed,
(without being reversed and complemented).


--
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054
Return-Path: stephen.r.wheat@intel.com
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com
[171.70.157.152]) by dogwood.cisco.com (8.8.6
(PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA13149 for
<mbakke@dogwood.cisco.com>; Fri, 17 Aug 2001 14:31:30 -0400 (EDT)
Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com
[171.69.11.130])    by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id
f7HITbD04150   for <mbakke@cisco.com>; Fri, 17 Aug 2001 11:29:38 -0700
(PDT)
Received: from proxy3.cisco.com (localhost [127.0.0.1])      by
sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f7HIVdW25226  for
<mbakke@sj-av.cisco.com>; Fri, 17 Aug 2001 11:31:39 -0700 (PDT)
Received: from baucis.sc.intel.com (ns3.intel.com [143.183.152.22])    by
proxy3.cisco.com (8.11.2/8.11.2) with ESMTP id f7HIW3Q20439  for
<mbakke@cisco.com>; Fri, 17 Aug 2001 11:32:03 -0700 (PDT)
Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203])  by
baucis.sc.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22
root Exp $) with SMTP id SAA03408  for <mbakke@cisco.com>; Fri, 17 Aug 2001
18:31:16 GMT
Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.203
(Norton AntiVirus for Internet Email Gateways 1.0) ;  Fri, 17 Aug 2001
18:31:15 0000 (GMT)
Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19)
id <RBZ4BF1K>; Fri, 17 Aug 2001 11:31:14 -0700
Message-ID:
<638EC1B28663D211AC3E00A0C96B78A8086ABB28@orsmsx40.jf.intel.com>
From: "Wheat, Stephen R" <stephen.r.wheat@intel.com>
To: "'Mark Bakke'" <mbakke@cisco.com>
Subject: RE: iSCSI: [Fwd: Crc-32c example in iSCSI spec]
Date: Fri, 17 Aug 2001 11:31:10 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;     charset="iso-8859-1"
X-Mozilla-Status2: 00000000

Mark,

OK, we're cooking with fire now.  Yup, the reflected-complemented result
matches yours.



Thanks,
Stephen

-----Original Message-----
From: Mark Bakke [mailto:mbakke@cisco.com]
Sent: Friday, August 17, 2001 10:53 AM
To: Wheat, Stephen R
Subject: Re: iSCSI: [Fwd: Crc-32c example in iSCSI spec]


Stephen-

The remainder was from running an entire test case through
the CRC generator, including the CRC itself.  I then had to
complement and bit-flip the remainder to make it work out the
same as the documented Ethernet remainder.  So here's how
I get the remainder for the 32-bytes of ones example:

Run

       0:        ff ff ff ff
       4:        ff ff ff ff
       8:        ff ff ff ff
      12:        ff ff ff ff
      16:        ff ff ff ff
      20:        ff ff ff ff
      24:        ff ff ff ff
      28:        ff ff ff ff

      32:        43 ab a8 62

Through the generator to get the CRC of the whole thing,
including the CRC that was sent.

In all cases, if the CRC is correct for the data, the CRC
will be 0x48674bc7.  Since the CRC that came out of my
generator was not really the remainder, it was the bit-flipped,
complemented remainder, I have to reverse both of these to
get 0x1c2d19ed.

--
Mark

"Wheat, Stephen R" wrote:
>
> OK, until now, I was matching everything you posted (after the
correction).
> Now, I cannot get the same result as you on the remainder, either with a
> simple engine, or a table driven.
>
> So, what exactly are you passing through the engine for this latest
> confirmation calculation?
>
> I have been assuming you've been passing a 4-byte stream to the
crc-engine,
> where the 4-byte stream consists of the generation polynomial, byte order
> 0x41 0x6f 0xdc 0x1e
>
> I'm not looking for you to help debug my engine; just to confirm the
input
> to it.
>
> Thanks,
> Stephen
>
> -----Original Message-----
> From: Mark Bakke [mailto:mbakke@cisco.com]
> Sent: Friday, August 17, 2001 10:06 AM
> To: Sanjay Goyal
> Cc: Ips (E-mail)
> Subject: Re: iSCSI: [Fwd: Crc-32c example in iSCSI spec]
>
> Sanjay Goyal wrote:
> >
> > Hi
> >  I get the remainder for iSCSI as 0x1c2d19ed if I complement my CRC and
> then
> > pass it through the CRC engine.
> >
> >  As per CRC generation for data: the thing which is not clear to me is
> >    why do we need to bit-swap the CRC reminader as is done in all your
> > examples.
>
> As far as I can tell, bit-swapping does nothing to help or hurt
> the effectiveness of the CRC.  When I ran my examples, I thought
> that it would be the simplest for our CRC to different from the
> Ethernet CRC only in the polynomial.  Ethernet, FDDI, FC, and SCSI
> all do this, so I figured it would cause the least confusion if
> we did the same.
>
> > We can just complement it and append it after the DATA bytes.
> >  The other side also can just pass it through the CRC engine to check
it.
> >
> > Regards
> > Sanjay Goyal
> >
> > -----Original Message-----
> > From: Mark Bakke [mailto:mbakke@cisco.com]
> > Sent: Thursday, August 16, 2001 1:43 PM
> > To: Steve Blightman; ips@ece.cmu.edu
> > Subject: Re: [Fwd: Crc-32c example in iSCSI spec]
> >
> > One more thing that might be helpful.  When the Ethernet
> > polynomial is used in SCSI to generate its CRC, the T10
> > doc specifies the remainder polynomial that one should see
> > after running the data with a valid CRC through.  For
> > the Ethernet CRC, this was specified as 0xc704dd7b.  This
> > remainder polynomial is taken before the CRC is complemented
> > and bit-reflected.  For iSCSI, I came up with a remainder of
> > 0x1c2d19ed.  Can anyone verify this result?
> >
> > --
> > Mark
> >
> > Mark Bakke wrote:
> > >
> > > Steve-
> > >
> > > I just ran some Ethernet packets with known CRCs through
> > > my iSCSI/Ethernet CRC generator, and found the same thing
> > > as you did.
> > >
> > > All of my examples need to be byte-swapped, along with the
> > > fix I already posted for the all-ones example.  Here is a
> > > new set of examples, which will be in -08.  I also ran
> > > 64 bytes of zeroes and ones, which now agree with your
> > > numbers as well.
> > >
> > > Thanks again for bringing this up.
> > >
> > > --
> > > Mark
> > >
> > >      07 CRC Examples
> > >
> > >         N.B. all Values are Hexadecimal
> > >
> > >           Byte:        0  1  2  3
> > >
> > >              0:       01 a0 00 00
> > >              4:       00 00 00 00
> > >              8:       00 00 00 00
> > >             12:       00 00 00 00
> > >             16:       04 05 00 00
> > >             20:       00 01 00 00
> > >             24:       00 00 00 05
> > >             28:       00 00 00 04
> > >             32:       2a 00 00 00
> > >             36:       00 00 00 00
> > >             40:       80 00 00 00
> > >             44:       00 00 00 00
> > >
> > >            CRC:       93 70 51 db
> > >
> > >         32 bytes of zeroes:
> > >
> > >           Byte:        0  1  2  3
> > >
> > >              0:       00 00 00 00
> > >            ...
> > >             28:       00 00 00 00
> > >
> > >            CRC:       aa 36 91 8a
> > >
> > >         32 bytes of ones:
> > >
> > >           Byte:        0  1  2  3
> > >
> > >              0:       ff ff ff ff
> > >            ...
> > >             28:       ff ff ff ff
> > >
> > >            CRC:       43 ab a8 62
> > >
> > >         32 bytes of incrementing 00..1f:
> > >
> > >           Byte:        0  1  2  3
> > >
> > >              0:       00 01 02 03
> > >            ...
> > >             28:       1c 1d 1e 1f
> > >
> > >            CRC:       4e 79 dd 46
> > >
> > >
> > > Steve Blightman wrote:
> > > >
> > > > I believe the examples for the ISCSI CRC  have the wrong
endianness.
> > > >
> > > > As yiou suugested over the phone I ran some Ethernet frames through
a
> > > > simulation. I have some difficulty running the exact simulations
you
> > > > wanted becuase the minimum size Ethernet frame is 64 bytes.
> > > >
> > > > However using the Ethernet CRC polynomial,
> > > > Running 64 bytes of 0 onto the wire, we append "36 63 8d 75" onto
the
> > > > wire for the CRC - "36" goes out first.
> > > > Running 64 bytes of all 1, we append "ba 87 61 0f" onto the wire -
> "ba"
> > > > goes out first.
> > > >
> > > > Using the same logic for the ISCSI polynomial
> > > > Running 64 bytes of 0 I think we should append "67 eb c8 03" - "67"
> > > > going out first
> > > > and running 64 bytes of all 1 we should append "66 4e cd 2f" - "66"
> > > > going out first
> > > >
> > > > And now for 32 bytes with the ISCSI polynomial
> > > >
> > > > Running 32 bytes of 0 we should append "aa 36 91 8a" - "aa" going
out
> > > > first
> > > > Running 32 bytes of all 1 we should append "43 ab a8 62" - "43"
going
> > > > out first
> > > >
> > > > I don't want to get into an endless endian debate, but I believe it
is
> > > > important to get the order of these bytes in the right order, so
that
> we
> > > > can use the same hardware to check as well as to generate CRCs.
> > > >
> > > > Thanks for your help on this,
> > > > Steve Blightman
> > >
> > > --
> > > Mark A. Bakke
> > > Cisco Systems
> > > mbakke@cisco.com
> > > 763.398.1054
> >
> > --
> > Mark A. Bakke
> > Cisco Systems
> > mbakke@cisco.com
> > 763.398.1054
> >
> >
>
----------------------------------------------------------------------------

> ------------------------
> >
> >    Part 1.2    Type: application/ms-tnef
> >            Encoding: base64
>
> --
> Mark A. Bakke
> Cisco Systems
> mbakke@cisco.com
> 763.398.1054

--
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054








From owner-ips@ece.cmu.edu  Fri Aug 17 20:52:29 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17682
	for <ips-archive@odin.ietf.org>; Fri, 17 Aug 2001 20:52:29 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7HNkPT18430
	for ips-outgoing; Fri, 17 Aug 2001 19:46:25 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from ariel.nishansystems.com (smtp.nishansystems.com [216.217.36.162])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7HNkOe18426
	for <ips@ece.cmu.edu>; Fri, 17 Aug 2001 19:46:24 -0400 (EDT)
Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19)
	id <RDTY634A>; Fri, 17 Aug 2001 16:46:18 -0700
Message-ID: <B300BD9620BCD411A366009027C21D9B5BADF0@ariel.nishansystems.com>
From: Joshua Tseng <jtseng@NishanSystems.com>
To: "'Ips (E-mail)'" <ips@ece.cmu.edu>
Cc: "'David Black (E-mail)'" <Black_David@emc.com>,
        "'Elizabeth Rodgriguez (E-mail)'" <egrodriguez@lucent.com>
Subject: iSNS: Application for port-number
Date: Fri, 17 Aug 2001 16:46:17 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk



-----Original Message-----
From: jtseng@nishansystems.com [mailto:jtseng@nishansystems.com]
Sent: Friday, August 17, 2001 4:42 PM
To: iana@iana.org; jtseng@nishansystems.com
Subject: Application for port-number


Application for System (Well-Known) Port Number
    
Name :
Josh Tseng
    
E-mail :
jtseng@nishansystems.com
        
Protocol Number :
TCP & UDP
    
Message Formats :
Tag-Length-Value (T-L-V)


Message Types :  
Request, reply, interrupt
    
Message opcodes :
   Register Dev Attr Req     RegDevAttr    0x0001
   Dev Attr Query Request    DevAttrQry    0x0002
   Dev Get Next Request      DevGetNext    0x0003
   Deregister Dev Request    DeregDev      0x0004
   SCN Register Request      SCNReg        0x0005
   SCN Deregister Request    SCNDereg      0x0006
   SCN Event                 SCNEvent      0x0007
   State Change Notification SCN           0x0008
   DD Register               DDReg         0x0009
   DD Deregister             DDDereg       0x000A
   DDS Register              DDSReg        0x000B
   DDS Deregister            DDSDereg      0x000C
   Entity Status Inquiry     ESI           0x000D
   Name Service Heartbeat    Heartbeat     0x000E

   Register Dev Attr Rsp     RegDevRsp     0x8001
   Dev Attr Query Rsp        DevAttrQryRsp 0x8002
   Dev Get Next Rsp          DevGetNextRsp 0x8003
   Deregister Dev Rsp        DeregDevRsp   0x8004
   SCN Register Rsp          SCNRegRsp     0x8005
   SCN Deregister Rsp        SCNDeregRsp   0x8006
   SCN Event Rsp             SCNEventRsp   0x8007
   SCN Response              SCNRsp        0x8008
   DD Register Rsp           DDRegRsp      0x8009
   DD Deregister Rsp         DDDeregRsp    0x800A
   DDS Register Rsp          DDSRegRsp     0x800B
   DDS Deregister Rsp        DDSDeregRsp   0x800C
   Entity Stat Inquiry Rsp   ESIRsp        0x800D

     
Message Sequences :
Client sends request, server sends response.  Server may asynchronously send
interrupt to client
    
Protocol functions :
Protocol for managing iSCSI devices and iFCP gateways

     
Broadcast or Multicast used ?
yes
    
How and what for Broadcast or Multicast is used (if used):
Multicast is optional, and may be used by clients for discovering location
of iSNS server, monitoring its status, and fail-over to a new server if
necessary.
                
Description :
http://www.ietf.org/internet-drafts/draft-ietf-ips-isns-04.txt
    
Name of the port :
iSNS Server Port

Short name of the port :
iSNS



From owner-ips@ece.cmu.edu  Sat Aug 18 09:19:29 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12351
	for <ips-archive@odin.ietf.org>; Sat, 18 Aug 2001 09:19:28 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7ICIM423000
	for ips-outgoing; Sat, 18 Aug 2001 08:18:22 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7HB3Xe13561
	for <ips@ece.cmu.edu>; Fri, 17 Aug 2001 07:03:33 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23190;
	Fri, 17 Aug 2001 07:02:19 -0400 (EDT)
Message-Id: <200108171102.HAA23190@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ips@ece.cmu.edu
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ips-fcencapsulation-02.txt
Date: Fri, 17 Aug 2001 07:02:19 -0400
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Storage Working Group of the IETF.

	Title		: FC Frame Encapsulation
	Author(s)	: R. Weber, M. Rajagopal, F. Travostino, 
                          V. Chau, M. O'Donnell, C. Monia, M. Merhar
	Filename	: draft-ietf-ips-fcencapsulation-02.txt
	Pages		: 14
	Date		: 16-Aug-01
	
This is the ips (IP Storage) working group draft describing the
common encapsulation format and a procedure for the measurement and
calculation of frame transit time through the IP network. This
specification is intended for use by any IETF protocol that
encapsulates Fibre Channel (FC) frames. This draft describes a frame
header containing information mandated for encapsulating,
transmitting, de-encapsulating, and calculating the transit times of
FC frames.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ips-fcencapsulation-02.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ips-fcencapsulation-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ips-fcencapsulation-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010816080108.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ips-fcencapsulation-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ips-fcencapsulation-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010816080108.I-D@ietf.org>

--OtherAccess--

--NextPart--



From owner-ips@ece.cmu.edu  Sat Aug 18 09:22:31 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12395
	for <ips-archive@odin.ietf.org>; Sat, 18 Aug 2001 09:22:31 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7ICISh23008
	for ips-outgoing; Sat, 18 Aug 2001 08:18:28 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7HB3ce13571
	for <ips@ece.cmu.edu>; Fri, 17 Aug 2001 07:03:38 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23208;
	Fri, 17 Aug 2001 07:02:24 -0400 (EDT)
Message-Id: <200108171102.HAA23208@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ips@ece.cmu.edu
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ips-fcovertcpip-05.txt
Date: Fri, 17 Aug 2001 07:02:24 -0400
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Storage Working Group of the IETF.

	Title		: Fibre Channel Over TCP/IP (FCIP)
	Author(s)	: M. Rajagopal, R. Bhagwat et al.
	Filename	: draft-ietf-ips-fcovertcpip-05.txt
	Pages		: 44
	Date		: 16-Aug-01
	
Fibre Channel Over TCP/IP (FCIP) describes mechanisms that allow the
interconnection of islands of Fibre Channel storage area networks
over IP-based networks to form a unified storage area network in a
single Fibre Channel fabric. FCIP relies on IP-based network
services to provide the connectivity between the storage area
network islands over local area networks, metropolitan area
networks, or wide area networks.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ips-fcovertcpip-05.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ips-fcovertcpip-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ips-fcovertcpip-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010816080118.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ips-fcovertcpip-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ips-fcovertcpip-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010816080118.I-D@ietf.org>

--OtherAccess--

--NextPart--



From owner-ips@ece.cmu.edu  Sat Aug 18 16:31:51 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15413
	for <ips-archive@odin.ietf.org>; Sat, 18 Aug 2001 16:31:50 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7IJRXi08916
	for ips-outgoing; Sat, 18 Aug 2001 15:27:33 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7IJRWe08911
	for <ips@ece.cmu.edu>; Sat, 18 Aug 2001 15:27:32 -0400 (EDT)
Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <QSSYG52A>; Sat, 18 Aug 2001 15:27:27 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD5FC@CORPMX14>
From: Black_David@emc.com
To: ips@ece.cmu.edu
Subject: iSCSI: Login/CmdSN consensus call
Date: Sat, 18 Aug 2001 15:21:48 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

This issue of how CmdSN and its ordering requirements apply
to login phase commands needs to be closed.  While I have
not been able to review every message on this topic, I
believe that the rough consensus of the IPS WG is that
login phase messages do NOT participate in CmdSN-based
ordering of iSCSI commands.

One way of achieving this is to REQUIRE that all
login phase messages (login, login response, text [when
used during login phase}) be sent for immediate delivery
with the I bit set to "1" rather than "0" as currently
specified in the -07 draft, but I'm open to further
discussion of alternatives to this on the list.

The only technical argument I've seen against this has
been based on the notion that an Initiator may wish to
order a Login command with respect to an outstanding
SCSI Task Management operation.  I find this unconvincing
because:
- iSCSI's mapping of SCSI Task Management is already
	more than sufficiently complicated.  We should
	not be adding more functionality here.
- If ordering wrt SCSI task management is required,
	the Initiator should login and then issue the
	appropriate SCSI commands to obtain the desired
	result rather than relying on iSCSI side effects.
Any further objection to this consensus call should be
sent to the list.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


From owner-ips@ece.cmu.edu  Sat Aug 18 16:40:59 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15462
	for <ips-archive@odin.ietf.org>; Sat, 18 Aug 2001 16:40:59 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7IJEJU08518
	for ips-outgoing; Sat, 18 Aug 2001 15:14:19 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mxic1.isus.emc.com ([168.159.129.100])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7IJEIe08514
	for <ips@ece.cmu.edu>; Sat, 18 Aug 2001 15:14:18 -0400 (EDT)
Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <QQ9CNYD5>; Sat, 18 Aug 2001 15:16:17 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD5FB@CORPMX14>
From: Black_David@emc.com
To: ips@ece.cmu.edu
Subject: iSCSI: Alias consensus call
Date: Sat, 18 Aug 2001 15:08:32 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Traffic on this topic has died down, so I believe that the
rough consensus of the IPS WG is to retain support for Alias
in the iSCSI protocol.

I have seen two expressions of the opposite view:
- Bob Snively's, which I am setting aside, as not
	being relevant to the topic - Bob's post
	concerned LU aliases rather than Initiator/
	Target aliases.
- Marj Krueger's, which I take note of in making this
	call (i.e., the consensus call is over Marj's
	objection).

Anyone other than Marj who wishes to object should post
to the list.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


From owner-ips@ece.cmu.edu  Sun Aug 19 15:41:51 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAB15947
	for <ips-archive@odin.ietf.org>; Sun, 19 Aug 2001 15:41:51 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7JIN0D01888
	for ips-outgoing; Sun, 19 Aug 2001 14:23:00 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7JIMwe01884
	for <ips@ece.cmu.edu>; Sun, 19 Aug 2001 14:22:58 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id UAA165476
	for <ips@ece.cmu.edu>; Sun, 19 Aug 2001 20:22:51 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7JIMjY145312
	for <ips@ece.cmu.edu>; Sun, 19 Aug 2001 20:22:50 +0200
Importance: Normal
Subject: Re: iSCSI: [Fwd: Crc-32c example in iSCSI spec]
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFDBCB783C.7D4A6F23-ONC2256AAD.0061B750@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Sun, 19 Aug 2001 21:22:19 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 19/08/2001 21:22:50
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Here are some clarifications about how the CRC is to be calculated (Network
byte order etc.),
the assumptions on data flow, the value of the CRC register for a good
segment and a corrected set of examples:

The Appendix A part will read:

   The following table lists cyclic integrity checksums that can be
   negotiated for the digests and MUST be implemented by every iSCSI
   initiator and target. Note that these digest options have only error
   detection significance.

   +---------------------------------------------+
   | Name          | Description     | Generator |
   +---------------------------------------------+
   | crc-32C       | 32 bit CRC      | 11EDC6F41 |
   +---------------------------------------------+
   | none          | no digest                   |
   +---------------------------------------------+

   The generator polynomial for this digest is given in hex-notation, for
   example 3b stands for 0011 1011 - the polynomial x**5+X**4+x**3+x+1.

   The generator polynomial selected is evaluated in [Castagnioli93].
   When using the CRC the CRC register must be initialized to all 1s
   (0xFFFFFFFF) and the CRC bits must be complemented before transmission.
   Padding bytes, when present, in a segment covered by a CRC, should be
   set to 0 and are included in the CRC. The CRC should be calculated as
   follows:

      - data are assumed to be  in the numbering order that appears in the
      draft - start with byte 0 bit 0 continue byte 1 bit 0 etc. (Big
      Endian on bytes / Little Endian on bits)
      - the CRC register is initialized with all 1s (equivalent to
      complementing the first 32 bits of the message)
      - the n PDU bits are considered coefficients of a polynomial M(x) of
      order n-1, with bit 0 of byte 0 being x^(n-1)
      - the polynomial is multiplied by x^32 and divided by G(x)- the
      generator polynomial - producing a remainder R(x) of degree <= 31
      - the coefficients of R(x) are considered a 32 bit sequence
      - the bit sequence is complemented and the result is the CRC
      - after the last bit of the original segment the CRC bits are
      transmitted with x^31 first followed by x^30 etc. ( whenever examples
      are given the value to be specified in examples follows the same
      rules of representation as the rest of this document)
      - a receiver of a "good" segment (data or header) built using the
      generator 0x11EDC6F41 will end-up having in the CRC register the
      value 0x1c2d19ed (this a register value and not a word as outlined in
      this draft)


CRC Examples will read:

01   CRC Examples

   N.B. all Values are Hexadecimal

   32 bytes of zeroes:

     Byte:        0  1  2  3

        0:       00 00 00 00
      ...
       28:       00 00 00 00

      CRC:       aa 36 91 8a

   32 bytes of ones:

     Byte:        0  1  2  3

        0:       ff ff ff ff
      ...
       28:       ff ff ff ff

      CRC:       43 ab a8 62

   32 bytes of incrementing 00..1f:

     Byte:        0  1  2  3

        0:       00 01 02 03
      ...
       28:       1c 1d 1e 1f

      CRC:       4e 79 dd 46

   32 bytes of decrementing ff..e0:

     Byte:        0  1  2  3

        0:       ff fe fd fc
      ...
       28:       e3 e2 e1 e0

      CRC:       5c db 3f 11




From owner-ips@ece.cmu.edu  Mon Aug 20 11:25:09 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23828
	for <ips-archive@odin.ietf.org>; Mon, 20 Aug 2001 11:25:08 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7KDSn219503
	for ips-outgoing; Mon, 20 Aug 2001 09:28:49 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mxic1.isus.emc.com ([168.159.129.100])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7KDSme19498
	for <ips@ece.cmu.edu>; Mon, 20 Aug 2001 09:28:48 -0400 (EDT)
Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <QQ9C3YML>; Mon, 20 Aug 2001 09:30:47 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD606@CORPMX14>
From: Black_David@emc.com
To: ips@ece.cmu.edu
Subject: FW: I-D ACTION:draft-black-ips-iscsi-security-01.txt
Date: Mon, 20 Aug 2001 09:22:53 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C1297B.3777D140"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C1297B.3777D140
Content-Type: text/plain;
	charset="iso-8859-1"

Important reminder:

   This draft is unlikely to become an RFC in its current form; its 
   primary purpose is to capture a set of ideas as a basis for further 
   discussions.  Portions of this draft may be incorporated into other 
   drafts that are intended to become RFCs.  Caution should be 
   exercised in drawing inferences from the fact that the author of 
   this draft is one of the chairs of the IP Storage WG.  This draft is 
   an individual submission that the IP Storage WG is free to adopt, 
   modify, reject, fold, spindle, and/or mutilate as it sees fit. 

Changes from -00 Version:
    
   Added statement that there is no requirement to keep authentication 
   identities confidential. 
    
   Removed discussion of IKE text from authentication requirements 
   section to remove any implication that IKE is required.  Added short 
   discussion of multiple authentications and pointer to L2TP security 
   draft. 
    
   Updated confidentiality section to indicate that confidentiality is 
   now "MUST implement" but "OPTIONAL to use". 
    
   Added note that starting ESP on an active TCP connection will not 
   work correctly when TCP port translation is in use. 
    
   Added statement that SAs used with the proposed key management are 
   tightly bound to iSCSI TCP connections and hence not reusable to key 
   management description.

--David

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
Sent: Monday, August 20, 2001 7:07 AM
Subject: I-D ACTION:draft-black-ips-iscsi-security-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.


	Title		: iSCSI Security Requirements and SRP-based ESP Keys
	Author(s)	: D. Black
	Filename	: draft-black-ips-iscsi-security-01.txt
	Pages		: 16
	Date		: 17-Aug-01
	
This draft describes security requirements, status of security
specification, operating environment characteristics, and related
considerations for iSCSI. It also outlines an SRP-based [RFC-2945]
mechanism to derive ESP [RFC-2406] keying material and associated
rekeying mechanisms.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-black-ips-iscsi-security-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-black-ips-iscsi-security-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-black-ips-iscsi-security-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


------_=_NextPart_000_01C1297B.3777D140
Content-Type: message/rfc822

To: 
Subject: 
Date: Mon, 20 Aug 2001 09:30:47 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_002_01C1297B.3777D140"


------_=_NextPart_002_01C1297B.3777D140
Content-Type: text/plain



------_=_NextPart_002_01C1297B.3777D140
Content-Type: application/octet-stream;
	name="ATT32332"
Content-Disposition: attachment;
	filename="ATT32332"

Content-type: message/external-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010817120218.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-black-ips-iscsi-security-01.txt

------_=_NextPart_002_01C1297B.3777D140
Content-Type: message/external-body;
	site="internet-drafts";
	dir="draft-black-ips-iscsi-security-01.txt";
	mode="ftp.ietf.org";
	access-type="anon-ftp"


------_=_NextPart_002_01C1297B.3777D140--

------_=_NextPart_000_01C1297B.3777D140--


From owner-ips@ece.cmu.edu  Mon Aug 20 13:55:28 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28545
	for <ips-archive@odin.ietf.org>; Mon, 20 Aug 2001 13:55:27 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7KEsHr22902
	for ips-outgoing; Mon, 20 Aug 2001 10:54:17 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7KEsAe22894
	for <ips@ece.cmu.edu>; Mon, 20 Aug 2001 10:54:10 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id QAB207432
	for <ips@ece.cmu.edu>; Mon, 20 Aug 2001 16:53:12 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7KErCs21112
	for <ips@ece.cmu.edu>; Mon, 20 Aug 2001 16:53:12 +0200
Importance: Normal
Subject: Re: iSCSI: [Fwd: Crc-32c example in iSCSI spec]
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFBE828163.3548C843-ONC2256AAE.00500DA8@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Mon, 20 Aug 2001 17:52:05 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 20/08/2001 17:53:11
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Mark,

I appologize - since I built the examples I just transcribed the results
and the data from two different runs.
They value used are 1f to 0 and not ff to e0.

Julo

Mark Bakke <mbakke@cisco.com>@cisco.com on 20-08-2001 17:03:50

Please respond to Mark Bakke <mbakke@cisco.com>

Sent by:  mbakke@cisco.com


To:   Julian Satran/Haifa/IBM@IBMIL
cc:
Subject:  Re: iSCSI: [Fwd: Crc-32c example in iSCSI spec]



Julian-

I have to run out for a while, so I'll look at the rest of the
message later today.  I noticed that you've added a new example,
but when I run it through my generator I get a different CRC.

Julian Satran wrote:

>    32 bytes of decrementing ff..e0:
>
>      Byte:        0  1  2  3
>
>         0:       ff fe fd fc
>       ...
>        28:       e3 e2 e1 e0
>
>       CRC:       5c db 3f 11

I get   CRC:       a7 e4 e4 ae

--
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054





From owner-ips@ece.cmu.edu  Mon Aug 20 18:00:29 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05362
	for <ips-archive@odin.ietf.org>; Mon, 20 Aug 2001 18:00:29 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7KIEja05109
	for ips-outgoing; Mon, 20 Aug 2001 14:14:45 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from clyde.stargateip.com ([209.237.5.66])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7KIEce05102
	for <ips@ece.cmu.edu>; Mon, 20 Aug 2001 14:14:38 -0400 (EDT)
Received: from bluestar (dhcp-101.stargateip.com [10.10.5.101])
	by clyde.stargateip.com (8.9.1/8.9.1) with SMTP id LAA29118;
	Mon, 20 Aug 2001 11:08:23 -0700 (PDT)
Reply-To: <deva@stargateip.com>
From: "Dev" <deva@stargateip.com>
To: "Julian Satran" <Julian_Satran@il.ibm.com>,
        "Ips \(E-mail\)" <ips@ece.cmu.edu>
Subject: iSCSI:Data Recovery from digest errors ...
Date: Mon, 20 Aug 2001 11:18:59 -0700
Message-ID: <NFBBKBDFJCDMGCBKJLCJCECJFDAA.deva@stargateip.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Importance: Normal
In-Reply-To: <OF633F936E.C6D51EFD-ONC2256AAB.0076DFA9@telaviv.ibm.com>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Julian,

I dont know if this has been already discussed. If so forgive me and point
me to the link please.

In Section 7.4, in draft 7 (page 115)it is stated that the target may
request retransmission
with a R2T. It then goes on to say that non-data PDU. It does not talk about
unsolicited data PDUs, explicitly.
I presume that data digest errors in unsolicited and immediate data PDUs
cannot be retried and should be responded
with delivery-subsystem failure. Is this correct? If so, why is this
requirement ?

In section 7.11.1, page 119, the spec. implies that digest errors in data
PDUs may be recovered by issuing R2T. Once again,
it fails to talk about digest errors in immediate data unsolicited data
PDUs.

Thanks

Deva
Platys communications



-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Julian Satran
Sent: Friday, August 17, 2001 3:23 PM
To: Mark Bakke
Cc: Douglas Otis; Sanjay Goyal; Ips (E-mail)
Subject: Re: iSCSI: [Fwd: Crc-32c example in iSCSI spec]



Mark & all,

The 2 "additions" you will find in the CRC calculation:

   initializing the "remainder" field with all ones (instead of the implied
   shifting in of 0's) and
   XORing the result with a mask (usually "full house")


are done to improve the error correction capabilities of CRCs.
CRCs are weak in detecting the spurious addition of leading 0s (that can
result from clocking errors) and the deletion of initial 1 with spurious
insertion of a 1 at the end.

Julo

Mark Bakke <mbakke@cisco.com>@ece.cmu.edu on 17-08-2001 23:10:22

Please respond to Mark Bakke <mbakke@cisco.com>

Sent by:  owner-ips@ece.cmu.edu


To:   Douglas Otis <dotis@sanlight.net>
cc:   Sanjay Goyal <sanjay_goyal@ivivity.com>, "Ips (E-mail)"
      <ips@ece.cmu.edu>
Subject:  Re: iSCSI: [Fwd: Crc-32c example in iSCSI spec]



OK.  I don't see any reason for sending the CRC inverted either
(we would just have a different remainder poly), but since Ethernet
does it that way, and it doesn't cost anything, we might as well
do it, too.

--
Mark

Douglas Otis wrote:
>
> Mark,
>
> The reason for the bit swap within the table is to allow a serial
hardware
> scheme as CRC is processed ms to ls over the entire stream as if a single
> number.  Ethernet sends the byte out least significant bit first.  The
> entire table is also swapped ls to ms and actually reduces the operations
> needed within the table calculations.  This reflects the method used for
> Ethernet as it is being stored inverted and the initial value is started
as
> all ones.  The reason for the initial value being set to all ones is
clear
> for leading zero interaction, but I do not understand the value in
storing
> the CRC inverted.  I thought to include my ignorance to the mix.
>
> Doug
>
> > Sanjay Goyal wrote:
> > >
> > > Hi
> > >  I get the remainder for iSCSI as 0x1c2d19ed if I complement my
> > CRC and then
> > > pass it through the CRC engine.
> > >
> > >  As per CRC generation for data: the thing which is not clear to me
is
> > >    why do we need to bit-swap the CRC reminader as is done in all
your
> > > examples.
> >
> > As far as I can tell, bit-swapping does nothing to help or hurt
> > the effectiveness of the CRC.  When I ran my examples, I thought
> > that it would be the simplest for our CRC to different from the
> > Ethernet CRC only in the polynomial.  Ethernet, FDDI, FC, and SCSI
> > all do this, so I figured it would cause the least confusion if
> > we did the same.
> >
> > > We can just complement it and append it after the DATA bytes.
> > >  The other side also can just pass it through the CRC engine to
> > check it.
> > >
> > > Regards
> > > Sanjay Goyal
> > >
> > > -----Original Message-----
> > > From: Mark Bakke [mailto:mbakke@cisco.com]
> > > Sent: Thursday, August 16, 2001 1:43 PM
> > > To: Steve Blightman; ips@ece.cmu.edu
> > > Subject: Re: [Fwd: Crc-32c example in iSCSI spec]
> > >
> > > One more thing that might be helpful.  When the Ethernet
> > > polynomial is used in SCSI to generate its CRC, the T10
> > > doc specifies the remainder polynomial that one should see
> > > after running the data with a valid CRC through.  For
> > > the Ethernet CRC, this was specified as 0xc704dd7b.  This
> > > remainder polynomial is taken before the CRC is complemented
> > > and bit-reflected.  For iSCSI, I came up with a remainder of
> > > 0x1c2d19ed.  Can anyone verify this result?
> > >
> > > --
> > > Mark
> > >
> > > Mark Bakke wrote:
> > > >
> > > > Steve-
> > > >
> > > > I just ran some Ethernet packets with known CRCs through
> > > > my iSCSI/Ethernet CRC generator, and found the same thing
> > > > as you did.
> > > >
> > > > All of my examples need to be byte-swapped, along with the
> > > > fix I already posted for the all-ones example.  Here is a
> > > > new set of examples, which will be in -08.  I also ran
> > > > 64 bytes of zeroes and ones, which now agree with your
> > > > numbers as well.
> > > >
> > > > Thanks again for bringing this up.
> > > >
> > > > --
> > > > Mark
> > > >
> > > >      07 CRC Examples
> > > >
> > > >         N.B. all Values are Hexadecimal
> > > >
> > > >           Byte:        0  1  2  3
> > > >
> > > >              0:       01 a0 00 00
> > > >              4:       00 00 00 00
> > > >              8:       00 00 00 00
> > > >             12:       00 00 00 00
> > > >             16:       04 05 00 00
> > > >             20:       00 01 00 00
> > > >             24:       00 00 00 05
> > > >             28:       00 00 00 04
> > > >             32:       2a 00 00 00
> > > >             36:       00 00 00 00
> > > >             40:       80 00 00 00
> > > >             44:       00 00 00 00
> > > >
> > > >            CRC:       93 70 51 db
> > > >
> > > >         32 bytes of zeroes:
> > > >
> > > >           Byte:        0  1  2  3
> > > >
> > > >              0:       00 00 00 00
> > > >            ...
> > > >             28:       00 00 00 00
> > > >
> > > >            CRC:       aa 36 91 8a
> > > >
> > > >         32 bytes of ones:
> > > >
> > > >           Byte:        0  1  2  3
> > > >
> > > >              0:       ff ff ff ff
> > > >            ...
> > > >             28:       ff ff ff ff
> > > >
> > > >            CRC:       43 ab a8 62
> > > >
> > > >         32 bytes of incrementing 00..1f:
> > > >
> > > >           Byte:        0  1  2  3
> > > >
> > > >              0:       00 01 02 03
> > > >            ...
> > > >             28:       1c 1d 1e 1f
> > > >
> > > >            CRC:       4e 79 dd 46
> > > >
> > > >
> > > > Steve Blightman wrote:
> > > > >
> > > > > I believe the examples for the ISCSI CRC  have the wrong
endianness.
> > > > >
> > > > > As yiou suugested over the phone I ran some Ethernet frames
> > through a
> > > > > simulation. I have some difficulty running the exact simulations
you
> > > > > wanted becuase the minimum size Ethernet frame is 64 bytes.
> > > > >
> > > > > However using the Ethernet CRC polynomial,
> > > > > Running 64 bytes of 0 onto the wire, we append "36 63 8d
> > 75" onto the
> > > > > wire for the CRC - "36" goes out first.
> > > > > Running 64 bytes of all 1, we append "ba 87 61 0f" onto the
> > wire - "ba"
> > > > > goes out first.
> > > > >
> > > > > Using the same logic for the ISCSI polynomial
> > > > > Running 64 bytes of 0 I think we should append "67 eb c8 03" -
"67"
> > > > > going out first
> > > > > and running 64 bytes of all 1 we should append "66 4e cd 2f" -
"66"
> > > > > going out first
> > > > >
> > > > > And now for 32 bytes with the ISCSI polynomial
> > > > >
> > > > > Running 32 bytes of 0 we should append "aa 36 91 8a" - "aa"
> > going out
> > > > > first
> > > > > Running 32 bytes of all 1 we should append "43 ab a8 62" -
> > "43" going
> > > > > out first
> > > > >
> > > > > I don't want to get into an endless endian debate, but I
> > believe it is
> > > > > important to get the order of these bytes in the right
> > order, so that we
> > > > > can use the same hardware to check as well as to generate CRCs.
> > > > >
> > > > > Thanks for your help on this,
> > > > > Steve Blightman
> > > >
> > > > --
> > > > Mark A. Bakke
> > > > Cisco Systems
> > > > mbakke@cisco.com
> > > > 763.398.1054
> > >
> > > --
> > > Mark A. Bakke
> > > Cisco Systems
> > > mbakke@cisco.com
> > > 763.398.1054
> > >
> > >
> > ------------------------------------------------------------------
> > ----------------------------------
> > >
> > >    Part 1.2    Type: application/ms-tnef
> > >            Encoding: base64
> >
> > --
> > Mark A. Bakke
> > Cisco Systems
> > mbakke@cisco.com
> > 763.398.1054
> >

--
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054





From owner-ips@ece.cmu.edu  Mon Aug 20 18:08:17 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05529
	for <ips-archive@odin.ietf.org>; Mon, 20 Aug 2001 18:08:17 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7KJMx208567
	for ips-outgoing; Mon, 20 Aug 2001 15:22:59 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7KJMve08563
	for <ips@ece.cmu.edu>; Mon, 20 Aug 2001 15:22:57 -0400 (EDT)
Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA13263; Mon, 20 Aug 2001 15:22:50 -0400 (EDT)
Message-ID: <3B8161F2.78890D53@cisco.com>
Date: Mon, 20 Aug 2001 14:16:02 -0500
From: Mark Bakke <mbakke@cisco.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686)
X-Accept-Language: en, de
MIME-Version: 1.0
To: Julian Satran <Julian_Satran@il.ibm.com>
CC: ips@ece.cmu.edu
Subject: Re: iSCSI: [Fwd: Crc-32c example in iSCSI spec]
References: <OFBE828163.3548C843-ONC2256AAE.00500DA8@telaviv.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Julian Satran wrote:
> 
> Mark,
> 
> I appologize - since I built the examples I just transcribed the results
> and the data from two different runs.
> They value used are 1f to 0 and not ff to e0.

OK; when I use 1f..00 my CRC matches yours.

--
Mark

> 
> Julo
> 
> Mark Bakke <mbakke@cisco.com>@cisco.com on 20-08-2001 17:03:50
> 
> Please respond to Mark Bakke <mbakke@cisco.com>
> 
> Sent by:  mbakke@cisco.com
> 
> To:   Julian Satran/Haifa/IBM@IBMIL
> cc:
> Subject:  Re: iSCSI: [Fwd: Crc-32c example in iSCSI spec]
> 
> Julian-
> 
> I have to run out for a while, so I'll look at the rest of the
> message later today.  I noticed that you've added a new example,
> but when I run it through my generator I get a different CRC.
> 
> Julian Satran wrote:
> 
> >    32 bytes of decrementing ff..e0:
> >
> >      Byte:        0  1  2  3
> >
> >         0:       ff fe fd fc
> >       ...
> >        28:       e3 e2 e1 e0
> >
> >       CRC:       5c db 3f 11
> 
> I get   CRC:       a7 e4 e4 ae
> 
> --
> Mark A. Bakke
> Cisco Systems
> mbakke@cisco.com
> 763.398.1054

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054


From owner-ips@ece.cmu.edu  Mon Aug 20 20:18:17 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08158
	for <ips-archive@odin.ietf.org>; Mon, 20 Aug 2001 20:18:17 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7KNJEo21679
	for ips-outgoing; Mon, 20 Aug 2001 19:19:14 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from va2mc.ummailbox.net (va2mc.ummailbox.net [64.210.247.16])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7KNJCe21675
	for <ips@ece.cmu.edu>; Mon, 20 Aug 2001 19:19:12 -0400 (EDT)
Received: from hqmailweb.COMMSTOR.Crossroads.com (HQMailWeb.Crossroads.com [63.237.99.250:25])
	by va2mc.ummailbox.net with ESMTP id V0820-1919-533b09;
	Mon, 20 Aug 2001 23:19:07 GMT
Received: from HQMAILNODE1.COMMSTOR.Crossroads.com ([10.5.1.42]) by hqmailweb.COMMSTOR.Crossroads.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Mon, 20 Aug 2001 17:56:29 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: A Question on "Full Feature Phase" of iSCSI 07
Disposition-Notification-To: "Lee Xing" <lxing@Crossroads.com>
Date: Mon, 20 Aug 2001 17:56:29 -0500
Message-ID: <CFD808D1D39ACB47ABFF586D484CC52E341425@HQMAILNODE1.COMMSTOR.Crossroads.com>
Thread-Topic: A Question on "Full Feature Phase" of iSCSI 07
Thread-Index: AcEpy1kcxg+zjfKXSTmWLtS02gDEhA==
From: "Lee Xing" <lxing@Crossroads.com>
To: <ips@ece.cmu.edu>
X-OriginalArrivalTime: 20 Aug 2001 22:56:29.0914 (UTC) FILETIME=[5976C3A0:01C129CB]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f7KNJDe21676
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit

Hi,

On iSCSI 07 page 23 (section 1.2.5), it says "... A session is in full
feature phase after successfully finishing the login phase on the first
(leading) connection of a session. A connection is in full feature phase
if the session in full feature phase and the connection login has
completed successfully."

I assume that the above statements are not true after logging into the
default target "iSCSI", right?  If so, should we make them clearer?

Thank you.


Lee Xing
Sr. Software Engineer
Crossroads Systems, Inc.



From owner-ips@ece.cmu.edu  Mon Aug 20 21:01:49 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08598
	for <ips-archive@odin.ietf.org>; Mon, 20 Aug 2001 21:01:49 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7L091w23700
	for ips-outgoing; Mon, 20 Aug 2001 20:09:01 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from c007.snv.cp.net (c007-h011.c007.snv.cp.net [209.228.33.217])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f7L08xe23695
	for <ips@ece.cmu.edu>; Mon, 20 Aug 2001 20:08:59 -0400 (EDT)
Received: (cpmta 7722 invoked from network); 20 Aug 2001 17:08:53 -0700
Received: from adsl-63-202-160-80.dsl.snfc21.pacbell.net (HELO littlejoy) (63.202.160.80)
  by smtp.telocity.com (209.228.33.217) with SMTP; 20 Aug 2001 17:08:53 -0700
X-Sent: 21 Aug 2001 00:08:53 GMT
From: "Douglas Otis" <dotis@sanlight.net>
To: <Black_David@emc.com>, <ips@ece.cmu.edu>
Subject: RE: iSCSI: Alias consensus call
Date: Mon, 20 Aug 2001 17:07:07 -0700
Message-ID: <NEBBJGDMMLHHCIKHGBEJIEIJCKAA.dotis@sanlight.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: <277DD60FB639D511AC0400B0D068B71ECAD5FB@CORPMX14>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

David,

The human abstraction offered by an alias may be misleading and in some
cases could be best handled by a management scheme that better understands
user's perspectives and can provide clues within the name to its real
designation.  This places fewer burdens on future transports should the
alias feature be removed.  In the end, a management scheme should be more
friendly than an odd collection of labels.  Here less is more but not in
keeping with the all-in-one approach.

Doug

> Traffic on this topic has died down, so I believe that the
> rough consensus of the IPS WG is to retain support for Alias
> in the iSCSI protocol.
>
> I have seen two expressions of the opposite view:
> - Bob Snively's, which I am setting aside, as not
> 	being relevant to the topic - Bob's post
> 	concerned LU aliases rather than Initiator/
> 	Target aliases.
> - Marj Krueger's, which I take note of in making this
> 	call (i.e., the consensus call is over Marj's
> 	objection).
>
> Anyone other than Marj who wishes to object should post
> to the list.
>
> Thanks,
> --David
>
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------
>



From owner-ips@ece.cmu.edu  Mon Aug 20 21:02:37 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08611
	for <ips-archive@odin.ietf.org>; Mon, 20 Aug 2001 21:02:36 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7L0ZDd24801
	for ips-outgoing; Mon, 20 Aug 2001 20:35:13 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7L0ZCe24797
	for <ips@ece.cmu.edu>; Mon, 20 Aug 2001 20:35:12 -0400 (EDT)
Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <QSSYKD4W>; Mon, 20 Aug 2001 20:35:06 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD614@CORPMX14>
From: Black_David@emc.com
To: dotis@sanlight.net, ips@ece.cmu.edu
Subject: iSCSI: Alias consensus call FAILURE
Date: Mon, 20 Aug 2001 20:29:15 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

The attempt to call consensus on this issue on the list has failed.
At this point, I would guess that this issue will be on the agenda
for the December meeting in Salt Lake City, and we can try again
to close it there.

--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


From owner-ips@ece.cmu.edu  Mon Aug 20 22:03:17 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10233
	for <ips-archive@odin.ietf.org>; Mon, 20 Aug 2001 22:03:17 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7L1fuC27373
	for ips-outgoing; Mon, 20 Aug 2001 21:41:56 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7L1fte27369
	for <ips@ece.cmu.edu>; Mon, 20 Aug 2001 21:41:55 -0400 (EDT)
Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35])
	by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id SAA06749
	for <ips@ece.cmu.edu>; Mon, 20 Aug 2001 18:41:47 -0700 (PDT)
Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19)
	id <Q8DQ5JGN>; Mon, 20 Aug 2001 18:41:47 -0700
Message-ID: <F13508319A1CD41187DE00508BACED6A03A1DF24@cs2ex.brocade.com>
From: Jay Kidd <jkidd@Brocade.COM>
To: ips@ece.cmu.edu
Subject: remove
Date: Mon, 20 Aug 2001 18:41:46 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: owner-ips@ece.cmu.edu
Precedence: bulk






From owner-ips@ece.cmu.edu  Mon Aug 20 22:03:18 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10244
	for <ips-archive@odin.ietf.org>; Mon, 20 Aug 2001 22:03:18 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7L0xx425749
	for ips-outgoing; Mon, 20 Aug 2001 20:59:59 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from msgbas1t.cos.agilent.com (msgbas1tx.cos.agilent.com [192.6.9.34])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7L0xwe25740
	for <ips@ece.cmu.edu>; Mon, 20 Aug 2001 20:59:58 -0400 (EDT)
Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77])
	by msgbas1t.cos.agilent.com (Postfix) with ESMTP
	id CDABB190; Mon, 20 Aug 2001 18:59:56 -0600 (MDT)
Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145])
	by msgrel1.cos.agilent.com (Postfix) with SMTP
	id 5314C2D5; Mon, 20 Aug 2001 18:59:56 -0600 (MDT)
Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Mon, 20 Aug 2001 18:59:56 -0600
Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19)
	id <Q9S2D6JJ>; Mon, 20 Aug 2001 18:59:56 -0600
Message-ID: <1BEBA5E8600DD4119A50009027AF54A00781155E@axcs04.cos.agilent.com>
From: "THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>
To: Sanjay Goyal <sanjay_goyal@ivivity.com>, "'Mark Bakke'" <mbakke@cisco.com>,
        Julian Satran <julian_satran@il.ibm.com>, IPS <ips@ece.cmu.edu>
Subject: RE: iSCSI CRC: A CRC-checking example
Date: Mon, 20 Aug 2001 18:59:48 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Sanjay,

I thought the bitswapping of the CRC was being done to match the way
Ethernet sends the CRC. Ethernet sends the bits of a packet most significant
byte first and least significant bit first. It puts the bits of the CRC into
the packet such that the CRC remainder in the serial stream goes from most
significant coefficient to least significant coefficient. Therefore, the
x^31 term goes into the LSB of the first byte and the x^0 term goes into the
MSB of the last byte. The order of bits within the bytes is swapped but the
order of the bytes is not swapped.

This would covert a CRC of 0x556c8951 into a bit swapped 0xaa36918a.

I agree that to get a constant value out of a CRC checker, the bits have to
be processed in their polynomial coefficient order regardless of the order
in which they are sent.

Pat

-----Original Message-----
From: Sanjay Goyal [mailto:sanjay_goyal@ivivity.com]
Sent: Friday, August 17, 2001 2:35 PM
To: 'Mark Bakke'; Julian Satran; IPS
Cc: Sanjay Goyal
Subject: RE: iSCSI CRC: A CRC-checking example


Hi
 For all zeros the value after complementing the CRC result is 0x556c8951.
If it is bit-swapped it becomes  0x8a9136aa.
 
 The way you will get the constant remainder 0x1c2d19ed is that you append
 0x556c8951 and not 0xaa36918a to the all-zero data bytes. The crc-check
engine would assume as if it is processing 4 more bytes. If we bit-swap the
CRC while transmitting, don't we have to again swap it at the receive side
and then pass it through the crc-check engine.

Sanjay Goyal                                  
www.ivivity.com


From owner-ips@ece.cmu.edu  Mon Aug 20 22:06:22 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10269
	for <ips-archive@odin.ietf.org>; Mon, 20 Aug 2001 22:06:21 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7L1dCc27258
	for ips-outgoing; Mon, 20 Aug 2001 21:39:12 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from ns.strahm.net (sub18-42.member.dsl-only.net [63.105.18.42])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f7L1dAe27254
	for <ips@ece.cmu.edu>; Mon, 20 Aug 2001 21:39:10 -0400 (EDT)
Received: (qmail 5853 invoked by uid 500); 21 Aug 2001 00:10:04 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
  by localhost with SMTP; 21 Aug 2001 00:10:04 -0000
Date: Mon, 20 Aug 2001 17:10:04 -0700 (PDT)
From: Bill Strahm <bill@strahm.net>
To: ips@ece.cmu.edu
cc: Black_David@emc.com
Subject: Security in iSCSI
In-Reply-To: <NEBBJGDMMLHHCIKHGBEJIEIJCKAA.dotis@sanlight.net>
Message-ID: <Pine.LNX.4.10.10108201702280.5726-100000@homegate.strahm.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

David,

I am becoming more and more concerned about the IPS security strategy the
longer I think about having to implement this into product.  The first
problem with defining a new keying standard is that an iSCSI vendor will
have to implement this keying standard, and then on a per OS bassis
attempt to push a negotiated key down into the IPsec layer to handle the
correct iSCSI traffic.  Many of these interfaces will be difficult to
find, if they are available at all...

I want to propose that our security story cover
1) Defining a security policy that can be used to cover iSCSI traffic
2) Allowing end users to use this security policy with their OSes current
IPsec stacks (on both the client and target end), or integrating an IPsec
stack into products
3) Allowing the IPsec WG cover all aspects of algorithm selection, key
negotiating, encapsulation, etc. that are needed

This will allow the IPS working group do what we do best, and allow the
IPsec WG to do what they do best, and lead to interoperating products the
fastest

Bill Strahm
Sanera Systems Inc.




From owner-ips@ece.cmu.edu  Tue Aug 21 00:24:16 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12863
	for <ips-archive@odin.ietf.org>; Tue, 21 Aug 2001 00:24:15 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7L3YO001622
	for ips-outgoing; Mon, 20 Aug 2001 23:34:24 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7KJm4e09761
	for <ips@ece.cmu.edu>; Mon, 20 Aug 2001 15:48:05 -0400 (EDT)
Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35])
	by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id MAA08305;
	Mon, 20 Aug 2001 12:47:52 -0700 (PDT)
Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19)
	id <Q8DQ5A0J>; Mon, 20 Aug 2001 12:47:51 -0700
Message-ID: <FFD40DB4943CD411876500508BAD027902993749@sj5-ex2.brocade.com>
From: Robert Snively <rsnively@Brocade.COM>
To: "'Black_David@emc.com'" <Black_David@emc.com>, ips@ece.cmu.edu
Subject: RE: iSCSI: Alias consensus call
Date: Mon, 20 Aug 2001 12:47:51 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Well, of course I had not thought it totally irrelevant, or
else I would not have posted it :-)

What is irrelevant is the concept of an initiator or target
alias.  The SCSI architecture explicitly allows more than one 
target to provide porting to a given logical unit.  The ultimate
target of a SCSI command is a logical unit, so there is no 
necessity to have architected familiar names for the 
simple path/session/target-initiator pair that gets you to the logical unit.
Those names can be and should be provided
if necessary by higher level mechanisms outside the scope 
of the iSCSI document set, as Marjorie indicates.  Count me 
on her side.

Bob

-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Saturday, August 18, 2001 12:09 PM
To: ips@ece.cmu.edu
Subject: iSCSI: Alias consensus call


Traffic on this topic has died down, so I believe that the
rough consensus of the IPS WG is to retain support for Alias
in the iSCSI protocol.

I have seen two expressions of the opposite view:
- Bob Snively's, which I am setting aside, as not
	being relevant to the topic - Bob's post
	concerned LU aliases rather than Initiator/
	Target aliases.
- Marj Krueger's, which I take note of in making this
	call (i.e., the consensus call is over Marj's
	objection).

Anyone other than Marj who wishes to object should post
to the list.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


From owner-ips@ece.cmu.edu  Tue Aug 21 00:26:07 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13369
	for <ips-archive@odin.ietf.org>; Tue, 21 Aug 2001 00:26:06 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7L3Z8601655
	for ips-outgoing; Mon, 20 Aug 2001 23:35:08 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7KLPBe16730
	for <ips@ece.cmu.edu>; Mon, 20 Aug 2001 17:25:11 -0400 (EDT)
Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35])
	by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id OAA16647;
	Mon, 20 Aug 2001 14:24:42 -0700 (PDT)
Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19)
	id <Q8DQ5DNY>; Mon, 20 Aug 2001 14:24:41 -0700
Message-ID: <FFD40DB4943CD411876500508BAD02790299374D@sj5-ex2.brocade.com>
From: Robert Snively <rsnively@Brocade.COM>
To: "'Mark S. Edwards'" <marke@muttsnuts.com>, ips@ece.cmu.edu
Subject: RE: iSCSI: Support Alias in the protocol
Date: Mon, 20 Aug 2001 14:24:40 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Folks,

I remain concerned about this called consensus.  Clearly there
will be thousands of Targets and Initiators running around
a network.  Creating a set of human useable aliases
that will distinguish all these seems to me somewhat farfetched.
We don't even do very well on kings.  George, George II, etc.

To create aliases in the context of a single management environment
makes some sense, but again, that should be outside the 
scope of iSCSI.

That we call our car Skeezix (human useable, for management
purposes within the tightly constrained context of our own
family) is non-architected information.  Whenever anyone cares 
which car it is (including during servicing and upgrades) they 
use the VIN, a registered and architected non-human-readable value.

If Marjorie and I are the only voices in the woods, we have
clearly had the consensus called against us, but this is high
on my list of things that really aren't much help to anyone
and shouldn't be in the document.

Bob

> >Let me also acknowledge as valid Marj's opinion that anything of
> >this sort belongs in a management tool rather than the protocol.
> 
> But it only works if everyone uses the same management tool, 
> or the tools agree upon the location and storage format of the 
> information 
> --  Somebody dig me up from my grave when Tivoli and 
> OpenView merge.
> 
> As a way of easily identifying virtual LUN's or LU's within a 
> Target Space of potential hundreds or thousands the alias 
> is very valuable.


From owner-ips@ece.cmu.edu  Tue Aug 21 00:27:19 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13382
	for <ips-archive@odin.ietf.org>; Tue, 21 Aug 2001 00:27:19 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7L3Xpb01592
	for ips-outgoing; Mon, 20 Aug 2001 23:33:51 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7KJRde08798
	for <ips@ece.cmu.edu>; Mon, 20 Aug 2001 15:27:39 -0400 (EDT)
Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35])
	by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id MAA06899;
	Mon, 20 Aug 2001 12:27:25 -0700 (PDT)
Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19)
	id <Q8DQ5AS8>; Mon, 20 Aug 2001 12:27:24 -0700
Message-ID: <FFD40DB4943CD411876500508BAD027902993748@sj5-ex2.brocade.com>
From: Robert Snively <rsnively@Brocade.COM>
To: "'Mark Bakke'" <mbakke@cisco.com>,
        Kaladhar Voruganti
	 <kaladhar@us.ibm.com>, IPS <ips@ece.cmu.edu>
Subject: RE: iSCSI NDT: Nameprep additions
Date: Mon, 20 Aug 2001 12:27:24 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Mark,

Why did we want to prohibit a properly normalized 
white-space character?  I have
always felt that spaces are useful supplements to readability,
especially for symbolic character sets.

Bob

-----Original Message-----
From: Mark Bakke [mailto:mbakke@cisco.com]
Sent: Thursday, August 16, 2001 2:20 PM
To: Kaladhar Voruganti; IPS
Subject: iSCSI NDT: Nameprep additions



Kaladhar-

Here are some modifications to make to the NDT doc to
add nameprep.  For now, these changes will assume that
nameprep will become an RFC before we do; if this is
a problem, we will do some more cut-and-paste later.

--
Mark


Replace:

    3. iSCSI names must be transcribable by humans.  iSCSI names should  
       be kept as simple as possible, and should not use more than a  
       few special characters.  They must also be case-insensitive, and  
       cannot include white space.   

With:

    3. iSCSI names must be transcribable by humans.  iSCSI names should  
       be kept as simple as possible, and should not use more than a  
       few special characters.  They must provide for the use of
       international character sets, and must not allow the use of
       different names that would be identical except for their case.
       Whitespace characters must not be allowed.

Replace:

   The iSCSI Name may be displayed by user interfaces, but is generally  
   uninterpreted and used as an opaque, case-sensitive string for  
   comparison with other iSCSI Name values.

With:  

   The iSCSI Name may be displayed by user interfaces, but is generally  
   uninterpreted and used as an opaque string for comparison with other
   iSCSI Name values.   
 
Replace:


   An iSCSI name can be any Unicode character string with the following  
   properties:   
     
    - it is in Normalization Form C (see Unicode Standard Annex #15,  
       "Unicode Normalization Forms" at  
       http://www.unicode.org/unicode/reports/15)   
      
    - it contains only the ASCII dash character ('-'=U+002d) or the   
    ASCII dot character ('.'=U+002e) or is in one of the following   
    Unicode General Categories:   
     
             a) Lu (Letter, Uppercase)   
             b) Ll (Letter, Lowercase)   
             c) Lt (Letter, Titlecase)   
             d) Lm (Letter, Modifier)   
             e) Lo (Letter, Other)   
             f) Nd (Number, Decimal Digit)   
             g) Nl (Number, Letter)   
     
             h) No (Number, Other)   
         
    - when encoded in UTF-8, it is no more than 255 bytes   
     
   In particular, white space, punctuation (except as noted), marks and  
   symbols are not allowed. 



With:

   An iSCSI name can be any Unicode character string with the following  
   properties:   
     
    - it is in Normalization Form C (see Unicode Standard Annex #15,  
       "Unicode Normalization Forms" at  
       http://www.unicode.org/unicode/reports/15)   

    - it contains only the following types of characters:

         - ASCII dash character ('-'=U+002d)  
         - ASCII dot character ('.'=U+002e)
         - Any character allowed by the output of the nameprep
           process

    - when encoded in UTF-8, it is no more than 255 bytes   

   The output of the nameprep process is described in [NAMEPREP].  Nameprep
   is a method designed by the Internationalized Domain Name (IDN) working
   group to translate human-typed strings into a format that can be compared
   as opaque strings, and does not include punctuation, spacing, dicritical
   marks, or other characters that could get in the way of transcribability.
   It also converts everything into its equivalent of lower case.

   Note that in most cases, the nameprep process does not need to be
   implemented:

   - If the names are just generated using lower-case (in any
     character set) plus digits, no normalization is required.

   - If the names are generated from some other all-ASCII string,
     tolower() normalizes and isalnum() verifies.

   - If the names are generated from more general, internationalized
     text, either the equivalent of tolower() and isalnum() appropriate
     to the character set may be used, or the full nameprep procedure
     can be used.


From owner-ips@ece.cmu.edu  Tue Aug 21 00:27:35 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13393
	for <ips-archive@odin.ietf.org>; Tue, 21 Aug 2001 00:27:35 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7L3VSM01458
	for ips-outgoing; Mon, 20 Aug 2001 23:31:28 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7KB8fe15510
	for <ips@ece.cmu.edu>; Mon, 20 Aug 2001 07:08:42 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10780;
	Mon, 20 Aug 2001 07:07:25 -0400 (EDT)
Message-Id: <200108201107.HAA10780@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ips@ece.cmu.edu
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ips-ifcp-04.txt
Date: Mon, 20 Aug 2001 07:07:25 -0400
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Storage Working Group of the IETF.

	Title		: iFCP - A Protocol for Internet Fibre Channel Storage 
                          Networking
	Author(s)	: C. Monia et al.
	Filename	: draft-ietf-ips-ifcp-04.txt
	Pages		: 84
	Date		: 17-Aug-01
	
This document specifies an architecture and gateway-to-gateway
protocol for the implementation of Fibre Channel fabric
functionality on a network in which TCP/IP switching and routing
elements replace Fibre Channel components. The protocol enables the
attachment of existing Fibre Channel storage products to an IP
network by supporting the fabric services required by such devices.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ips-ifcp-04.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ips-ifcp-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ips-ifcp-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010817141625.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ips-ifcp-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ips-ifcp-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010817141625.I-D@ietf.org>

--OtherAccess--

--NextPart--



From owner-ips@ece.cmu.edu  Tue Aug 21 01:25:42 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16308
	for <ips-archive@odin.ietf.org>; Tue, 21 Aug 2001 01:25:42 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7L4GgV03277
	for ips-outgoing; Tue, 21 Aug 2001 00:16:42 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from c007.snv.cp.net (c007-h000.c007.snv.cp.net [209.228.33.206])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f7L4Gfe03273
	for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 00:16:41 -0400 (EDT)
Received: (cpmta 25022 invoked from network); 20 Aug 2001 21:16:34 -0700
Received: from adsl-63-202-160-80.dsl.snfc21.pacbell.net (HELO littlejoy) (63.202.160.80)
  by smtp.telocity.com (209.228.33.206) with SMTP; 20 Aug 2001 21:16:34 -0700
X-Sent: 21 Aug 2001 04:16:34 GMT
From: "Douglas Otis" <dotis@sanlight.net>
To: "THALER,PAT \(A-Roseville,ex1\)" <pat_thaler@agilent.com>,
        "Sanjay Goyal" <sanjay_goyal@ivivity.com>,
        "'Mark Bakke'" <mbakke@cisco.com>,
        "Julian Satran" <julian_satran@il.ibm.com>, "IPS" <ips@ece.cmu.edu>
Subject: RE: iSCSI CRC: A CRC-checking example
Date: Mon, 20 Aug 2001 21:14:50 -0700
Message-ID: <NEBBJGDMMLHHCIKHGBEJMEIMCKAA.dotis@sanlight.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A00781155E@axcs04.cos.agilent.com>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Pat,

As the lookup table is reflected, meaning that bit 0 becomes bit 31, bit 1
becomes 30 etc, the order of these bytes are actually reversed.  You wish to
keep the bits reversed within the byte as that is how they will be sent, but
the byte order out of the table lookup has the least significant byte in the
most significant location.  This reversed byte order must be accommodated,
but no accommodation is required of the bits thanks to the reflected table.
In the case of an Intel architecture, this reversed order allows direct
placement into big endian order using the little endian CPU.  Just as
shifting bits for the table was helped by the bit order of the process, so
too is the byte placement in this case.

Doug

> Sanjay,
>
> I thought the bitswapping of the CRC was being done to match the way
> Ethernet sends the CRC. Ethernet sends the bits of a packet most
> significant
> byte first and least significant bit first. It puts the bits of
> the CRC into
> the packet such that the CRC remainder in the serial stream goes from most
> significant coefficient to least significant coefficient. Therefore, the
> x^31 term goes into the LSB of the first byte and the x^0 term
> goes into the
> MSB of the last byte. The order of bits within the bytes is
> swapped but the
> order of the bytes is not swapped.
>
> This would covert a CRC of 0x556c8951 into a bit swapped 0xaa36918a.
>
> I agree that to get a constant value out of a CRC checker, the
> bits have to
> be processed in their polynomial coefficient order regardless of the order
> in which they are sent.
>
> Pat
>
> -----Original Message-----
> From: Sanjay Goyal [mailto:sanjay_goyal@ivivity.com]
> Sent: Friday, August 17, 2001 2:35 PM
> To: 'Mark Bakke'; Julian Satran; IPS
> Cc: Sanjay Goyal
> Subject: RE: iSCSI CRC: A CRC-checking example
>
>
> Hi
>  For all zeros the value after complementing the CRC result is 0x556c8951.
> If it is bit-swapped it becomes  0x8a9136aa.
>
>  The way you will get the constant remainder 0x1c2d19ed is that you append
>  0x556c8951 and not 0xaa36918a to the all-zero data bytes. The crc-check
> engine would assume as if it is processing 4 more bytes. If we
> bit-swap the
> CRC while transmitting, don't we have to again swap it at the receive side
> and then pass it through the crc-check engine.
>
> Sanjay Goyal
> www.ivivity.com
>



From owner-ips@ece.cmu.edu  Tue Aug 21 02:54:42 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01145
	for <ips-archive@odin.ietf.org>; Tue, 21 Aug 2001 02:54:42 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7L5gmt06519
	for ips-outgoing; Tue, 21 Aug 2001 01:42:48 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7L5gke06514
	for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 01:42:46 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id HAA210722
	for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 07:42:40 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7L5gdA40046
	for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 07:42:39 +0200
Importance: Normal
Subject: Re: iSCSI: Alias consensus call FAILURE
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF5950A131.E9A9D7D3-ONC2256AAF.001EB4F7@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Tue, 21 Aug 2001 08:42:12 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 21/08/2001 08:42:39
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


David,

Did you see something on the list that none of us did?  Are objections not
meant to be public too?
I was under the impression that even the proponents of Alias where not so
hot on it as to make it
a major issue and the opponent was only Marjorie (and I agree with all her
arguments).
I was under the impression that if your question would have been -  "decide
or postpone" you would have had a majority for decide even if the decision
would have been abandon it!

Julo

Black_David@emc.com@ece.cmu.edu on 21-08-2001 03:29:15

Please respond to Black_David@emc.com

Sent by:  owner-ips@ece.cmu.edu


To:   dotis@sanlight.net, ips@ece.cmu.edu
cc:
Subject:  iSCSI: Alias consensus call FAILURE



The attempt to call consensus on this issue on the list has failed.
At this point, I would guess that this issue will be on the agenda
for the December meeting in Salt Lake City, and we can try again
to close it there.

--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------





From owner-ips@ece.cmu.edu  Tue Aug 21 06:29:58 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03760
	for <ips-archive@odin.ietf.org>; Tue, 21 Aug 2001 06:29:58 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7L9Ixn13613
	for ips-outgoing; Tue, 21 Aug 2001 05:18:59 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7L9Ive13609
	for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 05:18:57 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id LAA142098
	for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 11:18:50 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7L9Iie89396
	for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 11:18:49 +0200
Importance: Low
Subject: RE: Application for port-number (status)
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFC753F2A1.E57B3FEF-ONC2256AAF.0033162D@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Tue, 21 Aug 2001 12:18:15 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 21/08/2001 12:18:49
MIME-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=C2256AAF0033162D8f9e8a93df938690918cC2256AAF0033162D"
Content-Disposition: inline
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

--0__=C2256AAF0033162D8f9e8a93df938690918cC2256AAF0033162D
Content-type: text/plain; charset=us-ascii


---------------------- Forwarded by Julian Satran/Haifa/IBM on 21-08-2001
12:18 ---------------------------





"IANA" <iana@icann.org> on 20-08-2001 22:47:34

Please respond to "IANA" <iana@icann.org>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:

Subject:  RE: Application for port-number (status)




Dear Julian,

We have received your application.  Requests are reviewed in
the order they are received.  Due to the number of requests we
receive, it may take up to 15 working days to process your
application.  We will contact you if further information is
needed.

Thank you,

IANA


-----Original Message-----
From: Julian_Satran@il.ibm.com [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, August 16, 2001 9:17 AM
To: iana@iana.org; Julian_Satran@il.ibm.com
Subject: Application for port-number


Application for System (Well-Known) Port Number

Name :
Julian Satran

E-mail :
Julian_Satran@il.ibm.com

Protocol Number :
TCP

Message Formats :
BasicHeader+AuxiliaryHeader+Data

Message Types :
Request/Reply

Message opcodes :
Over 20 types

Message Sequences :
request/response

Protocol functions :
Carries SCSI commands

Broadcast or Multicast used ?
no

How and what for Broadcast or Multicast is used (if used):


Description :
 draft-ietf-ips-iscsi-07.txt

Name of the port :
iSCSI Target Access

Short name of the port :
iSCSI-target



(Embedded image moved to file: pic03480.pcx) - winmail.dat


--0__=C2256AAF0033162D8f9e8a93df938690918cC2256AAF0033162D
Content-type: application/octet-stream; 
	name="pic03480.pcx"
Content-Disposition: attachment; filename="pic03480.pcx"
Content-Transfer-Encoding: base64

CgUBCAAAAAAfAB8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAABIAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAADRD8gPxA/CDw/ED88AxADFD8MPD8QPAA8IDwgPCA8IDwgPCA8IDwgPwgDF
D8IPD8QPAAgPCA8IDwgPCA8IDwgPCA8IAAgAxA/CDw/EDwAPCA8IDwgPCA8IDwgPCA8IDwDCCADE
D8IPxA8ACA8IDwgPCA8IDwgPCA8IDwgAwwgAww/CD8QPAA8IDwgPCA8IDwgPCA8IDwgPAMQIAMMP
D8QPAAgPCA8IDwgPCA8IDwgPCA8IxgAAwg8PxA8ADwgPCA8IDwgPCA8IDwgPCA8IDwgPCA8Awg8P
xA8ACA8IDwgPCA8IDwgPCA8IDwgPCA8IDwgAwg8PxA8ADwgPCA8IDwgPCA8IDwgPCA8IDwgPCA8A
wg8PxA8ACA8IDwgPCA8IDwgPCA8IDwgPCA8IDwgAwg8PxA8ADwgPCA8IDwgPCA8IDwgPCA8IDwgP
CA8Awg8PxA8ACA8IDwgPCA8IDwgPCA8IDwgPCA8IDwgAwg8PxA8ADwgPCA8IDwgPCA8IDwgPCA8I
DwgPCA8Awg8PxA8ACA8IDwgPCA8IDwgPCA8IDwgPCA8IDwgAwg8PxA8ADwgPCA8IDwgPCA8IDwgP
CA8IDwgPCA8Awg8PxA8ACA8IDwgPCA8IDwgPCA8IDwgPCA8IDwgAwg8PxA8ADwgPCA8IDwgPCA8I
DwgPCA8IDwgPCA8Awg8PxA8ACA8IDwgPCA8IDwgPCA8IDwgPCA8IDwgAwg8PxA8ADwgPCA8IDwgP
CA8IDwgPCA8IDwgPCA8Awg8PxA8ACA8IDwgPCA8IDwgPCA8IDwgPCA8IDwgAwg8PxA8ADwgPCA8I
DwgPCA8IDwgPCA8IDwgPCA8Awg8PxA8ACA8IDwgPCA8IDwgPCA8IDwgPCA8IDwgAwg8PxA8ADwgP
CA8IDwgPCA8IDwgPCA8IDwgPCA8Awg8PxA8ACA8IDwgPCA8IDwgPCA8IDwgPCA8IDwgAwg8PxA8A
DwgPCA8IDwgPCA8IDwgPCA8IDwgPCA8Awg8PxA8ACA8IDwgPCA8IDwgPCA8IDwgPCA8IDwgAwg8P
xA8ADwgPCA8IDwgPCA8IDwgPCA8IDwgPCA8Awg8PxA8ACA8IDwgPCA8IDwgPCA8IDwgPCA8IDwgA
wg8PxA/PAMcAwwDCDw/RD8gPxA/CDw8MAAAAgAAAAIAAgIAAAACAgACAAICAgICAwMDA/wAAAP8A
//8AAAD//wD/AP//////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

--0__=C2256AAF0033162D8f9e8a93df938690918cC2256AAF0033162D--



From owner-ips@ece.cmu.edu  Tue Aug 21 09:21:46 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11084
	for <ips-archive@odin.ietf.org>; Tue, 21 Aug 2001 09:21:46 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7LCBhZ29977
	for ips-outgoing; Tue, 21 Aug 2001 08:11:43 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from exch-connector.netcomsystems.com (mushroom.netcomsystems.com [12.9.24.195])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7LCBfe29971
	for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 08:11:41 -0400 (EDT)
Received: by exch-connector.netcomsystems.com with Internet Mail Service (5.5.2653.19)
	id <QK9ZM864>; Tue, 21 Aug 2001 05:11:35 -0700
Message-ID: <9384475DFC05D2118F9C00805F6F263106DDB7BD@exchange1.netcomsystems.com>
From: "Cunningham, Howard" <Howard.Cunningham@spirentcom.com>
To: "'Bill Strahm'" <bill@strahm.net>, ips@ece.cmu.edu
Cc: Black_David@emc.com
Subject: RE: Security in iSCSI
Date: Tue, 21 Aug 2001 05:11:33 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C12A3A.6B252230"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C12A3A.6B252230
Content-Type: text/plain;
	charset="iso-8859-1"

I have been trying to follow the evolving story on authentication, digests,
SRP and ESP for a few weeks.  In light of darft 07 and David's recent
offering, draft-black-ips-iscsi-security-01.txt, I need to ask some
questions to help me clarify some of the implications for an implementation.

Some items I had taken as true:
1. Draft 7, section 2.2 has optional, separate header and data digest areas
and says that this separation is useful for routing applications.
2. Draft 7 indicates that there must be mandatory support for CRC-32c for
both header and data. Presumably this would imply one use of a 32 bit header
and data digest to carry the CRC32. Draft 7 states that "Implementations MAY
also negotiate digests with security significance for data authentication
and integrity".
3. Draft 7 Appendix A also indicates a mandatory authentication method:
"Initiator and target MUST implement SRP."
4. Draft 7 Appendix A offers some guidelines that some types of header and
data digest presume certain kinds of authentication (e.g., "KRB5_* digests
are allowed only when combined with KRB5 authentication method"). There are
no digests listed for CHAP and SRP so presumably these authentication
methods use CRC-32c or None. 

Up to this point I had been thinking that the header and data digests were
to be used for all data authentication (even cryptographic integrity). If
there was to be any data confidentiality, that would be outside of iSCSI and
probably accompanied by no header and data digest usage. Then I read in
David's paper, Section 4.3: "The current status is that ESP [RFC-2406] with
NULL encryption has been chosen as the implementation approach to meet this
requirement (Cryptographic Integrity and Data Origin Authentication), but
the Authentication Algorithm (MAC, e.g., HMAC-SHA1) has not been selected."

Questions:
1. Does SRP authentication imply ESP with NULL encryption? Of course this is
security at the IP level rather than the iSCSI layer. What about a different
header and data digest method?
2. Is there thought that the 'hash' result of SRP could be applied to the
header and the data separately using the digests in the PDU? I guess one
could envision a 'routing application' that could verify CRC32-c on the
header in order to route the PDU but not be 'trusted' to not tamper with the
data (SHA1 data digest).
3. Under what conditions are the header and data digests used?
4. I am not an IPsec expert, but I thought that one way IPsec is used is to
set up a tunnel for all traffic from one IP address to another. Is it
possible that an initiator might want an iSCSI TCP stream and an HTTP stream
to the same IP address with different levels of security? Using the iSCSI
header and data digests, this would be possible.

Thanks for your help in advance....

Howard Cunningham, Senior MTS
Spirent Communications
900 Main Campus Drive, Suite 201
Raleigh, NC 27606
Voice: +1 (919) 829-6332
Fax: +1 (919) 829-6400
Mobile: +1 (919) 345-4658
Email: howard.cunningham@spirentcom.com



-----Original Message-----
From: Bill Strahm [mailto:bill@strahm.net]
Sent: Monday, August 20, 2001 8:10 PM
To: ips@ece.cmu.edu
Cc: Black_David@emc.com
Subject: Security in iSCSI


David,

I am becoming more and more concerned about the IPS security strategy the
longer I think about having to implement this into product.  The first
problem with defining a new keying standard is that an iSCSI vendor will
have to implement this keying standard, and then on a per OS bassis
attempt to push a negotiated key down into the IPsec layer to handle the
correct iSCSI traffic.  Many of these interfaces will be difficult to
find, if they are available at all...

I want to propose that our security story cover
1) Defining a security policy that can be used to cover iSCSI traffic
2) Allowing end users to use this security policy with their OSes current
IPsec stacks (on both the client and target end), or integrating an IPsec
stack into products
3) Allowing the IPsec WG cover all aspects of algorithm selection, key
negotiating, encapsulation, etc. that are needed

This will allow the IPS working group do what we do best, and allow the
IPsec WG to do what they do best, and lead to interoperating products the
fastest

Bill Strahm
Sanera Systems Inc.


------_=_NextPart_001_01C12A3A.6B252230
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: Security in iSCSI</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I have been trying to follow the evolving story on =
authentication, digests, SRP and ESP for a few weeks.&nbsp; In light of =
darft 07 and David's recent offering, =
draft-black-ips-iscsi-security-01.txt, I need to ask some questions to =
help me clarify some of the implications for an =
implementation.</FONT></P>

<P><FONT SIZE=3D2>Some items I had taken as true:</FONT>
<BR><FONT SIZE=3D2>1. Draft 7, section 2.2 has optional, separate =
header and data digest areas and says that this separation is useful =
for routing applications.</FONT></P>

<P><FONT SIZE=3D2>2. Draft 7 indicates that there must be mandatory =
support for CRC-32c for both header and data. Presumably this would =
imply one use of a 32 bit header and data digest to carry the CRC32. =
Draft 7 states that &quot;Implementations MAY also negotiate digests =
with security significance for data authentication and =
integrity&quot;.</FONT></P>

<P><FONT SIZE=3D2>3. Draft 7 Appendix A also indicates a mandatory =
authentication method: &quot;Initiator and target MUST implement =
SRP.&quot;</FONT>
<BR><FONT SIZE=3D2>4. Draft 7 Appendix A offers some guidelines that =
some types of header and data digest presume certain kinds of =
authentication (e.g., &quot;KRB5_* digests are allowed only when =
combined with KRB5 authentication method&quot;). There are no digests =
listed for CHAP and SRP so presumably these authentication methods use =
CRC-32c or None. </FONT></P>

<P><FONT SIZE=3D2>Up to this point I had been thinking that the header =
and data digests were to be used for all data authentication (even =
cryptographic integrity). If there was to be any data confidentiality, =
that would be outside of iSCSI and probably accompanied by no header =
and data digest usage. Then I read in David's paper, Section 4.3: =
&quot;The current status is that ESP [RFC-2406] with NULL encryption =
has been chosen as the implementation approach to meet this requirement =
(Cryptographic Integrity and Data Origin Authentication), but the =
Authentication Algorithm (MAC, e.g., HMAC-SHA1) has not been =
selected.&quot;</FONT></P>

<P><FONT SIZE=3D2>Questions:</FONT>
<BR><FONT SIZE=3D2>1. Does SRP authentication imply ESP with NULL =
encryption? Of course this is security at the IP level rather than the =
iSCSI layer. What about a different header and data digest =
method?</FONT></P>

<P><FONT SIZE=3D2>2. Is there thought that the 'hash' result of SRP =
could be applied to the header and the data separately using the =
digests in the PDU? I guess one could envision a 'routing application' =
that could verify CRC32-c on the header in order to route the PDU but =
not be 'trusted' to not tamper with the data (SHA1 data =
digest).</FONT></P>

<P><FONT SIZE=3D2>3. Under what conditions are the header and data =
digests used?</FONT>
<BR><FONT SIZE=3D2>4. I am not an IPsec expert, but I thought that one =
way IPsec is used is to set up a tunnel for all traffic from one IP =
address to another. Is it possible that an initiator might want an =
iSCSI TCP stream and an HTTP stream to the same IP address with =
different levels of security? Using the iSCSI header and data digests, =
this would be possible.</FONT></P>

<P><FONT SIZE=3D2>Thanks for your help in advance....</FONT>
</P>

<P><FONT SIZE=3D2>Howard Cunningham, Senior MTS</FONT>
<BR><FONT SIZE=3D2>Spirent Communications</FONT>
<BR><FONT SIZE=3D2>900 Main Campus Drive, Suite 201</FONT>
<BR><FONT SIZE=3D2>Raleigh, NC 27606</FONT>
<BR><FONT SIZE=3D2>Voice: +1 (919) 829-6332</FONT>
<BR><FONT SIZE=3D2>Fax: +1 (919) 829-6400</FONT>
<BR><FONT SIZE=3D2>Mobile: +1 (919) 345-4658</FONT>
<BR><FONT SIZE=3D2>Email: howard.cunningham@spirentcom.com</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Bill Strahm [<A =
HREF=3D"mailto:bill@strahm.net">mailto:bill@strahm.net</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, August 20, 2001 8:10 PM</FONT>
<BR><FONT SIZE=3D2>To: ips@ece.cmu.edu</FONT>
<BR><FONT SIZE=3D2>Cc: Black_David@emc.com</FONT>
<BR><FONT SIZE=3D2>Subject: Security in iSCSI</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>David,</FONT>
</P>

<P><FONT SIZE=3D2>I am becoming more and more concerned about the IPS =
security strategy the</FONT>
<BR><FONT SIZE=3D2>longer I think about having to implement this into =
product.&nbsp; The first</FONT>
<BR><FONT SIZE=3D2>problem with defining a new keying standard is that =
an iSCSI vendor will</FONT>
<BR><FONT SIZE=3D2>have to implement this keying standard, and then on =
a per OS bassis</FONT>
<BR><FONT SIZE=3D2>attempt to push a negotiated key down into the IPsec =
layer to handle the</FONT>
<BR><FONT SIZE=3D2>correct iSCSI traffic.&nbsp; Many of these =
interfaces will be difficult to</FONT>
<BR><FONT SIZE=3D2>find, if they are available at all...</FONT>
</P>

<P><FONT SIZE=3D2>I want to propose that our security story =
cover</FONT>
<BR><FONT SIZE=3D2>1) Defining a security policy that can be used to =
cover iSCSI traffic</FONT>
<BR><FONT SIZE=3D2>2) Allowing end users to use this security policy =
with their OSes current</FONT>
<BR><FONT SIZE=3D2>IPsec stacks (on both the client and target end), or =
integrating an IPsec</FONT>
<BR><FONT SIZE=3D2>stack into products</FONT>
<BR><FONT SIZE=3D2>3) Allowing the IPsec WG cover all aspects of =
algorithm selection, key</FONT>
<BR><FONT SIZE=3D2>negotiating, encapsulation, etc. that are =
needed</FONT>
</P>

<P><FONT SIZE=3D2>This will allow the IPS working group do what we do =
best, and allow the</FONT>
<BR><FONT SIZE=3D2>IPsec WG to do what they do best, and lead to =
interoperating products the</FONT>
<BR><FONT SIZE=3D2>fastest</FONT>
</P>

<P><FONT SIZE=3D2>Bill Strahm</FONT>
<BR><FONT SIZE=3D2>Sanera Systems Inc.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C12A3A.6B252230--


From owner-ips@ece.cmu.edu  Tue Aug 21 10:24:33 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15735
	for <ips-archive@odin.ietf.org>; Tue, 21 Aug 2001 10:24:32 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7LDUdG03442
	for ips-outgoing; Tue, 21 Aug 2001 09:30:39 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7LDUce03438
	for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 09:30:38 -0400 (EDT)
Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <QSSYLHJR>; Tue, 21 Aug 2001 09:30:32 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD617@CORPMX14>
From: Black_David@emc.com
To: Julian_Satran@il.ibm.com, ips@ece.cmu.edu
Subject: RE: iSCSI: Alias consensus call FAILURE
Date: Tue, 21 Aug 2001 09:24:40 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Julian,

> Did you see something on the list that none of us did?  Are objections not
> meant to be public too?

All the objections are public.  Marj Krueger, Bob Snively
and Doug Otis have all objected to the inclusion of Alias,
and have all made essentially the same technical argument.
Between that and the significant prior traffic on the list
supporting the inclusion of Alias, the only reasonable
conclusion is that I do not see rough consensus on the list.

About all I can do in this case is postpone - if this
causes people to rethink their positions, that is
definitely an intended consequence.

--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


From owner-ips@ece.cmu.edu  Tue Aug 21 10:24:46 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15779
	for <ips-archive@odin.ietf.org>; Tue, 21 Aug 2001 10:24:46 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7LDRsI03319
	for ips-outgoing; Tue, 21 Aug 2001 09:27:54 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mxic1.isus.emc.com ([168.159.129.100])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7LDRre03315
	for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 09:27:53 -0400 (EDT)
Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <QQ9CQ3J2>; Tue, 21 Aug 2001 09:29:53 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD615@CORPMX14>
From: Black_David@emc.com
To: ips@ece.cmu.edu
Subject: FW: I-D ACTION:draft-aboba-ips-iscsi-security-00.txt
Date: Tue, 21 Aug 2001 09:21:58 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C12A44.418236C0"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C12A44.418236C0
Content-Type: text/plain;
	charset="iso-8859-1"

FYI - this is about use of IKE and IPsec algorithm selection
considerations.  --David

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
Sent: Tuesday, August 21, 2001 7:25 AM
Subject: I-D ACTION:draft-aboba-ips-iscsi-security-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.


	Title		: Securing iSCSI using IPsec
	Author(s)	: B. Aboba et al.
	Filename	: draft-aboba-ips-iscsi-security-00.txt
	Pages		: 35
	Date		: 20-Aug-01
	
This document discusses how iSCSI may utilize IPsec to provide
authentication, integrity, confidentiality and replay protection.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-aboba-ips-iscsi-security-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-aboba-ips-iscsi-security-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-aboba-ips-iscsi-security-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


------_=_NextPart_000_01C12A44.418236C0
Content-Type: message/rfc822

To: 
Subject: 
Date: Tue, 21 Aug 2001 09:29:53 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_002_01C12A44.418236C0"


------_=_NextPart_002_01C12A44.418236C0
Content-Type: text/plain



------_=_NextPart_002_01C12A44.418236C0
Content-Type: application/octet-stream;
	name="ATT36560"
Content-Disposition: attachment;
	filename="ATT36560"

Content-type: message/external-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010820135713.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-aboba-ips-iscsi-security-00.txt

------_=_NextPart_002_01C12A44.418236C0
Content-Type: message/external-body;
	site="internet-drafts";
	dir="draft-aboba-ips-iscsi-security-00.txt";
	mode="ftp.ietf.org";
	access-type="anon-ftp"


------_=_NextPart_002_01C12A44.418236C0--

------_=_NextPart_000_01C12A44.418236C0--


From owner-ips@ece.cmu.edu  Tue Aug 21 10:26:49 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15910
	for <ips-archive@odin.ietf.org>; Tue, 21 Aug 2001 10:26:44 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7LDLc903028
	for ips-outgoing; Tue, 21 Aug 2001 09:21:38 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7LDLae03024
	for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 09:21:36 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id PAA20572;
	Tue, 21 Aug 2001 15:21:30 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7LDLPA138122;
	Tue, 21 Aug 2001 15:21:30 +0200
Importance: Normal
Subject: RE: Security in iSCSI
To: "Cunningham, Howard" <Howard.Cunningham@spirentcom.com>
Cc: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <OFC220A6C8.7DE7C45F-ONC2256AAF.0044775E@telaviv.ibm.com>
From: "Ofer Biran" <BIRAN@il.ibm.com>
Date: Tue, 21 Aug 2001 16:20:54 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 21/08/2001 16:21:30
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk



Howard,

Currently SRP is the mandatory (to implement) end to end authentication
method on the iSCSI level.
ESP with X authentication algorithm (X to be decided) is mandatory (to
implement) on the IP level.
The ESP (mandatory to implement) keying mechanism will be discussed in the
interim meeting. It will
either be based on the resulting SRP key (or other authentication method)
according to David's draft, or on
IKE, according to draft-aboba-ips-iscsi-security-00.txt (out soon).

The existence of the current  iSCSI level cryptographic digests will also
be discussed in the interim meeting.

Now for the specific questions:

1. Does SRP authentication imply ESP with NULL encryption? Of course this
is security at the IP level rather than the iSCSI layer. What about a
different header and data digest method?

+ ESP with NULL encryption (or ESP with X authentication) is mandatory to
implement - this is not implied by any iSCSI level authentication
+ method. Having different header and data digests as a different issue,
more important to error detection / recovery rather than security.

2. Is there thought that the 'hash' result of SRP could be applied to the
header and the data separately using the digests in the PDU? I guess one
could envision a 'routing application' that could verify CRC32-c on the
header in order to route the PDU but not be 'trusted' to not tamper with
the data (SHA1 data digest).

+ As I mentioned above, the whole issue of iSCSI level cryptographic
digests will be discussed in the interim meeting (where the first question
+ is - with mandatory ESP MACs, should they stay ?


3. Under what conditions are the header and data digests used?

+ In situations where the data still has a 'sensitive' path after the IPSec
offload, you might still want end to end CRC in addition to
+ the ESP MAC that covers only the IPSec portion.  These kind of scenarios
are discussed on both drafts mention above.

4. I am not an IPsec expert, but I thought that one way IPsec is used is to
set up a tunnel for all traffic from one IP address to another. Is it
possible that an initiator might want an iSCSI TCP stream and an HTTP
stream to the same IP address with different levels of security? Using the
iSCSI header and data digests, this would be possible.

+ Yes, it is possible by specifying different IPSec SA policy for different
TCP connections.


   Regards,
      Ofer

Ofer Biran
Storage and Systems Technology
IBM Research Lab in Haifa
biran@il.ibm.com  972-4-8296253



From owner-ips@ece.cmu.edu  Tue Aug 21 11:27:13 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20303
	for <ips-archive@odin.ietf.org>; Tue, 21 Aug 2001 11:27:13 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7LDllj04362
	for ips-outgoing; Tue, 21 Aug 2001 09:47:47 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7LDlke04358
	for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 09:47:47 -0400 (EDT)
Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <QSSYL299>; Tue, 21 Aug 2001 09:47:40 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD618@CORPMX14>
From: Black_David@emc.com
To: bill@strahm.net, ips@ece.cmu.edu
Cc: Black_David@emc.com
Subject: RE: Security in iSCSI
Date: Tue, 21 Aug 2001 09:41:45 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Bill,

> I am becoming more and more concerned about the IPS security strategy the
> longer I think about having to implement this into product.  The first
> problem with defining a new keying standard is that an iSCSI vendor will
> have to implement this keying standard, and then on a per OS bassis
> attempt to push a negotiated key down into the IPsec layer to handle the
> correct iSCSI traffic.  Many of these interfaces will be difficult to
> find, if they are available at all...

Keep in mind that the SRP keying of ESP mechanism described in
draft-black-ips-iscsi-security-01.txt is only a proposal, and use
of IKE is another proposal - see draft-aboba-ips-iscsi-security-00.txt
(announcement just forwarded to ips) as well as the text in draft-black-...
about it being an individual submission that the WG is free
to fold, spindle, mutilate, etc.  The proverbial "fix" is not in
for the SRP/ESP keying, and I have no intention of forcing the WG
to adopt it - it's on the agenda to get a fair hearing in Orange
County, and I have no problem with a "thanks, but no thanks" decision
about pursuing it.

> I want to propose that our security story cover
> 1) Defining a security policy that can be used to cover iSCSI traffic
> 2) Allowing end users to use this security policy with their OSes current
> IPsec stacks (on both the client and target end), or integrating an IPsec
> stack into products
> 3) Allowing the IPsec WG cover all aspects of algorithm selection, key
> negotiating, encapsulation, etc. that are needed

That's certainly a reasonable position to take on this topic.  The result
that approach might be:
	IKE, 3DES-CBC, HMAC-SHA1
as "MUST implement" algorithms.  I've seen pushback/objection to all
three on various grounds, hence the need to discuss all of this in
Orange County.

Any authentication (e.g., HMAC-SHA-1, AES-CBC-MAC, UMAC, PMAC) or
encryption (e.g., 3DES-CBC, AES-CBC, AES-counter) algorithm that we
choose to use will need a standards track RFC that goes through the
ipsec WG, and the ipsec WG is prepared to work on advancing such drafts
in the next few months.  I WILL NOT PERMIT such drafts to be directly
worked on here in IPS.  Keying is more problematic, as it's not clear
what the right home for something like the SRP/ESP keying mechanism
is, but OTOH, IKE is quite a bit for an implementer to swallow.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


From owner-ips@ece.cmu.edu  Tue Aug 21 11:28:06 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20330
	for <ips-archive@odin.ietf.org>; Tue, 21 Aug 2001 11:28:05 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7LESMh06519
	for ips-outgoing; Tue, 21 Aug 2001 10:28:22 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mxic1.isus.emc.com ([168.159.129.100])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7LESLe06515
	for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 10:28:21 -0400 (EDT)
Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <QQ9CQSR2>; Tue, 21 Aug 2001 10:30:20 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD619@CORPMX14>
From: Black_David@emc.com
To: ips@ece.cmu.edu
Subject: Re: Security in iSCSI
Date: Tue, 21 Aug 2001 10:22:26 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Howard,

> I have been trying to follow the evolving story on authentication,
> digests, SRP and ESP for a few weeks.  In light of draft 07 and David's
> recent offering, draft-black-ips-iscsi-security-01.txt, I need to ask
> some questions to help me clarify some of the implications for an
> implementation.

"Evolving" is definitely a good word to describe the situation.  Please
also see draft-aboba-ips-iscsi-security-00.txt.

> Some items I had taken as true: 
> 1. Draft 7, section 2.2 has optional, separate header and data digest
> areas and says that this separation is useful for routing applications.

Digests are currently CRC-only.  They no longer have any security
use/significance/importance.  The usefulness of separate header and data
digests is that they allow an iSCSI proxy to preserve the data CRCs rather
than having to regenerate CRCs covering both header and data when the header
is changed.

>  2. Draft 7 indicates that there must be mandatory support for CRC-32c
> for both header and data. Presumably this would imply one use of a 32 bit
> header and data digest to carry the CRC32.

Yes.

> Draft 7 states that "Implementations MAY also negotiate digests with
> security significance for data authentication and integrity".

That sentence and the table following it (including the Note below the
table)
are vestiges of an earlier discarded approach to security.  They will be
removed in the -08 version of the draft.  This is partly my fault for not
asking that they be removed some months ago.

> 3. Draft 7 Appendix A also indicates a mandatory authentication method:
> "Initiator and target MUST implement SRP." 

Correct.

> 4. Draft 7 Appendix A offers some guidelines that some types of header
> and data digest presume certain kinds of authentication (e.g., "KRB5_*
> digests are allowed only when combined with KRB5 authentication method").
> There are no digests listed for CHAP and SRP so presumably these
> authentication methods use CRC-32c or None. 

All of that "guideline" text sill be removed in -08.  CRC-32C is **NOT**
a useful data authentication method, - it's entirely too easy for an
adversary to tamper with the data and adjust the CRC to cover its tracks,
even in the presence of simple keying, as WEP has learned to its chagrin.
(encrypting the CRC with a block cipher [i.e., NOT RC4] would have been
better, but that would still not be real cryptographic integrity).

> Up to this point I had been thinking that the header and data digests
> were to be  used for all data authentication (even cryptographic
> integrity). If there was to be any data confidentiality, that would be
> outside of iSCSI and probably accompanied by no header and data digest
> usage.

That digest approach was discarded in Orlando in January.  The remaining
security digest descriptions will be removed from the -08 version of the
draft.  Confidentiality has become "MUST implement" as of the London IETF
meetings.

> Then I read in David's paper, Section 4.3: "The current status is that
> ESP [RFC-2406] with NULL encryption has been chosen as the implementation
> approach to meet this requirement (Cryptographic Integrity and Data Origin
> Authentication), but the Authentication Algorithm (MAC, e.g., HMAC-SHA1)
> has not been selected."

That's correct.

> 1. Does SRP authentication imply ESP with NULL encryption? Of course this
> is security at the IP level rather than the iSCSI layer. 

SRP authentication does not imply NULL encryption - step 3) in Section 6.3
of draft-black-ips-iscsi-security-01.txt describes generation of both
encryption and authentication keying material.  If IKE is used, SRP would
still be "MUST implement", and IKE generates both encryption and
authentication keying material.

> What about a different header and data digest method?

ESP is the only approach currently being pursued for standardization.
Any proposal to go back to doing inband header and data digests encounter
strong resistance, and is unlikely to meet with the IESG's approval.

> 2. Is there thought that the 'hash' result of SRP could be applied to
> the header and the data separately using the digests in the PDU? 

No, that approach to using inband security digests has been abandoned.

> 3. Under what conditions are the header and data digests used? 

When CRC protection is desired, e.g., ESP is not being used (it is
negotiable) and the TCP/IP checksums are felt to be insufficient.

> 4. I am not an IPsec expert, but I thought that one way IPsec is used
> is to set up a tunnel for all traffic from one IP address to another.

That's one way, but not the only way.  See RFC 2401.

> Is it possible that an initiator might want an iSCSI TCP stream and an
> HTTP stream to the same IP address with different levels of security?
> Using the iSCSI header and data digests, this would be possible.

Yes, it's possible, and IPsec can support this, although that level of
support is not REQUIRED by IPsec.  See Section 4.4 of RFC 2401 for a
discussion of the IPsec Security Policy Database where this functionality
would reside.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


From owner-ips@ece.cmu.edu  Tue Aug 21 12:25:51 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22779
	for <ips-archive@odin.ietf.org>; Tue, 21 Aug 2001 12:25:51 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7LF62l08557
	for ips-outgoing; Tue, 21 Aug 2001 11:06:02 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e32.bld.us.ibm.com (e32.co.us.ibm.com [32.97.110.130])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7LF60e08552
	for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 11:06:00 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e32.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA35450;
	Tue, 21 Aug 2001 11:03:49 -0400
Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7LF5wA168386;
	Tue, 21 Aug 2001 09:05:58 -0600
Importance: Normal
Subject: RE: iSCSI: Alias consensus call FAILURE
To: Black_David@emc.com
Cc: ips@ece.cmu.edu
From: "Jim Hafner" <hafner@almaden.ibm.com>
Date: Tue, 21 Aug 2001 08:05:56 -0700
Message-ID: <OF3C1488A0.41E3E174-ON88256AAF.005295F4@boulder.ibm.com>
X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at
 08/21/2001 08:05:58 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


David,

You might have missed my note on this subject amidst the flood of other
notes.

I am also opposed to Aliases for all the reasons state by others, though my
objection is not strong.  In essence, I don't think it belongs here in the
iSCSI protocol, but I also don't think it breaks anything or causes any
significant problems in interoperability, testing, performance, etc.  There
are other things I've raised issue about that fit in these categories (some
of which have been addressed, others not -- but I'll pick up on those
later).

So, count me just over the line on negative side for aliases.

Jim Hafner


Black_David@emc.com@ece.cmu.edu on 08/21/2001 06:24:40 am

Sent by:  owner-ips@ece.cmu.edu


To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: Alias consensus call FAILURE



Julian,

> Did you see something on the list that none of us did?  Are objections
not
> meant to be public too?

All the objections are public.  Marj Krueger, Bob Snively
and Doug Otis have all objected to the inclusion of Alias,
and have all made essentially the same technical argument.
Between that and the significant prior traffic on the list
supporting the inclusion of Alias, the only reasonable
conclusion is that I do not see rough consensus on the list.

About all I can do in this case is postpone - if this
causes people to rethink their positions, that is
definitely an intended consequence.

--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------





From owner-ips@ece.cmu.edu  Tue Aug 21 12:29:38 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22880
	for <ips-archive@odin.ietf.org>; Tue, 21 Aug 2001 12:29:38 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7LFcTY10427
	for ips-outgoing; Tue, 21 Aug 2001 11:38:29 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from over.ny.us.ibm.com (over.ny.us.ibm.com [32.97.182.111])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7LFcSe10421
	for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 11:38:28 -0400 (EDT)
Received: from e31.bld.us.ibm.com (e31.esmtp.ibm.com [9.14.4.129])
	by admin.ny.us.ibm.com. (8.9.3/8.9.3) with ESMTP id KAA36396
	for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 10:56:57 -0400
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA46672;
	Tue, 21 Aug 2001 10:55:33 -0400
Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7LEvbA125162;
	Tue, 21 Aug 2001 08:57:37 -0600
Importance: Normal
Subject: RE: iSCSI NDT: Nameprep additions
To: Robert Snively <rsnively@Brocade.COM>
Cc: ips@ece.cmu.edu
From: "Jim Hafner" <hafner@almaden.ibm.com>
Date: Tue, 21 Aug 2001 07:57:34 -0700
Message-ID: <OF5F9CB516.ED0EF7F8-ON88256AAF.0051AE72@boulder.ibm.com>
X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at
 08/21/2001 07:57:36 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Bob,

The short answer to this is not an extraordinarily strong argument,
however..., it was felt that these names should follow many of the rules of
domain names.  It was also felt that in many cases, the names might be
embedded in URLs (and the like).  Also, since one of the naming conventions
is derived from domain names, there didn't seem a strong reason to allow
for any extra characters.  So, the simpler the allowed set of
non-alpha-numeric characters (punctuation, whitespace, etc). the easier to
process, embed, extend, etc.

On the other hand, doesn't an "underscore" accomplish much of what a
"white-space" character does for readability?

Jim Hafner


Robert Snively <rsnively@Brocade.COM>@ece.cmu.edu on 08/20/2001 12:27:24 pm

Sent by:  owner-ips@ece.cmu.edu


To:   "'Mark Bakke'" <mbakke@cisco.com>, Kaladhar
      Voruganti/Almaden/IBM@IBMUS, IPS <ips@ece.cmu.edu>
cc:
Subject:  RE: iSCSI NDT: Nameprep additions



Mark,

Why did we want to prohibit a properly normalized
white-space character?  I have
always felt that spaces are useful supplements to readability,
especially for symbolic character sets.

Bob

-----Original Message-----
From: Mark Bakke [mailto:mbakke@cisco.com]
Sent: Thursday, August 16, 2001 2:20 PM
To: Kaladhar Voruganti; IPS
Subject: iSCSI NDT: Nameprep additions



Kaladhar-

Here are some modifications to make to the NDT doc to
add nameprep.  For now, these changes will assume that
nameprep will become an RFC before we do; if this is
a problem, we will do some more cut-and-paste later.

--
Mark


Replace:

    3. iSCSI names must be transcribable by humans.  iSCSI names should
       be kept as simple as possible, and should not use more than a
       few special characters.  They must also be case-insensitive, and
       cannot include white space.

With:

    3. iSCSI names must be transcribable by humans.  iSCSI names should
       be kept as simple as possible, and should not use more than a
       few special characters.  They must provide for the use of
       international character sets, and must not allow the use of
       different names that would be identical except for their case.
       Whitespace characters must not be allowed.

Replace:

   The iSCSI Name may be displayed by user interfaces, but is generally
   uninterpreted and used as an opaque, case-sensitive string for
   comparison with other iSCSI Name values.

With:

   The iSCSI Name may be displayed by user interfaces, but is generally
   uninterpreted and used as an opaque string for comparison with other
   iSCSI Name values.

Replace:


   An iSCSI name can be any Unicode character string with the following
   properties:

    - it is in Normalization Form C (see Unicode Standard Annex #15,
       "Unicode Normalization Forms" at
       http://www.unicode.org/unicode/reports/15)

    - it contains only the ASCII dash character ('-'=U+002d) or the
    ASCII dot character ('.'=U+002e) or is in one of the following
    Unicode General Categories:

             a) Lu (Letter, Uppercase)
             b) Ll (Letter, Lowercase)
             c) Lt (Letter, Titlecase)
             d) Lm (Letter, Modifier)
             e) Lo (Letter, Other)
             f) Nd (Number, Decimal Digit)
             g) Nl (Number, Letter)

             h) No (Number, Other)

    - when encoded in UTF-8, it is no more than 255 bytes

   In particular, white space, punctuation (except as noted), marks and
   symbols are not allowed.



With:

   An iSCSI name can be any Unicode character string with the following
   properties:

    - it is in Normalization Form C (see Unicode Standard Annex #15,
       "Unicode Normalization Forms" at
       http://www.unicode.org/unicode/reports/15)

    - it contains only the following types of characters:

         - ASCII dash character ('-'=U+002d)
         - ASCII dot character ('.'=U+002e)
         - Any character allowed by the output of the nameprep
           process

    - when encoded in UTF-8, it is no more than 255 bytes

   The output of the nameprep process is described in [NAMEPREP].  Nameprep
   is a method designed by the Internationalized Domain Name (IDN) working
   group to translate human-typed strings into a format that can be
compared
   as opaque strings, and does not include punctuation, spacing, dicritical
   marks, or other characters that could get in the way of
transcribability.
   It also converts everything into its equivalent of lower case.

   Note that in most cases, the nameprep process does not need to be
   implemented:

   - If the names are just generated using lower-case (in any
     character set) plus digits, no normalization is required.

   - If the names are generated from some other all-ASCII string,
     tolower() normalizes and isalnum() verifies.

   - If the names are generated from more general, internationalized
     text, either the equivalent of tolower() and isalnum() appropriate
     to the character set may be used, or the full nameprep procedure
     can be used.





From owner-ips@ece.cmu.edu  Tue Aug 21 12:38:52 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23280
	for <ips-archive@odin.ietf.org>; Tue, 21 Aug 2001 12:38:52 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7LGBrM12318
	for ips-outgoing; Tue, 21 Aug 2001 12:11:53 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7LGBne12313
	for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 12:11:50 -0400 (EDT)
Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA04722; Tue, 21 Aug 2001 12:11:41 -0400 (EDT)
Message-ID: <3B8286A3.3D67120A@cisco.com>
Date: Tue, 21 Aug 2001 11:04:51 -0500
From: Mark Bakke <mbakke@cisco.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686)
X-Accept-Language: en, de
MIME-Version: 1.0
To: Jim Hafner <hafner@almaden.ibm.com>
CC: Robert Snively <rsnively@Brocade.COM>, ips@ece.cmu.edu
Subject: Re: iSCSI NDT: Nameprep additions
References: <OF5F9CB516.ED0EF7F8-ON88256AAF.0051AE72@boulder.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Jim Hafner wrote:
> 
> Bob,
> 
> The short answer to this is not an extraordinarily strong argument,
> however..., it was felt that these names should follow many of the rules of
> domain names.  It was also felt that in many cases, the names might be
> embedded in URLs (and the like).  Also, since one of the naming conventions
> is derived from domain names, there didn't seem a strong reason to allow
> for any extra characters.  So, the simpler the allowed set of
> non-alpha-numeric characters (punctuation, whitespace, etc). the easier to
> process, embed, extend, etc.

I agree.  The more we following domain names, the better.

> On the other hand, doesn't an "underscore" accomplish much of what a
> "white-space" character does for readability?

The dash is the white-space substitute used in domain names and
such; underscores are not allowed.

In an iSCSI name, a dot can also be used as a separator.  Like domain
names, I would recommend using the dash to denote word or other separation
within a hierarchical component of a name, and the dot to denote separation
between different parts of a hierarchy.

> 
> Jim Hafner
> 
> Robert Snively <rsnively@Brocade.COM>@ece.cmu.edu on 08/20/2001 12:27:24 pm
> 
> Sent by:  owner-ips@ece.cmu.edu
> 
> To:   "'Mark Bakke'" <mbakke@cisco.com>, Kaladhar
>       Voruganti/Almaden/IBM@IBMUS, IPS <ips@ece.cmu.edu>
> cc:
> Subject:  RE: iSCSI NDT: Nameprep additions
> 
> Mark,
> 
> Why did we want to prohibit a properly normalized
> white-space character?  I have
> always felt that spaces are useful supplements to readability,
> especially for symbolic character sets.
> 
> Bob
> 
> -----Original Message-----
> From: Mark Bakke [mailto:mbakke@cisco.com]
> Sent: Thursday, August 16, 2001 2:20 PM
> To: Kaladhar Voruganti; IPS
> Subject: iSCSI NDT: Nameprep additions
> 
> Kaladhar-
> 
> Here are some modifications to make to the NDT doc to
> add nameprep.  For now, these changes will assume that
> nameprep will become an RFC before we do; if this is
> a problem, we will do some more cut-and-paste later.
> 
> --
> Mark
> 
> Replace:
> 
>     3. iSCSI names must be transcribable by humans.  iSCSI names should
>        be kept as simple as possible, and should not use more than a
>        few special characters.  They must also be case-insensitive, and
>        cannot include white space.
> 
> With:
> 
>     3. iSCSI names must be transcribable by humans.  iSCSI names should
>        be kept as simple as possible, and should not use more than a
>        few special characters.  They must provide for the use of
>        international character sets, and must not allow the use of
>        different names that would be identical except for their case.
>        Whitespace characters must not be allowed.
> 
> Replace:
> 
>    The iSCSI Name may be displayed by user interfaces, but is generally
>    uninterpreted and used as an opaque, case-sensitive string for
>    comparison with other iSCSI Name values.
> 
> With:
> 
>    The iSCSI Name may be displayed by user interfaces, but is generally
>    uninterpreted and used as an opaque string for comparison with other
>    iSCSI Name values.
> 
> Replace:
> 
>    An iSCSI name can be any Unicode character string with the following
>    properties:
> 
>     - it is in Normalization Form C (see Unicode Standard Annex #15,
>        "Unicode Normalization Forms" at
>        http://www.unicode.org/unicode/reports/15)
> 
>     - it contains only the ASCII dash character ('-'=U+002d) or the
>     ASCII dot character ('.'=U+002e) or is in one of the following
>     Unicode General Categories:
> 
>              a) Lu (Letter, Uppercase)
>              b) Ll (Letter, Lowercase)
>              c) Lt (Letter, Titlecase)
>              d) Lm (Letter, Modifier)
>              e) Lo (Letter, Other)
>              f) Nd (Number, Decimal Digit)
>              g) Nl (Number, Letter)
> 
>              h) No (Number, Other)
> 
>     - when encoded in UTF-8, it is no more than 255 bytes
> 
>    In particular, white space, punctuation (except as noted), marks and
>    symbols are not allowed.
> 
> With:
> 
>    An iSCSI name can be any Unicode character string with the following
>    properties:
> 
>     - it is in Normalization Form C (see Unicode Standard Annex #15,
>        "Unicode Normalization Forms" at
>        http://www.unicode.org/unicode/reports/15)
> 
>     - it contains only the following types of characters:
> 
>          - ASCII dash character ('-'=U+002d)
>          - ASCII dot character ('.'=U+002e)
>          - Any character allowed by the output of the nameprep
>            process
> 
>     - when encoded in UTF-8, it is no more than 255 bytes
> 
>    The output of the nameprep process is described in [NAMEPREP].  Nameprep
>    is a method designed by the Internationalized Domain Name (IDN) working
>    group to translate human-typed strings into a format that can be
> compared
>    as opaque strings, and does not include punctuation, spacing, dicritical
>    marks, or other characters that could get in the way of
> transcribability.
>    It also converts everything into its equivalent of lower case.
> 
>    Note that in most cases, the nameprep process does not need to be
>    implemented:
> 
>    - If the names are just generated using lower-case (in any
>      character set) plus digits, no normalization is required.
> 
>    - If the names are generated from some other all-ASCII string,
>      tolower() normalizes and isalnum() verifies.
> 
>    - If the names are generated from more general, internationalized
>      text, either the equivalent of tolower() and isalnum() appropriate
>      to the character set may be used, or the full nameprep procedure
>      can be used.

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054


From owner-ips@ece.cmu.edu  Tue Aug 21 13:13:19 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24289
	for <ips-archive@odin.ietf.org>; Tue, 21 Aug 2001 13:13:18 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7LFoX011122
	for ips-outgoing; Tue, 21 Aug 2001 11:50:33 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7LFoWe11117
	for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 11:50:32 -0400 (EDT)
Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <QSSYLW7Q>; Tue, 21 Aug 2001 11:50:27 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD620@CORPMX14>
From: Black_David@emc.com
To: hafner@almaden.ibm.com
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI NDT: Nameprep additions
Date: Tue, 21 Aug 2001 11:44:38 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

I want to second Jim's comments.  This class of i18n issues
can be like the proverbial Adventure game "maze of little twisty
passages, all different", and following as closely as we can
what the domain naming folks are doing is the easiest way to
avoid spending an extended amount of time in this quagmire.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------

> -----Original Message-----
> From: Jim Hafner [mailto:hafner@almaden.ibm.com]
> Sent: Tuesday, August 21, 2001 10:58 AM
> To: Robert Snively
> Cc: ips@ece.cmu.edu
> Subject: RE: iSCSI NDT: Nameprep additions
> 
> 
> 
> Bob,
> 
> The short answer to this is not an extraordinarily strong argument,
> however..., it was felt that these names should follow many of the rules
of
> domain names.  It was also felt that in many cases, the names might be
> embedded in URLs (and the like).  Also, since one of the naming
conventions
> is derived from domain names, there didn't seem a strong reason to allow
> for any extra characters.  So, the simpler the allowed set of
> non-alpha-numeric characters (punctuation, whitespace, etc). the easier to
> process, embed, extend, etc.
> 
> On the other hand, doesn't an "underscore" accomplish much of what a
> "white-space" character does for readability?
> 
> Jim Hafner
> 
> 
> Robert Snively <rsnively@Brocade.COM>@ece.cmu.edu on 
> 08/20/2001 12:27:24 pm
> 
> Sent by:  owner-ips@ece.cmu.edu
> 
> 
> To:   "'Mark Bakke'" <mbakke@cisco.com>, Kaladhar
>       Voruganti/Almaden/IBM@IBMUS, IPS <ips@ece.cmu.edu>
> cc:
> Subject:  RE: iSCSI NDT: Nameprep additions
> 
> 
> 
> Mark,
> 
> Why did we want to prohibit a properly normalized
> white-space character?  I have
> always felt that spaces are useful supplements to readability,
> especially for symbolic character sets.
> 
> Bob
> 
> -----Original Message-----
> From: Mark Bakke [mailto:mbakke@cisco.com]
> Sent: Thursday, August 16, 2001 2:20 PM
> To: Kaladhar Voruganti; IPS
> Subject: iSCSI NDT: Nameprep additions
> 
> 
> 
> Kaladhar-
> 
> Here are some modifications to make to the NDT doc to
> add nameprep.  For now, these changes will assume that
> nameprep will become an RFC before we do; if this is
> a problem, we will do some more cut-and-paste later.
> 
> --
> Mark
> 
> 
> Replace:
> 
>     3. iSCSI names must be transcribable by humans.  iSCSI 
> names should
>        be kept as simple as possible, and should not use more than a
>        few special characters.  They must also be 
> case-insensitive, and
>        cannot include white space.
> 
> With:
> 
>     3. iSCSI names must be transcribable by humans.  iSCSI 
> names should
>        be kept as simple as possible, and should not use more than a
>        few special characters.  They must provide for the use of
>        international character sets, and must not allow the use of
>        different names that would be identical except for their case.
>        Whitespace characters must not be allowed.
> 
> Replace:
> 
>    The iSCSI Name may be displayed by user interfaces, but is 
> generally
>    uninterpreted and used as an opaque, case-sensitive string for
>    comparison with other iSCSI Name values.
> 
> With:
> 
>    The iSCSI Name may be displayed by user interfaces, but is 
> generally
>    uninterpreted and used as an opaque string for comparison 
> with other
>    iSCSI Name values.
> 
> Replace:
> 
> 
>    An iSCSI name can be any Unicode character string with the 
> following
>    properties:
> 
>     - it is in Normalization Form C (see Unicode Standard Annex #15,
>        "Unicode Normalization Forms" at
>        http://www.unicode.org/unicode/reports/15)
> 
>     - it contains only the ASCII dash character ('-'=U+002d) or the
>     ASCII dot character ('.'=U+002e) or is in one of the following
>     Unicode General Categories:
> 
>              a) Lu (Letter, Uppercase)
>              b) Ll (Letter, Lowercase)
>              c) Lt (Letter, Titlecase)
>              d) Lm (Letter, Modifier)
>              e) Lo (Letter, Other)
>              f) Nd (Number, Decimal Digit)
>              g) Nl (Number, Letter)
> 
>              h) No (Number, Other)
> 
>     - when encoded in UTF-8, it is no more than 255 bytes
> 
>    In particular, white space, punctuation (except as noted), 
> marks and
>    symbols are not allowed.
> 
> 
> 
> With:
> 
>    An iSCSI name can be any Unicode character string with the 
> following
>    properties:
> 
>     - it is in Normalization Form C (see Unicode Standard Annex #15,
>        "Unicode Normalization Forms" at
>        http://www.unicode.org/unicode/reports/15)
> 
>     - it contains only the following types of characters:
> 
>          - ASCII dash character ('-'=U+002d)
>          - ASCII dot character ('.'=U+002e)
>          - Any character allowed by the output of the nameprep
>            process
> 
>     - when encoded in UTF-8, it is no more than 255 bytes
> 
>    The output of the nameprep process is described in 
> [NAMEPREP].  Nameprep
>    is a method designed by the Internationalized Domain Name 
> (IDN) working
>    group to translate human-typed strings into a format that can be
> compared
>    as opaque strings, and does not include punctuation, 
> spacing, dicritical
>    marks, or other characters that could get in the way of
> transcribability.
>    It also converts everything into its equivalent of lower case.
> 
>    Note that in most cases, the nameprep process does not need to be
>    implemented:
> 
>    - If the names are just generated using lower-case (in any
>      character set) plus digits, no normalization is required.
> 
>    - If the names are generated from some other all-ASCII string,
>      tolower() normalizes and isalnum() verifies.
> 
>    - If the names are generated from more general, internationalized
>      text, either the equivalent of tolower() and isalnum() 
> appropriate
>      to the character set may be used, or the full nameprep procedure
>      can be used.
> 
> 
> 


From owner-ips@ece.cmu.edu  Tue Aug 21 14:33:46 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26942
	for <ips-archive@odin.ietf.org>; Tue, 21 Aug 2001 14:33:45 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7LHWQU16900
	for ips-outgoing; Tue, 21 Aug 2001 13:32:26 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from bramg1.net.external.hp.com (bramg1.net.external.hp.com [192.6.126.73])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7LHWMe16893
	for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 13:32:23 -0400 (EDT)
Received: from quasit.br.itc.hp.com (quasit.br.itc.hp.com [15.145.8.135])
	by bramg1.net.external.hp.com (Postfix) with ESMTP
	id D007315; Tue, 21 Aug 2001 19:32:33 +0200 (METDST)
Received: from fowey.BR.ITC.HP.COM (fowey.br.itc.hp.com [15.145.8.186])
	by quasit.br.itc.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id SAA20849;
	Tue, 21 Aug 2001 18:32:12 +0100 (BST)
Received: from 15.145.8.186 by fowey.BR.ITC.HP.COM (InterScan E-Mail VirusWall NT); Tue, 21 Aug 2001 18:31:41 +0100 (GMT Daylight Time)
Received: by fowey.br.itc.hp.com with Internet Mail Service (5.5.2653.19)
	id <Q94WNM2L>; Tue, 21 Aug 2001 18:31:41 +0100
Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC101E7A831@dickens.bri.hp.com>
From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <matthew_burbridge@hp.com>
To: "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>,
        "'Julian Satran'" <Julian_Satran@il.ibm.com>
Subject: Login Proposal
Date: Tue, 21 Aug 2001 18:32:11 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C12A67.358B8A60"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C12A67.358B8A60
Content-Type: text/plain;
	charset="iso-8859-1"

The recent plugfest highlighted areas of the login procedure that could be
improved.
With this in mind, Bob Russell, Marjorie Krueger, and myself have been
working on
a proposal for the Login procedure.

Our goals were to keep it inline as much as possible with 0.7 of the
specification and
to ensure connectivity can be maintained amongst target and initiators.  I
believe we
have meet all the goals we set out to do.

I have also attached a Login Reference Model (in the form of c code) which
backs up
our proposal.  Please note that the reference model is only a reference
model and should
not be considered as, or be part of the iSCSI specification.

Cheers

Matthew Burbridge
Marjorie Krueger
Bob Russell

++++++++++++++++++++++++

The Login Proposal:

Definitions:
FBit means "I have nothing (more) to negotiate"
Request: The first occurrence of a Text Parameter from the initiator or the
target. A request 
         MUST be answered with a reply.
Reply: A Text Parameter that is a response to a Request.
Negotiation: A request followed by a response.

1.1 Actions at the Initiator

The initiator starts the login phase by sending a Login Command PDU.

The IIN MUST be present in the login command.  The SessionType MUST be
present if the
session type is Discovery, Boot or CopyManager.  It MAY be present if
SessionType=Normal.
The ITN MUST be present unless SessionType=Discovery when it is optional.
The initiator
MUST NOT send operational text parameters in the login command.  The table
below defines
the parameter present in the login command.

        SessionType        SessionType          IIN               ITN
                           Present in        Present in        Present in
                             Login?            Login?            Login?

          Normal            Optional            Yes               Yes
           Boot               Yes               Yes               Yes
        CopyManager           Yes               Yes               Yes
         Discovery            Yes               Yes             Optional

SecurityContextComplete=yes MUST NOT be present in the login command
Operational Parameters MUST NOT be present in the login command

At anytime the initiator MAY terminate the login killing the TCP connection.

If the initiator requires security negotiation it MUST send one or more
security
parameters: (AuthMethod, HeaderDigest, DataDigest) in the login command.

             Fbit     Security
                     Parameters     Description
                      Present

              0          No         Initiator has no security parameters
                                    to negotiate but has operational
parameters
                                    to negotiate.
 
              0          Yes        The initiator wants to negotiate
security.

              1          No         The initiator has no security parameters
to
                                    negotiate and no operational parameters
to
                                    negotiate.

              1         Yes         ILLEGAL.  Target must reject login
                                    (Login Status = 0200)

1.2 Actions at the Target

On receipt of the Login Command the target MUST respond according to the
rules below:

If the InitiatorName is not present the target MUST reject the login
by sending a Login Response with FBit=1 and StatusCode=0200.  Similary, if
the
SessionType is not Discovery and the TargetName is not present the target
MUST
reject the login by sending a Login Response with FBit=1 and
StatusCode=0200. It
both cases the target should kill the TCP connection after the login
response has
successfully been sent.

At anytime the target MAY terminate the login by sending a login response
with
the FBit set to 1 and a non-zero StatusCode. The target should kill the TCP
connection after the login response has successfully been sent.

If the login command contains security parameters, the target MUST enter the
security
phase of the login.  It MUST send response to those security parameters and
MAY start
negotiating security parameters if the parameters that it wants to negotiate
are not
in the Login command.  The target responses with a Text Response (F=0).

If the login command does not contain security parameters the target MUST
perform one
of the two actions below:

      a) If the target requires security negotiation to be performed, then
it MUST
         enter the security phase and MUST send a text response containing
one or
         more security parameters and F=0.

      b) If the target does not require security negotiation (and therefore
neither
         does the initiator) it MUST perform one of the actions defined by
the table
         below.

              Initiator    Target has     Action
                FBit       params to
                           negotiate

                 0            No         Send Text Response with F=1
(Initiator
                                         only wants to negotiate operational
                                         parameters).

                 0            Yes        Send Text Response with operation
params
                                         If all parameters can be sent in
                                         a single response then F=1 else F=0
                                         (Both target and initiator want to
                                         negotiate operational parameters).

                 1            No         Send Login Response with F=1.
(Neither target
                                         nor initiator want to negotiate
operational
                                         parameters).

                 1            Yes        Send Text Response. If all
parameters can be
                                         sent in a single response then F=1
else
                                         F=0 (Target only wants to negotiate
                                         operational parameters).

1.3 General Rules

If an initiator or target has text parameters (security or operational) to
negotiate
then it MUST send them at the earliest opportunity and it MUST NOT send an
empty text
command.

An initiator or target MUST respond to the a text parameter request with a
text parameter
response in the next text PDU to be sent.

Once an initiator or target has completed initiating negotiations (security
or operational)
it MUST not initiate any more of the same type (security or operational).
In other
words it can not go backwards.

Operational Parameters MUST NOT be negotiated during the security phase.
Security Parameters MUST NOT be negotiated during the operartional phase.

When a party has no more text parameters to negotiate then the FBit MUST
be set in the PDU containing the last text parameter request and all
subsequent
PDUs.  For example: if an initiator only wants to negotiate "InitialR2T=yes"
and no others, then it MUST set the FBit to 1 in the commands containing
"InitialR2T=yes".

Once the FBit has been set to 1, it MUST not be set back to 0.  Also, if
the FBit is 1 then the party MUST not instigate anymore text parameter
negotiations.  It can only respond to requests from the other party.

If FMarker=yes then SFMarkInt and RFMarkInt MUST be present in the same
Text PDU as FMarker=yes.  If FMarker=no then SHOULD NOT be present.  If they
are then the remote party MUST reply to them and echo the values sent in the
initial PDU.

1.4 Completion of Security Phase
[Authors note: This section has been extracted from v0.7 but I have made
some
clarifications to the version 0.7 spec. - Changes in CAPITALS]

          -Every party in the security negotiation MUST [Added MUST]
           indicate that it has completed building its security context
           (has all the required information) by sending the key=value pair:

            
              SecurityContextComplete=yes 
            
           The other party either offers some more SECURITY parameters or
answers 
           with the same: 
            
              SecurityContextComplete=yes 
               
               
           The party that is ready MUST [Added MUST] keep sending the 
           SecurityContextComplete=yes pair (in addition to new security 
           Parameter REPLYS if required) until the handshake is complete. 
	   Once the party has set SecurityContextComplete=yes it MUST
           not instigate anymore negotiations but it MUST respond to any
           requests from the other pary.
            
           If the initiator has been the last to complete the SECUIRTY PHASE
it 
           MUST NOT start sending operational parameters within the same 
           text command; a text response including only 
           SecurityContextComplete=yes concludes the security sub-phase. 
            
           If the target has been the last to complete the SECURITY PHASE,
the 
           initiator can start the operational parameter negotiation with 
           the next text command; the security negotiation sub-phase ends 
           with the target text response. 
            
           The SecurityContextComplete handshake MUST be performed if any 
           of negotiating parties has offered a security/integrity item 
           (even if it is not selected). 
            
           All PDUs sent after the security negotiation sub phase MUST be 
           built using the agreed security.  

This proposal removes from 0.7 of the spec:
Partial Login response: It no longer coveys any information.
OpParamReset: No longer required as operational parameters can not be
negotiated
during security phase.

Keep:
SecurityContextComplete=yes.  This is how 0.7 works.  If people disagree
then
we can vote and change it.



Matthew Burbridge
Senior Development Engineer
NIS-Bristol
Hewlett Packard
Telnet: 312 7010
E-mail: matthewb@bri.hp.com
 


------_=_NextPart_000_01C12A67.358B8A60
Content-Type: application/octet-stream;
	name="LoginReferenceModel.zip"
Content-Disposition: attachment;
	filename="LoginReferenceModel.zip"
Content-Transfer-Encoding: base64

UEsDBBQAAAAIABqRFStuCfuw4RkAAD9/AAAXAAAATG9naW5SZWZlcmVuY2VNb2RlbC5jcHDtPWtz
GzeSn+kq/wdIqcSUTcmUb/euSlplT5bomBtL1Il0nD3H5RqRoDhncoaZGUpWNvrv1914DzB8yk4+
LFOxJAzQaPQb3Rjw+fNnD/J5/Oj5c/yfxd2Tbpu9Sa/jhF3yIc940ufsLB3wse5zFhXFiN+yl7Ps
KosH15xauzyJ04yd8hs+TqcTnhSslQAYzjN6/prfjnlRsIuo/ynKBuxNMdijBxMB7uq/AdjeaLrX
Tyd6qsWYL/HR0HqjOGfTLL3OosmEswmuKmcwubPsi1GUc+w2TfNozNIh2//L7vHsevdFs7lPcNqF
PfaKj6KbOJ1l2PUqLUYCYhIXcVQARaJkQC1FlF3zgt2OeEJQ+mkyzNKk4AN2dcduogxg5GyW84wB
8YDyAzaNAFMOv+d7ehHnacHzA/3nxZgjugm0wixRgVNlMH3OzjtmPIAfz2hRfZ7ncXLN+Oc+nxZs
mGaSe/1ZFhd3J4jQ5+IknUyBW/zojuesDovonpzg7zu0mi7CSJPe3ZQf7e3tseMxCQdLce7ypDnr
RwkQCUbeFSOcGkFEGeHM+iPe/8QHe2Z9xCRCv0dku02z8eCJwGIC4oQoi5Wi4PBsh/HhMO7HKHB9
4AqLcoKDYycR8DO9+j/eLxBkkSJK8SAiWimuj4nrU+S6weLlLB4XwNAhMlX0G2TRsGDNvf9i+ZT3
TdfO9CLKJpc854XCO59Np2mGnK0nKUyQXAM1Mv7rLAau7pilptA4mIGC9Ynen4EBOB+hjgLGYmxG
XYoKIDg9GKbjcXqLdDTSQdCQpM7kBsVXs/FYs5gl/DpF2QSISnMHPRLOnD0Drc+naZILpT7uo7y0
T+mPH8Y82e3NsgQW8xOMQbEASsRAffYjv8u/kNaSLAp0WTvJi2zWx98tHXgTJ7PPB+y632e77yJY
6m4qdNlYMPfPvf50SiPfxbCM2/yAvc2FSJx12U9xPgO9P3n2rGTMbmJQV/odeJTHk3gcCeXpoNwD
kDYQMMInwDR2woYx/KjfxmAREBjwGAfnWzssT1k+Smdj0HyQswGDlSntMEz7MUlvE1TZKxABa7VS
+1gB6scms7xA5YqFcAgLhjOhktW1EctBgEATY5LQdIr0i8ZaEBczY5nP40cCve4JO3vb7ZF6G8yE
PRxLbZMYbuGYb+KkP56B4v4tLwZxujf63m7r4zJLbSADSKly42AcX1Hjwwoh61z02p3zri2SozQF
gbkdxf0RMI+zu3TGbiOQDDAxYMFhXd8M+BCtFRjOWm0bzec2Di01V1jdbTGT6tw7vvyh1fv47vi8
1/3YbZ28bV/2/llr1gCTJjsCQjNQxX34DSz0lju0dfK60z6/eNtj+7VacAB7Bb/HyXRWoDECA9Uv
JAXlund3H5KeBGvXfOjvU0Q2Jq32n6ulnB3//PHi+PL47OOb1vkPvdeszv7zP8Bg7cP/L/76V/pt
h8Fo0GWQ/Shn7ScTNo5+u9shn4GGAaksFrsVANzqtS67tf0mUbYrFRRNcUa+NQG/nM6uR7gIlEoY
Di2zCfsXe9P5oX3eYL3Wz70Gu2z9o3XSY/fs4vRt758XrUOve+9dBKtNroH0pLEN5n56SjAAZGfK
s0goLPwF3a/5oJ0A9F63d9wLAG9DhKC6CcDti4wbiG3rVwd42wLergB+nmYT7Hsa5/30hmcA5CSd
3p1FSQQ+rsFepqD196zb6nZBdkqr74+ijBGlu+9don94X+buh0ObzMLqP370r8ePapKqDMMP6FSL
k6JWe/UyLvAPAb12oV2j7kGE7oIdnOWHjCFwYtDH4jDAz1eXrVaDdd72Pl62/udtqwtcbZ+b3087
5/AYSfS2i3xWxKpAmB7XcG5CGMlQ64EkViz6XtBIEq9K+aRjT8gZsossLVKcPK/uj04AXPVNGg/A
y0eDLpnROgaieSGY8xQVpCF/hzWwnUM9DqhIw4DFEHMm/ji7M02CgcWJsPR1QWv2VFr+hvo7k+GG
N1hEJBciYl0HCuLbzpWwa4moS4xNmFoaY2QHzTJEkApEXcquFXj581katcGUFpQFsxKtLoCRhQrc
6gtJi1w0U+oJTFPDSCB7Ss1dXpSR/gG4Y1boIdkoL1o1iK2IBcwyFgjU2l3Uq4bQMtpqi1UXf5ef
Hw8GnZmNowB2YRBasEoFpZ1sCkSKsQVobbKf4I4JdlyXsJ3geZF34Uk+jPmgvszo44xvPBaicb7C
UCLACbjPa66XSrZwOVo2pHn1QJ6mLdgw1Qk12vj58nmedoYBilfrL8yHnkQAfYq/Bo2apZ49Ebet
Z+MQlrIuGwGS25sKA9AQayPfR0PxPzlcOHr4gRyBiNCOHg4pYhRP5LZUJjFyaptE/REGUGKPoyJ8
erajJxBhCvyQE5Rjn8NN5tCzaMGpSb8hpaccZ8glcdrDWXIwy0UaxpofQvkii/qfsG0SmEibn+q5
1pzKFkmI2sWKSBiPWPNQxPH0J2wQy7BKYzWS1vDgaJ2vKgP4qEHAnsVA0K24lSF+gGxBzJ1zniyG
KZbkABRNa0DrbYBhkGa9tdBToBx7Ika9g52hDkRQBUL7OYwMHz+yYyovdMnff2BHIqbcPo2K6DS+
Bit+tN3Ahtfg1HnmNB3PitEZL0bpQDScv33zBsJLMgD2RKGYxZ7rLPoMcUnCRd5FAn91FmWfeCb/
uqQ/24maulv6WzBjfPmiJxtexqex19ieTGALCqqNq5Nt+CvYszc8uS5Gau44y4uXM/inG//GZSNY
k3RWkE05i5NePAk9iD5bD+AvCBCAXckADJJBA6fsZAO9OKI1H8e437HbpblGjxjddUXazX30KorH
uE1yHlaxAVZ5DsQnysMeZJsw3m6wbXQN+POSYyZzm93P2RZs8CGQZxB9bn0R4KgPlJCtsx0hWFMM
W4d1udJyvYE27ZR6/SXZJrdlBnglCFZ/fbHj9ysXHTCFr3pBPxNByoaMF7MsAZ0H/iymMT3vge5b
poac1tkxOa3F420f7oWzerv7EaySDAUOTYvy7gJzN2vifMRTjDWcTJyEuHCs7LeHATkIJqU6HCL/
kpx0zs6Oz08PNAPKOwwFw451Pf8phqqu0mHpiOw715VRX2eD+Z2Olr5z4iSxQGATVnWMG1YVCJUN
B1eIaVlOFZQJuuRBiiyshUPXbY0O6iwotr8ekScQmFYAsSspa4IQLmYZJFDgdZhnpYTEI9S2Ojs8
RLmroeDVcgi5+iNolKPwgXjSx5KTHSkeYKuRiNblZeeSHagcWsJvqP4BoRxJoD2SQGu5qdVUVL+v
Gq5g3CeBopzXQl3MGw8BScVzKadSUAXSAmvy469BQsacRTIRrUaJ58Ftmga8hPB6yFhZJ8SpKfFR
CInershbvXS3EmkPVDiSYzXCXQm74kNMWJoC5CgakFwTeJDrfYvcIYrXavfypxEXvSUQT2QHPlaU
U4iWTDr6P1Csb5t/+fkXdGVBuuhpfUzEPOJfnIwRvQwjvAxNgFlsxxMCST3M2FNVkOqtQCMZoVEt
UHQ2FLC0xUEpDHqQ8pzMi6oKiClSE2mJWVgdCzUJj6l0SqOsONfFwArTbCSEgsAvto4EFMSjmpNk
WoJwRgazLM0ORJUHK46j6IYzC5o1FaymRFdb+DyG34s1PIQi0prdHFUQAET0DYYhGSwXdG+/SlgA
dwAgy7owCNYPES6LQYKmEdXU98SQsJ2maQLWWSaRFUXcrdF+WdiE/DudPJQrTAVxSyxgbrUfzyeY
WrE4DKE6+LxjAeYRjoiluy8jRNl334nhwWXYTwPpm7CMyqFY+TmT1VB0MmkyvrPOIsgypGPvGfOY
fTyGwAhWzrM4YjCSglAszGPBPWQgBLUZBgTn7V77uIck1+STBPYIKMZKQpXNvyCE7UXsJyUH8hxP
hIgSlVXXR4sDdMAIBrDBIwhovhmF9mqYdM5tob6AZRaJ4xi4VDxE8nfZd3UvgEhxmA+wuE7xX8/u
EVa5CkmHuJ+zAlJ3Vs/u1WrzknBVcaDBuNJ4d4sY+O+ZrAPWj7LsDkRqb08qeWXmbs7strmmX/Ef
Ya6ttcyz2Cv5ubIdcM210XDHVnuMWmSu5TI2tthm1UsGcu/4E1iGFmzdfpqCSCcofdUiXSXRiwXD
d+CwaQhKxxriOUdAKgLt7owO6ATi52Yofh7wYTQbFwIILOsfaC/xOEZEZxY8oYEQvp3QkSm5B/Am
YoFIHRaCmN+vtodWCTaxgY6W3EBvUioU+2uqxlqJUtxJBQuzqqfZcM3t9hPWrMI9rIIXyoreAh6a
jdjhob8N6wW3YeV8umU/5NJ3vydN2gpqkmb4jyjhJs13wCQh8cQQBrKRKDIEQ4CmJcFKtqoyCpRT
UIUFiEVkElDiRtqaLwmDFrlVCvL0om2bM2e3jg2LTKfbmQzpFZ6m5LT/AgUSux1JMZtEpcKMqcg0
PzdfNDXdZOLJJeIKyyvlEX4S9dL5i7LGfI0l1RxRB9tbLvX+pIu81NlSs+YHysPbZLFBgWDr4yju
klegoJtGMX/5EVc4vg5KhoylDapSlzS6zk58WcI6lDUhjSHO/J1eYP1LhQ6I+IKd3hdRg7l2YNeY
k5Ah0YH3kpDm0NDEXhUEZDYFYao3zllMkYRRUaUZCOGDyR6XEhJqSg0S/SRWG+4ER4gb/8uzlHUy
doZbAD1DJiv8MiAx1deqNIbYWYbqVeXAy1/XeSe4tKtZoQ+9hxcmtpcaMp0mxsw0+rUolxs2d7md
hK+92nCQGrQHbhXZ2rNZWe/LVveic95tHdiSrkRbOt0jOhN4WFYrogIuJZVL0RRRRzNsmOVsuplj
Aco1Jc1zNtMlMQ4lKYPmgLgRFQzfPyjoEKwvA455q8rurZKdChqt+XguSlBpl5fPSVStiry/UXtY
MseZTWa1huUwNhh5JRbrpEG1Fw9sj2wDoF5zwLq4TGvm8YD2SddpKRWA5S/uKe3cPKeV5NTaLULe
zZU7kDIMjl+YMsSMljyYPmCWsQQayFdwWFyI3nOyhS6aXqrQO/dQkS0s91uYMDT+6OvlDCtcs3p2
ArwH4UBbar2gsmDcHFM8z4q7HYSp/ja3LTQdgKPXmNx2bbkbUgfrlWfmyiII//2dbZ93tmHLvR2N
xxYI5KCXKP39d+2tneSgBeU3DAzwpSnwL9sCGoMFyjLB+k6lSlXCAJZNr4P57QuJ8TOtbH1VobSw
GEipenppBqyQOMMj4NJaKg9GepxaxnTbOXe5LC5eQJCrFSrGB3bSNlelu5wXRIU5KrfY1G9uXpao
RPiSOc+wfPVKxPKuzgh1hcG0SxMBfYTPcrULPw5QxYsOFiyE51i6VHGiShXlMoUIEIhkFEFc4Uk1
mHXP5gzD4wN0Fm3NkoWia6Bm4T7yixYv8UVZDAxyNkhFpTSJqFKa8IE4kOEmWzXVJAwTL5SqEr7d
10dW3KdObZ7yC7XanKLGnADFqSvYEZMfs3iZ/s3Dlj+R76yFPKcdeJecp/voi/nPNf2kQwfDiffN
DyYlVdM6sbUKsuC/2XOntowqkKsx5CvMCQ61v9UGxl0RuCMLWJxT3W+rym706AVxPP4kw3N/HlRD
sfEuNGmch5PoE+1d8XV3WVLcZJO6mb0OmxzLHFdYK/18ed+/U0VUMmfSuVPSXNMUCW34Md84Vdm0
asNi1Yj0mIPK3viHUwOqLPf0Vir3PF622jP/477SBmLWF6YrYldRHvfpZXrjB3a8I1ybzZ1bZzFL
+cq571OIMlI1Xz2hpljK1mDRUumYPr9oNt0OFbZoHQZ4NKeifJQ4prknAwJRnl95BpuyG70+I0gd
4yn9gKEVAu4WvYzjmndcNQAMRlaZ84ojR4scn1jEcq6vzoIoCcsVcnQWVraRM11TkWzUTo4pMxoI
NVwHp47zlOE31Ta0AtWmtJdkJJ/b72PIKsiA3pznmNbK8GoC9IK245HmVPkdWmjFwWLXyVQw6N5d
r+diFh0w1nJpBBKP3dWk4q2mGJV6pwPx9ZXuoV4ykwXyNRRqbvqkpAjVCZTq8C/A4UrFqDqJRrIb
1Jq50aFWnA1EUWnVurlGpVK0W8Q7R7RX9FOMax5HXJw4mZ82CXHIZE5E4LQg8egkTkxA9ZC5k3Lm
hAIt75W3fWk9nCOY4aQqLeyr5D3KAdnq1m0Z+/YAUV3wU2H+DA5GiFndecNup0GGg2hcypN8ASzL
hnSNWIXFgtZaKtpgSsG0fJtblXICIN7+cuzth5I9lReEIA+PvhUDXZYr86K89+2IbiEKGZf3Mbn5
LaWVruzKmb7N3Umc4VIUYyC7EUG5aSqdxgoLV+0CpzOBti95q3PVEy3YRAykzAiZQqmR+LDxEsfM
/I8rGEtfpmGdOCv4ZAptc46QPZ0WmfkD+r4QrB2kklfIHmwGVufUVbb5zhf8WIPpKzqo0xB4BE5L
otHwbtdpMLyNKVHyhEPI8A15CqDlMxIbfKQckny7ptV5Jd7eK10r5CSPpHFsARPSobgsi14Rwnvv
Mj4BN5Px8V3Z4Gl7h9PemzUDeY/UatRjJft1hrSUgi7SlKrhyS/JE78te1JeG/6CDhe4PGXpDDf5
dyyfRn2eq8fysFGcU7MEJ1MGGo5gJKCquFurUYNQIGtRelXiibtaBUScicJbsIbWTU/ojGyWoZhh
OA8r++aJuyzNDqnm6soXNd83YPLi4WN8M7l2r+lZAniIlGlfJ+h+Ua3wkrM5eIFI5HU9k5phdTez
WM8jdiXuqqGul5QQkXc2inZ5LWK9Ke7DGqR8F/7f2lkZE2kN4sVX5FgmYL76I4pVPaBPrlhH2gv8
Y++bv+9/sPXctRY120qJUXIKnVAjaVHzCgbb8RpJZCm0aU2mEKMIsKTy6ISMzuKQQIzlSJMzJapf
U2tk6cE+qaVAVr6pWwd0dtyeuwLC4cahiydgBe5VgUh2vE3ht3/yxZG4fRwUU2YWxbMpLsq8jTeL
WRypW+6iIy8mibUR0YGCB4ccPZBfbEKUNJGsTPikP5nWzbIb4eFkWMY8qYK+E9gcSAbvWzJTCjRW
e1l7zc8cIVAhBCXOZdzSF+d/cmblW0KH476CfMz5OKJjWLHMfVdWCq4kQ1qCpjZv/QhT7J9C8jot
C0W1NDiyUAsIw6aUW1r5k3CZ8isxuGQElrx9bBk7EL4UZBVTUAXBWIPKOf7EBuHZw9iEqtr2H2kW
ni2yDM6ZzC9pHMJyvLZ9+BIGovKzlOXgn2MspSJfMysuzUUgJcJSeR3WfJNiAfoaAlK+Yc3izso3
AJakRW50+a9CcmABJxSjv52uK0eeTRLWx8JHGSLLNgYsDwETSNvGT9d/+a9iC94flYW0wZ4cPVHJ
RgEHOrtAFBQEAyIrXmROb5DxIDf811k0VmdecI7pncSlgaAU6HuJiXdqpRywa4ax1ucpbMpht32g
kjwl/ZKg/VcKA8ddLM37esrnaRpmWVFlktnkimele9fiJGyfvc1haPRDIexqzxL3E25mUucxI17S
TXpUFqnXaPnEq5stK6X85hR5y4nT3u73bZE4VcPdzKlbg18idVoqzavcKappuZ5vvzxJulWGK+r1
R95VJ245f0cyIsTHYH1/hRxtxXg/SbueClbkWyx1oczDBjrjZ1UDymGaKq5L9TVGXG0k6A0//la6
8Rvbnj0z5LUTJXT3mmU03wtDgctvJQNMtwRpjRLkMTEc0Cq7iT+8G2sdGHIut569WaDr8RRi1Rue
oXYTM2U8AsRMRXwi3mXEYqBnNuUzph8unj700UKw9LXAkuEy1UkeXzrIbf2i5bbt1on80grqHspC
VoESN59XwhGPLe0OwbCuSq8EZPVZAA3vWq8Egw/N+MpzXurLJJCsOm3nZuweP/LW+KC7K08GowEd
hEhnxXXqfM8Jk1IY5XnaFyVg8yzHyzcfDifbEq15kXQ4vsUaBfUxTVNVvdHPRDw5mE0tEyDdGRU6
VLCpB1iBJsmKLGW4G3VZTnADzCN88lSAbdpKUHZPamFgifbEOUWYAC/KL0XdSkwt3OyhZFD9GBtw
as0y/ikS5ySNBXVmhFHWpfxuFP4cj8SjT7qj2IROJIgn5rT7uyhLQKTsMBiiiUgOk4O4CA4MM1TY
W3oXbgGi5gsDPDzleQk2zNKJdbJBPA8Aozv81kJCXP73sGQyNyY+CJ3UkRMbyRKEinwPLEVMfJ4W
7FU6SwYHqKu4Ld7Ff9Tr+HqdKFsh8loyhdDVNqsstuW1fhUzGCewZ/mzmME1bsL/txX82lZQiztd
g0TfuCYOVR6A2IgvV1Nvnz6orVnX4P0x5vnflnEZy2h4urJhfDAzFEhAmHM82vLluAPF9fR5fAMm
sSrTs3i+xZ9yQmODL/eoLMW4Fqc6GVC2yk738pbRyQVVXCisDwqqy3AUiNXvM15hpDg1NmfKx9Km
b839BhS9WkOg0vmD+839tr9rRowYfSklnlXVb0qZVy8zOsKMNyL6WXwxRD1/0FS+k3Bc9Ztjlkg9
LusNl/NhwsSVM9ZvE/NanNZ2lfMqWyJlaXXCmdLpNggteZXGU2e02XPxlm3nU3T3BaSG6kIrCM1x
Xs1CumwnUblZ2Dr/cWJWeST8zyRkX0o+Ns+qklTQ9xUmd8jIXH49heRdoET8wIwNMnOp73z60rws
B5h/MlaWPgEvQW9TiDovLokClhhCJ/XKvzFvD7CNc4OUsNtdZgunv4BLIP2QXFabJBsBz6Av2iQF
REWganuCQykCfh1kDSJ7nMWbFw7EjdN08yx+CXByDaSgd2TZNAVqrTmTzUP/G88ELzi16u9AW0N6
vRXlspJKdbF6rM6h4Gt7+zvUG++i68+yDO/Ocs4r4JBVZ7csTjfwFWxWhl+0uClv2eYevd3Gxm0d
8ylVp76KSP8PUEsBAhQAFAAAAAgAGpEVK24J+7DhGQAAP38AABcAAAAAAAAAAQAgALaBAAAAAExv
Z2luUmVmZXJlbmNlTW9kZWwuY3BwUEsFBgAAAAABAAEARQAAABYaAAAAAA==

------_=_NextPart_000_01C12A67.358B8A60--


From owner-ips@ece.cmu.edu  Tue Aug 21 16:04:38 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29931
	for <ips-archive@odin.ietf.org>; Tue, 21 Aug 2001 16:04:38 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7LIZGc20242
	for ips-outgoing; Tue, 21 Aug 2001 14:35:16 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from zcamail03.zca.compaq.com (zcamail03.zca.compaq.com [161.114.32.103])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7LIZEe20234
	for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 14:35:14 -0400 (EDT)
Received: by zcamail03.zca.compaq.com (Postfix, from userid 12345)
	id A0CAB11A9; Tue, 21 Aug 2001 11:34:49 -0700 (PDT)
Received: from exchou-gh02.cca.cpqcorp.net (exchou-gh02.cca.cpqcorp.net [16.110.248.202])
	by zcamail03.zca.compaq.com (Postfix) with ESMTP
	id 177671C78; Tue, 21 Aug 2001 11:34:48 -0700 (PDT)
Received: by exchou-gh02.cca.cpqcorp.net with Internet Mail Service (5.5.2652.78)
	id <RBPPYN05>; Tue, 21 Aug 2001 13:35:00 -0500
Message-ID: <31891B757C09184BBFEC5275F85D5595104DAD@cceexc18.americas.cpqcorp.net>
From: "Martin, Nick" <Nick.Martin@compaq.com>
To: "'Robert Snively'" <rsnively@Brocade.COM>,
        "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
Subject: RE: iSCSI: Support Alias in the protocol
Date: Tue, 21 Aug 2001 13:34:54 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Bob,

I agree that the iSCSI Name is analogous to the VIN number on a car.
The VIN number and the iSCSI Name are supposed to be constant for the life
of the device.
In my mind the iSCSI Alias is like the license plate tag.  If someone is
looking for your car, in the mall parking lot you don't tell them the
manufacturer assigned VIN number, you tell them the tag.  (You may also
mention the make, model, and color.)  The VIN number is used for
confirmation when required.  These are administrator assigned regionally and
duplicate numbers are not much of a problem.

Initiator Target relationships are defined by the InitiatorName and
TargetName.  The protocol does not need aliases, but I believe the
administrators do.  We need to allow administrators to assign their own tags
to devices, and I believe these should be carried within the protocol so
that no external databases are required.  When reporting a problem to an
administrator, the device alias should be reported along with the device
name.  The chances for error and confusion will be greatly reduced.  The
alias or "tag" value will be easier for humans to deal with on a daily basis
than a name field or VIN number would be.

I support Alias within the iSCSI protocol.

Thanks,
Nick
-----Original Message-----
From: Robert Snively [mailto:rsnively@Brocade.COM]
Sent: Monday, August 20, 2001 4:25 PM
To: 'Mark S. Edwards'; ips@ece.cmu.edu
Subject: RE: iSCSI: Support Alias in the protocol


Folks,

I remain concerned about this called consensus.  Clearly there
will be thousands of Targets and Initiators running around
a network.  Creating a set of human useable aliases
that will distinguish all these seems to me somewhat farfetched.
We don't even do very well on kings.  George, George II, etc.

To create aliases in the context of a single management environment
makes some sense, but again, that should be outside the 
scope of iSCSI.

That we call our car Skeezix (human useable, for management
purposes within the tightly constrained context of our own
family) is non-architected information.  Whenever anyone cares 
which car it is (including during servicing and upgrades) they 
use the VIN, a registered and architected non-human-readable value.

If Marjorie and I are the only voices in the woods, we have
clearly had the consensus called against us, but this is high
on my list of things that really aren't much help to anyone
and shouldn't be in the document.

Bob

> >Let me also acknowledge as valid Marj's opinion that anything of
> >this sort belongs in a management tool rather than the protocol.
> 
> But it only works if everyone uses the same management tool, 
> or the tools agree upon the location and storage format of the 
> information 
> --  Somebody dig me up from my grave when Tivoli and 
> OpenView merge.
> 
> As a way of easily identifying virtual LUN's or LU's within a 
> Target Space of potential hundreds or thousands the alias 
> is very valuable.


From owner-ips@ece.cmu.edu  Tue Aug 21 16:06:38 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29999
	for <ips-archive@odin.ietf.org>; Tue, 21 Aug 2001 16:06:38 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7LIxoL21498
	for ips-outgoing; Tue, 21 Aug 2001 14:59:50 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7LIxme21491
	for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 14:59:48 -0400 (EDT)
Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77])
	by msgbas2.cos.agilent.com (Postfix) with ESMTP id 309FB84F
	for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 12:59:44 -0600 (MDT)
Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143])
	by msgrel1.cos.agilent.com (Postfix) with ESMTP id 1EF57D5
	for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 12:59:44 -0600 (MDT)
Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19)
	id <Q9QCADVM>; Tue, 21 Aug 2001 12:59:43 -0600
Message-ID: <9F8400020EC5D311AF62009027C3961605F265EA@axcs09.cos.agilent.com>
From: "LEMAY,KEVIN (A-Roseville,ex1)" <kevin_lemay@agilent.com>
To: "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
Subject: RE: Login Proposal
Date: Tue, 21 Aug 2001 12:59:41 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

This is the type of clarification that is needed for login. It still allows
the flexibility of the negotiated parameters with a little more framework of
expected behavior. 

I don't like having the target use the F bit on a text response. I don't
think that it is necessary. But the more structured requirements of having
to supply ITN and IIN on login are a definite plus.

This is a move in the right direction for login.

You have my support.

Kevin

-----Original Message-----
From: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)
[mailto:matthew_burbridge@hp.com]
Sent: Tuesday, August 21, 2001 10:32 AM
To: 'ips@ece.cmu.edu'; 'Julian Satran'
Subject: Login Proposal


The recent plugfest highlighted areas of the login procedure that could be
improved.
With this in mind, Bob Russell, Marjorie Krueger, and myself have been
working on
a proposal for the Login procedure.

Our goals were to keep it inline as much as possible with 0.7 of the
specification and
to ensure connectivity can be maintained amongst target and initiators.  I
believe we
have meet all the goals we set out to do.

I have also attached a Login Reference Model (in the form of c code) which
backs up
our proposal.  Please note that the reference model is only a reference
model and should
not be considered as, or be part of the iSCSI specification.

Cheers

Matthew Burbridge
Marjorie Krueger
Bob Russell

++++++++++++++++++++++++

The Login Proposal:

Definitions:
FBit means "I have nothing (more) to negotiate"
Request: The first occurrence of a Text Parameter from the initiator or the
target. A request 
         MUST be answered with a reply.
Reply: A Text Parameter that is a response to a Request.
Negotiation: A request followed by a response.

1.1 Actions at the Initiator

The initiator starts the login phase by sending a Login Command PDU.

The IIN MUST be present in the login command.  The SessionType MUST be
present if the
session type is Discovery, Boot or CopyManager.  It MAY be present if
SessionType=Normal.
The ITN MUST be present unless SessionType=Discovery when it is optional.
The initiator
MUST NOT send operational text parameters in the login command.  The table
below defines
the parameter present in the login command.

        SessionType        SessionType          IIN               ITN
                           Present in        Present in        Present in
                             Login?            Login?            Login?

          Normal            Optional            Yes               Yes
           Boot               Yes               Yes               Yes
        CopyManager           Yes               Yes               Yes
         Discovery            Yes               Yes             Optional

SecurityContextComplete=yes MUST NOT be present in the login command
Operational Parameters MUST NOT be present in the login command

At anytime the initiator MAY terminate the login killing the TCP connection.

If the initiator requires security negotiation it MUST send one or more
security
parameters: (AuthMethod, HeaderDigest, DataDigest) in the login command.

             Fbit     Security
                     Parameters     Description
                      Present

              0          No         Initiator has no security parameters
                                    to negotiate but has operational
parameters
                                    to negotiate.
 
              0          Yes        The initiator wants to negotiate
security.

              1          No         The initiator has no security parameters
to
                                    negotiate and no operational parameters
to
                                    negotiate.

              1         Yes         ILLEGAL.  Target must reject login
                                    (Login Status = 0200)

1.2 Actions at the Target

On receipt of the Login Command the target MUST respond according to the
rules below:

If the InitiatorName is not present the target MUST reject the login
by sending a Login Response with FBit=1 and StatusCode=0200.  Similary, if
the
SessionType is not Discovery and the TargetName is not present the target
MUST
reject the login by sending a Login Response with FBit=1 and
StatusCode=0200. It
both cases the target should kill the TCP connection after the login
response has
successfully been sent.

At anytime the target MAY terminate the login by sending a login response
with
the FBit set to 1 and a non-zero StatusCode. The target should kill the TCP
connection after the login response has successfully been sent.

If the login command contains security parameters, the target MUST enter the
security
phase of the login.  It MUST send response to those security parameters and
MAY start
negotiating security parameters if the parameters that it wants to negotiate
are not
in the Login command.  The target responses with a Text Response (F=0).

If the login command does not contain security parameters the target MUST
perform one
of the two actions below:

      a) If the target requires security negotiation to be performed, then
it MUST
         enter the security phase and MUST send a text response containing
one or
         more security parameters and F=0.

      b) If the target does not require security negotiation (and therefore
neither
         does the initiator) it MUST perform one of the actions defined by
the table
         below.

              Initiator    Target has     Action
                FBit       params to
                           negotiate

                 0            No         Send Text Response with F=1
(Initiator
                                         only wants to negotiate operational
                                         parameters).

                 0            Yes        Send Text Response with operation
params
                                         If all parameters can be sent in
                                         a single response then F=1 else F=0
                                         (Both target and initiator want to
                                         negotiate operational parameters).

                 1            No         Send Login Response with F=1.
(Neither target
                                         nor initiator want to negotiate
operational
                                         parameters).

                 1            Yes        Send Text Response. If all
parameters can be
                                         sent in a single response then F=1
else
                                         F=0 (Target only wants to negotiate
                                         operational parameters).

1.3 General Rules

If an initiator or target has text parameters (security or operational) to
negotiate
then it MUST send them at the earliest opportunity and it MUST NOT send an
empty text
command.

An initiator or target MUST respond to the a text parameter request with a
text parameter
response in the next text PDU to be sent.

Once an initiator or target has completed initiating negotiations (security
or operational)
it MUST not initiate any more of the same type (security or operational).
In other
words it can not go backwards.

Operational Parameters MUST NOT be negotiated during the security phase.
Security Parameters MUST NOT be negotiated during the operartional phase.

When a party has no more text parameters to negotiate then the FBit MUST
be set in the PDU containing the last text parameter request and all
subsequent
PDUs.  For example: if an initiator only wants to negotiate "InitialR2T=yes"
and no others, then it MUST set the FBit to 1 in the commands containing
"InitialR2T=yes".

Once the FBit has been set to 1, it MUST not be set back to 0.  Also, if
the FBit is 1 then the party MUST not instigate anymore text parameter
negotiations.  It can only respond to requests from the other party.

If FMarker=yes then SFMarkInt and RFMarkInt MUST be present in the same
Text PDU as FMarker=yes.  If FMarker=no then SHOULD NOT be present.  If they
are then the remote party MUST reply to them and echo the values sent in the
initial PDU.

1.4 Completion of Security Phase
[Authors note: This section has been extracted from v0.7 but I have made
some
clarifications to the version 0.7 spec. - Changes in CAPITALS]

          -Every party in the security negotiation MUST [Added MUST]
           indicate that it has completed building its security context
           (has all the required information) by sending the key=value pair:

            
              SecurityContextComplete=yes 
            
           The other party either offers some more SECURITY parameters or
answers 
           with the same: 
            
              SecurityContextComplete=yes 
               
               
           The party that is ready MUST [Added MUST] keep sending the 
           SecurityContextComplete=yes pair (in addition to new security 
           Parameter REPLYS if required) until the handshake is complete. 
	   Once the party has set SecurityContextComplete=yes it MUST
           not instigate anymore negotiations but it MUST respond to any
           requests from the other pary.
            
           If the initiator has been the last to complete the SECUIRTY PHASE
it 
           MUST NOT start sending operational parameters within the same 
           text command; a text response including only 
           SecurityContextComplete=yes concludes the security sub-phase. 
            
           If the target has been the last to complete the SECURITY PHASE,
the 
           initiator can start the operational parameter negotiation with 
           the next text command; the security negotiation sub-phase ends 
           with the target text response. 
            
           The SecurityContextComplete handshake MUST be performed if any 
           of negotiating parties has offered a security/integrity item 
           (even if it is not selected). 
            
           All PDUs sent after the security negotiation sub phase MUST be 
           built using the agreed security.  

This proposal removes from 0.7 of the spec:
Partial Login response: It no longer coveys any information.
OpParamReset: No longer required as operational parameters can not be
negotiated
during security phase.

Keep:
SecurityContextComplete=yes.  This is how 0.7 works.  If people disagree
then
we can vote and change it.



Matthew Burbridge
Senior Development Engineer
NIS-Bristol
Hewlett Packard
Telnet: 312 7010
E-mail: matthewb@bri.hp.com
 



From owner-ips@ece.cmu.edu  Tue Aug 21 17:20:26 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01469
	for <ips-archive@odin.ietf.org>; Tue, 21 Aug 2001 17:20:26 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7LKE3H28172
	for ips-outgoing; Tue, 21 Aug 2001 16:14:03 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7LKE1e28168
	for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 16:14:01 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-68-173.cisco.com [161.44.68.173]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA08410 for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 16:13:55 -0400 (EDT)
Message-ID: <3B82C0FC.8331630F@cisco.com>
Date: Tue, 21 Aug 2001 15:13:48 -0500
From: Steve Senum <ssenum@cisco.com>
X-Mailer: Mozilla 4.73 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-ips <ips@ece.cmu.edu>
Subject: Re: iSCSI: Login Proposal
References: <0B9A57FF1D57D411B47500D0B73E5CC101E7A831@dickens.bri.hp.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Matthew/Marjorie/Bob:

Some questions on your login proposal:

1. Why the following restriction?

    SecurityContextComplete=yes MUST NOT be present
    in the login command.

I don't see the benefit in not allowing something like:

I: AuthMethod:none
   HeaderDigest:crc-32c,none
   DataDigest:crc-32c,none
   SecurityContextComplete=yes
T: AuthMethod:none
   HeaderDigest:crc-32c
   DataDigest:crc-32c
   SecurityContextComlete=yes

2. In the following:

    If the login command does not contain security parameters
    the target MUST perform one of the two actions below:

    a) If the target requires security negotiation
       to be performed, then it MUST enter the security
       phase and MUST send a text response containing
       one or more security parameters and F=0.

    b)

Is this really needed?  Why not simply require the
initiator to offer security parameters if it supports them?
I would hope authentication would become the typical case
for login.

3. Is there only one Login Reponse then (just asking)?

Regards,
Steve Senum


From owner-ips@ece.cmu.edu  Tue Aug 21 18:14:20 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02546
	for <ips-archive@odin.ietf.org>; Tue, 21 Aug 2001 18:14:19 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7LLVX002297
	for ips-outgoing; Tue, 21 Aug 2001 17:31:33 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7LLVUe02292
	for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 17:31:30 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-68-173.cisco.com [161.44.68.173]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA02644 for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 17:31:24 -0400 (EDT)
Message-ID: <3B82D324.F53CF988@cisco.com>
Date: Tue, 21 Aug 2001 16:31:16 -0500
From: Steve Senum <ssenum@cisco.com>
X-Mailer: Mozilla 4.73 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-ips <ips@ece.cmu.edu>
Subject: Re: iSCSI: Login Proposal
References: <638EC1B28663D211AC3E00A0C96B78A8086ABB39@orsmsx40.jf.intel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Stephen,

The current draft (-07) does actually answer your
question, though it is somewhat buried:

On page 22:

        In "list" negotiation, the offering party sends for each key a list 
        of values (which may include "none") in its order of preference. 
         
        The responding party answers with the first value from the list it 
        supports and is allowed to use for the specific initiator. 

And on page 100:

          -The initiator sends a text command with an ordered list of the 
           options it supports for each subject (authentication algorithm, 
           iSCSI parameters and so on). The options are listed in the 
           initiator's order of preference.  

           -The target MUST reply with the first option in the list it 
           supports and is allowed for the specific initiator....

Even so, I don't see the value in:

AuthMethod=none,CHAP

Since every implementation must support "none", "CHAP"
will never get picked.

In the interest of keeping login processing as simple as
possible, I would simply require the initiator to offer
what it can support (if anything).  The target can then
pick a compatiable method, or reject the connection.

Steve Senum

"Wheat, Stephen R" wrote:
> 
> Good questions, Steve.
> 
> Question 2 caused me to ponder the concept of key-value preferences.  I.e.,
> I suspect that the concept in the proposed login spec was to address that
> the initiator may prefer to not have any security digests, but might be able
> to negotiate them if the target insisted.
> 
> I cannot find anywhere in the I-D that states that a recipient MUST consider
> key=v1,v2,v3 as the sender having preference of v1 over v2, and v2 over v3.
> Thus, I second Q2, but only if key values are to be interpreted in
> preferential order.  Thus, an initiator could send
> "DataDigest=none,crc32-c,SPKM", and the target's response MUST honor the
> preference order.
> 
> So, Q4 is: should the values in a key-value list be consider the sender's
> preference order that the receiver must honor?
> 
> Stephen
> 
> -----Original Message-----
> From: Steve Senum [mailto:ssenum@cisco.com]
> Sent: Tuesday, August 21, 2001 1:14 PM
> To: ietf-ips
> Subject: Re: iSCSI: Login Proposal
> 
> Matthew/Marjorie/Bob:
> 
> Some questions on your login proposal:
> 
> 1. Why the following restriction?
> 
>     SecurityContextComplete=yes MUST NOT be present
>     in the login command.
> 
> I don't see the benefit in not allowing something like:
> 
> I: AuthMethod:none
>    HeaderDigest:crc-32c,none
>    DataDigest:crc-32c,none
>    SecurityContextComplete=yes
> T: AuthMethod:none
>    HeaderDigest:crc-32c
>    DataDigest:crc-32c
>    SecurityContextComlete=yes
> 
> 2. In the following:
> 
>     If the login command does not contain security parameters
>     the target MUST perform one of the two actions below:
> 
>     a) If the target requires security negotiation
>        to be performed, then it MUST enter the security
>        phase and MUST send a text response containing
>        one or more security parameters and F=0.
> 
>     b)
> 
> Is this really needed?  Why not simply require the
> initiator to offer security parameters if it supports them?
> I would hope authentication would become the typical case
> for login.
> 
> 3. Is there only one Login Reponse then (just asking)?
> 
> Regards,
> Steve Senum


From owner-ips@ece.cmu.edu  Tue Aug 21 18:15:26 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02574
	for <ips-archive@odin.ietf.org>; Tue, 21 Aug 2001 18:15:26 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7LLBYA01280
	for ips-outgoing; Tue, 21 Aug 2001 17:11:35 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from baucis.sc.intel.com (ns3.intel.com [143.183.152.22])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7LLBXe01275
	for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 17:11:33 -0400 (EDT)
Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203])
	by baucis.sc.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id VAA07050;
	Tue, 21 Aug 2001 21:11:20 GMT
Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.203
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Tue, 21 Aug 2001 21:11:19 0000 (GMT)
Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <RLP21CXM>; Tue, 21 Aug 2001 14:11:18 -0700
Message-ID: <638EC1B28663D211AC3E00A0C96B78A8086ABB39@orsmsx40.jf.intel.com>
From: "Wheat, Stephen R" <stephen.r.wheat@intel.com>
To: "'Steve Senum'" <ssenum@cisco.com>, ietf-ips <ips@ece.cmu.edu>
Subject: RE: iSCSI: Login Proposal
Date: Tue, 21 Aug 2001 14:11:06 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Good questions, Steve.

Question 2 caused me to ponder the concept of key-value preferences.  I.e.,
I suspect that the concept in the proposed login spec was to address that
the initiator may prefer to not have any security digests, but might be able
to negotiate them if the target insisted.

I cannot find anywhere in the I-D that states that a recipient MUST consider
key=v1,v2,v3 as the sender having preference of v1 over v2, and v2 over v3.
Thus, I second Q2, but only if key values are to be interpreted in
preferential order.  Thus, an initiator could send
"DataDigest=none,crc32-c,SPKM", and the target's response MUST honor the
preference order.

So, Q4 is: should the values in a key-value list be consider the sender's
preference order that the receiver must honor?

Stephen

-----Original Message-----
From: Steve Senum [mailto:ssenum@cisco.com]
Sent: Tuesday, August 21, 2001 1:14 PM
To: ietf-ips
Subject: Re: iSCSI: Login Proposal


Matthew/Marjorie/Bob:

Some questions on your login proposal:

1. Why the following restriction?

    SecurityContextComplete=yes MUST NOT be present
    in the login command.

I don't see the benefit in not allowing something like:

I: AuthMethod:none
   HeaderDigest:crc-32c,none
   DataDigest:crc-32c,none
   SecurityContextComplete=yes
T: AuthMethod:none
   HeaderDigest:crc-32c
   DataDigest:crc-32c
   SecurityContextComlete=yes

2. In the following:

    If the login command does not contain security parameters
    the target MUST perform one of the two actions below:

    a) If the target requires security negotiation
       to be performed, then it MUST enter the security
       phase and MUST send a text response containing
       one or more security parameters and F=0.

    b)

Is this really needed?  Why not simply require the
initiator to offer security parameters if it supports them?
I would hope authentication would become the typical case
for login.

3. Is there only one Login Reponse then (just asking)?

Regards,
Steve Senum



From owner-ips@ece.cmu.edu  Tue Aug 21 19:17:22 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03203
	for <ips-archive@odin.ietf.org>; Tue, 21 Aug 2001 19:17:21 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7LMUXh05289
	for ips-outgoing; Tue, 21 Aug 2001 18:30:33 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7LMUVe05282
	for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 18:30:31 -0400 (EDT)
Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id WAA03209
	for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 22:30:30 GMT
Received: from fmsmsx19.fm.intel.com ([132.233.48.19])
 by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001082115291724653
 ; Tue, 21 Aug 2001 15:29:17 -0700
Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <RJ8VCBJG>; Tue, 21 Aug 2001 15:30:29 -0700
Message-ID: <638EC1B28663D211AC3E00A0C96B78A8086ABB3B@orsmsx40.jf.intel.com>
From: "Wheat, Stephen R" <stephen.r.wheat@intel.com>
To: "'Steve Senum'" <ssenum@cisco.com>, ietf-ips <ips@ece.cmu.edu>
Subject: RE: iSCSI: Login Proposal
Date: Tue, 21 Aug 2001 15:30:27 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Yup, I thought I had seen it, but couldn't find it; thanks.  And am now
embarrassed that I couldn't find it, when it was indeed documented in two
places.  I'll save related comments for when we go through the spec clean-up
phase.

So, the second paragraph you cite from both p22 and p100 imply that a target
could avoid selecting "none".  Thus, the initiator could prefer "none", but
the target still select another initiator-offered value, hence avoiding the
situation you propose, where "none" is always selected.

Yes?

Otherwise, how would a target and initiator be able to select "none", in the
presence of the ability to mutually do at least one method?

Aren't there times where either could do all protocols, but both would
*prefer* to do "none"??

Perhaps my question then is to get Para5 of 1.2.4 on p22 slightly clarified,
so as to avoid your conclusion.  I.e., the initiator should be allowed to
prefer "none" over something else, yet have the target be capable of not
selecting "none".

Again, I agree with you that the new-and-improved-login proposal would be
even better with a requirement to have the initiator include its security
parameters, even if they consist of only "none".

Stephen

-----Original Message-----
From: Steve Senum [mailto:ssenum@cisco.com]
Sent: Tuesday, August 21, 2001 2:31 PM
To: ietf-ips
Subject: Re: iSCSI: Login Proposal


Hi Stephen,

The current draft (-07) does actually answer your
question, though it is somewhat buried:

On page 22:

        In "list" negotiation, the offering party sends for each key a list 
        of values (which may include "none") in its order of preference. 
         
        The responding party answers with the first value from the list it 
        supports and is allowed to use for the specific initiator. 

And on page 100:

          -The initiator sends a text command with an ordered list of the 
           options it supports for each subject (authentication algorithm, 
           iSCSI parameters and so on). The options are listed in the 
           initiator's order of preference.  

           -The target MUST reply with the first option in the list it 
           supports and is allowed for the specific initiator....

Even so, I don't see the value in:

AuthMethod=none,CHAP

Since every implementation must support "none", "CHAP"
will never get picked.

In the interest of keeping login processing as simple as
possible, I would simply require the initiator to offer
what it can support (if anything).  The target can then
pick a compatiable method, or reject the connection.

Steve Senum

"Wheat, Stephen R" wrote:
> 
> Good questions, Steve.
> 
> Question 2 caused me to ponder the concept of key-value preferences.
I.e.,
> I suspect that the concept in the proposed login spec was to address that
> the initiator may prefer to not have any security digests, but might be
able
> to negotiate them if the target insisted.
> 
> I cannot find anywhere in the I-D that states that a recipient MUST
consider
> key=v1,v2,v3 as the sender having preference of v1 over v2, and v2 over
v3.
> Thus, I second Q2, but only if key values are to be interpreted in
> preferential order.  Thus, an initiator could send
> "DataDigest=none,crc32-c,SPKM", and the target's response MUST honor the
> preference order.
> 
> So, Q4 is: should the values in a key-value list be consider the sender's
> preference order that the receiver must honor?
> 
> Stephen
> 
> -----Original Message-----
> From: Steve Senum [mailto:ssenum@cisco.com]
> Sent: Tuesday, August 21, 2001 1:14 PM
> To: ietf-ips
> Subject: Re: iSCSI: Login Proposal
> 
> Matthew/Marjorie/Bob:
> 
> Some questions on your login proposal:
> 
> 1. Why the following restriction?
> 
>     SecurityContextComplete=yes MUST NOT be present
>     in the login command.
> 
> I don't see the benefit in not allowing something like:
> 
> I: AuthMethod:none
>    HeaderDigest:crc-32c,none
>    DataDigest:crc-32c,none
>    SecurityContextComplete=yes
> T: AuthMethod:none
>    HeaderDigest:crc-32c
>    DataDigest:crc-32c
>    SecurityContextComlete=yes
> 
> 2. In the following:
> 
>     If the login command does not contain security parameters
>     the target MUST perform one of the two actions below:
> 
>     a) If the target requires security negotiation
>        to be performed, then it MUST enter the security
>        phase and MUST send a text response containing
>        one or more security parameters and F=0.
> 
>     b)
> 
> Is this really needed?  Why not simply require the
> initiator to offer security parameters if it supports them?
> I would hope authentication would become the typical case
> for login.
> 
> 3. Is there only one Login Reponse then (just asking)?
> 
> Regards,
> Steve Senum


From owner-ips@ece.cmu.edu  Tue Aug 21 19:19:14 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAB03226
	for <ips-archive@odin.ietf.org>; Tue, 21 Aug 2001 19:19:14 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7LM5on04017
	for ips-outgoing; Tue, 21 Aug 2001 18:05:50 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7LM5me04012
	for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 18:05:48 -0400 (EDT)
Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100])
	by palrel1.hp.com (Postfix) with ESMTP
	id 8957A1524; Tue, 21 Aug 2001 15:05:47 -0700 (PDT)
Received: (from cbm@localhost) by core.rose.hp.com (8.8.6 (PHNE_14041)/8.8.6 SMKit7.02) id PAA14745; Tue, 21 Aug 2001 15:07:04 -0700 (PDT)
Message-Id: <200108212207.PAA14745@core.rose.hp.com>
Subject: Re: iSCSI:Data Recovery from digest errors ...
To: deva@stargateip.com
Date: Tue, 21 Aug 2001 15:07:04 PDT
Cc: ips@ece.cmu.edu
In-Reply-To: <NFBBKBDFJCDMGCBKJLCJCECJFDAA.deva@stargateip.com>; from "Dev" at Aug 20, 101 1:12 pm
Reply-To: cbm@rose.hp.com
From: "Mallikarjun C." <cbm@rose.hp.com>
X-Mailer: Elm [revision: 212.4]
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Deva,

Let me respond to your questions.

Currently, the draft assumes that recovery R2Ts can be generated
for digest errors on unsolicited data bursts in separate data PDUs.
This will be explicitly called out as I said in a response to Sandeep:

http://www.pdl.cmu.edu/mailinglists/ips/mail/msg05855.html

The immediate data digest failures however, are not intended to 
be recoverable with R2Ts since an iSCSI (and SCSI) task is not 
instantiated in that case (rev07, section 7.2).  The rationale
was that it is much easier for the initiator to re-ship the entire
PDU (command+immediate) than build a new data PDU with a Write-data
header (if only a part, command, of the rejected PDU were accepted 
on  the target).   Also, accepting partial PDUs didn't seem to make 
it easier for targets either.

New wording dealing with immediate data digest failures had already
been added to section 7.2, to appear in rev08. 

Thanks.
--
Mallikarjun 


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

>Julian,
>
>I dont know if this has been already discussed. If so forgive me and point
>me to the link please.
>
>In Section 7.4, in draft 7 (page 115)it is stated that the target may
>request retransmission
>with a R2T. It then goes on to say that non-data PDU. It does not talk about
>unsolicited data PDUs, explicitly.
>I presume that data digest errors in unsolicited and immediate data PDUs
>cannot be retried and should be responded
>with delivery-subsystem failure. Is this correct? If so, why is this
>requirement ?
>
>In section 7.11.1, page 119, the spec. implies that digest errors in data
>PDUs may be recovered by issuing R2T. Once again,
>it fails to talk about digest errors in immediate data unsolicited data
>PDUs.
>
>Thanks
>
>Deva
>Platys communications
>
>
>
>-----Original Message-----
>From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
>Julian Satran
>Sent: Friday, August 17, 2001 3:23 PM
>To: Mark Bakke
>Cc: Douglas Otis; Sanjay Goyal; Ips (E-mail)
>Subject: Re: iSCSI: [Fwd: Crc-32c example in iSCSI spec]
>
>
>
>Mark & all,
>
>The 2 "additions" you will find in the CRC calculation:
>
>   initializing the "remainder" field with all ones (instead of the implied
>   shifting in of 0's) and
>   XORing the result with a mask (usually "full house")
>
>
>are done to improve the error correction capabilities of CRCs.
>CRCs are weak in detecting the spurious addition of leading 0s (that can
>result from clocking errors) and the deletion of initial 1 with spurious
>insertion of a 1 at the end.
>
>Julo
>
>Mark Bakke <mbakke@cisco.com>@ece.cmu.edu on 17-08-2001 23:10:22
>
>Please respond to Mark Bakke <mbakke@cisco.com>
>
>Sent by:  owner-ips@ece.cmu.edu
>
>
>To:   Douglas Otis <dotis@sanlight.net>
>cc:   Sanjay Goyal <sanjay_goyal@ivivity.com>, "Ips (E-mail)"
>      <ips@ece.cmu.edu>
>Subject:  Re: iSCSI: [Fwd: Crc-32c example in iSCSI spec]
>
>
>
>OK.  I don't see any reason for sending the CRC inverted either
>(we would just have a different remainder poly), but since Ethernet
>does it that way, and it doesn't cost anything, we might as well
>do it, too.
>
>--
>Mark
>
>Douglas Otis wrote:
>>
>> Mark,
>>
>> The reason for the bit swap within the table is to allow a serial
>hardware
>> scheme as CRC is processed ms to ls over the entire stream as if a single
>> number.  Ethernet sends the byte out least significant bit first.  The
>> entire table is also swapped ls to ms and actually reduces the operations
>> needed within the table calculations.  This reflects the method used for
>> Ethernet as it is being stored inverted and the initial value is started
>as
>> all ones.  The reason for the initial value being set to all ones is
>clear
>> for leading zero interaction, but I do not understand the value in
>storing
>> the CRC inverted.  I thought to include my ignorance to the mix.
>>
>> Doug
>>
>> > Sanjay Goyal wrote:
>> > >
>> > > Hi
>> > >  I get the remainder for iSCSI as 0x1c2d19ed if I complement my
>> > CRC and then
>> > > pass it through the CRC engine.
>> > >
>> > >  As per CRC generation for data: the thing which is not clear to me
>is
>> > >    why do we need to bit-swap the CRC reminader as is done in all
>your
>> > > examples.
>> >
>> > As far as I can tell, bit-swapping does nothing to help or hurt
>> > the effectiveness of the CRC.  When I ran my examples, I thought
>> > that it would be the simplest for our CRC to different from the
>> > Ethernet CRC only in the polynomial.  Ethernet, FDDI, FC, and SCSI
>> > all do this, so I figured it would cause the least confusion if
>> > we did the same.
>> >
>> > > We can just complement it and append it after the DATA bytes.
>> > >  The other side also can just pass it through the CRC engine to
>> > check it.
>> > >
>> > > Regards
>> > > Sanjay Goyal
>> > >
>> > > -----Original Message-----
>> > > From: Mark Bakke [mailto:mbakke@cisco.com]
>> > > Sent: Thursday, August 16, 2001 1:43 PM
>> > > To: Steve Blightman; ips@ece.cmu.edu
>> > > Subject: Re: [Fwd: Crc-32c example in iSCSI spec]
>> > >
>> > > One more thing that might be helpful.  When the Ethernet
>> > > polynomial is used in SCSI to generate its CRC, the T10
>> > > doc specifies the remainder polynomial that one should see
>> > > after running the data with a valid CRC through.  For
>> > > the Ethernet CRC, this was specified as 0xc704dd7b.  This
>> > > remainder polynomial is taken before the CRC is complemented
>> > > and bit-reflected.  For iSCSI, I came up with a remainder of
>> > > 0x1c2d19ed.  Can anyone verify this result?
>> > >
>> > > --
>> > > Mark
>> > >
>> > > Mark Bakke wrote:
>> > > >
>> > > > Steve-
>> > > >
>> > > > I just ran some Ethernet packets with known CRCs through
>> > > > my iSCSI/Ethernet CRC generator, and found the same thing
>> > > > as you did.
>> > > >
>> > > > All of my examples need to be byte-swapped, along with the
>> > > > fix I already posted for the all-ones example.  Here is a
>> > > > new set of examples, which will be in -08.  I also ran
>> > > > 64 bytes of zeroes and ones, which now agree with your
>> > > > numbers as well.
>> > > >
>> > > > Thanks again for bringing this up.
>> > > >
>> > > > --
>> > > > Mark
>> > > >
>> > > >      07 CRC Examples
>> > > >
>> > > >         N.B. all Values are Hexadecimal
>> > > >
>> > > >           Byte:        0  1  2  3
>> > > >
>> > > >              0:       01 a0 00 00
>> > > >              4:       00 00 00 00
>> > > >              8:       00 00 00 00
>> > > >             12:       00 00 00 00
>> > > >             16:       04 05 00 00
>> > > >             20:       00 01 00 00
>> > > >             24:       00 00 00 05
>> > > >             28:       00 00 00 04
>> > > >             32:       2a 00 00 00
>> > > >             36:       00 00 00 00
>> > > >             40:       80 00 00 00
>> > > >             44:       00 00 00 00
>> > > >
>> > > >            CRC:       93 70 51 db
>> > > >
>> > > >         32 bytes of zeroes:
>> > > >
>> > > >           Byte:        0  1  2  3
>> > > >
>> > > >              0:       00 00 00 00
>> > > >            ...
>> > > >             28:       00 00 00 00
>> > > >
>> > > >            CRC:       aa 36 91 8a
>> > > >
>> > > >         32 bytes of ones:
>> > > >
>> > > >           Byte:        0  1  2  3
>> > > >
>> > > >              0:       ff ff ff ff
>> > > >            ...
>> > > >             28:       ff ff ff ff
>> > > >
>> > > >            CRC:       43 ab a8 62
>> > > >
>> > > >         32 bytes of incrementing 00..1f:
>> > > >
>> > > >           Byte:        0  1  2  3
>> > > >
>> > > >              0:       00 01 02 03
>> > > >            ...
>> > > >             28:       1c 1d 1e 1f
>> > > >
>> > > >            CRC:       4e 79 dd 46
>> > > >
>> > > >
>> > > > Steve Blightman wrote:
>> > > > >
>> > > > > I believe the examples for the ISCSI CRC  have the wrong
>endianness.
>> > > > >
>> > > > > As yiou suugested over the phone I ran some Ethernet frames
>> > through a
>> > > > > simulation. I have some difficulty running the exact simulations
>you
>> > > > > wanted becuase the minimum size Ethernet frame is 64 bytes.
>> > > > >
>> > > > > However using the Ethernet CRC polynomial,
>> > > > > Running 64 bytes of 0 onto the wire, we append "36 63 8d
>> > 75" onto the
>> > > > > wire for the CRC - "36" goes out first.
>> > > > > Running 64 bytes of all 1, we append "ba 87 61 0f" onto the
>> > wire - "ba"
>> > > > > goes out first.
>> > > > >
>> > > > > Using the same logic for the ISCSI polynomial
>> > > > > Running 64 bytes of 0 I think we should append "67 eb c8 03" -
>"67"
>> > > > > going out first
>> > > > > and running 64 bytes of all 1 we should append "66 4e cd 2f" -
>"66"
>> > > > > going out first
>> > > > >
>> > > > > And now for 32 bytes with the ISCSI polynomial
>> > > > >
>> > > > > Running 32 bytes of 0 we should append "aa 36 91 8a" - "aa"
>> > going out
>> > > > > first
>> > > > > Running 32 bytes of all 1 we should append "43 ab a8 62" -
>> > "43" going
>> > > > > out first
>> > > > >
>> > > > > I don't want to get into an endless endian debate, but I
>> > believe it is
>> > > > > important to get the order of these bytes in the right
>> > order, so that we
>> > > > > can use the same hardware to check as well as to generate CRCs.
>> > > > >
>> > > > > Thanks for your help on this,
>> > > > > Steve Blightman
>> > > >
>> > > > --
>> > > > Mark A. Bakke
>> > > > Cisco Systems
>> > > > mbakke@cisco.com
>> > > > 763.398.1054
>> > >
>> > > --
>> > > Mark A. Bakke
>> > > Cisco Systems
>> > > mbakke@cisco.com
>> > > 763.398.1054
>> > >
>> > >
>> > ------------------------------------------------------------------
>> > ----------------------------------
>> > >
>> > >    Part 1.2    Type: application/ms-tnef
>> > >            Encoding: base64
>> >
>> > --
>> > Mark A. Bakke
>> > Cisco Systems
>> > mbakke@cisco.com
>> > 763.398.1054
>> >
>
>--
>Mark A. Bakke
>Cisco Systems
>mbakke@cisco.com
>763.398.1054
>
>
>
>




From owner-ips@ece.cmu.edu  Tue Aug 21 20:47:17 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03904
	for <ips-archive@odin.ietf.org>; Tue, 21 Aug 2001 20:47:16 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7LNo3q08742
	for ips-outgoing; Tue, 21 Aug 2001 19:50:03 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7LNo1e08737
	for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 19:50:01 -0400 (EDT)
Received: from fmsmsxvs040.fm.intel.com (fmsmsxv040-1.fm.intel.com [132.233.48.108])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id XAA09680
	for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 23:49:53 GMT
Received: from fmsmsx17.intel.com ([132.233.48.17])
 by fmsmsxvs040.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001082116493312169
 for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 16:49:33 -0700
Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <RBZ4HKAC>; Tue, 21 Aug 2001 16:50:53 -0700
Message-ID: <638EC1B28663D211AC3E00A0C96B78A8086ABB3E@orsmsx40.jf.intel.com>
From: "Wheat, Stephen R" <stephen.r.wheat@intel.com>
To: ips@ece.cmu.edu
Subject: iSCSI: Ch7 clarifications
Date: Tue, 21 Aug 2001 16:49:49 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

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


From owner-ips@ece.cmu.edu  Tue Aug 21 20:47:37 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03916
	for <ips-archive@odin.ietf.org>; Tue, 21 Aug 2001 20:47:37 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7LNu3P09026
	for ips-outgoing; Tue, 21 Aug 2001 19:56:03 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7LNu2e09022
	for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 19:56:02 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-68-173.cisco.com [161.44.68.173]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id TAA29472 for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 19:55:56 -0400 (EDT)
Message-ID: <3B82F505.4AC2BDE7@cisco.com>
Date: Tue, 21 Aug 2001 18:55:49 -0500
From: Steve Senum <ssenum@cisco.com>
X-Mailer: Mozilla 4.73 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-ips <ips@ece.cmu.edu>
Subject: Re: iSCSI: Login Proposal
References: <638EC1B28663D211AC3E00A0C96B78A8086ABB3B@orsmsx40.jf.intel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Stephen,

I think the assumption is that <something> is usually
preferred over <none>.

Even if an option is required to be implemented
though (like crc-32c), an Initiator or Target
could be configured to not allow it (including <none>).
However, in such cases, it would be easy to get
into a situation where the Initiator and Target
will never agree and no connection is possible.
I think the offering party (usually the Initiator)
need to be allowed to control the preference.

Steve Senum

"Wheat, Stephen R" wrote:
> 
> Yup, I thought I had seen it, but couldn't find it; thanks.  And am now
> embarrassed that I couldn't find it, when it was indeed documented in two
> places.  I'll save related comments for when we go through the spec clean-up
> phase.
> 
> So, the second paragraph you cite from both p22 and p100 imply that a target
> could avoid selecting "none".  Thus, the initiator could prefer "none", but
> the target still select another initiator-offered value, hence avoiding the
> situation you propose, where "none" is always selected.
> 
> Yes?
> 
> Otherwise, how would a target and initiator be able to select "none", in the
> presence of the ability to mutually do at least one method?
> 
> Aren't there times where either could do all protocols, but both would
> *prefer* to do "none"??
> 
> Perhaps my question then is to get Para5 of 1.2.4 on p22 slightly clarified,
> so as to avoid your conclusion.  I.e., the initiator should be allowed to
> prefer "none" over something else, yet have the target be capable of not
> selecting "none".
> 
> Again, I agree with you that the new-and-improved-login proposal would be
> even better with a requirement to have the initiator include its security
> parameters, even if they consist of only "none".
> 
> Stephen
> 
> -----Original Message-----
> From: Steve Senum [mailto:ssenum@cisco.com]
> Sent: Tuesday, August 21, 2001 2:31 PM
> To: ietf-ips
> Subject: Re: iSCSI: Login Proposal
> 
> Hi Stephen,
> 
> The current draft (-07) does actually answer your
> question, though it is somewhat buried:
> 
> On page 22:
> 
>         In "list" negotiation, the offering party sends for each key a list
>         of values (which may include "none") in its order of preference.
> 
>         The responding party answers with the first value from the list it
>         supports and is allowed to use for the specific initiator.
> 
> And on page 100:
> 
>           -The initiator sends a text command with an ordered list of the
>            options it supports for each subject (authentication algorithm,
>            iSCSI parameters and so on). The options are listed in the
>            initiator's order of preference.
> 
>            -The target MUST reply with the first option in the list it
>            supports and is allowed for the specific initiator....
> 
> Even so, I don't see the value in:
> 
> AuthMethod=none,CHAP
> 
> Since every implementation must support "none", "CHAP"
> will never get picked.
> 
> In the interest of keeping login processing as simple as
> possible, I would simply require the initiator to offer
> what it can support (if anything).  The target can then
> pick a compatiable method, or reject the connection.
> 
> Steve Senum
> 
> "Wheat, Stephen R" wrote:
> >
> > Good questions, Steve.
> >
> > Question 2 caused me to ponder the concept of key-value preferences.
> I.e.,
> > I suspect that the concept in the proposed login spec was to address that
> > the initiator may prefer to not have any security digests, but might be
> able
> > to negotiate them if the target insisted.
> >
> > I cannot find anywhere in the I-D that states that a recipient MUST
> consider
> > key=v1,v2,v3 as the sender having preference of v1 over v2, and v2 over
> v3.
> > Thus, I second Q2, but only if key values are to be interpreted in
> > preferential order.  Thus, an initiator could send
> > "DataDigest=none,crc32-c,SPKM", and the target's response MUST honor the
> > preference order.
> >
> > So, Q4 is: should the values in a key-value list be consider the sender's
> > preference order that the receiver must honor?
> >
> > Stephen
> >
> > -----Original Message-----
> > From: Steve Senum [mailto:ssenum@cisco.com]
> > Sent: Tuesday, August 21, 2001 1:14 PM
> > To: ietf-ips
> > Subject: Re: iSCSI: Login Proposal
> >
> > Matthew/Marjorie/Bob:
> >
> > Some questions on your login proposal:
> >
> > 1. Why the following restriction?
> >
> >     SecurityContextComplete=yes MUST NOT be present
> >     in the login command.
> >
> > I don't see the benefit in not allowing something like:
> >
> > I: AuthMethod:none
> >    HeaderDigest:crc-32c,none
> >    DataDigest:crc-32c,none
> >    SecurityContextComplete=yes
> > T: AuthMethod:none
> >    HeaderDigest:crc-32c
> >    DataDigest:crc-32c
> >    SecurityContextComlete=yes
> >
> > 2. In the following:
> >
> >     If the login command does not contain security parameters
> >     the target MUST perform one of the two actions below:
> >
> >     a) If the target requires security negotiation
> >        to be performed, then it MUST enter the security
> >        phase and MUST send a text response containing
> >        one or more security parameters and F=0.
> >
> >     b)
> >
> > Is this really needed?  Why not simply require the
> > initiator to offer security parameters if it supports them?
> > I would hope authentication would become the typical case
> > for login.
> >
> > 3. Is there only one Login Reponse then (just asking)?
> >
> > Regards,
> > Steve Senum


From owner-ips@ece.cmu.edu  Tue Aug 21 20:47:44 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03927
	for <ips-archive@odin.ietf.org>; Tue, 21 Aug 2001 20:47:43 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7M0DTh09697
	for ips-outgoing; Tue, 21 Aug 2001 20:13:29 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7M0DSe09693
	for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 20:13:28 -0400 (EDT)
Received: from fmsmsxvs043.fm.intel.com (fmsmsxv043-1.fm.intel.com [132.233.48.128])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id AAA20011
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 00:13:27 GMT
Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29])
 by fmsmsxvs043.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001082117124729711
 ; Tue, 21 Aug 2001 17:12:47 -0700
Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <RBZX1MPB>; Tue, 21 Aug 2001 17:13:26 -0700
Message-ID: <638EC1B28663D211AC3E00A0C96B78A8086ABB40@orsmsx40.jf.intel.com>
From: "Wheat, Stephen R" <stephen.r.wheat@intel.com>
To: "'Steve Senum'" <ssenum@cisco.com>, ietf-ips <ips@ece.cmu.edu>
Subject: RE: iSCSI: Login Proposal
Date: Tue, 21 Aug 2001 17:13:21 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

We're so close!!  See comments (***) below,
Stephen

-----Original Message-----
From: Steve Senum [mailto:ssenum@cisco.com]
Sent: Tuesday, August 21, 2001 4:56 PM
To: ietf-ips
Subject: Re: iSCSI: Login Proposal


Hi Stephen,

I think the assumption is that <something> is usually
preferred over <none>.
*** But we have the option to specify deterministic behavior,
*** over accepting assumptions.

Even if an option is required to be implemented
though (like crc-32c), an Initiator or Target
could be configured to not allow it (including <none>).
However, in such cases, it would be easy to get
into a situation where the Initiator and Target
will never agree and no connection is possible.


I think the offering party (usually the Initiator)
need to be allowed to control the preference.
*** yes, yes, yes, yes, so let it be possible to put <none> first.
*** We get determinism and flexibility.
 

Steve Senum

"Wheat, Stephen R" wrote:
> 
> Yup, I thought I had seen it, but couldn't find it; thanks.  And am now
> embarrassed that I couldn't find it, when it was indeed documented in two
> places.  I'll save related comments for when we go through the spec
clean-up
> phase.
> 
> So, the second paragraph you cite from both p22 and p100 imply that a
target
> could avoid selecting "none".  Thus, the initiator could prefer "none",
but
> the target still select another initiator-offered value, hence avoiding
the
> situation you propose, where "none" is always selected.
> 
> Yes?
> 
> Otherwise, how would a target and initiator be able to select "none", in
the
> presence of the ability to mutually do at least one method?
> 
> Aren't there times where either could do all protocols, but both would
> *prefer* to do "none"??
> 
> Perhaps my question then is to get Para5 of 1.2.4 on p22 slightly
clarified,
> so as to avoid your conclusion.  I.e., the initiator should be allowed to
> prefer "none" over something else, yet have the target be capable of not
> selecting "none".
> 
> Again, I agree with you that the new-and-improved-login proposal would be
> even better with a requirement to have the initiator include its security
> parameters, even if they consist of only "none".
> 
> Stephen
> 
> -----Original Message-----
> From: Steve Senum [mailto:ssenum@cisco.com]
> Sent: Tuesday, August 21, 2001 2:31 PM
> To: ietf-ips
> Subject: Re: iSCSI: Login Proposal
> 
> Hi Stephen,
> 
> The current draft (-07) does actually answer your
> question, though it is somewhat buried:
> 
> On page 22:
> 
>         In "list" negotiation, the offering party sends for each key a
list
>         of values (which may include "none") in its order of preference.
> 
>         The responding party answers with the first value from the list it
>         supports and is allowed to use for the specific initiator.
> 
> And on page 100:
> 
>           -The initiator sends a text command with an ordered list of the
>            options it supports for each subject (authentication algorithm,
>            iSCSI parameters and so on). The options are listed in the
>            initiator's order of preference.
> 
>            -The target MUST reply with the first option in the list it
>            supports and is allowed for the specific initiator....
> 
> Even so, I don't see the value in:
> 
> AuthMethod=none,CHAP
> 
> Since every implementation must support "none", "CHAP"
> will never get picked.
> 
> In the interest of keeping login processing as simple as
> possible, I would simply require the initiator to offer
> what it can support (if anything).  The target can then
> pick a compatiable method, or reject the connection.
> 
> Steve Senum
> 
> "Wheat, Stephen R" wrote:
> >
> > Good questions, Steve.
> >
> > Question 2 caused me to ponder the concept of key-value preferences.
> I.e.,
> > I suspect that the concept in the proposed login spec was to address
that
> > the initiator may prefer to not have any security digests, but might be
> able
> > to negotiate them if the target insisted.
> >
> > I cannot find anywhere in the I-D that states that a recipient MUST
> consider
> > key=v1,v2,v3 as the sender having preference of v1 over v2, and v2 over
> v3.
> > Thus, I second Q2, but only if key values are to be interpreted in
> > preferential order.  Thus, an initiator could send
> > "DataDigest=none,crc32-c,SPKM", and the target's response MUST honor the
> > preference order.
> >
> > So, Q4 is: should the values in a key-value list be consider the
sender's
> > preference order that the receiver must honor?
> >
> > Stephen
> >
> > -----Original Message-----
> > From: Steve Senum [mailto:ssenum@cisco.com]
> > Sent: Tuesday, August 21, 2001 1:14 PM
> > To: ietf-ips
> > Subject: Re: iSCSI: Login Proposal
> >
> > Matthew/Marjorie/Bob:
> >
> > Some questions on your login proposal:
> >
> > 1. Why the following restriction?
> >
> >     SecurityContextComplete=yes MUST NOT be present
> >     in the login command.
> >
> > I don't see the benefit in not allowing something like:
> >
> > I: AuthMethod:none
> >    HeaderDigest:crc-32c,none
> >    DataDigest:crc-32c,none
> >    SecurityContextComplete=yes
> > T: AuthMethod:none
> >    HeaderDigest:crc-32c
> >    DataDigest:crc-32c
> >    SecurityContextComlete=yes
> >
> > 2. In the following:
> >
> >     If the login command does not contain security parameters
> >     the target MUST perform one of the two actions below:
> >
> >     a) If the target requires security negotiation
> >        to be performed, then it MUST enter the security
> >        phase and MUST send a text response containing
> >        one or more security parameters and F=0.
> >
> >     b)
> >
> > Is this really needed?  Why not simply require the
> > initiator to offer security parameters if it supports them?
> > I would hope authentication would become the typical case
> > for login.
> >
> > 3. Is there only one Login Reponse then (just asking)?
> >
> > Regards,
> > Steve Senum


From owner-ips@ece.cmu.edu  Tue Aug 21 20:47:59 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03941
	for <ips-archive@odin.ietf.org>; Tue, 21 Aug 2001 20:47:59 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7M0Mnq10067
	for ips-outgoing; Tue, 21 Aug 2001 20:22:49 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mxic2.us.dg.com (mxic2.us.dg.com [128.221.31.40])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7M0Mme10063
	for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 20:22:48 -0400 (EDT)
Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19)
	id <QQ9QYX76>; Tue, 21 Aug 2001 20:20:35 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD638@CORPMX14>
From: Black_David@emc.com
To: sandeepj@research.bell-labs.com, ips@ece.cmu.edu
Subject: RE: FW: I-D ACTION:draft-aboba-ips-iscsi-security-00.txt
Date: Tue, 21 Aug 2001 20:16:50 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Sandeep,

There is a patent on it, and a license is required to ship product.
The license should be available under fair, reasonable, and non-
discriminatory terms, but will not be free.  A reasonable guess
would be that iSCSI licensing terms would be similar to the 802.11
terms, and that a suitable IETF intellectual property rights notice
will be forthcoming.

OTOH, this does seem to run counter to the usual IETF preference
for unpatented technology over patented technology provided that
the unpatented technology is a functionally suitable replacement
for the patented technology.  Whether there are functionally suitable
unpatented replacements for OCB is an issue for further discussion,
ditto the requirements and preferences that lead to the recommendation
of OCB.  A draft on OCB would need to go through the ipsec WG if we
were to use OCB, and my impression is that at least some portion of
that community has a very strong preference for unpatented technology.

I hope this is what you were looking for in the way of comments.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


> -----Original Message-----
> From: sandeepj@research.bell-labs.com
> [mailto:sandeepj@research.bell-labs.com]
> Sent: Tuesday, August 21, 2001 7:49 PM
> To: ips@ece.cmu.edu
> Subject: Re: FW: I-D ACTION:draft-aboba-ips-iscsi-security-00.txt
> 
> 
> David,
> 
> Could you comment on the intellectual rights issues 
> here, particularly on AES-OCB, which will be mandatory 
> according to this draft (Sec 2.1)
> 
> http://www.cs.ucdavis.edu/~rogaway/ocb/ocb-back.htm
> mentions the licensing terms for 802.11 products.
> 
> Secondly, appendix tables A.5 and A.6 seem to indicate
> that AES-CTR+UMAC performance is better than AES-OCB.
> Has AES-OCB been chosen since it requires lesser keying
> material and memory ?
> 
> thanks
> -Sandeep
> 
> > FYI - this is about use of IKE and IPsec algorithm selection
> > considerations.  --David
> > 
> > -----Original Message-----
> > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> > Sent: Tuesday, August 21, 2001 7:25 AM
> > Subject: I-D ACTION:draft-aboba-ips-iscsi-security-00.txt
> > 
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > 
> > Title           : Securing iSCSI using IPsec
> > Author(s)       : B. Aboba et al.
> > Filename        : draft-aboba-ips-iscsi-security-00.txt
> > Pages           : 35
> > Date            : 20-Aug-01
> > 
> > This document discusses how iSCSI may utilize IPsec to provide
> > authentication, integrity, confidentiality and replay protection.
> > 
> > A URL for this Internet-Draft is:
> > 
http://www.ietf.org/internet-drafts/draft-aboba-ips-iscsi-security-00.txt
> 
> Internet-Drafts are also available by anonymous FTP. Login with the
username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-aboba-ips-iscsi-security-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> mailserv@ietf.org.
> In the body type:
> "FILE /internet-drafts/draft-aboba-ips-iscsi-security-00.txt".
> 
> NOTE:   The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility.  To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader.  Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
> 
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
> ---------------------------------------------------------
> + Date: Tue, 21 Aug 2001 09:29:53 -0400
> + Content-Type:
> multipart/mixed;boundary="----_=_NextPart_002_01C12A44.418236C0"
> 
> ATT36560
> 
> <ftp://internet-drafts/>
> Transfer-mode: ftp.ietf.org
> ---------------------------------------------------------
> 


From owner-ips@ece.cmu.edu  Tue Aug 21 20:48:15 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03952
	for <ips-archive@odin.ietf.org>; Tue, 21 Aug 2001 20:48:15 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7LNnWL08724
	for ips-outgoing; Tue, 21 Aug 2001 19:49:32 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f7LNnVe08719
	for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 19:49:31 -0400 (EDT)
Received: from grubby.research.bell-labs.com ([135.104.2.9]) by crufty; Tue Aug 21 19:45:13 EDT 2001
Received: from aura.research.bell-labs.com ([135.104.46.10]) by grubby; Tue Aug 21 19:49:12 EDT 2001
Received: (from sandeepj@localhost)
	by aura.research.bell-labs.com (8.9.1/8.9.1) id TAA18815
	for ips@ece.cmu.edu; Tue, 21 Aug 2001 19:48:41 -0400 (EDT)
Date: Tue, 21 Aug 2001 19:48:41 -0400 (EDT)
Message-Id: <200108212348.TAA18815@aura.research.bell-labs.com>
From: sandeepj@research.bell-labs.com (Sandeep Joshi)
To: ips@ece.cmu.edu
Subject: Re: FW: I-D ACTION:draft-aboba-ips-iscsi-security-00.txt
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

David,

Could you comment on the intellectual rights issues 
here, particularly on AES-OCB, which will be mandatory 
according to this draft (Sec 2.1)

http://www.cs.ucdavis.edu/~rogaway/ocb/ocb-back.htm
mentions the licensing terms for 802.11 products.

Secondly, appendix tables A.5 and A.6 seem to indicate
that AES-CTR+UMAC performance is better than AES-OCB.
Has AES-OCB been chosen since it requires lesser keying
material and memory ?

thanks
-Sandeep

> FYI - this is about use of IKE and IPsec algorithm selection
> considerations.  --David
> 
> -----Original Message-----
> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> Sent: Tuesday, August 21, 2001 7:25 AM
> Subject: I-D ACTION:draft-aboba-ips-iscsi-security-00.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> Title           : Securing iSCSI using IPsec
> Author(s)       : B. Aboba et al.
> Filename        : draft-aboba-ips-iscsi-security-00.txt
> Pages           : 35
> Date            : 20-Aug-01
> 
> This document discusses how iSCSI may utilize IPsec to provide
> authentication, integrity, confidentiality and replay protection.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-aboba-ips-iscsi-security-00.txt
> 
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-aboba-ips-iscsi-security-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> mailserv@ietf.org.
> In the body type:
> "FILE /internet-drafts/draft-aboba-ips-iscsi-security-00.txt".
> 
> NOTE:   The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility.  To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader.  Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
> 
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
> ---------------------------------------------------------
> + Date: Tue, 21 Aug 2001 09:29:53 -0400
> + Content-Type:
> multipart/mixed;boundary="----_=_NextPart_002_01C12A44.418236C0"
> 
> ATT36560
> 
> <ftp://internet-drafts/>
> Transfer-mode: ftp.ietf.org
> ---------------------------------------------------------
> 


From owner-ips@ece.cmu.edu  Tue Aug 21 21:52:11 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05517
	for <ips-archive@odin.ietf.org>; Tue, 21 Aug 2001 21:52:11 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7M0Xu210673
	for ips-outgoing; Tue, 21 Aug 2001 20:33:56 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7LFKLe09318
	for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 11:20:21 -0400 (EDT)
Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35])
	by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id IAA02691;
	Tue, 21 Aug 2001 08:16:57 -0700 (PDT)
Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19)
	id <Q8DQ5P0J>; Tue, 21 Aug 2001 08:16:56 -0700
Message-ID: <FFD40DB4943CD411876500508BAD027902993750@sj5-ex2.brocade.com>
From: Robert Snively <rsnively@Brocade.COM>
To: "'Jim Hafner'" <hafner@almaden.ibm.com>,
        Robert Snively
	 <rsnively@Brocade.COM>
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI NDT: Nameprep additions
Date: Tue, 21 Aug 2001 08:16:55 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

It was my assumption that we are striving for international
localization capabilities.  If that is so, an underscore looks
somewhat like the number 1 in the Chinese character set.
I haven't the foggiest idea how it might be interpreted
in other character sets, some of which have strongly
horizontal-oriented marks.

I would expect that domain names will eventually pick up the same
freedom in international character sets. 

Besides that, I have always hated having to use underscores 
and dashes in names.  Perhaps that is my Apple-user 
background coming out, or maybe it is my having to reach 
two directions with my little fingers to hit underscore on 
a QWERTY keyboard.

Bob

> -----Original Message-----
> From: Jim Hafner [mailto:hafner@almaden.ibm.com]
> Sent: Tuesday, August 21, 2001 7:58 AM
> To: Robert Snively
> Cc: ips@ece.cmu.edu
> Subject: RE: iSCSI NDT: Nameprep additions
> 
> 
> 
> Bob,
> 
> The short answer to this is not an extraordinarily strong argument,
> however..., it was felt that these names should follow many 
> of the rules of
> domain names.  It was also felt that in many cases, the names might be
> embedded in URLs (and the like).  Also, since one of the 
> naming conventions
> is derived from domain names, there didn't seem a strong 
> reason to allow
> for any extra characters.  So, the simpler the allowed set of
> non-alpha-numeric characters (punctuation, whitespace, etc). 
> the easier to
> process, embed, extend, etc.
> 
> On the other hand, doesn't an "underscore" accomplish much of what a
> "white-space" character does for readability?
> 
> Jim Hafner
> 
> 
> Robert Snively <rsnively@Brocade.COM>@ece.cmu.edu on 
> 08/20/2001 12:27:24 pm
> 
> Sent by:  owner-ips@ece.cmu.edu
> 
> 
> To:   "'Mark Bakke'" <mbakke@cisco.com>, Kaladhar
>       Voruganti/Almaden/IBM@IBMUS, IPS <ips@ece.cmu.edu>
> cc:
> Subject:  RE: iSCSI NDT: Nameprep additions
> 
> 
> 
> Mark,
> 
> Why did we want to prohibit a properly normalized
> white-space character?  I have
> always felt that spaces are useful supplements to readability,
> especially for symbolic character sets.
> 
> Bob
> 
> -----Original Message-----
> From: Mark Bakke [mailto:mbakke@cisco.com]
> Sent: Thursday, August 16, 2001 2:20 PM
> To: Kaladhar Voruganti; IPS
> Subject: iSCSI NDT: Nameprep additions
> 
> 
> 
> Kaladhar-
> 
> Here are some modifications to make to the NDT doc to
> add nameprep.  For now, these changes will assume that
> nameprep will become an RFC before we do; if this is
> a problem, we will do some more cut-and-paste later.
> 
> --
> Mark
> 
> 
> Replace:
> 
>     3. iSCSI names must be transcribable by humans.  iSCSI 
> names should
>        be kept as simple as possible, and should not use more than a
>        few special characters.  They must also be 
> case-insensitive, and
>        cannot include white space.
> 
> With:
> 
>     3. iSCSI names must be transcribable by humans.  iSCSI 
> names should
>        be kept as simple as possible, and should not use more than a
>        few special characters.  They must provide for the use of
>        international character sets, and must not allow the use of
>        different names that would be identical except for their case.
>        Whitespace characters must not be allowed.
> 
> Replace:
> 
>    The iSCSI Name may be displayed by user interfaces, but is 
> generally
>    uninterpreted and used as an opaque, case-sensitive string for
>    comparison with other iSCSI Name values.
> 
> With:
> 
>    The iSCSI Name may be displayed by user interfaces, but is 
> generally
>    uninterpreted and used as an opaque string for comparison 
> with other
>    iSCSI Name values.
> 
> Replace:
> 
> 
>    An iSCSI name can be any Unicode character string with the 
> following
>    properties:
> 
>     - it is in Normalization Form C (see Unicode Standard Annex #15,
>        "Unicode Normalization Forms" at
>        http://www.unicode.org/unicode/reports/15)
> 
>     - it contains only the ASCII dash character ('-'=U+002d) or the
>     ASCII dot character ('.'=U+002e) or is in one of the following
>     Unicode General Categories:
> 
>              a) Lu (Letter, Uppercase)
>              b) Ll (Letter, Lowercase)
>              c) Lt (Letter, Titlecase)
>              d) Lm (Letter, Modifier)
>              e) Lo (Letter, Other)
>              f) Nd (Number, Decimal Digit)
>              g) Nl (Number, Letter)
> 
>              h) No (Number, Other)
> 
>     - when encoded in UTF-8, it is no more than 255 bytes
> 
>    In particular, white space, punctuation (except as noted), 
> marks and
>    symbols are not allowed.
> 
> 
> 
> With:
> 
>    An iSCSI name can be any Unicode character string with the 
> following
>    properties:
> 
>     - it is in Normalization Form C (see Unicode Standard Annex #15,
>        "Unicode Normalization Forms" at
>        http://www.unicode.org/unicode/reports/15)
> 
>     - it contains only the following types of characters:
> 
>          - ASCII dash character ('-'=U+002d)
>          - ASCII dot character ('.'=U+002e)
>          - Any character allowed by the output of the nameprep
>            process
> 
>     - when encoded in UTF-8, it is no more than 255 bytes
> 
>    The output of the nameprep process is described in 
> [NAMEPREP].  Nameprep
>    is a method designed by the Internationalized Domain Name 
> (IDN) working
>    group to translate human-typed strings into a format that can be
> compared
>    as opaque strings, and does not include punctuation, 
> spacing, dicritical
>    marks, or other characters that could get in the way of
> transcribability.
>    It also converts everything into its equivalent of lower case.
> 
>    Note that in most cases, the nameprep process does not need to be
>    implemented:
> 
>    - If the names are just generated using lower-case (in any
>      character set) plus digits, no normalization is required.
> 
>    - If the names are generated from some other all-ASCII string,
>      tolower() normalizes and isalnum() verifies.
> 
>    - If the names are generated from more general, internationalized
>      text, either the equivalent of tolower() and isalnum() 
> appropriate
>      to the character set may be used, or the full nameprep procedure
>      can be used.
> 
> 
> 
> 


From owner-ips@ece.cmu.edu  Tue Aug 21 22:48:12 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07019
	for <ips-archive@odin.ietf.org>; Tue, 21 Aug 2001 22:48:12 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7M23sg14622
	for ips-outgoing; Tue, 21 Aug 2001 22:03:54 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from magic.adaptec.com (magic.adaptec.com [208.236.45.80])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7M23qe14617
	for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 22:03:52 -0400 (EDT)
Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11])
	by magic.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id TAA13822;
	Tue, 21 Aug 2001 19:03:25 -0700 (PDT)
Received: from aimexc02.corp.adaptec.com (aimexc02.corp.adaptec.com [162.62.62.40])
	by redfish.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id SAA06183;
	Tue, 21 Aug 2001 18:51:00 -0700 (PDT)
Received: from adaptec.com (ws116-206.corp.adaptec.com [162.62.116.206]) by aimexc02.corp.adaptec.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id RFSQJPF0; Tue, 21 Aug 2001 19:03:25 -0700
Message-ID: <3B8313B4.5D82BDB8@adaptec.com>
Date: Tue, 21 Aug 2001 19:06:44 -0700
From: Tow Wang <Tow_Wang@adaptec.com>
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "'Julian Satran'" <Julian_Satran@il.ibm.com>
CC: "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
Subject: Target record not to span PDUs?
References: <0B9A57FF1D57D411B47500D0B73E5CC101E7A831@dickens.bri.hp.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Julian (and all):

Hello. This is regarding draft 07; could we require that target records NOT span across
PDU's if a text response for SendTargets is very long? Upon reading appendix E, it seems
that a response (of 4096 bytes in length) could end with:

[Begin data segment]
...
TargetName=I.got.chopped.4096
TargetAddress=10.1.1.45
[End data segment]

In the above case, one could not determine whether the address is IP V4 or V6. Even if it
had had enough space to put in the whole address, port and group tag, one cannot parse and
process the record until inspecting the data segment of the next text response PDU, and
this would involve cumulative buffering, back-parsing, etc. I think the above complexity
could be avoided, as I can't imagine any single record exceeding 4096 bytes in length.

Tow Wang



From owner-ips@ece.cmu.edu  Tue Aug 21 22:49:13 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07035
	for <ips-archive@odin.ietf.org>; Tue, 21 Aug 2001 22:49:12 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7M1Zho13480
	for ips-outgoing; Tue, 21 Aug 2001 21:35:43 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7M1Zfe13476
	for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 21:35:41 -0400 (EDT)
Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100])
	by palrel1.hp.com (Postfix) with ESMTP
	id 059281EE8; Tue, 21 Aug 2001 18:35:41 -0700 (PDT)
Received: (from cbm@localhost) by core.rose.hp.com (8.8.6 (PHNE_14041)/8.8.6 SMKit7.02) id SAA04697; Tue, 21 Aug 2001 18:36:54 -0700 (PDT)
Message-Id: <200108220136.SAA04697@core.rose.hp.com>
Subject: Re: iSCSI: Ch7 clarifications
To: stephen.r.wheat@intel.com
Date: Tue, 21 Aug 2001 18:36:54 PDT
Cc: ips@ece.cmu.edu
In-Reply-To: <638EC1B28663D211AC3E00A0C96B78A8086ABB3E@orsmsx40.jf.intel.com>; from "Wheat, Stephen R" at Aug 21, 101 5:30 pm
Reply-To: cbm@rose.hp.com
From: "Mallikarjun C." <cbm@rose.hp.com>
X-Mailer: Elm [revision: 212.4]
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Stephen,

Thanks for the comments, let me comment on your questions.

>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?

Yes, it may be a protocol error.  The Reject reason code is intended to 
be a more precise identification of the source of the problem as opposed
to a generic "Protocol error" reason code. 

As of rev07, please note that this may also be a genuine case of different 
views of the same task between the two ends - initiator may be attempting to
plug a command which target, if it is done, could be mistaking for a replay.
This ambiguity however, is being fixed as Julian already indicated (check 
http://www.pdl.cmu.edu/mailinglists/ips/mail/msg05800.html).

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

They are clearly specified - whatever is required to satisfy bullet "(b)" 
(command plugging) - from the way I read it.   What this quote is saying 
is that 2 out of 3 identified scenarios are optional to support, whereas 
targets must process the X-bit and guarantee that initiators can plug 
command sequence gaps deterministically, and must generate a Reject with 
the "command in progress" reason code (para 2, page 114).

>
>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).

I admit that I am confused by your (1) - if a target chooses option
(a), it is requesting retransmission.  I am not sure what you mean by
"choose (a), and not request"...

Anyway, I see your point.  I will reword it along the lines of the 
initiator actions.

>
>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


Thanks.
--
Mallikarjun 


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


From owner-ips@ece.cmu.edu  Tue Aug 21 22:50:14 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07066
	for <ips-archive@odin.ietf.org>; Tue, 21 Aug 2001 22:50:14 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7M1fs913747
	for ips-outgoing; Tue, 21 Aug 2001 21:41:54 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from clyde.stargateip.com ([209.237.5.66])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7M1fqe13743
	for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 21:41:52 -0400 (EDT)
Received: from bluestar (dhcp-101.stargateip.com [10.10.5.101])
	by clyde.stargateip.com (8.9.1/8.9.1) with SMTP id SAA14300;
	Tue, 21 Aug 2001 18:32:42 -0700 (PDT)
Reply-To: <deva@stargateip.com>
From: "Dev" <deva@stargateip.com>
To: <cbm@rose.hp.com>
Cc: <ips@ece.cmu.edu>
Subject: RE: iSCSI:Data Recovery from digest errors ...
Date: Tue, 21 Aug 2001 18:43:20 -0700
Message-ID: <NFBBKBDFJCDMGCBKJLCJGEDIFDAA.deva@stargateip.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <200108212207.PAA14745@core.rose.hp.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Importance: Normal
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Mallikarjun,

Thanks for the input.  I thought about it. I like the way of using R2T
to retry the data. But on further thoughts I have some
clarifications/concerns.

At the outset, it looks to me to open the door for having the
target solicit for data (unless some restrictions are on the R2T) even
though  R2T is disabled as initR2T is disabled.. But R2T PDU has all the
relevant field
 data offset, data length etc and fits in to retry data. Now, If out of 64K
received,
target desires to choose to retry the 16K,say between 32K to 48K, what will
be the data
sequence numbers generated for the data PDUs sent as response to R2T. Will
it be the
same sequence number for Data PDUs when they were sent as unsolicited burst
or a different
one? What will be the value of the value of expR2TSN and expDataSN in the
SCSI response PDU for this case. Probably a flag in the R2T header indicate
that
it is a retry for immediate and the initiator should resend the entire
data..

If an initiator/target have to still be capable of supporting R2T when it is
disabled,
why would R2T and unsolicited data burst be mutually exclusive in the iSCSI
spec? Meaning,
if a command request is for 64K write and unsolicited burst size is 32K, why
not the target
receive the rest of the data (the next 32K) through R2Ts?

Am I missing something?
Just my thoughts. what do you think? If Im on the wrong track, could you
correct me?



Thanks

Deva
Platys Communications



-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Mallikarjun C.
Sent: Tuesday, August 21, 2001 3:07 PM
To: deva@stargateip.com
Cc: ips@ece.cmu.edu
Subject: Re: iSCSI:Data Recovery from digest errors ...


Deva,

Let me respond to your questions.

Currently, the draft assumes that recovery R2Ts can be generated
for digest errors on unsolicited data bursts in separate data PDUs.
This will be explicitly called out as I said in a response to Sandeep:

http://www.pdl.cmu.edu/mailinglists/ips/mail/msg05855.html

The immediate data digest failures however, are not intended to
be recoverable with R2Ts since an iSCSI (and SCSI) task is not
instantiated in that case (rev07, section 7.2).  The rationale
was that it is much easier for the initiator to re-ship the entire
PDU (command+immediate) than build a new data PDU with a Write-data
header (if only a part, command, of the rejected PDU were accepted
on  the target).   Also, accepting partial PDUs didn't seem to make
it easier for targets either.

New wording dealing with immediate data digest failures had already
been added to section 7.2, to appear in rev08.

Thanks.
--
Mallikarjun


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

>Julian,
>
>I dont know if this has been already discussed. If so forgive me and point
>me to the link please.
>
>In Section 7.4, in draft 7 (page 115)it is stated that the target may
>request retransmission
>with a R2T. It then goes on to say that non-data PDU. It does not talk
about
>unsolicited data PDUs, explicitly.
>I presume that data digest errors in unsolicited and immediate data PDUs
>cannot be retried and should be responded
>with delivery-subsystem failure. Is this correct? If so, why is this
>requirement ?
>
>In section 7.11.1, page 119, the spec. implies that digest errors in data
>PDUs may be recovered by issuing R2T. Once again,
>it fails to talk about digest errors in immediate data unsolicited data
>PDUs.
>
>Thanks
>
>Deva
>Platys communications
>
>
>
>-----Original Message-----
>From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
>Julian Satran
>Sent: Friday, August 17, 2001 3:23 PM
>To: Mark Bakke
>Cc: Douglas Otis; Sanjay Goyal; Ips (E-mail)
>Subject: Re: iSCSI: [Fwd: Crc-32c example in iSCSI spec]
>
>
>
>Mark & all,
>
>The 2 "additions" you will find in the CRC calculation:
>
>   initializing the "remainder" field with all ones (instead of the implied
>   shifting in of 0's) and
>   XORing the result with a mask (usually "full house")
>
>
>are done to improve the error correction capabilities of CRCs.
>CRCs are weak in detecting the spurious addition of leading 0s (that can
>result from clocking errors) and the deletion of initial 1 with spurious
>insertion of a 1 at the end.
>
>Julo
>
>Mark Bakke <mbakke@cisco.com>@ece.cmu.edu on 17-08-2001 23:10:22
>
>Please respond to Mark Bakke <mbakke@cisco.com>
>
>Sent by:  owner-ips@ece.cmu.edu
>
>
>To:   Douglas Otis <dotis@sanlight.net>
>cc:   Sanjay Goyal <sanjay_goyal@ivivity.com>, "Ips (E-mail)"
>      <ips@ece.cmu.edu>
>Subject:  Re: iSCSI: [Fwd: Crc-32c example in iSCSI spec]
>
>
>
>OK.  I don't see any reason for sending the CRC inverted either
>(we would just have a different remainder poly), but since Ethernet
>does it that way, and it doesn't cost anything, we might as well
>do it, too.
>
>--
>Mark
>
>Douglas Otis wrote:
>>
>> Mark,
>>
>> The reason for the bit swap within the table is to allow a serial
>hardware
>> scheme as CRC is processed ms to ls over the entire stream as if a single
>> number.  Ethernet sends the byte out least significant bit first.  The
>> entire table is also swapped ls to ms and actually reduces the operations
>> needed within the table calculations.  This reflects the method used for
>> Ethernet as it is being stored inverted and the initial value is started
>as
>> all ones.  The reason for the initial value being set to all ones is
>clear
>> for leading zero interaction, but I do not understand the value in
>storing
>> the CRC inverted.  I thought to include my ignorance to the mix.
>>
>> Doug
>>
>> > Sanjay Goyal wrote:
>> > >
>> > > Hi
>> > >  I get the remainder for iSCSI as 0x1c2d19ed if I complement my
>> > CRC and then
>> > > pass it through the CRC engine.
>> > >
>> > >  As per CRC generation for data: the thing which is not clear to me
>is
>> > >    why do we need to bit-swap the CRC reminader as is done in all
>your
>> > > examples.
>> >
>> > As far as I can tell, bit-swapping does nothing to help or hurt
>> > the effectiveness of the CRC.  When I ran my examples, I thought
>> > that it would be the simplest for our CRC to different from the
>> > Ethernet CRC only in the polynomial.  Ethernet, FDDI, FC, and SCSI
>> > all do this, so I figured it would cause the least confusion if
>> > we did the same.
>> >
>> > > We can just complement it and append it after the DATA bytes.
>> > >  The other side also can just pass it through the CRC engine to
>> > check it.
>> > >
>> > > Regards
>> > > Sanjay Goyal
>> > >
>> > > -----Original Message-----
>> > > From: Mark Bakke [mailto:mbakke@cisco.com]
>> > > Sent: Thursday, August 16, 2001 1:43 PM
>> > > To: Steve Blightman; ips@ece.cmu.edu
>> > > Subject: Re: [Fwd: Crc-32c example in iSCSI spec]
>> > >
>> > > One more thing that might be helpful.  When the Ethernet
>> > > polynomial is used in SCSI to generate its CRC, the T10
>> > > doc specifies the remainder polynomial that one should see
>> > > after running the data with a valid CRC through.  For
>> > > the Ethernet CRC, this was specified as 0xc704dd7b.  This
>> > > remainder polynomial is taken before the CRC is complemented
>> > > and bit-reflected.  For iSCSI, I came up with a remainder of
>> > > 0x1c2d19ed.  Can anyone verify this result?
>> > >
>> > > --
>> > > Mark
>> > >
>> > > Mark Bakke wrote:
>> > > >
>> > > > Steve-
>> > > >
>> > > > I just ran some Ethernet packets with known CRCs through
>> > > > my iSCSI/Ethernet CRC generator, and found the same thing
>> > > > as you did.
>> > > >
>> > > > All of my examples need to be byte-swapped, along with the
>> > > > fix I already posted for the all-ones example.  Here is a
>> > > > new set of examples, which will be in -08.  I also ran
>> > > > 64 bytes of zeroes and ones, which now agree with your
>> > > > numbers as well.
>> > > >
>> > > > Thanks again for bringing this up.
>> > > >
>> > > > --
>> > > > Mark
>> > > >
>> > > >      07 CRC Examples
>> > > >
>> > > >         N.B. all Values are Hexadecimal
>> > > >
>> > > >           Byte:        0  1  2  3
>> > > >
>> > > >              0:       01 a0 00 00
>> > > >              4:       00 00 00 00
>> > > >              8:       00 00 00 00
>> > > >             12:       00 00 00 00
>> > > >             16:       04 05 00 00
>> > > >             20:       00 01 00 00
>> > > >             24:       00 00 00 05
>> > > >             28:       00 00 00 04
>> > > >             32:       2a 00 00 00
>> > > >             36:       00 00 00 00
>> > > >             40:       80 00 00 00
>> > > >             44:       00 00 00 00
>> > > >
>> > > >            CRC:       93 70 51 db
>> > > >
>> > > >         32 bytes of zeroes:
>> > > >
>> > > >           Byte:        0  1  2  3
>> > > >
>> > > >              0:       00 00 00 00
>> > > >            ...
>> > > >             28:       00 00 00 00
>> > > >
>> > > >            CRC:       aa 36 91 8a
>> > > >
>> > > >         32 bytes of ones:
>> > > >
>> > > >           Byte:        0  1  2  3
>> > > >
>> > > >              0:       ff ff ff ff
>> > > >            ...
>> > > >             28:       ff ff ff ff
>> > > >
>> > > >            CRC:       43 ab a8 62
>> > > >
>> > > >         32 bytes of incrementing 00..1f:
>> > > >
>> > > >           Byte:        0  1  2  3
>> > > >
>> > > >              0:       00 01 02 03
>> > > >            ...
>> > > >             28:       1c 1d 1e 1f
>> > > >
>> > > >            CRC:       4e 79 dd 46
>> > > >
>> > > >
>> > > > Steve Blightman wrote:
>> > > > >
>> > > > > I believe the examples for the ISCSI CRC  have the wrong
>endianness.
>> > > > >
>> > > > > As yiou suugested over the phone I ran some Ethernet frames
>> > through a
>> > > > > simulation. I have some difficulty running the exact simulations
>you
>> > > > > wanted becuase the minimum size Ethernet frame is 64 bytes.
>> > > > >
>> > > > > However using the Ethernet CRC polynomial,
>> > > > > Running 64 bytes of 0 onto the wire, we append "36 63 8d
>> > 75" onto the
>> > > > > wire for the CRC - "36" goes out first.
>> > > > > Running 64 bytes of all 1, we append "ba 87 61 0f" onto the
>> > wire - "ba"
>> > > > > goes out first.
>> > > > >
>> > > > > Using the same logic for the ISCSI polynomial
>> > > > > Running 64 bytes of 0 I think we should append "67 eb c8 03" -
>"67"
>> > > > > going out first
>> > > > > and running 64 bytes of all 1 we should append "66 4e cd 2f" -
>"66"
>> > > > > going out first
>> > > > >
>> > > > > And now for 32 bytes with the ISCSI polynomial
>> > > > >
>> > > > > Running 32 bytes of 0 we should append "aa 36 91 8a" - "aa"
>> > going out
>> > > > > first
>> > > > > Running 32 bytes of all 1 we should append "43 ab a8 62" -
>> > "43" going
>> > > > > out first
>> > > > >
>> > > > > I don't want to get into an endless endian debate, but I
>> > believe it is
>> > > > > important to get the order of these bytes in the right
>> > order, so that we
>> > > > > can use the same hardware to check as well as to generate CRCs.
>> > > > >
>> > > > > Thanks for your help on this,
>> > > > > Steve Blightman
>> > > >
>> > > > --
>> > > > Mark A. Bakke
>> > > > Cisco Systems
>> > > > mbakke@cisco.com
>> > > > 763.398.1054
>> > >
>> > > --
>> > > Mark A. Bakke
>> > > Cisco Systems
>> > > mbakke@cisco.com
>> > > 763.398.1054
>> > >
>> > >
>> > ------------------------------------------------------------------
>> > ----------------------------------
>> > >
>> > >    Part 1.2    Type: application/ms-tnef
>> > >            Encoding: base64
>> >
>> > --
>> > Mark A. Bakke
>> > Cisco Systems
>> > mbakke@cisco.com
>> > 763.398.1054
>> >
>
>--
>Mark A. Bakke
>Cisco Systems
>mbakke@cisco.com
>763.398.1054
>
>
>
>




From owner-ips@ece.cmu.edu  Tue Aug 21 22:51:16 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07080
	for <ips-archive@odin.ietf.org>; Tue, 21 Aug 2001 22:51:16 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7M24Lb14647
	for ips-outgoing; Tue, 21 Aug 2001 22:04:21 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7M23We14605
	for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 22:03:32 -0400 (EDT)
Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100])
	by atlrel2.hp.com (Postfix) with ESMTP id DBCDEDA2
	for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 22:03:31 -0400 (EDT)
Received: (from cbm@localhost) by core.rose.hp.com (8.8.6 (PHNE_14041)/8.8.6 SMKit7.02) id TAA06516 for ips@ece.cmu.edu; Tue, 21 Aug 2001 19:04:48 -0700 (PDT)
Message-Id: <200108220204.TAA06516@core.rose.hp.com>
Subject: RE: iSCSI:Data Recovery from digest errors ...
To: ips@ece.cmu.edu
Date: Tue, 21 Aug 2001 19:04:48 PDT
Reply-To: cbm@rose.hp.com
From: "Mallikarjun C." <cbm@rose.hp.com>
X-Mailer: Elm [revision: 212.4]
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Deva,

InitialR2T=no only implies that an *initial* unsolicited
burst is allowed by the target - _not_ that R2T is completely
disabled.  For complete details, see rev07, Appendix D, item 24.

Data sequence numbers always follow the rules clearly outlined
in section 1.2.2.3.  R2T is a request to transfer certain data
range, *not* PDU sequence range (as does a SNACK).

I hope that addresses your questions.
--
Mallikarjun 


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


>Mallikarjun,
>
>Thanks for the input.  I thought about it. I like the way of using R2T
>to retry the data. But on further thoughts I have some
>clarifications/concerns.
>
>At the outset, it looks to me to open the door for having the
>target solicit for data (unless some restrictions are on the R2T) even
>though  R2T is disabled as initR2T is disabled.. But R2T PDU has all the
>relevant field
> data offset, data length etc and fits in to retry data. Now, If out of 64K
>received,
>target desires to choose to retry the 16K,say between 32K to 48K, what will
>be the data
>sequence numbers generated for the data PDUs sent as response to R2T. Will
>it be the
>same sequence number for Data PDUs when they were sent as unsolicited burst
>or a different
>one? What will be the value of the value of expR2TSN and expDataSN in the
>SCSI response PDU for this case. Probably a flag in the R2T header indicate
>that
>it is a retry for immediate and the initiator should resend the entire
>data..
>
>If an initiator/target have to still be capable of supporting R2T when it is
>disabled,
>why would R2T and unsolicited data burst be mutually exclusive in the iSCSI
>spec? Meaning,
>if a command request is for 64K write and unsolicited burst size is 32K, why
>not the target
>receive the rest of the data (the next 32K) through R2Ts?
>
>Am I missing something?
>Just my thoughts. what do you think? If Im on the wrong track, could you
>correct me?
>
>
>
>Thanks
>
>Deva
>Platys Communications
>
>
>
>-----Original Message-----
>From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
>Mallikarjun C.
>Sent: Tuesday, August 21, 2001 3:07 PM
>To: deva@stargateip.com
>Cc: ips@ece.cmu.edu
>Subject: Re: iSCSI:Data Recovery from digest errors ...
>
>
>Deva,
>
>Let me respond to your questions.
>
>Currently, the draft assumes that recovery R2Ts can be generated
>for digest errors on unsolicited data bursts in separate data PDUs.
>This will be explicitly called out as I said in a response to Sandeep:
>
>http://www.pdl.cmu.edu/mailinglists/ips/mail/msg05855.html
>
>The immediate data digest failures however, are not intended to
>be recoverable with R2Ts since an iSCSI (and SCSI) task is not
>instantiated in that case (rev07, section 7.2).  The rationale
>was that it is much easier for the initiator to re-ship the entire
>PDU (command+immediate) than build a new data PDU with a Write-data
>header (if only a part, command, of the rejected PDU were accepted
>on  the target).   Also, accepting partial PDUs didn't seem to make
>it easier for targets either.
>
>New wording dealing with immediate data digest failures had already
>been added to section 7.2, to appear in rev08.
>
>Thanks.
>--
>Mallikarjun
>
>
>Mallikarjun Chadalapaka
>Networked Storage Architecture
>Network Storage Solutions Organization
>MS 5668	Hewlett-Packard, Roseville.
>cbm@rose.hp.com
>
>>Julian,
>>
>>I dont know if this has been already discussed. If so forgive me and point
>>me to the link please.
>>
>>In Section 7.4, in draft 7 (page 115)it is stated that the target may
>>request retransmission
>>with a R2T. It then goes on to say that non-data PDU. It does not talk
>about
>>unsolicited data PDUs, explicitly.
>>I presume that data digest errors in unsolicited and immediate data PDUs
>>cannot be retried and should be responded
>>with delivery-subsystem failure. Is this correct? If so, why is this
>>requirement ?
>>
>>In section 7.11.1, page 119, the spec. implies that digest errors in data
>>PDUs may be recovered by issuing R2T. Once again,
>>it fails to talk about digest errors in immediate data unsolicited data
>>PDUs.
>>
>>Thanks
>>
>>Deva
>>Platys communications


From owner-ips@ece.cmu.edu  Wed Aug 22 00:05:51 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08184
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 00:05:51 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7M2cGr16099
	for ips-outgoing; Tue, 21 Aug 2001 22:38:16 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from chmls05.mediaone.net (chmls05.mediaone.net [24.147.1.143])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7M2cFe16094
	for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 22:38:15 -0400 (EDT)
Received: from cs.uchicago.edu (h005018030f43.ne.mediaone.net [24.91.87.73])
	by chmls05.mediaone.net (8.11.1/8.11.1) with ESMTP id f7M2cDZ19862
	for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 22:38:14 -0400 (EDT)
Message-Id: <200108220238.f7M2cDZ19862@chmls05.mediaone.net>
To: ips@ece.cmu.edu
Subject: Re: iSCSI: Support Alias in the protocol 
In-Reply-To: Message from Robert Snively <rsnively@Brocade.COM> 
   of "Mon, 20 Aug 2001 14:24:40 PDT." <FFD40DB4943CD411876500508BAD02790299374D@sj5-ex2.brocade.com> 
References: <FFD40DB4943CD411876500508BAD02790299374D@sj5-ex2.brocade.com> 
Date: Tue, 21 Aug 2001 22:37:50 -0400
From: Stephen Bailey <steph@cs.uchicago.edu>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Bob,

> That we call our car Skeezix (human useable, for management
> purposes within the tightly constrained context of our own
> family) is non-architected information.

What's your position on the SCSI LU alias?  Do you think that was a
bad idea too?


From owner-ips@ece.cmu.edu  Wed Aug 22 01:13:31 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10218
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 01:13:31 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7M4N9K20545
	for ips-outgoing; Wed, 22 Aug 2001 00:23:09 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from siaar1aa.compuserve.com (siaar1aa.compuserve.com [149.174.40.9])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7M4N7e20541
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 00:23:07 -0400 (EDT)
Received: (from mailgate@localhost)
	by siaar1aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id AAA19075
	for ips@ece.cmu.edu; Wed, 22 Aug 2001 00:22:58 -0400 (EDT)
Received: from compuserve.com (dal-tgn-tkr-vty51.as.wcom.net [216.192.229.51])
	by siaar1aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id AAA19028
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 00:22:50 -0400 (EDT)
Message-ID: <3B8334AE.83B6FEE7@compuserve.com>
Date: Tue, 21 Aug 2001 23:27:26 -0500
From: Ralph Weber <ralphoweber@compuserve.com>
Reply-To: ENDL_TX@computer.org
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47  (Win95; I)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: IPS Reflector <ips@ece.cmu.edu>
Subject: IPS: FCIP & this list
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

David,

To be honest, the following is more than a little
difficult to accept.

On 17 August 2001, David Black wrote:

> While I'm at it, it appears to me that the FCIP authors
> are reverting to the unfortunate habit of holding technical
> discussions off-line and not sharing them with the list.

First, the FCIP authors are posting their works to this
reflector.  Otherwise, there would have been nothing
to complain about vis-a-vis the content of the FCIP
draft on 17 August.

Second, this reflector is clearly the ALL iSCSI ALL THE
TIME reflector.  In the last 24 hours, no fewer than two
new postings to this reflector have failed to include the
project identifier in the subject as requested by John
Hufferd and myself less than two weeks ago.

And why should people bother to prefix iSCSI postings with
"iSCSI:" when one of the co-chairs violated the protocol
as recently as yesterday morning with a posting titled
"FW: I-D ACTION:draft-black-ips-iscsi-security-01.txt".

The FCIP authors are trying to complete their draft
under clearly disadvantaged circumstances.  Due diligence
is being made to bring issues to this reflector and to
respond to the concerns raised here.  And, I have no
doubt that the issue raised on 17 August will be addressed
in due course.

But it is patent nonsense to claim that the FCIP authors
should be trying to use this reflector in the traditional
IETF manner.  This reflector belongs to iSCSI, and to all
practical purposes it belongs ONLY to iSCSI.

FCIP (and for that matter iFCP) are barely tolerated,
uninvited guests, or at least that is how it feels
every time I review the directory the day's new messages.

Ralph...




From owner-ips@ece.cmu.edu  Wed Aug 22 01:14:26 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10334
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 01:14:21 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7M3gZO18799
	for ips-outgoing; Tue, 21 Aug 2001 23:42:35 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7M3gXe18794
	for <ips@ece.cmu.edu>; Tue, 21 Aug 2001 23:42:33 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id FAA204004
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 05:42:26 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7M3gPe60898
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 05:42:25 +0200
Importance: Normal
Subject: Re: A Question on "Full Feature Phase" of iSCSI 07
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFCBC716A9.9B25A5D2-ONC2256AB0.0014197E@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Wed, 22 Aug 2001 06:41:57 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 22/08/2001 06:42:25
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

There is no default target anymore. The default target has been replaced by
a session of type discovery in which you don't have to give a target name.

Julo

"Lee Xing" <lxing@Crossroads.com>@ece.cmu.edu on 21-08-2001 01:56:29

Please respond to "Lee Xing" <lxing@Crossroads.com>

Sent by:  owner-ips@ece.cmu.edu


To:   <ips@ece.cmu.edu>
cc:
Subject:  A Question on "Full Feature Phase" of iSCSI 07



Hi,

On iSCSI 07 page 23 (section 1.2.5), it says "... A session is in full
feature phase after successfully finishing the login phase on the first
(leading) connection of a session. A connection is in full feature phase
if the session in full feature phase and the connection login has
completed successfully."

I assume that the above statements are not true after logging into the
default target "iSCSI", right?  If so, should we make them clearer?

Thank you.


Lee Xing
Sr. Software Engineer
Crossroads Systems, Inc.






From owner-ips@ece.cmu.edu  Wed Aug 22 03:42:16 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27131
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 03:42:16 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7M6lK726549
	for ips-outgoing; Wed, 22 Aug 2001 02:47:20 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from c007.snv.cp.net (c007-h000.c007.snv.cp.net [209.228.33.206])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f7M6lIe26544
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 02:47:18 -0400 (EDT)
Received: (cpmta 24868 invoked from network); 21 Aug 2001 23:47:12 -0700
Received: from dsl-64-130-130-105.telocity.com (HELO littlejoy) (64.130.130.105)
  by smtp.telocity.com (209.228.33.206) with SMTP; 21 Aug 2001 23:47:12 -0700
X-Sent: 22 Aug 2001 06:47:12 GMT
From: "Douglas Otis" <dotis@sanlight.net>
To: <ENDL_TX@computer.org>, "IPS Reflector" <ips@ece.cmu.edu>
Subject: RE: FCIP & this list
Date: Tue, 21 Aug 2001 23:45:26 -0700
Message-ID: <NEBBJGDMMLHHCIKHGBEJCEJMCKAA.dotis@sanlight.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <3B8334AE.83B6FEE7@compuserve.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Ralph,

You appear to be sensitive to the amount of traffic being waged in the iSCSI
battle.  To be fair to David, if you had a filter on your email subjects
looking for iscsi, then even his message would have been redirected.  You
could even positively filter for FCIP.  Two messages a day does not sound
like a heavy burden however to be handled manually.  Perhaps general
announcements could include a list of filter words.

Doug


> David,
>
> To be honest, the following is more than a little
> difficult to accept.
>
> On 17 August 2001, David Black wrote:
>
> > While I'm at it, it appears to me that the FCIP authors
> > are reverting to the unfortunate habit of holding technical
> > discussions off-line and not sharing them with the list.
>
> First, the FCIP authors are posting their works to this
> reflector.  Otherwise, there would have been nothing
> to complain about vis-a-vis the content of the FCIP
> draft on 17 August.
>
> Second, this reflector is clearly the ALL iSCSI ALL THE
> TIME reflector.  In the last 24 hours, no fewer than two
> new postings to this reflector have failed to include the
> project identifier in the subject as requested by John
> Hufferd and myself less than two weeks ago.
>
> And why should people bother to prefix iSCSI postings with
> "iSCSI:" when one of the co-chairs violated the protocol
> as recently as yesterday morning with a posting titled
> "FW: I-D ACTION:draft-black-ips-iscsi-security-01.txt".
>
> The FCIP authors are trying to complete their draft
> under clearly disadvantaged circumstances.  Due diligence
> is being made to bring issues to this reflector and to
> respond to the concerns raised here.  And, I have no
> doubt that the issue raised on 17 August will be addressed
> in due course.
>
> But it is patent nonsense to claim that the FCIP authors
> should be trying to use this reflector in the traditional
> IETF manner.  This reflector belongs to iSCSI, and to all
> practical purposes it belongs ONLY to iSCSI.
>
> FCIP (and for that matter iFCP) are barely tolerated,
> uninvited guests, or at least that is how it feels
> every time I review the directory the day's new messages.
>
> Ralph...
>
>
>



From owner-ips@ece.cmu.edu  Wed Aug 22 03:44:27 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27167
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 03:44:27 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7M6lee26564
	for ips-outgoing; Wed, 22 Aug 2001 02:47:40 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7M6lce26559
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 02:47:38 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id IAA13664
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 08:47:29 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7M6lTO54018
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 08:47:29 +0200
Importance: Normal
Subject: Re: Security in iSCSI
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF18B54B43.763EE069-ONC2256AB0.00239D2A@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Wed, 22 Aug 2001 09:46:59 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 22/08/2001 09:47:29
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

David,

To be absolutely correct the issue of removing the option of cryptographyc
digest was brough up
by you as a possibility,  under the now fashionable umbrela of
simplification, and I agree that we might want to
remove some of them and limit ourselves to the set close to what we intend
to make mandatory to implement (e.g., if we make SRP mandatory to implement
then a SRP "keyed" digest could be the right thing to specify - not
mandate).  As Kerberos and CHAP are popular in enterprises due to their
manageability removing them and leving the implementation for them to be
completely vendor specific is not a good idea.

There was no consesus call on it and people interested in protecting their
data when passing through iSCSI proxies might object to removing a stronger
authetication option for the data passing through proxies.  CRCs can
protect you only against accidental errors and are useless as data
authenticators.

Removing them will not make the protocol simpler ( a weak form of digests
is bound to remain) and will remove
a strong form of data authentication through proxies.

Julo



Black_David@emc.com@ece.cmu.edu on 21-08-2001 17:22:26

Please respond to Black_David@emc.com

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  Re: Security in iSCSI



Howard,

> I have been trying to follow the evolving story on authentication,
> digests, SRP and ESP for a few weeks.  In light of draft 07 and David's
> recent offering, draft-black-ips-iscsi-security-01.txt, I need to ask
> some questions to help me clarify some of the implications for an
> implementation.

"Evolving" is definitely a good word to describe the situation.  Please
also see draft-aboba-ips-iscsi-security-00.txt.

> Some items I had taken as true:
> 1. Draft 7, section 2.2 has optional, separate header and data digest
> areas and says that this separation is useful for routing applications.

Digests are currently CRC-only.  They no longer have any security
use/significance/importance.  The usefulness of separate header and data
digests is that they allow an iSCSI proxy to preserve the data CRCs rather
than having to regenerate CRCs covering both header and data when the
header
is changed.

>  2. Draft 7 indicates that there must be mandatory support for CRC-32c
> for both header and data. Presumably this would imply one use of a 32 bit
> header and data digest to carry the CRC32.

Yes.

> Draft 7 states that "Implementations MAY also negotiate digests with
> security significance for data authentication and integrity".

That sentence and the table following it (including the Note below the
table)
are vestiges of an earlier discarded approach to security.  They will be
removed in the -08 version of the draft.  This is partly my fault for not
asking that they be removed some months ago.

> 3. Draft 7 Appendix A also indicates a mandatory authentication method:
> "Initiator and target MUST implement SRP."

Correct.

> 4. Draft 7 Appendix A offers some guidelines that some types of header
> and data digest presume certain kinds of authentication (e.g., "KRB5_*
> digests are allowed only when combined with KRB5 authentication method").
> There are no digests listed for CHAP and SRP so presumably these
> authentication methods use CRC-32c or None.

All of that "guideline" text sill be removed in -08.  CRC-32C is **NOT**
a useful data authentication method, - it's entirely too easy for an
adversary to tamper with the data and adjust the CRC to cover its tracks,
even in the presence of simple keying, as WEP has learned to its chagrin.
(encrypting the CRC with a block cipher [i.e., NOT RC4] would have been
better, but that would still not be real cryptographic integrity).

> Up to this point I had been thinking that the header and data digests
> were to be  used for all data authentication (even cryptographic
> integrity). If there was to be any data confidentiality, that would be
> outside of iSCSI and probably accompanied by no header and data digest
> usage.

That digest approach was discarded in Orlando in January.  The remaining
security digest descriptions will be removed from the -08 version of the
draft.  Confidentiality has become "MUST implement" as of the London IETF
meetings.

> Then I read in David's paper, Section 4.3: "The current status is that
> ESP [RFC-2406] with NULL encryption has been chosen as the implementation
> approach to meet this requirement (Cryptographic Integrity and Data
Origin
> Authentication), but the Authentication Algorithm (MAC, e.g., HMAC-SHA1)
> has not been selected."

That's correct.

> 1. Does SRP authentication imply ESP with NULL encryption? Of course this
> is security at the IP level rather than the iSCSI layer.

SRP authentication does not imply NULL encryption - step 3) in Section 6.3
of draft-black-ips-iscsi-security-01.txt describes generation of both
encryption and authentication keying material.  If IKE is used, SRP would
still be "MUST implement", and IKE generates both encryption and
authentication keying material.

> What about a different header and data digest method?

ESP is the only approach currently being pursued for standardization.
Any proposal to go back to doing inband header and data digests encounter
strong resistance, and is unlikely to meet with the IESG's approval.

> 2. Is there thought that the 'hash' result of SRP could be applied to
> the header and the data separately using the digests in the PDU?

No, that approach to using inband security digests has been abandoned.

> 3. Under what conditions are the header and data digests used?

When CRC protection is desired, e.g., ESP is not being used (it is
negotiable) and the TCP/IP checksums are felt to be insufficient.

> 4. I am not an IPsec expert, but I thought that one way IPsec is used
> is to set up a tunnel for all traffic from one IP address to another.

That's one way, but not the only way.  See RFC 2401.

> Is it possible that an initiator might want an iSCSI TCP stream and an
> HTTP stream to the same IP address with different levels of security?
> Using the iSCSI header and data digests, this would be possible.

Yes, it's possible, and IPsec can support this, although that level of
support is not REQUIRED by IPsec.  See Section 4.4 of RFC 2401 for a
discussion of the IPsec Security Policy Database where this functionality
would reside.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------





From owner-ips@ece.cmu.edu  Wed Aug 22 04:31:16 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27594
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 04:31:16 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7M7aG628394
	for ips-outgoing; Wed, 22 Aug 2001 03:36:16 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from bramg1.net.external.hp.com (bramg1.net.external.hp.com [192.6.126.73])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7M7aEe28389
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 03:36:14 -0400 (EDT)
Received: from quasit.br.itc.hp.com (quasit.br.itc.hp.com [15.145.8.135])
	by bramg1.net.external.hp.com (Postfix) with ESMTP
	id A30EB154; Wed, 22 Aug 2001 09:36:33 +0200 (METDST)
Received: from loddon.br.itc.hp.com (loddon.br.itc.hp.com [15.145.8.166])
	by quasit.br.itc.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id IAA18775;
	Wed, 22 Aug 2001 08:36:12 +0100 (BST)
Received: from 15.145.8.166 by loddon.br.itc.hp.com (InterScan E-Mail VirusWall NT); Wed, 22 Aug 2001 08:36:12 +0100 (GMT Daylight Time)
Received: by loddon.br.itc.hp.com with Internet Mail Service (5.5.2653.19)
	id <QN1BRVH5>; Wed, 22 Aug 2001 08:36:12 +0100
Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC101E7A832@dickens.bri.hp.com>
From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <matthew_burbridge@hp.com>
To: "'Steve Senum'" <ssenum@cisco.com>, ietf-ips <ips@ece.cmu.edu>
Subject: RE: iSCSI: Login Proposal
Date: Wed, 22 Aug 2001 08:36:11 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Steve,

The reason why it was decided to do this was two fold:

If the initiator does not want to negotiate security then it must not have
any security parameters in the login command.  Therefore
SecurityContextComplete=yes is unnecessary.

If the initiator does want to enter into security as per your example, then
it MUST not send SecurityContextComplete=yes as its security context is not
yet built: Page 101 of 0.7 states that

QUOTE
-Every party in the security negotiation indicates that it has 
           completed building its security context (has all the required 
           information) by sending the key=value pair: 
            
           SecurityContextComplete=yes 
UNQUOTE

My understanding is that its security context is not yet built until it has
received the security parameter replies from (in your example) the
initiator.

Cheers

Matthew

-----Original Message-----
From: Steve Senum [mailto:ssenum@cisco.com]
Sent: Tuesday, August 21, 2001 9:14 PM
To: ietf-ips
Subject: Re: iSCSI: Login Proposal


Matthew/Marjorie/Bob:

Some questions on your login proposal:

1. Why the following restriction?

    SecurityContextComplete=yes MUST NOT be present
    in the login command.

I don't see the benefit in not allowing something like:

I: AuthMethod:none
   HeaderDigest:crc-32c,none
   DataDigest:crc-32c,none
   SecurityContextComplete=yes
T: AuthMethod:none
   HeaderDigest:crc-32c
   DataDigest:crc-32c
   SecurityContextComlete=yes

2. In the following:

    If the login command does not contain security parameters
    the target MUST perform one of the two actions below:

    a) If the target requires security negotiation
       to be performed, then it MUST enter the security
       phase and MUST send a text response containing
       one or more security parameters and F=0.

    b)

Is this really needed?  Why not simply require the
initiator to offer security parameters if it supports them?
I would hope authentication would become the typical case
for login.

3. Is there only one Login Reponse then (just asking)?

Regards,
Steve Senum


From owner-ips@ece.cmu.edu  Wed Aug 22 05:24:29 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28242
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 05:24:28 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7M8ORq00285
	for ips-outgoing; Wed, 22 Aug 2001 04:24:27 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from bramg1.net.external.hp.com (bramg1.net.external.hp.com [192.6.126.73])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7M8OOe00275
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 04:24:24 -0400 (EDT)
Received: from quasit.br.itc.hp.com (quasit.br.itc.hp.com [15.145.8.135])
	by bramg1.net.external.hp.com (Postfix) with ESMTP
	id C299816A; Wed, 22 Aug 2001 10:24:43 +0200 (METDST)
Received: from fowey.BR.ITC.HP.COM (fowey.br.itc.hp.com [15.145.8.186])
	by quasit.br.itc.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id JAA28827;
	Wed, 22 Aug 2001 09:24:23 +0100 (BST)
Received: from 15.145.8.186 by fowey.BR.ITC.HP.COM (InterScan E-Mail VirusWall NT); Wed, 22 Aug 2001 09:23:50 +0100 (GMT Daylight Time)
Received: by fowey.br.itc.hp.com with Internet Mail Service (5.5.2653.19)
	id <Q94WNXX8>; Wed, 22 Aug 2001 09:23:50 +0100
Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC101E7A833@dickens.bri.hp.com>
From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <matthew_burbridge@hp.com>
To: "'Steve Senum'" <ssenum@cisco.com>, ietf-ips <ips@ece.cmu.edu>
Subject: RE: iSCSI: Login Proposal
Date: Wed, 22 Aug 2001 09:24:21 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Hi Steve,

I forgot to answer your latter two questions in my earlier email!

Comments within:-

Cheers

Matthew

-----Original Message-----
From: Steve Senum [mailto:ssenum@cisco.com]
Sent: Tuesday, August 21, 2001 9:14 PM
To: ietf-ips
Subject: Re: iSCSI: Login Proposal


Matthew/Marjorie/Bob:

Some questions on your login proposal:

1. Why the following restriction?

    SecurityContextComplete=yes MUST NOT be present
    in the login command.

I don't see the benefit in not allowing something like:

I: AuthMethod:none
   HeaderDigest:crc-32c,none
   DataDigest:crc-32c,none
   SecurityContextComplete=yes
T: AuthMethod:none
   HeaderDigest:crc-32c
   DataDigest:crc-32c
   SecurityContextComlete=yes

2. In the following:

    If the login command does not contain security parameters
    the target MUST perform one of the two actions below:

    a) If the target requires security negotiation
       to be performed, then it MUST enter the security
       phase and MUST send a text response containing
       one or more security parameters and F=0.

    b)

Is this really needed?  Why not simply require the
initiator to offer security parameters if it supports them?
I would hope authentication would become the typical case
for login.

MATTHEW: So I was maintaining flexibility here.  If an initiator prefers not
to negotiate security then why force it? Also, the login is faster if
neither side want to negotiate security.  I think the majority of people
would go for flexibility and provided that the procedure caters for all four
scenarios of either side wanting/not wanting security then the flexibility
should be present.  In other words, as long as the flexibility does not
cause interoperability problems and allows everyone to do what they want to
do then the flexibility should be there. I agree that the typical case would
be to include authentication but some people will always want to skip it.

3. Is there only one Login Reponse then (just asking)?

MATTHEW: yes.  In deriving the proposal we came to the conclusion that the
partial login response is unnecessary so we removed it.  Also, some
implementers have said that this makes the implementation easier as they
will always return a text response unless login is completed (successfully
or otherwise).

Regards,
Steve Senum


From owner-ips@ece.cmu.edu  Wed Aug 22 05:26:11 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28257
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 05:26:10 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7M8ngK11836
	for ips-outgoing; Wed, 22 Aug 2001 04:49:42 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7M8nde11830
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 04:49:39 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id KAA350712;
	Wed, 22 Aug 2001 10:49:32 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7M8nVw99650;
	Wed, 22 Aug 2001 10:49:31 +0200
Importance: Normal
Subject: Re:iSCSI Login Proposal
To: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <matthew_burbridge@hp.com>
Cc: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF2E0B95D2.77F6DBCA-ONC2256AB0.002FAB28@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Wed, 22 Aug 2001 11:49:01 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 22/08/2001 11:49:31
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Matthew,

Apologies to you, Marjorie and Bob for "changing the rules" during the
game.

I thought that it was obvious that I am going to rewrite 4 and simplify the
rules by neatly staging the login phase through a binary type indicator
that should show where the command is. Although I was myself not very
thrilled by the idea (presented in London) the meeting ended with a
consensus that I should explore this and that is what I did.

The result is not bad (the stages a clearly delineated, there are fewer
handshakes than before etc.).

Regards,
Julo



From owner-ips@ece.cmu.edu  Wed Aug 22 05:28:10 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28290
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 05:28:10 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7M8V6G00551
	for ips-outgoing; Wed, 22 Aug 2001 04:31:06 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7M8V2e00546
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 04:31:02 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id KAA20350
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 10:30:56 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7M8Uqw79340
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 10:30:52 +0200
Importance: Normal
Subject: iSCSI - Change - Login/Text commands with the binary stage code
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF82FB686A.05CE2141-ONC2256AB0.002CEF1A@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Wed, 22 Aug 2001 11:30:12 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 22/08/2001 11:30:52
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

As was agreed in London I did attempt a rewrite of part 4 (Login Phase) and
added a binary current/next stage
to the all the PDUs involved in the Login Phase (Login/Text command and
response).

Here are the changed parts (2.8, 2.9, 2.10, 2.11 and 4). The Login Appendix
is also changed (attached).

There are some more changes in the appendixes but those are minor.


1.1  Text Command

   The Text Command is provided to allow the exchange of information and
   for future extensions. It permits the initiator to inform a target of
   its capabilities or to request some special operations.


   Byte /    0       |       1       |       2       |       3       |
      /              |               |               |               |
     |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
     +---------------+---------------+---------------+---------------+
    0|X|I| 0x04      |F|B|0 0| CNxSG | Reserved (0)                  |
     +---------------+---------------+---------------+---------------+
    4| Reserved (0)  | DataSegmentLength                             |
     +---------------+---------------+---------------+---------------+
    8| Reserved (0)                                                  |
     +                                                               +
   12|                                                               |
     +---------------+---------------+---------------+---------------+
   16| Initiator Task Tag                                            |
     +---------------+---------------+---------------+---------------+
   20| Reserved (0)                                                  |
     +---------------+---------------+---------------+---------------+
   24| CmdSN                                                         |
     +---------------+---------------+---------------+---------------+
   28| ExpStatSN                                                     |
     +---------------+---------------+---------------+---------------+
   32| Reserved (0)                                                  |
     |                                                               |
     +---------------+---------------+---------------+---------------+
   40| Bookmark or Reserved (0)                                      |
     |                                                               |
     +---------------+---------------+---------------+---------------+
   48| Digests if any...                                             |
     +---------------+---------------+---------------+---------------+
     / DataSegment (Text)                                            /
    +/                                                               /
     +---------------+---------------+---------------+---------------+


1.1.1     F (Final) Bit

   When set to 1 it indicates that this is the last or only text command in
   a sequence of commands; otherwise it indicates that more commands will
   follow.

1.1.2     CNxSG

   Through this field, called Current-Next Stage (CNxSG), the textual
   negotiation commands and responses (Login and Text) are associated with
   a specific stage in the session (SecurityNegotiation,
   LoginOperationalNegotiation, FullPhaseOperationalNegotiations) and may
   indicate the next stage they want to move to (see 4).

   The current stage is coded in bits 0-1 and the next stage in bits 2-3.
   The next stage value is valid only when the F bit is 1 and can be
   ignored otherwise.

   The stage codes are:

      - 0 - SecurityNegotiation
      - 1 - LoginOperationalNegotiation
      - 3 - FullFeaturePhaseOperationalNegotiation

1.1.3     B (Bookmark-valid) Bit

   A value of 1 indicates that the Bookmark field is valid.

1.1.4     Initiator Task Tag

   The initiator assigned identifier for this Text Command.
   If the command is sent as part of a sequence of commands (e.g., the
   Login Phase or a sequence of Text commands) the Initiator Task Tag MUST
   be the same for all the commands within the sequence (similar to linked
   SCSI commands).

1.1.5     Bookmark

   An opaque handle copied from a previous text response.  It is supposed
   to allow a target to transfer a large amount of textual data over a
   sequence of text-command/text-response exchanges.  The target associates
   the bookmark it issues with the Initiator Task Tag and a received
   Bookmark is considered valid by the Target only if received with the
   same Initiator Task Tag and if the target did not receive on the same
   connection a text command with a different Initiator Text Tag since it
   issued the Bookmark.

   A target MAY reject an old Bookmark.

   The Bookmark field is valid only if the B bit is 1.

   Long text responses are handled as in the following example:

      I->T Text SendTargets=all (F=1,B=0)
      T->I Text <part 1> (F=0,B=1,Bookmark)
      I->T Text <empty> (F=1,B=1,Bookmark)
      T->I Text <part 2> (F=0,B=1,Bookmark)
      I->T Text <empty> (F=1,B=1,Bookmark)
      ...
      T->I Text <part n> (F=1,B=0)

1.1.6     Text

   The initiator sends the target a set of key=value or key=list pairs
   encoded in UTF-8 Unicode. All the text keys and text values specified in
   this document are to be presented and interpreted in the case they
   appear in this document (they are case sensitive). The key and value are
   separated by a '=' (0x3D) delimiter. Every key=value pair (including the
   last or only pair) MUST be followed by null (0x00) delimiter.  A list is
   a set of values separated by comma (0x2C). Large binary items can be
   encoded using their hexadecimal representation (e.g., 8190 is 0x1FFE) or
   decimal representation. The maximum length of an individual value (not
   its string representation) is 255 bytes.

   The data lengths of a text command or response MUST NOT exceed 4096
   bytes.  Key names MUST NOT exceed 63 bytes. Key values MUST NOT exceed
   255 characters.

   Character strings are represented as plain text. Numeric and binary
   values are represented using either decimal numbers or the hexadecimal
   0xFFFF notation. Upper and lower case letters may be used
   interchangeably in hexadecimal notation (i.e., 0x1aBc, 0x1AbC and 0x1ABC
   are equivalent).

   The target responds by sending its response back to the initiator. The
   response text format is similar to the request text format.

   Some basic key=value pairs are described in Appendix A and Appendix D.
   All of these keys, except for the X- extension format, MUST be supported
   by iSCSI initiators and targets.

   Manufacturers may introduce new keys by prefixing them with X- followed
   by their (reversed) domain name, for example the company owning the
   domain acme.com can issue:

      X-com.acme.bar.foo.do_something=0000000000000003

   Any other key not understood by the target may be ignored by the target
   without affecting basic function. However the Text Response for a key
   that was not understood MUST be key=NotUnderstood.

   Text operations are usually meant for parameter setting/negotiations but
   can be used also to perform some long lasting operations.

   It is recommended that Text operations that will take a long time should
   be placed in their own Text command.

   A connection may have only one outstanding text command at any given
   time.

1.2

Text Response

   The Text Response PDU contains the target's responses to the initiator's
   Text Command. The format of the Text field matches that of the Text
   Command.


   Byte /    0       |       1       |       2       |       3       |
      /              |               |               |               |
     |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
     +---------------+---------------+---------------+---------------+
    0|1|1| 0x24      |F|B|0 0| CNxSG | Reserved (0)                  |
     +---------------+---------------+---------------+---------------+
    4| Reserved (0)  | DataSegmentLength                             |
     +---------------+---------------+---------------+---------------+
    8| Reserved (0)                                                  |
     +                                                               +
   12|                                                               |
     +---------------+---------------+---------------+---------------+
   16| Initiator Task Tag                                            |
     +---------------+---------------+---------------+---------------+
   20| Reserved (0)                                                  |
     +---------------+---------------+---------------+---------------+
   24| StatSN                                                        |
     +---------------+---------------+---------------+---------------+
   28| ExpCmdSN                                                      |
     +---------------+---------------+---------------+---------------+
   32| MaxCmdSN                                                      |
     +---------------+---------------+---------------+---------------+
   36| Reserved (0)                                                  |
     +---------------+---------------+---------------+---------------+
   40| Bookmark or Reserved (0)                                      |
     |                                                               |
     +---------------+---------------+---------------+---------------+
   48| Digests if any...                                             |
     +---------------+---------------+---------------+---------------+
     / DataSegment (Text)                                            /
    +/                                                               /
     +---------------+---------------+---------------+---------------+

1.2.1     F (Final) Bit

   When set to 1 in response to a text command with the Final bit set to 1
   the F bit indicates that the target has finished the current stage of
   the operation or the whole operation.  Otherwise if set to 0 in response
   to a text command with the Final Bit set to 1 it indicates that the
   target has more work to do (invites a follow-on text command).  A text
   response with the F bit set to 1 in response to a text command with the
   F bit set to 0 is a protocol error.

   A text response with a F bit set to 1 MUST NOT contain key=value pairs
   that may require additional answers from the initiator.

1.2.2     B (Bookmark-valid) Bit

   A value of 1 indicates that the Bookmark field is valid.
   F bit must be 0.

1.2.3     Initiator Task Tag

   The Initiator Task Tag matches the tag used in the initial Text Command
   or the Login Initiator Task Tag.

1.2.4     Bookmark

   An opaque handle to be copied to the next text command by the initiator.
   It is supposed to allow a target to transfer a large amount of textual
   data over a sequence of text-command/text-response exchanges.  The
   target associates the bookmark it issues with the Initiator Task Tag and
   a received Bookmark is considered valid by the Target only if received
   with the same Initiator Task Tag and if the target did not receive on
   the same connection a text command with a different Initiator Text Tag
   since it issued the Bookmark.

   A target MAY reject an old Bookmark.

   The Bookmark is valid only if the F bit is 0 and the B bit is 1.

1.2.5     Text Response Data

   The Text Response Data Segment contains responses in the same key=value
   format as the Text Command and with the same length and coding
   constraints. Appendix C lists some basic Text Commands and their
   Responses.

   Although the initiator is the requesting party and controls the
   request-response initiation and termination the target can offer
   key=value pairs of its own as part of a sequence and not only in
   response to an identical key=value pair offered by the initiator.

1.3

Login Command

   After establishing a TCP connection between an initiator and a target,
   the initiator MUST issue a Login Command to gain further access to the
   target's resources.

   A Login Command MUST NOT be issued more than once on an iSCSI TCP
   connection.


   Byte /    0       |       1       |       2       |       3       |
      /              |               |               |               |
     |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
     +---------------+---------------+---------------+---------------+
    0|X|I| 0x03      |F|0 0 0| CNxSG | Version-max   | Version-min   |
     +---------------+---------------+---------------+---------------+
    4| Reserved (0)  | DataSegmentLength                             |
     +---------------+---------------+---------------+---------------+
    8| CID                           | Reserved (0)                  |
     +---------------+---------------+---------------+---------------+
   12| ISID                          |TSID                           |
     +---------------+---------------+---------------+---------------+
   16| Initiator Task Tag                                            |
     +---------------+---------------+---------------+---------------+
   20| Reserved (0)                                                  |
     +---------------+---------------+---------------+---------------+
   24| CmdSN   or   Reserved (0)                                     |
     +---------------+---------------+---------------+---------------+
   28| ExpStatSN   or   Reserved (0)                                 |
     +---------------+---------------+---------------+---------------+
   32/ Reserved (0)                                                  /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
   48/ DataSegment - Login Parameters in Text Command Format         /
    +/                                                               /
     +---------------+---------------+---------------+---------------+

1.3.1     X - Restart

   If this bit is set to 1 then this command is an attempt to reinstate a
   failed connection. CID does not change and this command performs first
   the logout function of the old connection if an explicit logout was not
   performed earlier. In sessions with a single connection, this may imply
   the opening of a second connection with the sole purpose of cleaning-up
   the first. Targets should support opening a second connection even when
   not supporting multiple connections in full feature phase.  A restart
   login indicates to the target that commands may be missing and therefore
   it should be handled immediately.


1.3.2     F (Final) Bit

   If set to 1 indicates that the initiator has no more parameters to set.

1.3.3     Version-max

   Maximum Version number supported.

1.3.4     Version-min

   Minimum Version supported
   The version number of the current draft is 0x2.



1.3.5     CID

   This is a unique ID for this connection within the session.


1.3.6     ISID

   This is an initiator-defined session-identifier.  It MUST be the same
   for all connections within a session.  A SCSI initiator port is uniquely
   identified by the value pair (InitiatorName, ISID).

   When a target is detecting an attempt to open a new session by the same
   SCSI initiator port (same InitiatorName and ISID) to the same target
   portal group it MUST check if the old session is still active.  If it is
   not active and the target has failed to realize that the old-session
   must be reset by the target and the new session established. Otherwise
   the Login MUST be terminated with a Login Response of "Session already
   open with this initiator".

1.3.7     CmdSN

   CmdSN is either the initial command sequence number of a session (for
   the first Login of a session - the "leading" login) or the command
   sequence number in the command stream (e.g., if the leading login
   carries the CmdSN 123 the next command carries the number 124 etc.).

1.3.8     ExpStatSN

   This is ExpStatSN for the old connection.
   This field is valid only if the X bit is set to 1.


1.3.9     Login Parameters

   The initiator MAY provide some basic parameters in order to enable the
   target to determine if the initiator may use the target's resources and
   the initial text parameters for the security exchange.  The format of
   the parameters is as specified for the Text Command.    Keys and their
   explanations are listed in the Appendixes.




1.4  Login Response

   The Login Response indicates the progress and/or end of the login phase.
   Note that after security is established, the login response is
   authenticated.


   Byte /    0       |       1       |       2       |       3       |
      /              |               |               |               |
     |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
     +---------------+---------------+---------------+---------------+
    0|1|1| 0x23      |F|0 0 0| CNxSG | Version-max   | Version-active|
     +---------------+---------------+---------------+---------------+
    4| Reserved (0)  | DataSegmentLength                             |
     +---------------+---------------+---------------+---------------+
    8| Reserved (0)                                                  |
     +---------------+---------------+---------------+---------------+
   12| ISID                          |TSID                           |
     +---------------+---------------+---------------+---------------+
   16| Initiator Task Tag                                            |
     +---------------+---------------+---------------+---------------+
   20| Reserved (0)                                                  |
     +---------------+---------------+---------------+---------------+
   24| StatSN                                                        |
     +---------------+---------------+---------------+---------------+
   28| ExpCmdSN                                                      |
     +---------------+---------------+---------------+---------------+
   32| MaxCmdSN                                                      |
     +---------------+---------------+---------------+---------------+
   36| Status-Class  | Status-Detail | Reserved (0)                  |
     +---------------+---------------+---------------+---------------+
   40/ Reserved (0)                                                  /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
   48| Digests if any...                                             |
     +---------------+---------------+---------------+---------------+
     / DataSegment - Login Parameters in Text Command Format         /
    +/                                                               /
     +---------------+---------------+---------------+---------------+

1.4.1     F (Final) bit

   Final bit is set to one as an indicator of end of stage and if the next
   stage part in CNxSG is FullFeaturePhaseOperationalNegotiation the this
   is also the Final Login Response (see 4). A Final bit of 0 indicates a
   "partial" response, which means "more negotiation needed".

   A login response with a F bit set to 1 MUST NOT contain key=value pairs
   that may require additional answers from the initiator within the same
   stage.


1.4.2     Version-max

   This is the highest version number supported by the target.


1.4.3     Version-active/lowest

   Indicates the version supported (the highest version supported by the
   target and initiator). If the target is not supporting a version within
   the range specified by the initiator, the target rejects the login and
   this field indicates the lowest version supported by the target.

1.4.4     TSID

   The TSID is an initiator SCSI port identifying tag set by the target.
   It MUST be valid only in the final response.

1.4.5     StatSN

   For the first Login Response this is the starting status Sequence Number
   for the connection (the next response of any kind will carry this number
   + 1). This field is valid only if the Status Class is 0.

1.4.6     Status-Class and Status-Detail

   The Status returned in a Login Response indicates the status of the
   login request. The status includes:

      Status-Class
      Status-Detail

   The Status-Class is sufficient for a simple initiator to use when
   handling errors, without having to look at the Status-Detail.  The
   Status-Detail allows finer-grained error recovery for more sophisticated
   initiators, as well as better information for error logging.

   The status classes are as follows:

      0 - Success - indicates that the iSCSI target successfully received,
      understood, and accepted the request. The numbering fields (StatSN,
      ExpCmdSN, MaxCmdSN are valid only if Status-Class is 0).

      1 - Redirection - indicates that further action must be taken by the
      initiator to complete the request. This is usually due to the target
      moving to a different address. All of the redirection status class
      responses MUST return one or more text key parameters of the type
      "TargetAddress", which indicates the target's new address.

      2 - Initiator Error - indicates that the initiator likely caused the
      error. This MAY be due to a request for a resource for which the
      initiator does not have permission.

      3 - Target Error - indicates that the target is incapable of
      fulfilling the request.

   The table below shows all of the currently allocated status codes.  The
   codes are in hexadecimal; the first byte is the status class and the
   second byte is the status detail.  The allowable state of the Final (F)
   bit in responses with each of the codes is also displayed.

   -----------------------------------------------------------------
   Status        | Code |Final|   Description
                 |(hex) | bit |
   -----------------------------------------------------------------
   Accept Login  | 0000 | 1/0 | Login is OK, moving to Full Feature
                 |      |     | Phase or LoginOperationalNegotiation
                 |      |     | stage (*1)
   -----------------------------------------------------------------
   Authenticate  | 0001 | 0   | The iSCSI TargetName (ITN) exists and
                 |      |     | authentication proceeds.
   -----------------------------------------------------------------
   iSCSI Target  | 0002 | 0   | The ITN must be provided
   Name required |      |     | for authentication to proceed.
   -----------------------------------------------------------------
   Target Moved  | 0101 | 1   | The requested ITN has moved
   Temporarily   |      |     | temporarily to the address provided.
   -----------------------------------------------------------------
   Target Moved  | 0102 | 1   | The requested ITN has moved
   Permanently   |      |     | permanently to the address provided.
   -----------------------------------------------------------------
   Proxy Required| 0103 | 1   | The initiator must use an iSCSI
                 |      |     | proxy for this target.
                 |      |     | The address is provided.
   -----------------------------------------------------------------
   Initiator     | 0200 | 1   | Miscellaneous iSCSI initiator
   Error         |      |     | errors
   -----------------------------------------------------------------
   Security Nego-| 0201 | 1   | The security negotiation failed
   tiation Failed|      |     |
   -----------------------------------------------------------------
   Forbidden     | 0202 | 1   | The initiator is not allowed access
   Target        |      |     | to the given target.
   -----------------------------------------------------------------
   Not Found     | 0203 | 1   | The requested ITN does not
                 |      |     | exist at this address.
   -----------------------------------------------------------------
   Target Removed| 0204 | 1   | The requested ITN has been
                 |      |     | removed. No forwarding address is
                 |      |     | provided.
   -----------------------------------------------------------------
   Target        | 0205 | 1   | Target is currently in use by
   Conflict      |      |     | another initiator and does
                 |      |     | not support multiple initiators.
   -----------------------------------------------------------------
   Initiator     | 0206 | 1   | Invalid TSID - no more connections
   SID error     |      |     | accepted
                 |      |     |
   -----------------------------------------------------------------
   Missing       | 0207 | 1   | Missing parameters (e.g., iSCSI
   parameter     |      |     | Initiator and/or Target Name)
   -----------------------------------------------------------------
   Can't include | 0208 | 1   | Target does not support session
   in session    |      |     | spanning to this connection (address)
   -----------------------------------------------------------------
   Session open  | 0209 | 1   | The iSCSI InitiatorName and ISID
   already with  |      |     | identify an existing session
   this Initiator|      |     | with this initiator
   -----------------------------------------------------------------
   Session type  | 020a | 1   | Target does not support this type of
   Not supported |      |     | of session (not from this Initiator)
   -----------------------------------------------------------------
   Target Error  | 0300 | 1   | Miscellaneous iSCSI target
                 |      |     | errors (out of resources, etc.).
   -----------------------------------------------------------------
   Service       | 0301 | 1   | The iSCSI service or target is not
   Unavailable   |      |     | currently operational.
   -----------------------------------------------------------------
   Unsupported   | 0302 | 1   | The required version is not
   version       |      |     | supported by the target.
   -----------------------------------------------------------------

   (*1)If the Status is "accept login" (0x0000) the initiator has stated
   the current stage as LoginOperationalNegotiation (and if the F bit was 1
   the next stage to FullFeaturePhaseOperationalNegotiation). If the
   response F bit is 1 (the next stage part is also
   FullFeaturePhaseOperationalNegotiation) the login phase is finished and
   the initiator may proceed to issue SCSI commands. If the Status is
   "accept login" (0x0000) and the F bit is 0, the initiator may proceed to
   negotiate operational parameters.

   If the Status Class is not 0, the initiator and target MUST close the
   TCP connection.

   If the target wishes to reject the login request for more than one
   reason, it should return the primary reason for the rejection.

 Part 4 (login) is now:

1.   Login Phase

   In the rest of this chapter, whenever we mention security we mean
   security and/or data integrity.

   The login phase establishes an iSCSI session between initiator and
   target. It sets the iSCSI protocol parameters, security parameters, and
   authenticates the initiator and target to each other.

   The login phase is implemented via login and text commands and responses
   only.  The whole login phase is considered as a single task and has a
   single Initiator Task Tag (similar to the linked SCSI commands).

   The login phase sequence of commands and responses proceeds as follows:

      - Login command (mandatory)
      - Login Partial-Response (optional)
      - Text Command(s) and Response(s) (optional)
      - Login Final-Response (mandatory)

   The Login Final-response accepts or rejects the Login Command.

   The Login Phase MAY include a SecurityNegotiation stage and a
   LoginOperationalNegotiation stage and MUST include at least one of them,
   but the included stage MAY be empty.

   The login and text commands and responses contain a field that indicates
   the negotiation stage (SecurityNegotiation or
   LoginOperationalNegotiation).  If both stages are used the
   SecurityNegotiation MUST precede the LoginOperationalNegotiation.

   Some operational parameters can be negotiated outside login, through
   text command response - called for uniformity -
   FullFeaturePhaseOperationalNegotiation.

   Security MUST be completely negotiated within the Login Phase or
   provided by external means (e.g., IPSec).

   In some environments, a target or an initiator is not interested in
   authenticating its counterpart. It is possible to bypass authentication
   through the Login Command and Response.

   The initiator and target MAY want to negotiate authentication and data
   integrity parameters. Once this negotiation is completed, the channel is
   considered secure.

   Authentication and a Secure Channel setup MAY be performed independent
   of iSCSI (as when using tunneling IPSec or some implementations of
   transport IPSec) in which case the Login phase can be reduced to
   operational parameter negotiations.

   Most of the negotiation keys are allowed only in a specific stage - the
   SecurityNegotiation keys appear all in Appendix A while the
   LoginOperationalNegotiation keys appear in Appendix D.
   Only a limited set of keys (marked as Declarative in Appendix D) may be
   used in any of the 2 stages.

   Any given Login or Text command or response belongs to a specific stage
   and this determines the negotiation keys allowed with the command or
   response.

   Stage transition is performed through a command exchange
   (request/response) carrying the F bit and the same current stage code.
   During this exchange, the next stage selected is the lower of the two
   next stage codes.  The initiator can request a transition whenever it is
   ready but a target can respond with a transition only after it is
   offered one by the initiator.

   In a negotiation sequence, the F bit settings in one pair of text/login
   request-responses have no bearing on the F bit settings of the next
   pair.  An initiator having F bit set to 1 in one pair and being answered
   with an F bit setting of 0 may issue the next request with F bit set to
   0.

   Stage transitions during login (including entering and exit) are
   possible only as outlined in the following table:

   +-----------------------------------------------------------+
   |From     To ->   | Security    | Operational | FullFeature |
   |  |              |             |             |             |
   |  V              |             |             |             |
   +-----------------------------------------------------------+
   | (start)         |  yes        |  yes        |  no         |
   +-----------------------------------------------------------+
   | Security        |  no         |  yes        |  yes        |
   +-----------------------------------------------------------+
   | Operational     |  no         |  no         |  yes        |
   +-----------------------------------------------------------+

   The Login Final-Response that accepts a Login Command can come only as a
   response to a Login command with the F bit set to 1 or a Text Command
   with the F bit set to 1 and both the command and response MUST have
   FullFeaturePhaseOperationalNegotiation in the next stage part of the
   CNxSG field.


1.1  Login Phase Start

   The login phase starts with a login request via a login command from the
   initiator to the target. The login request includes:

      -Protocol version supported by the initiator (currently 0x'02')
      -Session and connection Ids
      -The negotiation stage that the initiator is ready to enter

   Optionally the login request may include:

      -Security/Integrity parameters OR
      -iSCSI operational parameters AND/OR
      -The next negotiation stage that the initiator is ready to enter

   The target can answer the login in the following ways:

      -Login Response with Login Reject.  This is an immediate rejection
      from the target that causes the session to terminate. The F bit of
      the response MUST be set to 1 and the CNxSG is to be ignored
      -Login Response with Login Accept as a final response (F bit set to 1
      and the next part of CNxSG in both command a response are set to
      FullFeaturePhaseOperationalNegotiation). The response includes the
      protocol version supported by the target  and the session ID and may
      include iSCSI operational or security parameters (depending on the
      current stage).
      -Login Response with Login Accept as a partial response indicating
      the start of a negotiation sequence.  The response includes the
      protocol version supported by the target and either
      security/integrity parameters or iSCSI parameters (when no
      security/integrity mechanism is chosen) supported by the target.

   If the initiator decides to forego the SecurityNegotiation stage it
   issues the Login with the CNxSG set to LoginOperationalNegotiation in
   the current stage and the target may replay with a Login Response
   indicating that it is unwilling to accept the connection without
   SecurityNegotiation and terminate the connection.

   If the initiator is willing no negotiate security but it is unwilling to
   make the initial parameter offer and may accept a connection without
   security it issues the Login with the F bit set to 1, the CNxSG set to
   SecurityNegotiation in the current stage and LoginOperationalNegotiation
   in the next stage. If the target is also ready to forego security the
   Login response is empty and has F bit is set to 1 and the CNxSG set to
   SecurityNegotiation in the current stage and LoginOperationalNegotiation
   in the next stage.

   An initiator that can operate without security and with all the
   operational parameters taking the default values issues the Login with
   the F bit set to 1, the CNxSG set to LoginOperationalNegotiation in the
   current stage and FullFeaturePhaseOperationalNegotiation in the next
   stage. If the target is also ready to forego security and
   LoginOperationalNegotiation the Login response is empty and has F bit is
   set to 1 and the CNxSG set to LoginOperationalNegotiation in the current
   stage and FullFeaturePhaseOperationalNegotiation in the next stage.

   A target MAY use the iSCSI Initiator Name as part of its access control
   mechanism; therefore, the iSCSI Initiator Name MUST be sent before the
   target is required to disclose its LUs.

   If the iSCSI Target Name and/or iSCSI Initiator Name is going to be used
   in determining the security mode or it is implicit part of
   authentication, then the iSCSI Target Name and/or iSCSI Initiator Name
   MUST be sent in the login command for the first connection of a session
   to identify the storage endpoint of the session. If sent on new
   connections within an existing session it MUST be the same as the one
   used for the leading connection.  If the iSCSI Target Name and/or iSCSI
   Initiator Name is going to be used only for access control, it can be
   sent after the SecurityNegotiation stage. A target can be accessed
   without a Target Name only if the session type is a discovery session.

   The iSCSI Names MUST be in text command format.

1.2  iSCSI Security and Integrity Negotiation

   The security exchange sets the security mechanism and authenticates the
   user and the target to each other. The exchange proceeds according to
   the algorithms that were chosen in the negotiation phase and is
   conducted by the login and text commands key=value parameters.

   The negotiable security mechanisms include the following modes:

      -Initiator-target authentication - the host and the target
      authenticate themselves to each other. A negotiable algorithm such as
      Kerberos provides this feature.
      -PDU integrity - an integrity/authentication digest is attached to
      each packet.  The algorithm is negotiable.

      Using IPsec for encryption or authentication may eliminate part of
      the security negotiation at the iSCSI level but not necessarily all.

   If security is established in the login phase then after the security
   negotiation is complete, each iSCSI PDU MUST include the appropriate
   digest field if any.

   The negotiation proceeds as follows:

      -The initiator sends a login or text command with an ordered list of
      the options it supports for each subject (authentication algorithm,
      iSCSI parameters and so on). The options are listed in the
      initiator's order of preference.
      -The target MUST reply with the first option in the list it supports
      and is allowed for the specific initiator.  The parameters are
      encoded in UTF8 as key=value.  The initiator MAY also send
      proprietary options. The "none" option, if allowed, MUST be included
      in the list, which indicates that no algorithm is supported by the
      target. For a list of security parameters see Appendix A.

      -The initiator must be aware of the imminent completion of the
      SecurityNegotiation stage and MUST set the F bit to 1 and the next
      stage part of CNxSG to what it would like the next stage to be. The
      target will answer with a Login or Text response with the F bit set
      to 1 and the next stage part of CNxSG to what it would like the next
      stage to be. The next stage selected will be the "lower" of the two.
      If the next stage is FullFeaturePhase, the target MUST respond with a
      Login Response with the Session ID and the protocol version.


   All PDUs sent after the security negotiation stage MUST be built using
   the agreed security.

   If the security negotiation fails at the target then the target MUST
   send the appropriate Login Response PDU.  If the security negotiation
   fails at the initiator, the initiator shall drop the connection.

1.3  Operational Parameter Negotiation During the Login Phase

   Operational parameter negotiation during the login MAY be done:

      - starting with the Login command if the initiator does not offer
      any security/ integrity option
      - starting immediately after the security/integrity negotiation if
      the initiator and target perform such a negotiation

   An operational parameter negotiation on a connection MUST NOT start
   before the security negotiation if a security negotiation exists.

   Operational parameter negotiation MAY involve several request-response
   exchanges (login and/or text) started and terminated by the initiator.
   The initiator MUST indicate its intent to terminate the negotiation by
   setting the F bit to 1; the target sets the F bit to 1 on the last
   response. The last response MUST be the Login Response.
   If the target responds to a text or Login command with the F bit set to
   1, with a text response with the F bit set to 0, or a login response
   with the F bit set to 0, the initiator must keep sending the text
   command (even empty) with the F bit set to 1 until it gets the Login
   Response with the F bit set to 1.

   Whenever parameter action or acceptance is dependent of other parameters
   the dependent parameters MUST be sent after the parameters they are
   depending on.  If they are sent within the same command a response for a
   parameter might imply responses for others.

   A target MUST NOT send more than one Login Response with the F bit set
   to 0.

   An initiator MUST send a single Login command per connection, per
   session.

   For a list of operational parameters, see Appendix D.

 The Appendix A is now:

Appendix A.    iSCSI Security and Integrity

01   Security Keys and Values

   The parameters (keys) negotiated for security are:

      - Digests (HeaderDigest, DataDigest)
      - Authentication method (AuthMethod)

   Digests enable checking end-to-end data integrity beyond the integrity
   checks provided by the link layers and covering the whole communication
   path including all elements that may change the network level PDUs like
   routers, switches, proxies, etc.


   The following table lists cyclic integrity checksums that can be
   negotiated for the digests and MUST be implemented by every iSCSI
   initiator and target. Note that these digest options have only error
   detection significance.

   +---------------------------------------------+
   | Name          | Description     | Generator |
   +---------------------------------------------+
   | crc-32C       | 32 bit CRC      | 11EDC6F41 |
   +---------------------------------------------+
   | none          | no digest                   |
   +---------------------------------------------+

   The generator polynomial for this digest is given in hex-notation, for
   example 3b stands for 0011 1011 - the polynomial x**5+X**4+x**3+x+1.


   Padding bytes, when present, in a segment covered by a CRC, should be
   set to 0 and are included in the CRC. The CRC should be calculated as
   follows:

      - data are assumed to be  in the numbering order that appears in the
      draft - start with byte 0 bit 0 continue byte 1 bit 0 etc. (Big
      Endian on bytes / Little Endian on bits)
      - the CRC register is initialized with all 1s (equivalent to
      complementing the first 32 bits of the message)
      - the n PDU bits are considered coefficients of a polynomial M(x) of
      order n-1, with bit 0 of byte 0 being x^(n-1)
      - the polynomial is multiplied by x^32 and divided by G(x)- the
      generator polynomial - producing a remainder R(x) of degree <= 31
      - the coefficients of R(x) are considered a 32 bit sequence
      - the bit sequence is complemented and the result is the CRC
      - after the last bit of the original segment the CRC bits are
      transmitted with x^31 first followed by x^30 etc. ( whenever examples
      are given the value to be specified in examples follows the same
      rules of representation as the rest of this document)
      - a receiver of a "good" segment (data or header) built using the
      generator 0x11EDC6F41 will end-up having in the CRC register the
      value 0x1c2d19ed (this a register value and not a word as outlined in
      this draft)


   Implementations MAY also negotiate digests with security significance
   for data authentication and integrity as detailed in the following
   table:



   +-------------------------------------------------------------+
   | Name          | Description                   | Definition  |
   +-------------------------------------------------------------+
   | KRB5_MD5      | the SGN_CKSUM field (8 bytes) | RFC1964     |
   |               | of the GSS_GetMIC() token in  |             |
   |               | GSS_KRB5_INTEG_C_QOP_MD5 QOP  |             |
   |               | (partial MD5 ("MD2.5") )      |             |
   +-------------------------------------------------------------+
   | KRB5_DES_MD5  | the SGN_CKSUM field (8 bytes) | RFC1964     |
   |               | of the GSS_GetMIC() token in  |             |
   |               | GSS_KRB5_INTEG_C_QOP_DES_MD5  |             |
   |               | QOP (DES MAC of MD5)          |             |
   +-------------------------------------------------------------+
   | KRB5_DES_MAC  | the SGN_CKSUM field (8 bytes) | RFC1964     |
   |               | of the GSS_GetMIC() token in  |             |
   |               | GSS_KRB5_INTEG_C_QOP_ DES_MAC |             |
   |               | QOP (DES MAC)                 |             |
   +-------------------------------------------------------------+
   | SPKM          | the int-cksum field of the    | RFC2025     |
   |               | SPKM-MIC token, calculated    |             |
   |               | without the optional int-alg  |             |
   |               | and snd-seq fields of the     |             |
   |               | mic-header (i.e., the default |             |
   |               | I-ALG is used, and sequencing |             |
   |               | service is not used).         |             |
   +-------------------------------------------------------------+

   Note: the KRB5_* digests are allowed only when combined with KRB5
   authentication method (see below) (i.e., the initiator may offer one of
   these digests only if it also offers KRB5 as AuthMethod, and the target
   may respond with one of these digests only if it also responds with KRB5
   as the AuthMethod). Similarly, the SPKM digest is allowed only when
   combined with SPKM-1 or SPKM-2 authentication methods (see below).


   Other and proprietary algorithms MAY also be negotiated.
   The none value is the only one that MUST be supported.


   The following table details authentication methods:


   +------------------------------------------------------------+
   | Name          | Description                                |
   +------------------------------------------------------------+
   | KRB5          | Kerberos V5                                |
   +------------------------------------------------------------+
   | SPKM-1        | Simple Public-Key GSS-API Mechanism        |
   +------------------------------------------------------------+
   | SPKM-2        | Simple Public-Key GSS-API Mechanism        |
   +------------------------------------------------------------+
   | SRP           | Secure Remote Password                     |
   +------------------------------------------------------------+
   | CHAP          | Challenge Handshake Authentication Protocol|
   +------------------------------------------------------------+
   | none          | No authentication                          |
   +------------------------------------------------------------+

   KRB5 is defined in [RFC1510], SPKM-1, SPKM-2 are defined in
   [RFC2025], Secure Remote Password is defined in [RFC2945] and CHAP is
   defined in [RFC1994].

   Initiator and target MUST implement SRP.

02   Authentication

   The authentication exchange authenticates the initiator to the target,
   and optionally the target to the initiator.  Authentication is not
   mandatory and is distinct from the data integrity exchange.

   The authentication methods to be used are KRB5, SPKM-1, SPKM-2, SRP,
   CHAP, or proprietary.

   For KRB5 (Kerberos V5) [RFC1510], the initiator MUST use:

       KRB_AP_REQ=<KRB_AP_REQ>

   where KRB_AP_REQ is the client message as defined in [RFC1510].

   If the initiator authentication fails, the target MUST return an error.
   Otherwise, if the initiator has selected the mutual authentication
   option (by setting MUTUAL-REQUIRED in the ap-options field of the
   KRB_AP_REQ), the target MUST reply with:

       KRB_AP_REP=<KRB_AP_REP>

   where KRB_AP_REP is the server's response message as defined in
   [RFC1510].

   KRB_AP_REQ,KRB_AP_REP are large binaries encoded as hexadecimal strings.


   For SPKM-1,SPKM-2 [RFC2025], the initiator MUST use:

       SPKM-REQ=<SPKM-REQ>

   where SPKM-REQ is the first initiator token as defined in [RFC2025].

   [RFC2025] defines situations where each side may send an error token
   which may cause the peer to re-generate and resend his last token. This
   scheme is followed in iSCSI, and the error token syntax is:

       SPKM-ERROR=<SPKM-ERROR>

   However, SPKM-DEL tokens that are defined by [RFC2025] for fatal errors
   will not be used by iSCSI. If the target needs (by
   [RFC2025]) to send SPKM-DEL token, it will, instead, send a Login "login
   reject" message and terminate the connection. If the initiator needs to
   send SPKM-DEL token, it will just abort the connection.

   In the sequel, we assume that no SPKM-ERROR tokens are required:

   If the initiator authentication fails, the target MUST return an error.
   Otherwise, if the AuthMethod is SPKM-1 or if the initiator has selected
   the mutual authentication option (by setting mutual-state bit in the
   options field of the REQ-TOKEN in the SPKM-REQ), the target MUST reply
   with:

       SPKM-REP-TI=<SPKM-REP-TI>

   where SPKM-REP-TI is the target token as defined in [RFC2025].

   If mutual authentication was selected and target authentication fails,
   the initiator MUST abort the connection. Otherwise, if the AuthMethod is
   SPKM-1, the initiator MUST continue with:

       SPKM-REP-IT=<SPKM-REP-IT>

   where SPKM-REP-IT is the second initiator token as defined in [RFC2025].

   All the SPKM-* tokens are large binaries encoded as hexadecimal strings.


   For SRP [RFC2945], the initiator MUST use:

      U=<user> TargetAuth=yes   /* or TargetAuth=no */

   The target MUST either return an error or reply with:

      N=<N> g=<g> s=<s>

   The initiator MUST continue with:

      A=<A>

   The target MUST either return an error or reply with:

      B=<B>

   The initiator MUST either abort or continue with:

      M=<M>

   If the initiator authentication fails, the target MUST return an error.
   Otherwise, If the initiator sent TargetAuth=yes in the first message
   (requiring target authentication) the target MUST reply with:

     HM=<H(A | M | K)>


   Where U, N, g, s, A, B, M and H(A | M | K) are defined in [RFC2945].
   U is a text string, N,g,s,A,B,M and H(A | M | K) are numbers.


   For CHAP [RFC1994], the initiator MUST use:

      A=<A1,A2...>

   Where A1,A2... are proposed algorithms, in order of preference.

   The target MUST either return an error or reply with:

      A=<A> I=<I> C=<C>

   Where A is one of A1,A2... that were proposed by the initiator.

   The initiator MUST continue either with:

      N=<N> R=<R>

   or, if he requires target authentication, with:

      N=<N> R=<R> I=<I> C=<C>

   If the initiator authentication fails, the target MUST return an error.
   Otherwise, if the initiator required target authentication, the target
   MUST reply with

      N=<N> R=<R>

   Where N, (A,A1,A2), I, C, R are (correspondingly) the Name, Algorithm,
   Identifier, Challenge and Response as defined in [RFC1994]. N is a text
   string, A,A1,A2,I are numbers and C,R are large binaries encoded as
   hexadecimal strings.

   For the Algorithm, as stated in [RFC1994], one value is required
   to be implemented:
       5       (CHAP with MD5)
   To guarantee interoperability, initiators SHOULD always offer it as one
   of the proposed algorithms.


03   Login Phase Examples

   In the first example, the initiator and target authenticate each other
   via Kerberos:

      I-> Login (CNxSG=0,1 F=1) InitiatorName=iqn.1999-07.com.os.hostid.77
      TargetName=iqn.1999-07.com.acme.diskarray.sn.88
      HeaderDigest=KRB5_MD5,KRB5_DES_MAC,crc-32C,none
      DataDigest=crc-32C,none AuthMethod=SRP,KRB5,none

      T-> Login-PR (CNxSG=0,1 F=0) HeaderDigest=KRB5_MD5 DataDigest=crc-32C
      AuthMethod=KRB5

        (Login-PR stands for Login-Partial-Response)

      I-> Text (CNxSG=0,1 F=1) KRB_AP_REQ=<krb_ap_req>
      (krb_ap_req contains the Kerberos V5 ticket and authenticator with
      MUTUAL-REQUIRED set in the ap-options field)

      If the authentication is successful, the target proceeds with:

      T-> Text (CNxSG=0,1 F=1) KRB_AP_REP=<krb_ap_rep>
      (krb_ap_rep is the Kerberos V5 mutual authentication reply)

      If the authentication is successful, the initiator proceeds.

      From this point on, any Text command and each PDU thereafter has a
      KRB5_MD5 digest for the header and a crc-32C for the data.

      The initiator may proceed:

      I-> Text (CNxSG=1,3 F=0) ... iSCSI Operational Parameters
      T-> Text (CNxSG=1,3 F=0) ... iSCSI Operational Parameters

      And at the end:

      I-> Text (CNxSG=1,3 F=1) optional iSCSI parameters
      TargetName=iqn.1999-07.com.acme.diskarray.sn.88
      T-> Login (CNxSG=1,3 F=1) "login accept"

      If the initiator authentication by the target is not successful, the
      target responds with:

      T-> Login "login reject"

      instead of the Text KRB_AP_REP message, and terminates the
      connection.

      If the target authentication by the initiator is not successful, the
      initiator terminates the connection (without responding to the Text
      KRB_AP_REP message).

   In the next example only the initiator is authenticated by the target
   via Kerberos:

      I-> Login (CNxSG=0,1 F=1) InitiatorName=iqn.1999-07.com.os.hostid.77
      TargetName=iqn.1999-07.com.acme.diskarray.sn.88
      HeaderDigest=KRB5_MD5,KRB5_DES_MAC,crc-32C,none
      DataDigest=crc-32C,none AuthMethod=SRP,KRB5,none
      T-> Login-PR (CNxSG=0,1 F=0)HeaderDigest=KRB5_MD5 DataDigest=crc-32C
      AuthMethod=KRB5

      I-> Text (CNxSG=0,1 F=1)KRB_AP_REQ=krb_ap_req
      (MUTUAL-REQUIRED not set in the ap-options field of krb_ap_req)

      If the authentication is successful, the target proceeds with:

      T-> Text (CNxSG=0,1 F=1)

      From this point on, any Text command and each PDU thereafter MUST
      have a KRB5_MD5 digest for the header and a crc-32C for the data.

      I-> Text (CNxSG=1,3 F=0) ... iSCSI parameters
      T-> Text (CNxSG=1,3 F=0)... iSCSI parameters

      . . .

      T-> Login (CNxSG=1,3 F=1)"login accept"
      TargetName=iqn.1999-07.com.acme.diskarray.sn.88


   In the next example, the initiator and target authenticate each other
   via SPKM-1:

      I-> Login (CNxSG=0,1 F=1) InitiatorName=iqn.1999-07.com.os.hostid.77
      TargetName=iqn.1999-07.com.acme.diskarray.sn.88
      HeaderDigest=KRB5_MD5,KRB5_DES_MAC,SPKM,crc-32C,none
      DataDigest=crc-32C,SPKM,none AuthMethod=SPKM-1,KRB5,none

      T-> Login-PR (CNxSG=0,1 F=0) HeaderDigest=SPKM DataDigest=SPKM
      AuthMethod=SPKM-1

      I-> Text (CNxSG=0,1 F=0) SPKM-REQ=<spkm-req>
      (spkm-req is the SPKM-REQ token with the mutual-state bit in the
      options field of the REQ-TOKEN set)

      T-> Text (CNxSG=0,1 F=0) SPKM-REP-TI=<spkm-rep-ti>

      If the authentication is successful, the initiator proceeds:

      I-> Text (CNxSG=0,1 F=1) SPKM-REP-IT=<spkm-rep-it>

      If the authentication is successful, the target proceeds with:

      T-> Text (CNxSG=0,1 F=1)

      From this point on, any Text command and each PDU thereafter has SPKM
      digests for the header and data.

      The initiator may proceed:

      I-> Text  (CNxSG=1,3 F=0) ... iSCSI parameters
      T-> Text  (CNxSG=1,3 F=0) ... iSCSI parameters

      And at the end:

      I-> Text  (CNxSG=1,3 F=1) optional iSCSI parameters
      T-> Login (CNxSG=1,3 F=1) "login accept"
      TargetName=iqn.1999-07.com.acme.diskarray.sn.88


      If the target authentication by the initiator is not successful, the
      initiator terminates the connection (without responding to the Text
      SPKM-REP-TI message).

      If the initiator authentication by the target is not successful, the
      target responds with:

      T-> Login "login reject"

      instead of the Text SecurityContextComplete=yes message, and
      terminates the connection.


   In the next example, the initiator and target authenticate each other
   via SPKM-2:

      I-> Login (CNxSG=0,1 F=0) InitiatorName=iqn.1999-07.com.os.hostid.77
      TargetName=iqn.1999-07.com.acme.diskarray.sn.88
      HeaderDigest=SPKM,crc-32C,none
      DataDigest=crc-32C,SPKM,none AuthMethod=SPKM-1,SPKM-2

      T-> Login-PR (CNxSG=0,1 F=0) HeaderDigest=SPKM DataDigest=SPKM
      AuthMethod=SPKM-2

      I-> Text (CNxSG=0,1 F=1) SPKM-REQ=<spkm-req>

       (spkm-req is the SPKM-REQ token with the mutual-state bit in the
      options field of the REQ-TOKEN not set)

      If the authentication is successful, the target proceeds with:

      T-> Text (CNxSG=0,1 F=1)

      From this point on, any Text command and each PDU thereafter has SPKM
      digests for the header and data.

      The initiator may proceed:

      I-> Text (CNxSG=1,3 F=0) ... iSCSI parameters
      T-> Text (CNxSG=1,3 F=0) ... iSCSI parameters

      And at the end:

      I-> Text  (CNxSG=1,3 F=1) optional iSCSI parameters
      T-> Login (CNxSG=1,3 F=1) "login accept"
      TargetName=iqn.1999-07.com.acme.diskarray.sn.88


   In the next example, the initiator and target authenticate each other
   via SRP:

      I-> Login (CNxSG=0,1 F=1) InitiatorName=iqn.1999-07.com.os.hostid.77
      TargetName=iqn.1999-07.com.acme.diskarray.sn.88
      HeaderDigest=crc-32C,none DataDigest=crc-32C,none
      AuthMethod=KRB5,SRP,none
      T-> Login-PR  (CNxSG=0,1 F=0) HeaderDigest=crc-32C DataDigest=crc-32C
      AuthMethod=SRP

      I-> Text (CNxSG=0,1 F=0) U=<user> TargetAuth=yes
      T-> Text (CNxSG=0,1 F=0) N=<N> g=<g> s=<s>
      I-> Text (CNxSG=0,1 F=0) A=<A>
      T-> Text (CNxSG=0,1 F=0) B=<B>
      I-> Text (CNxSG=0,1 F=1) M=<M>

      If the initiator authentication is successful, the target proceeds:

      T-> Text (CNxSG=0,1 F=1) HM=<H(A | M | K)>

      Where N, g, s, A, B, M, and H(A | M | K) are defined in [RFC2945].

      If the target authentication is not successful, the initiator
      terminates the connection. Otherwise it proceeds.

      From this point on, any Text command and each PDU thereafter has a
      crc-32C digest for the header and the data.

      I-> Text(CNxSG=1,3 F=0) ... iSCSI parameters
      T-> Text(CNxSG=1,3 F=0) ... iSCSI parameters

      And at the end:

      I-> Text (CNxSG=1,3 F=1) optional iSCSI parameters
      T-> Login  (CNxSG=1,3 F=1) "login accept"
      TargetName=iqn.1999-07.com.acme.diskarray.sn.88

      If the initiator authentication is not successful, the target
      responds with:

      T-> Login "login reject"

      Instead of the T-> Text HM=<H(A | M | K)>  message and terminates the
      connection.

   In the next example only the initiator is authenticated by the target
   via SRP:

      I-> Login (CNxSG=0,1 F=1) InitiatorName=iqn.1999-07.com.os.hostid.77
      TargetName=iqn.1999-07.com.acme.diskarray.sn.88
      HeaderDigest=crc-32C,none DataDigest=crc-32C,none
      AuthMethod=KRB5,SRP,none
      T-> Login-PR (CNxSG=0,1 F=0) HeaderDigest=crc-32C DataDigest=crc-32C
      AuthMethod=SRP

      I-> Text (CNxSG=0,1 F=0) U=<user> TargetAuth=no
      T-> Text (CNxSG=0,1 F=0) N=<N> g=<g> s=<s>
      I-> Text (CNxSG=0,1 F=0) A=<A>
      T-> Text (CNxSG=0,1 F=0) B=<B>
      I-> Text (CNxSG=0,1 F=1) M=<M>

      If the initiator authentication is successful, the target proceeds:

      T-> Text (CNxSG=0,1 F=1)

      From this point on, any Text command and each PDU thereafter has a
      crc-32C digest for the header and the data.

      I-> Text (CNxSG=1,3 F=0) ... iSCSI parameters
      T-> Text (CNxSG=1,3 F=0) ... iSCSI parameters

      And at the end:

      I-> Text (CNxSG=1,3 F=1) optional iSCSI parameters
      T-> Login (CNxSG=1,3 F=1) "login accept"
      TargetName=iqn.1999-07.com.acme.diskarray.sn.88


   In the next example the initiator and target authenticate each other via
   CHAP:

      I-> Login (CNxSG=0,1 F=0) InitiatorName=iqn.1999-07.com.os.hostid.77
      TargetName=iqn.1999-07.com.acme.diskarray.sn.88
      HeaderDigest=crc-32C,none DataDigest=crc-32C,none
      AuthMethod=KRB5,CHAP,none
      T-> Login-PR (CNxSG=0,1 F=0) HeaderDigest=crc-32C DataDigest=crc-32C
      AuthMethod=CHAP

      I-> Text (CNxSG=0,1 F=0) A=<A1,A2>
      T-> Text (CNxSG=0,1 F=0) A=<A1> I=<I> C=<C>
      I-> Text (CNxSG=0,1 F=1) N=<N> R=<R> I=<I> C=<C>

      If the initiator authentication is successful, the target proceeds:

      T-> Text (CNxSG=0,1 F=1) N=<N> R=<R>

      If the target authentication is not successful, the initiator aborts
      the connection. Otherwise it proceeds.

      From this point on, any Text command and each PDU thereafter has a
      crc-32C digest for the header and the data.

      I-> Text (CNxSG=1,3 F=0) ... iSCSI parameters
      T-> Text (CNxSG=1,3 F=0) ... iSCSI parameters

      And at the end:

      I-> Text (CNxSG=1,3 F=1) optional iSCSI parameters
      T-> Login (CNxSG=1,3 F=1) "login accept"
      TargetName=iqn.1999-07.com.acme.diskarray.sn.88

      If the initiator authentication is not successful, the target
      responds with:

      T-> Login "login reject"

      Instead of the Text R=<response> SecurityContextComplete=yes
      message and terminates the connection.


   In the next example only the initiator is authenticated by the target
   via CHAP:

      I-> Login (CNxSG=0,1 F=0) InitiatorName=iqn.1999-07.com.os.hostid.77
      TargetName=iqn.1999-07.com.acme.diskarray.sn.88
      HeaderDigest=crc-32C,none DataDigest=crc-32C,none
      AuthMethod=KRB5,CHAP,none
      T-> Login-PR (CNxSG=0,1 F=0) HeaderDigest=crc-32C DataDigest=crc-32C
      AuthMethod=CHAP

      I-> Text (CNxSG=0,1 F=0) A=<A1,A2>
      T-> Text (CNxSG=0,1 F=0) A=<A1> I=<I> C=<C>
      I-> Text (CNxSG=0,1 F=1) N=<N> R=<R>

      If the initiator authentication is successful, the target proceeds:

      T-> Text (CNxSG=0,1 F=1)
      I-> Text (CNxSG=1,3 F=0) ... iSCSI parameters
      T-> Text (CNxSG=1,3 F=0) ... iSCSI parameters

      And at the end:

      I-> Text (CNxSG=1,3 F=1) optional iSCSI parameters
      T-> Login (CNxSG=1,3 F=1) "login accept"
      TargetName=iqn.1999-07.com.acme.diskarray.sn.88


   In the next example, the initiator does not offer any security/integrity
   parameters, so it may offer iSCSI parameters on the Login PDU with the F
   bit set to 1, and the target may respond with a final Login Response PDU
   immediately:

      I-> Login (CNxSG=1,3 F=1) InitiatorName=iqn.1999-07.com.os.hostid.77
      TargetName=iqn.1999-07.com.acme.diskarray.sn.88  ... iSCSI parameters
      T-> Login (CNxSG=1,3 F=1) "login accept"
      TargetName=iqn.1999-07.com.acme.diskarray.sn.88  ... ISCSI parameters

   In the next example, the initiator does offer security/integrity
   parameters on the Login PDU, but the target does not choose any (i.e.,
   chooses the "none" values):

      I-> Login (CNxSG=0,1 F=1) InitiatorName=iqn.1999-07.com.os.hostid.77
      TargetName=iqn.1999-07.com.acme.diskarray.sn.88
      HeaderDigest=crc-32C,none DataDigest=crc-32C,none
      AuthMethod:KRB5,SRP,none
      T-> Login-PR (CNxSG=0,1 F=1) HeaderDigest=none, DataDigest=none,
      AuthMethod=none

      I-> Text (CNxSG=1,3 F=0) ... iSCSI parameters
      T-> Text (CNxSG=1,3 F=0) ... iSCSI parameters

      And at the end:

      I-> Text (CNxSG=1,3 F=1) optional iSCSI parameters
      T-> Login (CNxSG=1,3 F=1) "login accept"
      TargetName=iqn.1999-07.com.acme.diskarray.sn.88


    Julo



From owner-ips@ece.cmu.edu  Wed Aug 22 05:40:30 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28384
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 05:40:30 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7M96dP12463
	for ips-outgoing; Wed, 22 Aug 2001 05:06:39 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from bramg1.net.external.hp.com (bramg1.net.external.hp.com [192.6.126.73])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7M96be12458
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 05:06:38 -0400 (EDT)
Received: from quasit.br.itc.hp.com (quasit.br.itc.hp.com [15.145.8.135])
	by bramg1.net.external.hp.com (Postfix) with ESMTP
	id EBEB51CD; Wed, 22 Aug 2001 11:06:56 +0200 (METDST)
Received: from loddon.br.itc.hp.com (loddon.br.itc.hp.com [15.145.8.166])
	by quasit.br.itc.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id KAA10313;
	Wed, 22 Aug 2001 10:06:35 +0100 (BST)
Received: from 15.145.8.166 by loddon.br.itc.hp.com (InterScan E-Mail VirusWall NT); Wed, 22 Aug 2001 10:06:35 +0100 (GMT Daylight Time)
Received: by loddon.br.itc.hp.com with Internet Mail Service (5.5.2653.19)
	id <QN1BRY6B>; Wed, 22 Aug 2001 10:06:35 +0100
Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC101E7A834@dickens.bri.hp.com>
From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <matthew_burbridge@hp.com>
To: "'Julian Satran'" <Julian_Satran@il.ibm.com>
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI Login Proposal
Date: Wed, 22 Aug 2001 10:06:32 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Hi Julian,

I was aware of the proposed change (I actually voted for it in London). I
thought of staying with SecurityContextComplete for the time being as it is
nearer the current spec.  I am happy to go either way. Personally I prefer
the put the status in the text command/response (For the new proposal its
not needed in the login command/response).  The login proposal has an
additional state ("Pre-security state") which would need to be reflected in
your proposal.

Is there value is specifying a login state machine in the spec?  I am happy
to do this (I have written one any way) but did not include it in the
proposal for simplicity's sake.

Cheers

Matthew


-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, August 22, 2001 9:49 AM
To: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)
Cc: ips@ece.cmu.edu
Subject: Re:iSCSI Login Proposal


Matthew,

Apologies to you, Marjorie and Bob for "changing the rules" during the
game.

I thought that it was obvious that I am going to rewrite 4 and simplify the
rules by neatly staging the login phase through a binary type indicator
that should show where the command is. Although I was myself not very
thrilled by the idea (presented in London) the meeting ended with a
consensus that I should explore this and that is what I did.

The result is not bad (the stages a clearly delineated, there are fewer
handshakes than before etc.).

Regards,
Julo


From owner-ips@ece.cmu.edu  Wed Aug 22 07:40:59 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00476
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 07:40:58 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7MArrQ16311
	for ips-outgoing; Wed, 22 Aug 2001 06:53:53 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7MArqe16307
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 06:53:52 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id MAA206292
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 12:53:45 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7MArdw69654
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 12:53:44 +0200
Importance: Normal
Subject: Re: Target record not to span PDUs?
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF4C07DE7A.A24DB738-ONC2256AB0.00383C0F@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Wed, 22 Aug 2001 13:22:57 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 22/08/2001 13:53:44
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Good point. I think that we can do this as we have a limit on the size of
an individual record far lower than 4096.

I'll ad the following text to 2.9.5:

   A Key=value pair must be confined to a given text response even in the
   presence of bookmark - i.e., it must start and end within one Text
   Response.

Julo

Tow Wang <Tow_Wang@adaptec.com> on 22-08-2001 05:06:44

Please respond to Tow Wang <Tow_Wang@adaptec.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
Subject:  Target record not to span PDUs?



Julian (and all):

Hello. This is regarding draft 07; could we require that target records NOT
span across
PDU's if a text response for SendTargets is very long? Upon reading
appendix E, it seems
that a response (of 4096 bytes in length) could end with:

[Begin data segment]
...
TargetName=I.got.chopped.4096
TargetAddress=10.1.1.45
[End data segment]

In the above case, one could not determine whether the address is IP V4 or
V6. Even if it
had had enough space to put in the whole address, port and group tag, one
cannot parse and
process the record until inspecting the data segment of the next text
response PDU, and
this would involve cumulative buffering, back-parsing, etc. I think the
above complexity
could be avoided, as I can't imagine any single record exceeding 4096 bytes
in length.

Tow Wang






From owner-ips@ece.cmu.edu  Wed Aug 22 07:42:03 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00521
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 07:42:03 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7MB3jw16647
	for ips-outgoing; Wed, 22 Aug 2001 07:03:45 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7MB3he16643
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 07:03:43 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id NAA117686
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 13:03:36 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7MB3ZO114424
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 13:03:35 +0200
Importance: Normal
Subject: RE: iSCSI: Login Proposal
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFA1883D20.CDEFA1B2-ONC2256AB0.003C1FF6@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Wed, 22 Aug 2001 13:58:33 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 22/08/2001 14:03:35
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

none first is definitely legal (although it may invite the question "who's
first" :-))  Julo

"Wheat, Stephen R" <stephen.r.wheat@intel.com>@ece.cmu.edu on 22-08-2001
03:13:21

Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>

Sent by:  owner-ips@ece.cmu.edu


To:   "'Steve Senum'" <ssenum@cisco.com>, ietf-ips <ips@ece.cmu.edu>
cc:
Subject:  RE: iSCSI: Login Proposal



We're so close!!  See comments (***) below,
Stephen

-----Original Message-----
From: Steve Senum [mailto:ssenum@cisco.com]
Sent: Tuesday, August 21, 2001 4:56 PM
To: ietf-ips
Subject: Re: iSCSI: Login Proposal


Hi Stephen,

I think the assumption is that <something> is usually
preferred over <none>.
*** But we have the option to specify deterministic behavior,
*** over accepting assumptions.

Even if an option is required to be implemented
though (like crc-32c), an Initiator or Target
could be configured to not allow it (including <none>).
However, in such cases, it would be easy to get
into a situation where the Initiator and Target
will never agree and no connection is possible.


I think the offering party (usually the Initiator)
need to be allowed to control the preference.
*** yes, yes, yes, yes, so let it be possible to put <none> first.
*** We get determinism and flexibility.


Steve Senum

"Wheat, Stephen R" wrote:
>
> Yup, I thought I had seen it, but couldn't find it; thanks.  And am now
> embarrassed that I couldn't find it, when it was indeed documented in two
> places.  I'll save related comments for when we go through the spec
clean-up
> phase.
>
> So, the second paragraph you cite from both p22 and p100 imply that a
target
> could avoid selecting "none".  Thus, the initiator could prefer "none",
but
> the target still select another initiator-offered value, hence avoiding
the
> situation you propose, where "none" is always selected.
>
> Yes?
>
> Otherwise, how would a target and initiator be able to select "none", in
the
> presence of the ability to mutually do at least one method?
>
> Aren't there times where either could do all protocols, but both would
> *prefer* to do "none"??
>
> Perhaps my question then is to get Para5 of 1.2.4 on p22 slightly
clarified,
> so as to avoid your conclusion.  I.e., the initiator should be allowed to
> prefer "none" over something else, yet have the target be capable of not
> selecting "none".
>
> Again, I agree with you that the new-and-improved-login proposal would be
> even better with a requirement to have the initiator include its security
> parameters, even if they consist of only "none".
>
> Stephen
>
> -----Original Message-----
> From: Steve Senum [mailto:ssenum@cisco.com]
> Sent: Tuesday, August 21, 2001 2:31 PM
> To: ietf-ips
> Subject: Re: iSCSI: Login Proposal
>
> Hi Stephen,
>
> The current draft (-07) does actually answer your
> question, though it is somewhat buried:
>
> On page 22:
>
>         In "list" negotiation, the offering party sends for each key a
list
>         of values (which may include "none") in its order of preference.
>
>         The responding party answers with the first value from the list
it
>         supports and is allowed to use for the specific initiator.
>
> And on page 100:
>
>           -The initiator sends a text command with an ordered list of the
>            options it supports for each subject (authentication
algorithm,
>            iSCSI parameters and so on). The options are listed in the
>            initiator's order of preference.
>
>            -The target MUST reply with the first option in the list it
>            supports and is allowed for the specific initiator....
>
> Even so, I don't see the value in:
>
> AuthMethod=none,CHAP
>
> Since every implementation must support "none", "CHAP"
> will never get picked.
>
> In the interest of keeping login processing as simple as
> possible, I would simply require the initiator to offer
> what it can support (if anything).  The target can then
> pick a compatiable method, or reject the connection.
>
> Steve Senum
>
> "Wheat, Stephen R" wrote:
> >
> > Good questions, Steve.
> >
> > Question 2 caused me to ponder the concept of key-value preferences.
> I.e.,
> > I suspect that the concept in the proposed login spec was to address
that
> > the initiator may prefer to not have any security digests, but might be
> able
> > to negotiate them if the target insisted.
> >
> > I cannot find anywhere in the I-D that states that a recipient MUST
> consider
> > key=v1,v2,v3 as the sender having preference of v1 over v2, and v2 over
> v3.
> > Thus, I second Q2, but only if key values are to be interpreted in
> > preferential order.  Thus, an initiator could send
> > "DataDigest=none,crc32-c,SPKM", and the target's response MUST honor
the
> > preference order.
> >
> > So, Q4 is: should the values in a key-value list be consider the
sender's
> > preference order that the receiver must honor?
> >
> > Stephen
> >
> > -----Original Message-----
> > From: Steve Senum [mailto:ssenum@cisco.com]
> > Sent: Tuesday, August 21, 2001 1:14 PM
> > To: ietf-ips
> > Subject: Re: iSCSI: Login Proposal
> >
> > Matthew/Marjorie/Bob:
> >
> > Some questions on your login proposal:
> >
> > 1. Why the following restriction?
> >
> >     SecurityContextComplete=yes MUST NOT be present
> >     in the login command.
> >
> > I don't see the benefit in not allowing something like:
> >
> > I: AuthMethod:none
> >    HeaderDigest:crc-32c,none
> >    DataDigest:crc-32c,none
> >    SecurityContextComplete=yes
> > T: AuthMethod:none
> >    HeaderDigest:crc-32c
> >    DataDigest:crc-32c
> >    SecurityContextComlete=yes
> >
> > 2. In the following:
> >
> >     If the login command does not contain security parameters
> >     the target MUST perform one of the two actions below:
> >
> >     a) If the target requires security negotiation
> >        to be performed, then it MUST enter the security
> >        phase and MUST send a text response containing
> >        one or more security parameters and F=0.
> >
> >     b)
> >
> > Is this really needed?  Why not simply require the
> > initiator to offer security parameters if it supports them?
> > I would hope authentication would become the typical case
> > for login.
> >
> > 3. Is there only one Login Reponse then (just asking)?
> >
> > Regards,
> > Steve Senum





From owner-ips@ece.cmu.edu  Wed Aug 22 07:44:56 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00638
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 07:44:56 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7MArqN16306
	for ips-outgoing; Wed, 22 Aug 2001 06:53:52 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7MArne16301
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 06:53:50 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id MAA151904
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 12:53:43 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7MArbw44366
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 12:53:42 +0200
Importance: Normal
Subject: Re: iSCSI:Data Recovery from digest errors ...
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF6FA1BF60.108E96C6-ONC2256AB0.0033C108@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Wed, 22 Aug 2001 12:30:25 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 22/08/2001 13:53:42
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Mallikarjun,

I am not sure that you are right.
For immediate data you have a header digest and a data digest. If the
header is OK the task is most probably instantiated and R2T might be flying
already back when the data-digest error is discovered (data segment can be
long and the target may be trying to keep the pipe full). And immediate
data can be recovered as any data (if EMDP does not prevent it) with R2T.

Julo

"Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on 22-08-2001 01:07:04

Please respond to cbm@rose.hp.com

Sent by:  owner-ips@ece.cmu.edu


To:   deva@stargateip.com
cc:   ips@ece.cmu.edu
Subject:  Re: iSCSI:Data Recovery from digest errors ...



Deva,

Let me respond to your questions.

Currently, the draft assumes that recovery R2Ts can be generated
for digest errors on unsolicited data bursts in separate data PDUs.
This will be explicitly called out as I said in a response to Sandeep:

http://www.pdl.cmu.edu/mailinglists/ips/mail/msg05855.html

The immediate data digest failures however, are not intended to
be recoverable with R2Ts since an iSCSI (and SCSI) task is not
instantiated in that case (rev07, section 7.2).  The rationale
was that it is much easier for the initiator to re-ship the entire
PDU (command+immediate) than build a new data PDU with a Write-data
header (if only a part, command, of the rejected PDU were accepted
on  the target).   Also, accepting partial PDUs didn't seem to make
it easier for targets either.

New wording dealing with immediate data digest failures had already
been added to section 7.2, to appear in rev08.

Thanks.
--
Mallikarjun


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

>Julian,
>
>I dont know if this has been already discussed. If so forgive me and point
>me to the link please.
>
>In Section 7.4, in draft 7 (page 115)it is stated that the target may
>request retransmission
>with a R2T. It then goes on to say that non-data PDU. It does not talk
about
>unsolicited data PDUs, explicitly.
>I presume that data digest errors in unsolicited and immediate data PDUs
>cannot be retried and should be responded
>with delivery-subsystem failure. Is this correct? If so, why is this
>requirement ?
>
>In section 7.11.1, page 119, the spec. implies that digest errors in data
>PDUs may be recovered by issuing R2T. Once again,
>it fails to talk about digest errors in immediate data unsolicited data
>PDUs.
>
>Thanks
>
>Deva
>Platys communications
>
>
>
>-----Original Message-----
>From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
>Julian Satran
>Sent: Friday, August 17, 2001 3:23 PM
>To: Mark Bakke
>Cc: Douglas Otis; Sanjay Goyal; Ips (E-mail)
>Subject: Re: iSCSI: [Fwd: Crc-32c example in iSCSI spec]
>
>
>
>Mark & all,
>
>The 2 "additions" you will find in the CRC calculation:
>
>   initializing the "remainder" field with all ones (instead of the
implied
>   shifting in of 0's) and
>   XORing the result with a mask (usually "full house")
>
>
>are done to improve the error correction capabilities of CRCs.
>CRCs are weak in detecting the spurious addition of leading 0s (that can
>result from clocking errors) and the deletion of initial 1 with spurious
>insertion of a 1 at the end.
>
>Julo
>
>Mark Bakke <mbakke@cisco.com>@ece.cmu.edu on 17-08-2001 23:10:22
>
>Please respond to Mark Bakke <mbakke@cisco.com>
>
>Sent by:  owner-ips@ece.cmu.edu
>
>
>To:   Douglas Otis <dotis@sanlight.net>
>cc:   Sanjay Goyal <sanjay_goyal@ivivity.com>, "Ips (E-mail)"
>      <ips@ece.cmu.edu>
>Subject:  Re: iSCSI: [Fwd: Crc-32c example in iSCSI spec]
>
>
>
>OK.  I don't see any reason for sending the CRC inverted either
>(we would just have a different remainder poly), but since Ethernet
>does it that way, and it doesn't cost anything, we might as well
>do it, too.
>
>--
>Mark
>
>Douglas Otis wrote:
>>
>> Mark,
>>
>> The reason for the bit swap within the table is to allow a serial
>hardware
>> scheme as CRC is processed ms to ls over the entire stream as if a
single
>> number.  Ethernet sends the byte out least significant bit first.  The
>> entire table is also swapped ls to ms and actually reduces the
operations
>> needed within the table calculations.  This reflects the method used for
>> Ethernet as it is being stored inverted and the initial value is started
>as
>> all ones.  The reason for the initial value being set to all ones is
>clear
>> for leading zero interaction, but I do not understand the value in
>storing
>> the CRC inverted.  I thought to include my ignorance to the mix.
>>
>> Doug
>>
>> > Sanjay Goyal wrote:
>> > >
>> > > Hi
>> > >  I get the remainder for iSCSI as 0x1c2d19ed if I complement my
>> > CRC and then
>> > > pass it through the CRC engine.
>> > >
>> > >  As per CRC generation for data: the thing which is not clear to me
>is
>> > >    why do we need to bit-swap the CRC reminader as is done in all
>your
>> > > examples.
>> >
>> > As far as I can tell, bit-swapping does nothing to help or hurt
>> > the effectiveness of the CRC.  When I ran my examples, I thought
>> > that it would be the simplest for our CRC to different from the
>> > Ethernet CRC only in the polynomial.  Ethernet, FDDI, FC, and SCSI
>> > all do this, so I figured it would cause the least confusion if
>> > we did the same.
>> >
>> > > We can just complement it and append it after the DATA bytes.
>> > >  The other side also can just pass it through the CRC engine to
>> > check it.
>> > >
>> > > Regards
>> > > Sanjay Goyal
>> > >
>> > > -----Original Message-----
>> > > From: Mark Bakke [mailto:mbakke@cisco.com]
>> > > Sent: Thursday, August 16, 2001 1:43 PM
>> > > To: Steve Blightman; ips@ece.cmu.edu
>> > > Subject: Re: [Fwd: Crc-32c example in iSCSI spec]
>> > >
>> > > One more thing that might be helpful.  When the Ethernet
>> > > polynomial is used in SCSI to generate its CRC, the T10
>> > > doc specifies the remainder polynomial that one should see
>> > > after running the data with a valid CRC through.  For
>> > > the Ethernet CRC, this was specified as 0xc704dd7b.  This
>> > > remainder polynomial is taken before the CRC is complemented
>> > > and bit-reflected.  For iSCSI, I came up with a remainder of
>> > > 0x1c2d19ed.  Can anyone verify this result?
>> > >
>> > > --
>> > > Mark
>> > >
>> > > Mark Bakke wrote:
>> > > >
>> > > > Steve-
>> > > >
>> > > > I just ran some Ethernet packets with known CRCs through
>> > > > my iSCSI/Ethernet CRC generator, and found the same thing
>> > > > as you did.
>> > > >
>> > > > All of my examples need to be byte-swapped, along with the
>> > > > fix I already posted for the all-ones example.  Here is a
>> > > > new set of examples, which will be in -08.  I also ran
>> > > > 64 bytes of zeroes and ones, which now agree with your
>> > > > numbers as well.
>> > > >
>> > > > Thanks again for bringing this up.
>> > > >
>> > > > --
>> > > > Mark
>> > > >
>> > > >      07 CRC Examples
>> > > >
>> > > >         N.B. all Values are Hexadecimal
>> > > >
>> > > >           Byte:        0  1  2  3
>> > > >
>> > > >              0:       01 a0 00 00
>> > > >              4:       00 00 00 00
>> > > >              8:       00 00 00 00
>> > > >             12:       00 00 00 00
>> > > >             16:       04 05 00 00
>> > > >             20:       00 01 00 00
>> > > >             24:       00 00 00 05
>> > > >             28:       00 00 00 04
>> > > >             32:       2a 00 00 00
>> > > >             36:       00 00 00 00
>> > > >             40:       80 00 00 00
>> > > >             44:       00 00 00 00
>> > > >
>> > > >            CRC:       93 70 51 db
>> > > >
>> > > >         32 bytes of zeroes:
>> > > >
>> > > >           Byte:        0  1  2  3
>> > > >
>> > > >              0:       00 00 00 00
>> > > >            ...
>> > > >             28:       00 00 00 00
>> > > >
>> > > >            CRC:       aa 36 91 8a
>> > > >
>> > > >         32 bytes of ones:
>> > > >
>> > > >           Byte:        0  1  2  3
>> > > >
>> > > >              0:       ff ff ff ff
>> > > >            ...
>> > > >             28:       ff ff ff ff
>> > > >
>> > > >            CRC:       43 ab a8 62
>> > > >
>> > > >         32 bytes of incrementing 00..1f:
>> > > >
>> > > >           Byte:        0  1  2  3
>> > > >
>> > > >              0:       00 01 02 03
>> > > >            ...
>> > > >             28:       1c 1d 1e 1f
>> > > >
>> > > >            CRC:       4e 79 dd 46
>> > > >
>> > > >
>> > > > Steve Blightman wrote:
>> > > > >
>> > > > > I believe the examples for the ISCSI CRC  have the wrong
>endianness.
>> > > > >
>> > > > > As yiou suugested over the phone I ran some Ethernet frames
>> > through a
>> > > > > simulation. I have some difficulty running the exact simulations
>you
>> > > > > wanted becuase the minimum size Ethernet frame is 64 bytes.
>> > > > >
>> > > > > However using the Ethernet CRC polynomial,
>> > > > > Running 64 bytes of 0 onto the wire, we append "36 63 8d
>> > 75" onto the
>> > > > > wire for the CRC - "36" goes out first.
>> > > > > Running 64 bytes of all 1, we append "ba 87 61 0f" onto the
>> > wire - "ba"
>> > > > > goes out first.
>> > > > >
>> > > > > Using the same logic for the ISCSI polynomial
>> > > > > Running 64 bytes of 0 I think we should append "67 eb c8 03" -
>"67"
>> > > > > going out first
>> > > > > and running 64 bytes of all 1 we should append "66 4e cd 2f" -
>"66"
>> > > > > going out first
>> > > > >
>> > > > > And now for 32 bytes with the ISCSI polynomial
>> > > > >
>> > > > > Running 32 bytes of 0 we should append "aa 36 91 8a" - "aa"
>> > going out
>> > > > > first
>> > > > > Running 32 bytes of all 1 we should append "43 ab a8 62" -
>> > "43" going
>> > > > > out first
>> > > > >
>> > > > > I don't want to get into an endless endian debate, but I
>> > believe it is
>> > > > > important to get the order of these bytes in the right
>> > order, so that we
>> > > > > can use the same hardware to check as well as to generate CRCs.
>> > > > >
>> > > > > Thanks for your help on this,
>> > > > > Steve Blightman
>> > > >
>> > > > --
>> > > > Mark A. Bakke
>> > > > Cisco Systems
>> > > > mbakke@cisco.com
>> > > > 763.398.1054
>> > >
>> > > --
>> > > Mark A. Bakke
>> > > Cisco Systems
>> > > mbakke@cisco.com
>> > > 763.398.1054
>> > >
>> > >
>> > ------------------------------------------------------------------
>> > ----------------------------------
>> > >
>> > >    Part 1.2    Type: application/ms-tnef
>> > >            Encoding: base64
>> >
>> > --
>> > Mark A. Bakke
>> > Cisco Systems
>> > mbakke@cisco.com
>> > 763.398.1054
>> >
>
>--
>Mark A. Bakke
>Cisco Systems
>mbakke@cisco.com
>763.398.1054
>
>
>
>







From owner-ips@ece.cmu.edu  Wed Aug 22 08:36:30 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03108
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 08:36:25 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7MBuJ919648
	for ips-outgoing; Wed, 22 Aug 2001 07:56:19 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7MBuHe19642
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 07:56:17 -0400 (EDT)
Received: from london ([192.168.195.163])
	by mail.wrs.com (8.9.3/8.9.1) with SMTP id EAA08053;
	Wed, 22 Aug 2001 04:56:01 -0700 (PDT)
From: "Rod Harrison" <rod.harrison@windriver.com>
To: "Wheat, Stephen R" <stephen.r.wheat@intel.com>,
        "'Steve Senum'" <ssenum@cisco.com>, "ietf-ips" <ips@ece.cmu.edu>
Subject: RE: iSCSI: Login Proposal
Date: Wed, 22 Aug 2001 12:57:40 +0100
Message-ID: <NEBBKMMOEMCINPLCHKGMMEMMCMAA.rod.harrison@windriver.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <638EC1B28663D211AC3E00A0C96B78A8086ABB3B@orsmsx40.jf.intel.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


	I think we should view this as the order indicates the
initiators preference and the target SHOULD pick the first
item from the list it supports. Note that SHOULD allows the
target to do something other than pick the first item it
supports if it has a good reason to do so, e.g. If it would
otherwise terminate the session. The initiator can always
terminate the session if it doesn't like what the target
chooses.

	So, to extend your example, as an initiator if I didn't
want to do CHAP at all I would send ...

AuthMethod=none

	if I preferred not to do CHAP but I could tolerate it I
would send ...

AuthMethod=none,CHAP

	and if I would prefer CHAP I would send ...

AuthMethod=CHAP,none

	I expect this to be under the control of the sys admin
through some kind of config at the initiator side. I think a
good guide to keep in mind with all this is that it is the
initiator's data, and so it seems reasonable to let the
initiator control connection security and integrity.

	- Rod

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On
Behalf Of
Wheat, Stephen R
Sent: Tuesday, August 21, 2001 11:30 PM
To: 'Steve Senum'; ietf-ips
Subject: RE: iSCSI: Login Proposal


Yup, I thought I had seen it, but couldn't find it; thanks.
And am now
embarrassed that I couldn't find it, when it was indeed
documented in two
places.  I'll save related comments for when we go through
the spec clean-up
phase.

So, the second paragraph you cite from both p22 and p100
imply that a target
could avoid selecting "none".  Thus, the initiator could
prefer "none", but
the target still select another initiator-offered value,
hence avoiding the
situation you propose, where "none" is always selected.

Yes?

Otherwise, how would a target and initiator be able to
select "none", in the
presence of the ability to mutually do at least one method?

Aren't there times where either could do all protocols, but
both would
*prefer* to do "none"??

Perhaps my question then is to get Para5 of 1.2.4 on p22
slightly clarified,
so as to avoid your conclusion.  I.e., the initiator should
be allowed to
prefer "none" over something else, yet have the target be
capable of not
selecting "none".

Again, I agree with you that the new-and-improved-login
proposal would be
even better with a requirement to have the initiator include
its security
parameters, even if they consist of only "none".

Stephen

-----Original Message-----
From: Steve Senum [mailto:ssenum@cisco.com]
Sent: Tuesday, August 21, 2001 2:31 PM
To: ietf-ips
Subject: Re: iSCSI: Login Proposal


Hi Stephen,

The current draft (-07) does actually answer your
question, though it is somewhat buried:

On page 22:

        In "list" negotiation, the offering party sends for
each key a list
        of values (which may include "none") in its order of
preference.

        The responding party answers with the first value
from the list it
        supports and is allowed to use for the specific
initiator.

And on page 100:

          -The initiator sends a text command with an
ordered list of the
           options it supports for each subject
(authentication algorithm,
           iSCSI parameters and so on). The options are
listed in the
           initiator's order of preference.

           -The target MUST reply with the first option in
the list it
           supports and is allowed for the specific
initiator....

Even so, I don't see the value in:

AuthMethod=none,CHAP

Since every implementation must support "none", "CHAP"
will never get picked.

In the interest of keeping login processing as simple as
possible, I would simply require the initiator to offer
what it can support (if anything).  The target can then
pick a compatiable method, or reject the connection.

Steve Senum

"Wheat, Stephen R" wrote:
>
> Good questions, Steve.
>
> Question 2 caused me to ponder the concept of key-value
preferences.
I.e.,
> I suspect that the concept in the proposed login spec was
to address that
> the initiator may prefer to not have any security digests,
but might be
able
> to negotiate them if the target insisted.
>
> I cannot find anywhere in the I-D that states that a
recipient MUST
consider
> key=v1,v2,v3 as the sender having preference of v1 over
v2, and v2 over
v3.
> Thus, I second Q2, but only if key values are to be
interpreted in
> preferential order.  Thus, an initiator could send
> "DataDigest=none,crc32-c,SPKM", and the target's response
MUST honor the
> preference order.
>
> So, Q4 is: should the values in a key-value list be
consider the sender's
> preference order that the receiver must honor?
>
> Stephen
>
> -----Original Message-----
> From: Steve Senum [mailto:ssenum@cisco.com]
> Sent: Tuesday, August 21, 2001 1:14 PM
> To: ietf-ips
> Subject: Re: iSCSI: Login Proposal
>
> Matthew/Marjorie/Bob:
>
> Some questions on your login proposal:
>
> 1. Why the following restriction?
>
>     SecurityContextComplete=yes MUST NOT be present
>     in the login command.
>
> I don't see the benefit in not allowing something like:
>
> I: AuthMethod:none
>    HeaderDigest:crc-32c,none
>    DataDigest:crc-32c,none
>    SecurityContextComplete=yes
> T: AuthMethod:none
>    HeaderDigest:crc-32c
>    DataDigest:crc-32c
>    SecurityContextComlete=yes
>
> 2. In the following:
>
>     If the login command does not contain security
parameters
>     the target MUST perform one of the two actions below:
>
>     a) If the target requires security negotiation
>        to be performed, then it MUST enter the security
>        phase and MUST send a text response containing
>        one or more security parameters and F=0.
>
>     b)
>
> Is this really needed?  Why not simply require the
> initiator to offer security parameters if it supports
them?
> I would hope authentication would become the typical case
> for login.
>
> 3. Is there only one Login Reponse then (just asking)?
>
> Regards,
> Steve Senum



From owner-ips@ece.cmu.edu  Wed Aug 22 08:38:18 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03204
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 08:38:18 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7MBb2m18053
	for ips-outgoing; Wed, 22 Aug 2001 07:37:02 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7MBb0e18045
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 07:37:00 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id NAA16222;
	Wed, 22 Aug 2001 13:36:43 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7MBahw46824;
	Wed, 22 Aug 2001 13:36:43 +0200
Importance: Normal
Subject: RE: iSCSI Login Proposal
To: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <matthew_burbridge@hp.com>
Cc: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF49D3D1CF.91208E55-ONC2256AB0.003F959F@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Wed, 22 Aug 2001 14:36:14 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 22/08/2001 14:36:43
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Matthew,

There is a transition diagram in 4 and I doubt that we need now much beyond
it
but let's see what you have.

Regards,
Julo

"BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <matthew_burbridge@hp.com> on
22-08-2001 12:06:32

Please respond to "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)"
      <matthew_burbridge@hp.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   ips@ece.cmu.edu
Subject:  RE: iSCSI Login Proposal



Hi Julian,

I was aware of the proposed change (I actually voted for it in London). I
thought of staying with SecurityContextComplete for the time being as it is
nearer the current spec.  I am happy to go either way. Personally I prefer
the put the status in the text command/response (For the new proposal its
not needed in the login command/response).  The login proposal has an
additional state ("Pre-security state") which would need to be reflected in
your proposal.

Is there value is specifying a login state machine in the spec?  I am happy
to do this (I have written one any way) but did not include it in the
proposal for simplicity's sake.

Cheers

Matthew


-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, August 22, 2001 9:49 AM
To: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)
Cc: ips@ece.cmu.edu
Subject: Re:iSCSI Login Proposal


Matthew,

Apologies to you, Marjorie and Bob for "changing the rules" during the
game.

I thought that it was obvious that I am going to rewrite 4 and simplify the
rules by neatly staging the login phase through a binary type indicator
that should show where the command is. Although I was myself not very
thrilled by the idea (presented in London) the meeting ended with a
consensus that I should explore this and that is what I did.

The result is not bad (the stages a clearly delineated, there are fewer
handshakes than before etc.).

Regards,
Julo





From owner-ips@ece.cmu.edu  Wed Aug 22 08:40:30 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03363
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 08:40:30 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7MBjwP18417
	for ips-outgoing; Wed, 22 Aug 2001 07:45:58 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from siaar1aa.compuserve.com (siaar1aa.compuserve.com [149.174.40.9])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7MBjve18413
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 07:45:57 -0400 (EDT)
Received: (from mailgate@localhost)
	by siaar1aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id HAA19865
	for ips@ece.cmu.edu; Wed, 22 Aug 2001 07:45:51 -0400 (EDT)
Received: from compuserve.com (dal-tgn-tlw-vty19.as.wcom.net [216.192.237.19])
	by siaar1aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id HAA19813
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 07:45:41 -0400 (EDT)
Message-ID: <3B839C7C.6C0BE527@compuserve.com>
Date: Wed, 22 Aug 2001 06:50:20 -0500
From: Ralph Weber <ralphoweber@compuserve.com>
Reply-To: ENDL_TX@computer.org
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47  (Win95; I)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: IPS Reflector <ips@ece.cmu.edu>
Subject: Re: IPS: FCIP & this list
References: <NEBBJGDMMLHHCIKHGBEJCEJMCKAA.dotis@sanlight.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Douglas,

Thank you for striping the tag off your response.
You have reinforced my point more strongly than could have been wished for.

Ralph...

Douglas Otis wrote:

>
> Ralph,
>
> You appear to be sensitive to the amount of traffic being waged in the iSCSI
> battle.  To be fair to David, if you had a filter on your email subjects
> looking for iscsi, then even his message would have been redirected.  You
> could even positively filter for FCIP.  Two messages a day does not sound
> like a heavy burden however to be handled manually.  Perhaps general
> announcements could include a list of filter words.
>
> Doug
>



From owner-ips@ece.cmu.edu  Wed Aug 22 10:26:37 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10188
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 10:26:37 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7MDu0P25507
	for ips-outgoing; Wed, 22 Aug 2001 09:56:00 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mxic2.us.dg.com (mxic2.us.dg.com [128.221.31.40])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7MDtxe25503
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 09:55:59 -0400 (EDT)
Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19)
	id <QQ9QZQY2>; Wed, 22 Aug 2001 09:53:46 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD63C@CORPMX14>
From: Black_David@emc.com
To: ENDL_TX@computer.org, ips@ece.cmu.edu
Subject: RE: FCIP & this list
Date: Wed, 22 Aug 2001 09:49:56 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Ralph,

> On 17 August 2001, David Black wrote:
> 
> > While I'm at it, it appears to me that the FCIP authors
> > are reverting to the unfortunate habit of holding technical
> > discussions off-line and not sharing them with the list.
> 
> First, the FCIP authors are posting their works to this
> reflector.  Otherwise, there would have been nothing
> to complain about vis-a-vis the content of the FCIP
> draft on 17 August.

Unfortunately, posting the "works" is not enough.  The rationale
behind the design decisions needs to be visible and open to
discussion on the list.  The fact that the FCIP authors have
discussed an issue offline will not be sufficient to resolve
a related WG Last Call objection on the list - to oversimplify
things slightly, the choice is between doing this right and
doing it over.

> Second, this reflector is clearly the ALL iSCSI ALL THE
> TIME reflector.  In the last 24 hours, no fewer than two
> new postings to this reflector have failed to include the
> project identifier in the subject as requested by John
> Hufferd and myself less than two weeks ago.

There's a chicken and egg problem here in that the FCIP
authors have chosen to do their technical work offline
and invite anyone who expresses any interest in FCIP into
that offline community including the conference calls.
That is a major contributing factor to the current traffic
mix on the reflector, as anyone with an FCIP issue will take
it to the conference call.  My attitude towards the conference
calls has been one of tolerating them *as long as*
the issues/discussion/results are summarized to the list,
which has not been happening.  I can't promise that the
Area Directors will be as accommodating.

> And why should people bother to prefix iSCSI postings with
> "iSCSI:" when one of the co-chairs violated the protocol
> as recently as yesterday morning with a posting titled
> "FW: I-D ACTION:draft-black-ips-iscsi-security-01.txt".

IIRC, the FCIP authors have stated an intention to follow
iSCSI's security direction, making iSCSI security drafts
(both that and draft-aboba) relevant to FCIP.  If the FCIP
authors have made an offline decision that iSCSI security
is no longer relevant to FCIP, than I apologize for the
lack of tag, but I do wish someone had paid me the courtesy
of letting me know about this change in direction ...

> The FCIP authors are trying to complete their draft
> under clearly disadvantaged circumstances.  Due diligence
> is being made to bring issues to this reflector and to
> respond to the concerns raised here.  And, I have no
> doubt that the issue raised on 17 August will be addressed
> in due course.
> 
> But it is patent nonsense to claim that the FCIP authors
> should be trying to use this reflector in the traditional
> IETF manner.  This reflector belongs to iSCSI, and to all
> practical purposes it belongs ONLY to iSCSI.

When in Rome ...
 
> FCIP (and for that matter iFCP) are barely tolerated,
> uninvited guests, or at least that is how it feels
> every time I review the directory the day's new messages.

WG Last Call will be conducted on this reflector for FCIP
and iFCP.  If the FCIP authors continue in their current
direction, those WG Last Calls could take a very long time.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


From owner-ips@ece.cmu.edu  Wed Aug 22 10:27:50 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10281
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 10:27:50 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7MDkuh25024
	for ips-outgoing; Wed, 22 Aug 2001 09:46:56 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail3.tor.primus.ca (mail.tor.primus.ca [216.254.136.21])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7MDkre25010
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 09:46:53 -0400 (EDT)
Received: from dsl-216-254-190-93.tor.primus.ca ([216.254.190.93] helo=perfisan4)
	by mail3.tor.primus.ca with smtp (Exim 2.11 #1)
	id 15ZYL0-0004G5-06; Wed, 22 Aug 2001 09:46:30 -0400
Reply-To: <tnguyen@perfisans.com>
From: "Trang Nguyen" <tnguyen@perfisans.com>
To: "BURBRIDGE,MATTHEW \(HP-UnitedKingdom,ex2\)" <matthew_burbridge@hp.com>,
        "'Julian Satran'" <Julian_Satran@il.ibm.com>
Cc: <ips@ece.cmu.edu>
Subject: RE: iSCSI Login Proposal
Date: Wed, 22 Aug 2001 09:50:50 -0400
Message-ID: <BNEALKHNNHCOIGPENKKMCECKCBAA.tnguyen@perfisans.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <0B9A57FF1D57D411B47500D0B73E5CC101E7A834@dickens.bri.hp.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Julian,

So far I've seen there are two iSCSI changes (Login/ Text commands and
Nop-in/out commands).  Are they official changes?  I mean can we use them
now?

Thanks,

Trang


-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)
Sent: August 22, 2001 5:07 AM
To: 'Julian Satran'
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI Login Proposal


Hi Julian,

I was aware of the proposed change (I actually voted for it in London). I
thought of staying with SecurityContextComplete for the time being as it is
nearer the current spec.  I am happy to go either way. Personally I prefer
the put the status in the text command/response (For the new proposal its
not needed in the login command/response).  The login proposal has an
additional state ("Pre-security state") which would need to be reflected in
your proposal.

Is there value is specifying a login state machine in the spec?  I am happy
to do this (I have written one any way) but did not include it in the
proposal for simplicity's sake.

Cheers

Matthew


-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, August 22, 2001 9:49 AM
To: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)
Cc: ips@ece.cmu.edu
Subject: Re:iSCSI Login Proposal


Matthew,

Apologies to you, Marjorie and Bob for "changing the rules" during the
game.

I thought that it was obvious that I am going to rewrite 4 and simplify the
rules by neatly staging the login phase through a binary type indicator
that should show where the command is. Although I was myself not very
thrilled by the idea (presented in London) the meeting ended with a
consensus that I should explore this and that is what I did.

The result is not bad (the stages a clearly delineated, there are fewer
handshakes than before etc.).

Regards,
Julo



From owner-ips@ece.cmu.edu  Wed Aug 22 10:30:27 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10459
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 10:30:27 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7ME55326057
	for ips-outgoing; Wed, 22 Aug 2001 10:05:05 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7ME53e26053
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 10:05:03 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id QAA187626;
	Wed, 22 Aug 2001 16:04:55 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7ME4sw23284;
	Wed, 22 Aug 2001 16:04:55 +0200
Importance: Normal
Subject: RE: Security in iSCSI
To: Black_David@emc.com
Cc: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF64A64672.A7868F87-ONC2256AB0.004C83A0@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Wed, 22 Aug 2001 17:04:25 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 22/08/2001 17:04:54
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

David,

I am certainly not confusing issues.  Removing cryptographic digests was
never a consensus call thing.
And true I agreed that we might remove the current specific ones but even
doing this will require everybody to agree after being clear what the
consequences are. As for using an SRP keys in ESP they will serve a
completely different purpose. A cryptographically safe digest on data is
needed to get a cryptographically safe transfer of data
through iSCSI proxies - CRCs are not cryptographically safe.

Julo

Black_David@emc.com on 22-08-2001 16:26:39

Please respond to Black_David@emc.com

To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
cc:
Subject:  RE: Security in iSCSI



Julian,

> To be absolutely correct the issue of removing the option of
cryptographyc
> digest was brough up
> by you as a possibility,  under the now fashionable umbrela of
> simplification, and I agree that we might want to
> remove some of them and limit ourselves to the set close to what we
intend
> to make mandatory to implement (e.g., if we make SRP mandatory to
implement
> then a SRP "keyed" digest could be the right thing to specify - not
> mandate).  As Kerberos and CHAP are popular in enterprises due to their
> manageability removing them and leving the implementation for them to be
> completely vendor specific is not a good idea.

You've confused two separate issues.  The digests referred to in
the email exchange below are the KRB5 and SPKM digests in the
table on p.135 of -07 which I proposed for removal on the list
well before the London meeting and which you agreed to do; please
make sure that they do not appear in -08.  There is no SRP keyed
inband digest specified anywhere in -07 -- at the moment, any such
functionality would be obtained via keying of ESP.

The issue of whether all 5 of the authentication methods (Kerberos, SRP,
SPKM-1, SPKM-2, CHAP) in the table on p.136 are needed is a separate and
open issue that is on the agenda for Orange County.

--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------






From owner-ips@ece.cmu.edu  Wed Aug 22 10:37:12 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10730
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 10:37:12 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7MDviM25590
	for ips-outgoing; Wed, 22 Aug 2001 09:57:44 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7MDvge25585
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 09:57:43 -0400 (EDT)
Received: from ahganemw2k (dhcp-161-44-68-168.cisco.com [161.44.68.168]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id JAA28988 for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 09:57:37 -0400 (EDT)
From: "Ayman Ghanem" <aghanem@cisco.com>
To: <ips@ece.cmu.edu>
Subject: RE: Login Proposal
Date: Wed, 22 Aug 2001 08:56:42 -0500
Message-ID: <LOEPJENHBHAHEABBNDAJMEALCDAA.aghanem@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <0B9A57FF1D57D411B47500D0B73E5CC101E7A831@dickens.bri.hp.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

I would vote in favor of requiring IIN and ITN to be sent in the login cmd.
If either is missing, the appropriate login response status code is 0x0207
(F=1). I would also vote in favor of eliminating the partial login response.
If we agree that a connection is not in full feature phase until it has
completed the login sequence, then the fields returned in the partial login
response (TSID, ExpCmdSN, MaxCmdSN) are of no use, and a text response can
replace a partial login response.

One comment though. If the initiator has no security parameters to negotiate
(implied by absence of all 4 security keys), then the initiator should be
allowed to include the operational parameters in the login cmd and set F=1.
This would conclude the login in just one exchange (unless the target
restarts the negotiation).

-Ayman


> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)
> Sent: Tuesday, August 21, 2001 12:32 PM
> To: 'ips@ece.cmu.edu'; 'Julian Satran'
> Subject: Login Proposal
>
>
> The recent plugfest highlighted areas of the login procedure that could be
> improved.
> With this in mind, Bob Russell, Marjorie Krueger, and myself have been
> working on
> a proposal for the Login procedure.
>
> Our goals were to keep it inline as much as possible with 0.7 of the
> specification and
> to ensure connectivity can be maintained amongst target and initiators.  I
> believe we
> have meet all the goals we set out to do.
>
> I have also attached a Login Reference Model (in the form of c code) which
> backs up
> our proposal.  Please note that the reference model is only a reference
> model and should
> not be considered as, or be part of the iSCSI specification.
>
> Cheers
>
> Matthew Burbridge
> Marjorie Krueger
> Bob Russell
>
> ++++++++++++++++++++++++
>
> The Login Proposal:
>
> Definitions:
> FBit means "I have nothing (more) to negotiate"
> Request: The first occurrence of a Text Parameter from the
> initiator or the
> target. A request
>          MUST be answered with a reply.
> Reply: A Text Parameter that is a response to a Request.
> Negotiation: A request followed by a response.
>
> 1.1 Actions at the Initiator
>
> The initiator starts the login phase by sending a Login Command PDU.
>
> The IIN MUST be present in the login command.  The SessionType MUST be
> present if the
> session type is Discovery, Boot or CopyManager.  It MAY be present if
> SessionType=Normal.
> The ITN MUST be present unless SessionType=Discovery when it is optional.
> The initiator
> MUST NOT send operational text parameters in the login command.  The table
> below defines
> the parameter present in the login command.
>
>         SessionType        SessionType          IIN               ITN
>                            Present in        Present in        Present in
>                              Login?            Login?            Login?
>
>           Normal            Optional            Yes               Yes
>            Boot               Yes               Yes               Yes
>         CopyManager           Yes               Yes               Yes
>          Discovery            Yes               Yes             Optional
>
> SecurityContextComplete=yes MUST NOT be present in the login command
> Operational Parameters MUST NOT be present in the login command
>
> At anytime the initiator MAY terminate the login killing the TCP
> connection.
>
> If the initiator requires security negotiation it MUST send one or more
> security
> parameters: (AuthMethod, HeaderDigest, DataDigest) in the login command.
>
>              Fbit     Security
>                      Parameters     Description
>                       Present
>
>               0          No         Initiator has no security parameters
>                                     to negotiate but has operational
> parameters
>                                     to negotiate.
>
>               0          Yes        The initiator wants to negotiate
> security.
>
>               1          No         The initiator has no security
> parameters
> to
>                                     negotiate and no operational
> parameters
> to
>                                     negotiate.
>
>               1         Yes         ILLEGAL.  Target must reject login
>                                     (Login Status = 0200)
>
> 1.2 Actions at the Target
>
> On receipt of the Login Command the target MUST respond according to the
> rules below:
>
> If the InitiatorName is not present the target MUST reject the login
> by sending a Login Response with FBit=1 and StatusCode=0200.  Similary, if
> the
> SessionType is not Discovery and the TargetName is not present the target
> MUST
> reject the login by sending a Login Response with FBit=1 and
> StatusCode=0200. It
> both cases the target should kill the TCP connection after the login
> response has
> successfully been sent.
>
> At anytime the target MAY terminate the login by sending a login response
> with
> the FBit set to 1 and a non-zero StatusCode. The target should
> kill the TCP
> connection after the login response has successfully been sent.
>
> If the login command contains security parameters, the target
> MUST enter the
> security
> phase of the login.  It MUST send response to those security
> parameters and
> MAY start
> negotiating security parameters if the parameters that it wants
> to negotiate
> are not
> in the Login command.  The target responses with a Text Response (F=0).
>
> If the login command does not contain security parameters the target MUST
> perform one
> of the two actions below:
>
>       a) If the target requires security negotiation to be performed, then
> it MUST
>          enter the security phase and MUST send a text response containing
> one or
>          more security parameters and F=0.
>
>       b) If the target does not require security negotiation (and
> therefore
> neither
>          does the initiator) it MUST perform one of the actions defined by
> the table
>          below.
>
>               Initiator    Target has     Action
>                 FBit       params to
>                            negotiate
>
>                  0            No         Send Text Response with F=1
> (Initiator
>                                          only wants to negotiate
> operational
>                                          parameters).
>
>                  0            Yes        Send Text Response with operation
> params
>                                          If all parameters can be sent in
>                                          a single response then
> F=1 else F=0
>                                          (Both target and
> initiator want to
>                                          negotiate operational
> parameters).
>
>                  1            No         Send Login Response with F=1.
> (Neither target
>                                          nor initiator want to negotiate
> operational
>                                          parameters).
>
>                  1            Yes        Send Text Response. If all
> parameters can be
>                                          sent in a single
> response then F=1
> else
>                                          F=0 (Target only wants
> to negotiate
>                                          operational parameters).
>
> 1.3 General Rules
>
> If an initiator or target has text parameters (security or operational) to
> negotiate
> then it MUST send them at the earliest opportunity and it MUST NOT send an
> empty text
> command.
>
> An initiator or target MUST respond to the a text parameter request with a
> text parameter
> response in the next text PDU to be sent.
>
> Once an initiator or target has completed initiating negotiations
> (security
> or operational)
> it MUST not initiate any more of the same type (security or operational).
> In other
> words it can not go backwards.
>
> Operational Parameters MUST NOT be negotiated during the security phase.
> Security Parameters MUST NOT be negotiated during the operartional phase.
>
> When a party has no more text parameters to negotiate then the FBit MUST
> be set in the PDU containing the last text parameter request and all
> subsequent
> PDUs.  For example: if an initiator only wants to negotiate
> "InitialR2T=yes"
> and no others, then it MUST set the FBit to 1 in the commands containing
> "InitialR2T=yes".
>
> Once the FBit has been set to 1, it MUST not be set back to 0.  Also, if
> the FBit is 1 then the party MUST not instigate anymore text parameter
> negotiations.  It can only respond to requests from the other party.
>
> If FMarker=yes then SFMarkInt and RFMarkInt MUST be present in the same
> Text PDU as FMarker=yes.  If FMarker=no then SHOULD NOT be
> present.  If they
> are then the remote party MUST reply to them and echo the values
> sent in the
> initial PDU.
>
> 1.4 Completion of Security Phase
> [Authors note: This section has been extracted from v0.7 but I have made
> some
> clarifications to the version 0.7 spec. - Changes in CAPITALS]
>
>           -Every party in the security negotiation MUST [Added MUST]
>            indicate that it has completed building its security context
>            (has all the required information) by sending the
> key=value pair:
>
>
>               SecurityContextComplete=yes
>
>            The other party either offers some more SECURITY parameters or
> answers
>            with the same:
>
>               SecurityContextComplete=yes
>
>
>            The party that is ready MUST [Added MUST] keep sending the
>            SecurityContextComplete=yes pair (in addition to new security
>            Parameter REPLYS if required) until the handshake is complete.
> 	   Once the party has set SecurityContextComplete=yes it MUST
>            not instigate anymore negotiations but it MUST respond to any
>            requests from the other pary.
>
>            If the initiator has been the last to complete the
> SECUIRTY PHASE
> it
>            MUST NOT start sending operational parameters within the same
>            text command; a text response including only
>            SecurityContextComplete=yes concludes the security sub-phase.
>
>            If the target has been the last to complete the SECURITY PHASE,
> the
>            initiator can start the operational parameter negotiation with
>            the next text command; the security negotiation sub-phase ends
>            with the target text response.
>
>            The SecurityContextComplete handshake MUST be performed if any
>            of negotiating parties has offered a security/integrity item
>            (even if it is not selected).
>
>            All PDUs sent after the security negotiation sub phase MUST be
>            built using the agreed security.
>
> This proposal removes from 0.7 of the spec:
> Partial Login response: It no longer coveys any information.
> OpParamReset: No longer required as operational parameters can not be
> negotiated
> during security phase.
>
> Keep:
> SecurityContextComplete=yes.  This is how 0.7 works.  If people disagree
> then
> we can vote and change it.
>
>
>
> Matthew Burbridge
> Senior Development Engineer
> NIS-Bristol
> Hewlett Packard
> Telnet: 312 7010
> E-mail: matthewb@bri.hp.com
>
>
>



From owner-ips@ece.cmu.edu  Wed Aug 22 10:37:40 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10796
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 10:37:40 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7MDWZF24140
	for ips-outgoing; Wed, 22 Aug 2001 09:32:35 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7MDWYe24136
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 09:32:34 -0400 (EDT)
Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <RNJ8KYN7>; Wed, 22 Aug 2001 09:32:29 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD63B@CORPMX14>
From: Black_David@emc.com
To: Julian_Satran@il.ibm.com, ips@ece.cmu.edu
Subject: RE: Security in iSCSI
Date: Wed, 22 Aug 2001 09:26:39 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Julian,

> To be absolutely correct the issue of removing the option of cryptographyc
> digest was brough up
> by you as a possibility,  under the now fashionable umbrela of
> simplification, and I agree that we might want to
> remove some of them and limit ourselves to the set close to what we intend
> to make mandatory to implement (e.g., if we make SRP mandatory to
implement
> then a SRP "keyed" digest could be the right thing to specify - not
> mandate).  As Kerberos and CHAP are popular in enterprises due to their
> manageability removing them and leving the implementation for them to be
> completely vendor specific is not a good idea.

You've confused two separate issues.  The digests referred to in
the email exchange below are the KRB5 and SPKM digests in the
table on p.135 of -07 which I proposed for removal on the list
well before the London meeting and which you agreed to do; please
make sure that they do not appear in -08.  There is no SRP keyed
inband digest specified anywhere in -07 -- at the moment, any such
functionality would be obtained via keying of ESP.

The issue of whether all 5 of the authentication methods (Kerberos, SRP,
SPKM-1, SPKM-2, CHAP) in the table on p.136 are needed is a separate and
open issue that is on the agenda for Orange County.

--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------
 


From owner-ips@ece.cmu.edu  Wed Aug 22 11:19:58 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13094
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 11:19:53 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7ME9Fw26324
	for ips-outgoing; Wed, 22 Aug 2001 10:09:15 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7ME9De26316
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 10:09:13 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id QAA191772
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 16:09:07 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7ME96O158576
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 16:09:06 +0200
Importance: Normal
Subject: RE: iSCSI Login Proposal
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF98960660.B36D0CCD-ONC2256AB0.004D6180@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Wed, 22 Aug 2001 17:08:36 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 22/08/2001 17:09:05
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Trang,

Nothing is "official" until this does not become a RFC.  But I did not hear
any complaints about NOP.

As for the Login/Text - I've just put them out. Too early to tell how many
minor/major changes will be proposed.
Give people a chance to look through them.

Julo

"Trang Nguyen" <tnguyen@perfisans.com> on 22-08-2001 16:50:50

Please respond to <tnguyen@perfisans.com>

To:   "BURBRIDGE,MATTHEW \(HP-UnitedKingdom,ex2\)"
      <matthew_burbridge@hp.com>, Julian Satran/Haifa/IBM@IBMIL
cc:   <ips@ece.cmu.edu>
Subject:  RE: iSCSI Login Proposal



Hi Julian,

So far I've seen there are two iSCSI changes (Login/ Text commands and
Nop-in/out commands).  Are they official changes?  I mean can we use them
now?

Thanks,

Trang


-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)
Sent: August 22, 2001 5:07 AM
To: 'Julian Satran'
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI Login Proposal


Hi Julian,

I was aware of the proposed change (I actually voted for it in London). I
thought of staying with SecurityContextComplete for the time being as it is
nearer the current spec.  I am happy to go either way. Personally I prefer
the put the status in the text command/response (For the new proposal its
not needed in the login command/response).  The login proposal has an
additional state ("Pre-security state") which would need to be reflected in
your proposal.

Is there value is specifying a login state machine in the spec?  I am happy
to do this (I have written one any way) but did not include it in the
proposal for simplicity's sake.

Cheers

Matthew


-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, August 22, 2001 9:49 AM
To: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)
Cc: ips@ece.cmu.edu
Subject: Re:iSCSI Login Proposal


Matthew,

Apologies to you, Marjorie and Bob for "changing the rules" during the
game.

I thought that it was obvious that I am going to rewrite 4 and simplify the
rules by neatly staging the login phase through a binary type indicator
that should show where the command is. Although I was myself not very
thrilled by the idea (presented in London) the meeting ended with a
consensus that I should explore this and that is what I did.

The result is not bad (the stages a clearly delineated, there are fewer
handshakes than before etc.).

Regards,
Julo






From owner-ips@ece.cmu.edu  Wed Aug 22 13:03:01 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16707
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 13:03:01 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7MGFcm04572
	for ips-outgoing; Wed, 22 Aug 2001 12:15:38 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from baucis.sc.intel.com (ns3.intel.com [143.183.152.22])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7MGFae04558
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 12:15:36 -0400 (EDT)
Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203])
	by baucis.sc.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id QAA17541;
	Wed, 22 Aug 2001 16:15:28 GMT
Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.203
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Wed, 22 Aug 2001 16:15:27 0000 (GMT)
Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <RLP21ZMD>; Wed, 22 Aug 2001 09:15:26 -0700
Message-ID: <638EC1B28663D211AC3E00A0C96B78A8086ABB41@orsmsx40.jf.intel.com>
From: "Wheat, Stephen R" <stephen.r.wheat@intel.com>
To: "'Julian Satran'" <Julian_Satran@il.ibm.com>, ips@ece.cmu.edu
Subject: iSCSI: RE: Target record not to span PDUs?
Date: Wed, 22 Aug 2001 09:15:20 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Julian,

I'm not sure the problem case as stated is syntactically correct; maybe it
has to do with my interpretation of book marks.

As stated, the sequence looks like:
  [Begin data segment]
  ...
  TargetName=I.got.chopped.4096
  TargetAddress=10.1.1.45
  [End data segment]

My understanding of bookmark is that the packet would look like:
  [Begin data segment]
  ...
  TargetName=<incomplete target name>
  [End data segment]

Where the next message would simply be concatenated to the previous text.
And would look like:
  [Begin data segment]
  <rest of target name>
  ...
  TargetAddress=10.1.1.45
  [End data segment]

So, yes the host needs to buffer the last incomplete record, awaiting the
text to be concatenated, but there is no rewind or re-parse.

What am I missing?

If I'm right in my interpretation, then it would seem that your response is
overly restrictive.  Being concerned about buffer memory is one thing, but
when we are talking about a few kilobytes, that is getting too concerned.
If an initiator was really so limited in its memory, then it would probably
only be doing one login at a time anyway.

Stephen

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, August 22, 2001 3:23 AM
To: ips@ece.cmu.edu
Subject: Re: Target record not to span PDUs?



Good point. I think that we can do this as we have a limit on the size of
an individual record far lower than 4096.

I'll ad the following text to 2.9.5:

   A Key=value pair must be confined to a given text response even in the
   presence of bookmark - i.e., it must start and end within one Text
   Response.

Julo

Tow Wang <Tow_Wang@adaptec.com> on 22-08-2001 05:06:44

Please respond to Tow Wang <Tow_Wang@adaptec.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
Subject:  Target record not to span PDUs?



Julian (and all):

Hello. This is regarding draft 07; could we require that target records NOT
span across
PDU's if a text response for SendTargets is very long? Upon reading
appendix E, it seems
that a response (of 4096 bytes in length) could end with:

[Begin data segment]
...
TargetName=I.got.chopped.4096
TargetAddress=10.1.1.45
[End data segment]

In the above case, one could not determine whether the address is IP V4 or
V6. Even if it
had had enough space to put in the whole address, port and group tag, one
cannot parse and
process the record until inspecting the data segment of the next text
response PDU, and
this would involve cumulative buffering, back-parsing, etc. I think the
above complexity
could be avoided, as I can't imagine any single record exceeding 4096 bytes
in length.

Tow Wang







From owner-ips@ece.cmu.edu  Wed Aug 22 13:03:46 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16739
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 13:03:46 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7MG2HA03789
	for ips-outgoing; Wed, 22 Aug 2001 12:02:17 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from siaar1ab.compuserve.com (siaar1ab.compuserve.com [149.174.40.10])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7MG2Fe03779
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 12:02:15 -0400 (EDT)
Received: (from mailgate@localhost)
	by siaar1ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id MAA16618
	for ips@ece.cmu.edu; Wed, 22 Aug 2001 12:00:54 -0400 (EDT)
Received: from compuserve.com (dal-tgn-tvn-vty16.as.wcom.net [206.175.228.16])
	by siaar1ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id MAA16428
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 12:00:44 -0400 (EDT)
Message-ID: <3B83D7D3.8A182C85@compuserve.com>
Date: Wed, 22 Aug 2001 11:03:31 -0500
From: Ralph Weber <ralphoweber@compuserve.com>
Reply-To: ENDL_TX@computer.org
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47  (Win95; I)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: IPS Reflector <ips@ece.cmu.edu>
Subject: Re: IPS: FCIP & this list
References: <277DD60FB639D511AC0400B0D068B71ECAD63C@CORPMX14>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

David,

Your responses are most excellent.

There are minutes (well, more like discussion notes) from the 
conference call and I will ask that they be posted to this 
reflector.

The interim FCIP drafts and issues lists are maintained in PDF
format, amounting to between .2M and .5M of new material per 
week. Since this is Rome, they cannot be posted to this reflector.
It is totally impractical to translate the PDFs to text, sorry.

} WG Last Call will be conducted on this reflector for FCIP
} and iFCP.  If the FCIP authors continue in their current
} direction, those WG Last Calls could take a very long time.

There appears to be no alternative, however, I doubt that the
WG Last Calls time requirement would be shortened by more than
10% even if everything done by the FCIP authors was posted
to this reflector.  In particular, I see no reason to believe 
that the people who will raise Last Call issues will remember
earlier postings here, or bother to participate on this 
reflector prior to Last Call.  You are the sole exception 
to this perception.

Thanks for the well written, thoughtful response. I regret
that I see so few ways to be more accommodating.

Ralph...

Black_David@emc.com wrote:

>
> Ralph,
>
> > On 17 August 2001, David Black wrote:
> >
> > > While I'm at it, it appears to me that the FCIP authors
> > > are reverting to the unfortunate habit of holding technical
> > > discussions off-line and not sharing them with the list.
> >
> > First, the FCIP authors are posting their works to this
> > reflector.  Otherwise, there would have been nothing
> > to complain about vis-a-vis the content of the FCIP
> > draft on 17 August.
>
> Unfortunately, posting the "works" is not enough.  The rationale
> behind the design decisions needs to be visible and open to
> discussion on the list.  The fact that the FCIP authors have
> discussed an issue offline will not be sufficient to resolve
> a related WG Last Call objection on the list - to oversimplify
> things slightly, the choice is between doing this right and
> doing it over.
>
> > Second, this reflector is clearly the ALL iSCSI ALL THE
> > TIME reflector.  In the last 24 hours, no fewer than two
> > new postings to this reflector have failed to include the
> > project identifier in the subject as requested by John
> > Hufferd and myself less than two weeks ago.
>
> There's a chicken and egg problem here in that the FCIP
> authors have chosen to do their technical work offline
> and invite anyone who expresses any interest in FCIP into
> that offline community including the conference calls.
> That is a major contributing factor to the current traffic
> mix on the reflector, as anyone with an FCIP issue will take
> it to the conference call.  My attitude towards the conference
> calls has been one of tolerating them *as long as*
> the issues/discussion/results are summarized to the list,
> which has not been happening.  I can't promise that the
> Area Directors will be as accommodating.
>
> > And why should people bother to prefix iSCSI postings with
> > "iSCSI:" when one of the co-chairs violated the protocol
> > as recently as yesterday morning with a posting titled
> > "FW: I-D ACTION:draft-black-ips-iscsi-security-01.txt".
>
> IIRC, the FCIP authors have stated an intention to follow
> iSCSI's security direction, making iSCSI security drafts
> (both that and draft-aboba) relevant to FCIP.  If the FCIP
> authors have made an offline decision that iSCSI security
> is no longer relevant to FCIP, than I apologize for the
> lack of tag, but I do wish someone had paid me the courtesy
> of letting me know about this change in direction ...
>
> > The FCIP authors are trying to complete their draft
> > under clearly disadvantaged circumstances.  Due diligence
> > is being made to bring issues to this reflector and to
> > respond to the concerns raised here.  And, I have no
> > doubt that the issue raised on 17 August will be addressed
> > in due course.
> >
> > But it is patent nonsense to claim that the FCIP authors
> > should be trying to use this reflector in the traditional
> > IETF manner.  This reflector belongs to iSCSI, and to all
> > practical purposes it belongs ONLY to iSCSI.
>
> When in Rome ...
>
> > FCIP (and for that matter iFCP) are barely tolerated,
> > uninvited guests, or at least that is how it feels
> > every time I review the directory the day's new messages.
>
> WG Last Call will be conducted on this reflector for FCIP
> and iFCP.  If the FCIP authors continue in their current
> direction, those WG Last Calls could take a very long time.
>
> Thanks,
> --David
>
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------



From owner-ips@ece.cmu.edu  Wed Aug 22 13:03:58 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16756
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 13:03:57 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7MGPNh05178
	for ips-outgoing; Wed, 22 Aug 2001 12:25:23 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from c007.snv.cp.net (c007-h011.c007.snv.cp.net [209.228.33.217])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f7MGPLe05174
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 12:25:22 -0400 (EDT)
Received: (cpmta 20491 invoked from network); 22 Aug 2001 09:24:30 -0700
Received: from unknown (HELO littlejoy) (64.130.130.105)
  by smtp.telocity.com (209.228.33.217) with SMTP; 22 Aug 2001 09:24:30 -0700
X-Sent: 22 Aug 2001 16:24:30 GMT
From: "Douglas Otis" <dotis@sanlight.net>
To: <ENDL_TX@computer.org>, "IPS Reflector" <ips@ece.cmu.edu>
Subject: RE: IPS: FCIP & this list
Date: Wed, 22 Aug 2001 09:22:44 -0700
Message-ID: <NEBBJGDMMLHHCIKHGBEJOEKACKAA.dotis@sanlight.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <3B839C7C.6C0BE527@compuserve.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Ralph,

What tag was I stripping off?  I see that you have added IPS: but FCIP &
list was left untouched.  Did you wish that I include the header within the
body of the message?  You can sort on the subject line.
What are you attempting to filter?  I do not wish to be critical but I am
having trouble understanding your difficulty.

Doug

> Douglas,
>
> Thank you for striping the tag off your response.
> You have reinforced my point more strongly than could have been
> wished for.
>
> Ralph...
>
> Douglas Otis wrote:
>
> >
> > Ralph,
> >
> > You appear to be sensitive to the amount of traffic being waged
> in the iSCSI
> > battle.  To be fair to David, if you had a filter on your email subjects
> > looking for iscsi, then even his message would have been
> redirected.  You
> > could even positively filter for FCIP.  Two messages a day does
> not sound
> > like a heavy burden however to be handled manually.  Perhaps general
> > announcements could include a list of filter words.
> >
> > Doug
> >
>
>



From owner-ips@ece.cmu.edu  Wed Aug 22 13:21:59 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17304
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 13:21:59 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7MGmB806474
	for ips-outgoing; Wed, 22 Aug 2001 12:48:11 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mxic1.isus.emc.com ([168.159.129.100])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7MGm8e06469
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 12:48:08 -0400 (EDT)
Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <QQ9CSWQ0>; Wed, 22 Aug 2001 12:50:05 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD641@CORPMX14>
From: Black_David@emc.com
To: ENDL_TX@computer.org, ips@ece.cmu.edu
Subject: RE: IPS: FCIP & this list
Date: Wed, 22 Aug 2001 12:42:09 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Ralph,

> There are minutes (well, more like discussion notes) from the 
> conference call and I will ask that they be posted to this 
> reflector.

That'll be an improvement, thanks.  Discussion notes are 
exactly the sort of thing that should to be visible on this
reflector.

> The interim FCIP drafts and issues lists are maintained in PDF
> format, amounting to between .2M and .5M of new material per 
> week. Since this is Rome, they cannot be posted to this reflector.
> It is totally impractical to translate the PDFs to text, sorry.

That's a judgment call.  Actually sending the PDFs to the list
or the I-D servers is a no-no, but it would be ok to put them
on a web site and post URLs to the list, as long as new text
versions of the draft do go to the I-D servers at reasonable
intervals.  It would also be ok to keep the interim PDF versions
private among the authors until the next major revision of
the draft is ready for the I-D servers.  There's
no requirement to make all working notes visible.

I do need to clarify one point of process:

> I doubt that the
> WG Last Calls time requirement would be shortened by more than
> 10% even if everything done by the FCIP authors was posted
> to this reflector.  In particular, I see no reason to believe 
> that the people who will raise Last Call issues will remember
> earlier postings here, or bother to participate on this 
> reflector prior to Last Call.

My concern is that the existence of prior discussion on this
reflector can be a significant factor in whether an issue raised
in WG Last Call causes the Last Call to fail.  If one can point
to prior discussion or even acceptance without discussion on this
list of a technical approach that is questioned during WG Last
Call, then such an issue may be resolvable by pointing to that
discussion and indicating that the WG considered the alternative
and has rough consensus to proceed as currently specified.  OTOH,
if the issue is new to the reflector and technically valid, the
odds of the WG Last Call failing are significantly increased.
WG Last Call periods are measured in weeks (at least 2, but the
initial WG Last Call period for each of the main protocol
drafts is likely to be longer).  If a WG Last Call fails, the
draft has to be revised, and the WG Last Call repeated; we went
through one of these cycles with the iSCSI requirements draft.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


From owner-ips@ece.cmu.edu  Wed Aug 22 13:30:17 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17605
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 13:30:17 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7MGeL506054
	for ips-outgoing; Wed, 22 Aug 2001 12:40:21 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7MGeJe06048
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 12:40:19 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA27068;
	Wed, 22 Aug 2001 12:38:08 -0400
Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7MGe7P220798;
	Wed, 22 Aug 2001 10:40:07 -0600
X-Priority: 1 (High)
Importance: Normal
Subject: RE: iSCSI: Support Alias in the protocol
To: "Martin, Nick" <Nick.Martin@compaq.com>
Cc: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OFAD360828.CCE00957-ON88256AB0.0058B56D@boulder.ibm.com>
From: "John Hufferd" <hufferd@us.ibm.com>
Date: Wed, 22 Aug 2001 09:39:42 -0700
X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at
 08/22/2001 10:40:07 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Martin,
I think your view is "Right-ON".  Over the years I have had the "marvelous"
opportunity to work in the management of an IS/IT organization.  It is the
presents of little things like this Alias that make or break so much of
what we attempted.  I was not only responsible for the management of a
Large Data Center (at IBM Santa Teresa Lab) but also its satellites  It was
in the satellite systems, where the full featured Management Software was
most likely not to exist.

I expect that this view is the rule in smaller installations, that is, you
will not generally find the large Network and Storage Management Software
in those environments.  They will have a number of simple low end, or no,
general Management Software.

Though I would like to have Tivoli or HP Open View (for example)
everywhere, I know this will not happen.  We need to do everything possible
to support the small installation as long as it does not cause a big impact
on the iSCSI protocol.

I think that the Alias capability, though not a hard requirement for iSCSI,
is a very worthwhile feature, that will help humans.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com


"Martin, Nick" <Nick.Martin@compaq.com>@ece.cmu.edu on 08/21/2001 11:34:54
AM

Sent by:  owner-ips@ece.cmu.edu


To:   "'Robert Snively'" <rsnively@Brocade.COM>, "'ips@ece.cmu.edu'"
      <ips@ece.cmu.edu>
cc:
Subject:  RE: iSCSI: Support Alias in the protocol



Bob,

I agree that the iSCSI Name is analogous to the VIN number on a car.
The VIN number and the iSCSI Name are supposed to be constant for the life
of the device.
In my mind the iSCSI Alias is like the license plate tag.  If someone is
looking for your car, in the mall parking lot you don't tell them the
manufacturer assigned VIN number, you tell them the tag.  (You may also
mention the make, model, and color.)  The VIN number is used for
confirmation when required.  These are administrator assigned regionally
and
duplicate numbers are not much of a problem.

Initiator Target relationships are defined by the InitiatorName and
TargetName.  The protocol does not need aliases, but I believe the
administrators do.  We need to allow administrators to assign their own
tags
to devices, and I believe these should be carried within the protocol so
that no external databases are required.  When reporting a problem to an
administrator, the device alias should be reported along with the device
name.  The chances for error and confusion will be greatly reduced.  The
alias or "tag" value will be easier for humans to deal with on a daily
basis
than a name field or VIN number would be.

I support Alias within the iSCSI protocol.

Thanks,
Nick
-----Original Message-----
From: Robert Snively [mailto:rsnively@Brocade.COM]
Sent: Monday, August 20, 2001 4:25 PM
To: 'Mark S. Edwards'; ips@ece.cmu.edu
Subject: RE: iSCSI: Support Alias in the protocol


Folks,

I remain concerned about this called consensus.  Clearly there
will be thousands of Targets and Initiators running around
a network.  Creating a set of human useable aliases
that will distinguish all these seems to me somewhat farfetched.
We don't even do very well on kings.  George, George II, etc.

To create aliases in the context of a single management environment
makes some sense, but again, that should be outside the
scope of iSCSI.

That we call our car Skeezix (human useable, for management
purposes within the tightly constrained context of our own
family) is non-architected information.  Whenever anyone cares
which car it is (including during servicing and upgrades) they
use the VIN, a registered and architected non-human-readable value.

If Marjorie and I are the only voices in the woods, we have
clearly had the consensus called against us, but this is high
on my list of things that really aren't much help to anyone
and shouldn't be in the document.

Bob

> >Let me also acknowledge as valid Marj's opinion that anything of
> >this sort belongs in a management tool rather than the protocol.
>
> But it only works if everyone uses the same management tool,
> or the tools agree upon the location and storage format of the
> information
> --  Somebody dig me up from my grave when Tivoli and
> OpenView merge.
>
> As a way of easily identifying virtual LUN's or LU's within a
> Target Space of potential hundreds or thousands the alias
> is very valuable.





From owner-ips@ece.cmu.edu  Wed Aug 22 14:22:33 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19179
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 14:22:32 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7MHri110496
	for ips-outgoing; Wed, 22 Aug 2001 13:53:44 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from atlrel7.hp.com (atlrel7.hp.com [192.151.27.9])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7MHrge10492
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 13:53:43 -0400 (EDT)
Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190])
	by atlrel7.hp.com (Postfix) with ESMTP
	id A97B61F767; Wed, 22 Aug 2001 13:52:21 -0400 (EDT)
Received: from xatlbh2.atl.hp.com (xatlbh2.atl.hp.com [15.45.89.187])
	by xatlrelay1.atl.hp.com (Postfix) with ESMTP
	id 550FA1F525; Wed, 22 Aug 2001 13:53:37 -0400 (EDT)
Received: by xatlbh2.atl.hp.com with Internet Mail Service (5.5.2653.19)
	id <RHJX6LAB>; Wed, 22 Aug 2001 13:53:37 -0400
Message-ID: <6BD67FFB937FD411A04F00D0B74FE87802A0925D@xrose06.rose.hp.com>
From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
To: "'Ayman Ghanem'" <aghanem@cisco.com>, ips@ece.cmu.edu
Subject: RE: Login Proposal
Date: Wed, 22 Aug 2001 13:53:35 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


> One comment though. If the initiator has no security 
> parameters to negotiate
> (implied by absence of all 4 security keys), then the 
> initiator should be
> allowed to include the operational parameters in the login 
> cmd and set F=1.
> This would conclude the login in just one exchange (unless the target
> restarts the negotiation).
> 
> -Ayman
> 

The login proposal is a result of the groups decision (in London IETF) to
make login deterministic (simplify implementation) and to that end it was
agreed to separate login into two phases: security and operational
parameter.  The reason for this has been discussed extensively on this list
(see emails discussing UNH plugfest results).  What you suggest has caused
problems in practical implementation.  The security phase must be agreed to
be complete before it's safe to negotiate operational parameters, and the
target must have a "say" in the security negotiations before this phase can
be considered complete.

Marj


From owner-ips@ece.cmu.edu  Wed Aug 22 14:27:28 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19330
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 14:27:28 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7MHlW510083
	for ips-outgoing; Wed, 22 Aug 2001 13:47:32 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7MHlUe10078
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 13:47:30 -0400 (EDT)
Received: from xparelay1.corp.hp.com (unknown [15.58.136.173])
	by palrel1.hp.com (Postfix) with ESMTP
	id 3CBE919AA; Wed, 22 Aug 2001 10:47:29 -0700 (PDT)
Received: from xpabh4.corp.hp.com (xpabh4.corp.hp.com [15.58.136.1])
	by xparelay1.corp.hp.com (Postfix) with ESMTP
	id 7A20B1F523; Wed, 22 Aug 2001 10:47:28 -0700 (PDT)
Received: by xpabh4.corp.hp.com with Internet Mail Service (5.5.2653.19)
	id <QRC56JZF>; Wed, 22 Aug 2001 10:47:28 -0700
Message-ID: <6BD67FFB937FD411A04F00D0B74FE87802A0925C@xrose06.rose.hp.com>
From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
To: "'Rod Harrison'" <rod.harrison@windriver.com>, ietf-ips <ips@ece.cmu.edu>
Subject: RE: iSCSI: Login Proposal
Date: Wed, 22 Aug 2001 10:47:27 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

I'm thinking a little differently regarding which party has priority in
chosing security parameters - while it *may* be the initiators data, this
can't be established until the initiator is authenticated.  Since the target
is the "server" side, I think the burden is on the target to ensure that
this is the intended initiator.  Therefore, the target must dictate the
authentication method used, since it has the security responsibility and the
"contact point" for potentially malicious entities.  Consider the example
where an initiator was previously authenticated using Kerberos, the session
was ended, and a new session is requested by what appears to be the same
initiator, but the authmethod requested is now "none".  Looks pretty
suspicious to me.  It seems to me like the target has the responsibility of
maintaining a consistent authmethod with all initiators that access it,
therefore the target MUST force the minimum level authorization it requires
or reject the login request.

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: marjorie_krueger@hp.com 

> -----Original Message-----
> From: Rod Harrison [mailto:rod.harrison@windriver.com]
> Sent: Wednesday, August 22, 2001 4:58 AM
> To: Wheat, Stephen R; 'Steve Senum'; ietf-ips
> Subject: RE: iSCSI: Login Proposal
> 
> 
> 
> 	I think we should view this as the order indicates the
> initiators preference and the target SHOULD pick the first
> item from the list it supports. Note that SHOULD allows the
> target to do something other than pick the first item it
> supports if it has a good reason to do so, e.g. If it would
> otherwise terminate the session. The initiator can always
> terminate the session if it doesn't like what the target
> chooses.
> 
> 	So, to extend your example, as an initiator if I didn't
> want to do CHAP at all I would send ...
> 
> AuthMethod=none
> 
> 	if I preferred not to do CHAP but I could tolerate it I
> would send ...
> 
> AuthMethod=none,CHAP
> 
> 	and if I would prefer CHAP I would send ...
> 
> AuthMethod=CHAP,none
> 
> 	I expect this to be under the control of the sys admin
> through some kind of config at the initiator side. I think a
> good guide to keep in mind with all this is that it is the
> initiator's data, and so it seems reasonable to let the
> initiator control connection security and integrity.
> 
> 	- Rod
> 
 


From owner-ips@ece.cmu.edu  Wed Aug 22 14:27:45 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19353
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 14:27:45 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7MHIgN08247
	for ips-outgoing; Wed, 22 Aug 2001 13:18:42 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7MHIee08243
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 13:18:40 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id TAA156514
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 19:18:34 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7MHIXw82478
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 19:18:33 +0200
Importance: Normal
Subject: iSCSI - Change - a neat s
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF0E1BFA2F.BDBF3479-ONC2256AB0.0057CA05@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Wed, 22 Aug 2001 20:18:03 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 22/08/2001 20:18:32
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Dear coleagues,

I owe an answer on this to both the design team, and lately to Robert
Griswold that raised the issue
of how can a target distinguish the reason for which the initiator issued a
command restart/retry (X bit 1).

This makes the life of the recovery implementor difficult and leaves some
ambiguity.
The three reasons to issue a restart are:

   plug-in a hole created by a command being dropped (e.g., bad digest)
   restart the command on another connection after the original is logged
   out
   replay a command

Out of the three only the first needs all the information from the command
(the command must be completely reissued).

On the other two the information from the command is not needed (the
command exists already at the target.

The current draft uses the restart/replay for all three of them and the
target may have a hard time
understanding unamiguously what the initiator meant.

Considering all those fact I suggest the following change to the current
draft:

1. Use the restart bit (X bit 1) only to indicate that the initiator thinks
he is doing a "plug-in-the-hole". The target can drop the PDU if it has
already the command
2.Use a different mechanism to accomplish the restart/replay

The mechanism for restart replay can be "transfered" easily to the task
management commands - as thhe tasks to be resumed or replyed already exist.

I  suggest  the following new text for the task management command and
response (with appropriate changes in the recovery sections):


1.1  Task Management Command

   Byte /    0       |       1       |       2       |       3       |
      /              |               |               |               |
     |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
     +---------------+---------------+---------------+---------------+
    0|X|I| x02       |0| Function    | Reserved (0)                  |
     +---------------+---------------+---------------+---------------+
    4| Reserved (0)                                                  |
     +---------------+---------------+---------------+---------------+
    8| Logical Unit Number (LUN) or Reserved (0)                     |
     +                                                               +
   12|                                                               |
     +---------------+---------------+---------------+---------------+
   16| Initiator Task Tag                                            |
     +---------------+---------------+---------------+---------------+
   20| Referenced Task Tag or Reserved (0xffffffff)                  |
     +---------------+---------------+---------------+---------------+
   24| CmdSN                                                         |
     +---------------+---------------+---------------+---------------+
   28| ExpStatSN                                                     |
     +---------------+---------------+---------------+---------------+
   32| RefCmdSN                                                      |
     +---------------+---------------+---------------+---------------+
   36/ Reserved (0)                                                  /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
   48

1.1.1     Function

   The Task Management functions provide an initiator with a way to
   explicitly control the execution of one or more Tasks (SCSI and iSCSI
   tasks). The Task Management functions are summarized as follows (for a
   more detailed description of SCSI task management see the [SAM2]
   document):

      1    Abort Task - aborts the task identified by the Referenced Task
      Tag field.
      2    Abort Task Set - aborts all Tasks issued by this initiator on
      the Logical Unit.
      3    Clear ACA - clears the Auto Contingent Allegiance condition.
      4    Clear Task Set - Aborts all Tasks (from all initiators) for the
      Logical Unit.
      5    Logical Unit Reset
      6    Target Warm Reset
7    Target Cold Reset
8    Task Resume - restart the task identified by the Referenced Task Tag
field on this connection
9    Task Replay - replay the task identified by the Referenced Task Tag
field on this connection

   For all these functions, if executed, the Task Management Response MUST
   be returned using the Initiator Task Tag to identify the operation for
   which it is responding. All those functions apply to the referenced
   tasks regardless if they are proper SCSI tasks or tagged iSCSI
   operations.  Task management commands must be executed as if all the
   commands having a CmdSN lower or equal to the task management CmdSN have
   been received by the target (i.e., have to be executed as if received
   for ordered delivery even when marked for immediate delivery).  For all
   the tasks covered by the task management response (i.e., with CmdSN not
   higher than the task management command CmdSN), additional responses
   MUST NOT be delivered to the SCSI layer after the task management
   response.

   For the <Logical Unit Reset>, the target MUST behave as dictated by the
   Logical Unit Reset function in [SAM-2].

   The Target Reset function (Warm and Cold) implementation is OPTIONAL and
   when implemented they should act as described below.  Target Reset MAY
   be also subject to authorization of the requesting initiator.  When not
   implemented or when authorization fails at target, Target Reset
   functions should end as if the function was executed successfully and
   the response qualifier will detail what was executed.

   For the <Target Warm Reset> and <Target Cold Reset> functions, the
   target cancels all pending operations and are both equivalent to the
   Hard Reset as specified by [SAM-2].  They can both affect many other
   initiators.

   In addition, for the <Target Cold Reset> the target then MUST terminate
   all of its TCP connections to all initiators (all sessions are
   terminated). However, if the target finds that it cannot send the
   required response or AEN, it MUST continue the reset operation and it
   SHOULD log the condition for later retrieval in its internal management
   structures.

   Further actions on reset functions are specified in the relevant SCSI
   documents for the specific class of devices.

   For the <Task Resume> and <Task Replay> the target should resume
   executing the referenced task or replay it completely. <Task Replay>
   MUST be received by the target ONLY after the status for the command was
   issued. <Task Resume> MUST be received by the target ONLY after the
   connection on which the command was previously executing has been
   successfully logged-out.
   <Task Resume> and <Task Replay> MUST be issued as immediate commands.

1.1.2     LUN

   This field is required for functions addressing a specific LU (<abort
   task, clear task set, abort task set, clear ACA, Reset LU and is
   reserved in all others.

1.1.3     Referenced Task Tag

   Initiator Task Tag of the task to be aborted, restarted or replayed

1.1.4     RefCmdSN

   For abort-task the task CmdSN to enable task removal. If RefCmdSN does
   not match the CmdSN of the command to be aborted at the target
   The abort action MUST not be performed and the response MUST be function
   rejected.


1.2  Task Management Response


   Byte /    0       |       1       |       2       |       3       |
      /              |               |               |               |
     |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
     +---------------+---------------+---------------+---------------+
    0|1|1| 0x22      |1| Reserved (0)                                |
     +---------------+---------------+---------------+---------------+
    4/ Reserved (0)                                                  /
     /                                                               /
     +---------------+---------------+---------------+---------------+
   16| Initiator Task Tag                                            |
     +---------------+---------------+---------------+---------------+
   20| Referenced Task Tag or Reserved (0xffffffff)                  |
     +---------------+---------------+---------------+---------------+
   24| StatSN                                                        |
     +---------------+---------------+---------------+---------------+
   28| ExpCmdSN                                                      |
     +---------------+---------------+---------------+---------------+
   32| MaxCmdSN                                                      |
     +---------------+---------------+---------------+---------------+
   36| Response      | Qualifier     | Reserved (0)                  |
     +---------------+---------------+---------------+---------------+
   40/ Reserved (0)                                                  /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
   48

   For the functions <Abort Task, Abort Task Set, Clear ACA, Clear Task
   Set, Logical Unit reset, Target Warm Reset>, the target performs the
   requested Task Management function and sends a Task Management Response
   back to the initiator. The target provides a Response, which may take on
   the following values:

       0    Function Complete
       1    Task was not in task set
       2    Command not received yet but placeholder marked for task abort
3    LUN does not exist
4    Task running on a connection that was not logged-out
5    Task failover not supported
6    Task in progress
7    Task replay not supported
      255   Function Rejected


   The Qualifier field details the Response.

   For Function Complete the valid Qualifiers are:

      0 - Function Executed
      1 - Function not implemented
      2 - Not Authorized

   For the <Target Cold Reset> and <Target Warm Reset> functions, the
   target cancels all pending operations.  For the <Target Cold Reset> the
   target MUST then close all of its TCP connections to all initiators
   (terminates all sessions).

   The mapping of the response code into a SCSI service response code, if
   needed, is outside the scope of this document.

1.2.1     Referenced Task Tag

   Initiator Task Tag of the task not found used in conjunction with
   responses referring to a specific task. It MUST be set to 0xffffffff in
   other cases.

   Julo



From owner-ips@ece.cmu.edu  Wed Aug 22 14:27:54 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19365
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 14:27:54 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7MHh8409775
	for ips-outgoing; Wed, 22 Aug 2001 13:43:08 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7MHh5e09762
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 13:43:05 -0400 (EDT)
Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77])
	by msgbas2.cos.agilent.com (Postfix) with ESMTP
	id 0ECAE94D; Wed, 22 Aug 2001 11:42:52 -0600 (MDT)
Received: from axcsbh2.cos.agilent.com (axcsbh2.cos.agilent.com [130.29.152.144])
	by msgrel1.cos.agilent.com (Postfix) with SMTP
	id 81EEC492; Wed, 22 Aug 2001 11:42:51 -0600 (MDT)
Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 22 Aug 2001 11:42:51 -0600 (Mountain Daylight Time)
Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19)
	id <Q9QT4WT1>; Wed, 22 Aug 2001 11:42:51 -0600
Message-ID: <FEEBE78C8360D411ACFD00D0B74779719A892C@xsj02.sjs.agilent.com>
From: "CAVANNA,VICENTE V (A-Roseville,ex1)" <vince_cavanna@agilent.com>
To: "'Julian Satran'" <Julian_Satran@il.ibm.com>,
        "'Mark Bakke'" <mbakke@cisco.com>
Cc: "CAVANNA,VICENTE V (A-Roseville,ex1)" <vince_cavanna@agilent.com>,
        Pat.Thaler@d12relay01.de.ibm.com, ips@ece.cmu.edu
Subject: RE: iSCSI CRC: A CRC-checking example
Date: Wed, 22 Aug 2001 11:42:50 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Julian and Mark and others,

After I took into account the bit "reflection"  and the byte order (Big
Endian on Bytes and Little Endian on bits) I did finally obtain, using
polynomial math, the (corrected) results you show in the CRC examples. The
results have also been confirmed independently by an implementor here at
Agilent. 

I am the one who originally suggested to Julian that we specify the CRC
algorithm the same way as in ethernet even though for iSCSI it is not really
important to initialize the CRC register to all 1s and to complement the CRC
before transmission since there are other means to detect extra or missing
PDU bytes. However I had not realzied until recently that conformance with
the ethernet algorithm implies bit reflection. I had not been aware that in
ethernet the bits are sent out on the serial link with the least significant
bit first AND that the corresponding message polynomial is formed from the
bits in the sequence that they appear on the serial link; thus the need for
bit "reflection". 

Now that I understand the need for bit reflection (taken into account in the
rocksoft parameterized CRC generator by setting the in and out reflection
flag parameters to TRUE) I am not sure I agree that we want it in iSCSI. The
penalty for full conformity with ethernet seems too great. If people feel
strongly that we must keep the bit reflection I think that to make the
existing documentation clear and unambiguous we would need to explicitly
show the mapping of bits in the iSCSI PDU to coefficients of the message
polynomial that represents the iSCSI PDU. We would also need to show the
mapping of the CRC bits to the coefficients of its representative
polynomial. 

If you don't agree I will elaborate further later this week to try to
convince you. My objective is to be able to easily and unambiguously
describe the polynomial math behind the algorithm; right now, with the bit
reflection and without the explicit mapping it is awkward.

Vince  



From owner-ips@ece.cmu.edu  Wed Aug 22 14:46:15 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20155
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 14:46:15 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7MI28k11064
	for ips-outgoing; Wed, 22 Aug 2001 14:02:08 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from hebe.or.intel.com (jffdns02.or.intel.com [134.134.248.4])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7MI26e11058
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 14:02:06 -0400 (EDT)
Received: from SMTP (orsmsxvs01-1.jf.intel.com [192.168.65.200])
	by hebe.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id SAA13203
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 18:02:00 GMT
Received: from orsmsx29.jf.intel.com ([192.168.70.29]) by 192.168.70.200
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Wed, 22 Aug 2001 18:02:00 0000 (GMT)
Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2653.19)
	id <RD1XR3H1>; Wed, 22 Aug 2001 11:01:58 -0700
Message-ID: <638EC1B28663D211AC3E00A0C96B78A8086ABB44@orsmsx40.jf.intel.com>
From: "Wheat, Stephen R" <stephen.r.wheat@intel.com>
To: ietf-ips <ips@ece.cmu.edu>
Subject: RE: iSCSI: Login Proposal
Date: Wed, 22 Aug 2001 11:01:54 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Marjorie,

I agree with your premise that the target must be allowed to not just let
anyone in.

But why isn't this already covered by the ability of the sys admin to
configure the target to only agree to certain offerings?  Quoting from
1.2.4, with my
emphasis,
   "The responding party answers with the first value from the list it
supports and
    is **allowed** to use for the specific initiator."


For some network interfaces,
the sys admin could rely upon physical security and other means inherent to
the
environment.  In such cases, the admin could configure the target to follow
the
initiator's preferences, including "none".

For other network interfaces where the environment is not inherently
trusted,
the sysadmin would be motivated to not allow the target to
connect without any authentication; so they'd set it up to not accept
"none", even
though the initiator may prefer "none".

Yes?

Stephen

-----Original Message-----
From: KRUEGER,MARJORIE (HP-Roseville,ex1)
[mailto:marjorie_krueger@hp.com]
Sent: Wednesday, August 22, 2001 10:47 AM
To: 'Rod Harrison'; ietf-ips
Subject: RE: iSCSI: Login Proposal


I'm thinking a little differently regarding which party has priority in
chosing security parameters - while it *may* be the initiators data, this
can't be established until the initiator is authenticated.  Since the target
is the "server" side, I think the burden is on the target to ensure that
this is the intended initiator.  Therefore, the target must dictate the
authentication method used, since it has the security responsibility and the
"contact point" for potentially malicious entities.  Consider the example
where an initiator was previously authenticated using Kerberos, the session
was ended, and a new session is requested by what appears to be the same
initiator, but the authmethod requested is now "none".  Looks pretty
suspicious to me.  It seems to me like the target has the responsibility of
maintaining a consistent authmethod with all initiators that access it,
therefore the target MUST force the minimum level authorization it requires
or reject the login request.

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: marjorie_krueger@hp.com 

> -----Original Message-----
> From: Rod Harrison [mailto:rod.harrison@windriver.com]
> Sent: Wednesday, August 22, 2001 4:58 AM
> To: Wheat, Stephen R; 'Steve Senum'; ietf-ips
> Subject: RE: iSCSI: Login Proposal
> 
> 
> 
> 	I think we should view this as the order indicates the
> initiators preference and the target SHOULD pick the first
> item from the list it supports. Note that SHOULD allows the
> target to do something other than pick the first item it
> supports if it has a good reason to do so, e.g. If it would
> otherwise terminate the session. The initiator can always
> terminate the session if it doesn't like what the target
> chooses.
> 
> 	So, to extend your example, as an initiator if I didn't
> want to do CHAP at all I would send ...
> 
> AuthMethod=none
> 
> 	if I preferred not to do CHAP but I could tolerate it I
> would send ...
> 
> AuthMethod=none,CHAP
> 
> 	and if I would prefer CHAP I would send ...
> 
> AuthMethod=CHAP,none
> 
> 	I expect this to be under the control of the sys admin
> through some kind of config at the initiator side. I think a
> good guide to keep in mind with all this is that it is the
> initiator's data, and so it seems reasonable to let the
> initiator control connection security and integrity.
> 
> 	- Rod
> 
 



From owner-ips@ece.cmu.edu  Wed Aug 22 14:57:02 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20535
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 14:57:00 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7MIDh411719
	for ips-outgoing; Wed, 22 Aug 2001 14:13:43 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from c007.snv.cp.net (c007-h000.c007.snv.cp.net [209.228.33.206])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f7MIDge11715
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 14:13:42 -0400 (EDT)
Received: (cpmta 5695 invoked from network); 22 Aug 2001 11:13:35 -0700
Received: from adsl-63-202-160-80.dsl.snfc21.pacbell.net (HELO littlejoy) (63.202.160.80)
  by smtp.telocity.com (209.228.33.206) with SMTP; 22 Aug 2001 11:13:35 -0700
X-Sent: 22 Aug 2001 18:13:35 GMT
From: "Douglas Otis" <dotis@sanlight.net>
To: "John Hufferd" <hufferd@us.ibm.com>,
        "Martin, Nick" <Nick.Martin@compaq.com>
Cc: <ips@ece.cmu.edu>
Subject: RE: iSCSI: Support Alias in the protocol
Date: Wed, 22 Aug 2001 11:11:49 -0700
Message-ID: <NEBBJGDMMLHHCIKHGBEJOEKECKAA.dotis@sanlight.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
In-Reply-To: <OFAD360828.CCE00957-ON88256AB0.0058B56D@boulder.ibm.com>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

John,

As Bob eloquently explained, these labels are just as likely to confuse as
to assist those individuals that may be assigned different targets when
connecting to their storage.  It is likely these labels will be problematic
rather than helpful and a source of frustration for IT individuals to
explain to now confused users.  The goal should be to ensure that some
management functionality is obtainable even from such satellite environments
to avoid these types of problems rather than placing hopes on an alias label
that does not indicate the nature of the connection as being helpful.

Doug

> Martin,
> I think your view is "Right-ON".  Over the years I have had the
> "marvelous"
> opportunity to work in the management of an IS/IT organization.  It is the
> presents of little things like this Alias that make or break so much of
> what we attempted.  I was not only responsible for the management of a
> Large Data Center (at IBM Santa Teresa Lab) but also its
> satellites  It was
> in the satellite systems, where the full featured Management Software was
> most likely not to exist.
>
> I expect that this view is the rule in smaller installations, that is, you
> will not generally find the large Network and Storage Management Software
> in those environments.  They will have a number of simple low end, or no,
> general Management Software.
>
> Though I would like to have Tivoli or HP Open View (for example)
> everywhere, I know this will not happen.  We need to do
> everything possible
> to support the small installation as long as it does not cause a
> big impact
> on the iSCSI protocol.
>
> I think that the Alias capability, though not a hard requirement
> for iSCSI,
> is a very worthwhile feature, that will help humans.
>
> .
> .
> .
> John L. Hufferd
> Senior Technical Staff Member (STSM)
> IBM/SSG San Jose Ca
> Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
> Home Office (408) 997-6136
> Internet address: hufferd@us.ibm.com
>
>
> "Martin, Nick" <Nick.Martin@compaq.com>@ece.cmu.edu on 08/21/2001 11:34:54
> AM
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   "'Robert Snively'" <rsnively@Brocade.COM>, "'ips@ece.cmu.edu'"
>       <ips@ece.cmu.edu>
> cc:
> Subject:  RE: iSCSI: Support Alias in the protocol
>
>
>
> Bob,
>
> I agree that the iSCSI Name is analogous to the VIN number on a car.
> The VIN number and the iSCSI Name are supposed to be constant for the life
> of the device.
> In my mind the iSCSI Alias is like the license plate tag.  If someone is
> looking for your car, in the mall parking lot you don't tell them the
> manufacturer assigned VIN number, you tell them the tag.  (You may also
> mention the make, model, and color.)  The VIN number is used for
> confirmation when required.  These are administrator assigned regionally
> and
> duplicate numbers are not much of a problem.
>
> Initiator Target relationships are defined by the InitiatorName and
> TargetName.  The protocol does not need aliases, but I believe the
> administrators do.  We need to allow administrators to assign their own
> tags
> to devices, and I believe these should be carried within the protocol so
> that no external databases are required.  When reporting a problem to an
> administrator, the device alias should be reported along with the device
> name.  The chances for error and confusion will be greatly reduced.  The
> alias or "tag" value will be easier for humans to deal with on a daily
> basis
> than a name field or VIN number would be.
>
> I support Alias within the iSCSI protocol.
>
> Thanks,
> Nick
> -----Original Message-----
> From: Robert Snively [mailto:rsnively@Brocade.COM]
> Sent: Monday, August 20, 2001 4:25 PM
> To: 'Mark S. Edwards'; ips@ece.cmu.edu
> Subject: RE: iSCSI: Support Alias in the protocol
>
>
> Folks,
>
> I remain concerned about this called consensus.  Clearly there
> will be thousands of Targets and Initiators running around
> a network.  Creating a set of human useable aliases
> that will distinguish all these seems to me somewhat farfetched.
> We don't even do very well on kings.  George, George II, etc.
>
> To create aliases in the context of a single management environment
> makes some sense, but again, that should be outside the
> scope of iSCSI.
>
> That we call our car Skeezix (human useable, for management
> purposes within the tightly constrained context of our own
> family) is non-architected information.  Whenever anyone cares
> which car it is (including during servicing and upgrades) they
> use the VIN, a registered and architected non-human-readable value.
>
> If Marjorie and I are the only voices in the woods, we have
> clearly had the consensus called against us, but this is high
> on my list of things that really aren't much help to anyone
> and shouldn't be in the document.
>
> Bob
>
> > >Let me also acknowledge as valid Marj's opinion that anything of
> > >this sort belongs in a management tool rather than the protocol.
> >
> > But it only works if everyone uses the same management tool,
> > or the tools agree upon the location and storage format of the
> > information
> > --  Somebody dig me up from my grave when Tivoli and
> > OpenView merge.
> >
> > As a way of easily identifying virtual LUN's or LU's within a
> > Target Space of potential hundreds or thousands the alias
> > is very valuable.
>
>
>
>



From owner-ips@ece.cmu.edu  Wed Aug 22 16:19:57 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22991
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 16:19:57 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7MJmCW17388
	for ips-outgoing; Wed, 22 Aug 2001 15:48:12 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from siaar1ab.compuserve.com (siaar1ab.compuserve.com [149.174.40.10])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7MJmAe17382
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 15:48:10 -0400 (EDT)
Received: (from mailgate@localhost)
	by siaar1ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id PAA17869
	for ips@ece.cmu.edu; Wed, 22 Aug 2001 15:48:04 -0400 (EDT)
Received: from compuserve.com (dal-tgn-tvq-vty50.as.wcom.net [216.192.240.50])
	by siaar1ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id PAA17806
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 15:48:02 -0400 (EDT)
Message-ID: <3B840B37.BC144EB9@compuserve.com>
Date: Wed, 22 Aug 2001 14:42:47 -0500
From: Ralph Weber <ralphoweber@compuserve.com>
Reply-To: ENDL_TX@computer.org
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47  (Win95; I)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: IPS Reflector <ips@ece.cmu.edu>
Subject: Re: IPS: FCIP & this list
References: <277DD60FB639D511AC0400B0D068B71ECAD641@CORPMX14>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit



Black_David@emc.com wrote:

>
> Ralph,
>
> > There are minutes (well, more like discussion notes) from the
> > conference call and I will ask that they be posted to this
> > reflector.
>
> That'll be an improvement, thanks.  Discussion notes are
> exactly the sort of thing that should to be visible on this
> reflector.
>
> > The interim FCIP drafts and issues lists are maintained in PDF
> > format, amounting to between .2M and .5M of new material per
> > week. Since this is Rome, they cannot be posted to this reflector.
> > It is totally impractical to translate the PDFs to text, sorry.
>
> That's a judgment call.  Actually sending the PDFs to the list
> or the I-D servers is a no-no, but it would be ok to put them
> on a web site and post URLs to the list, as long as new text
> versions of the draft do go to the I-D servers at reasonable
> intervals.  It would also be ok to keep the interim PDF versions
> private among the authors until the next major revision of
> the draft is ready for the I-D servers.  There's
> no requirement to make all working notes visible.
>
> I do need to clarify one point of process:
>
> > I doubt that the
> > WG Last Calls time requirement would be shortened by more than
> > 10% even if everything done by the FCIP authors was posted
> > to this reflector.  In particular, I see no reason to believe
> > that the people who will raise Last Call issues will remember
> > earlier postings here, or bother to participate on this
> > reflector prior to Last Call.
>
> My concern is that the existence of prior discussion on this
> reflector can be a significant factor in whether an issue raised
> in WG Last Call causes the Last Call to fail.  If one can point
> to prior discussion or even acceptance without discussion on this
> list of a technical approach that is questioned during WG Last
> Call, then such an issue may be resolvable by pointing to that
> discussion and indicating that the WG considered the alternative
> and has rough consensus to proceed as currently specified.  OTOH,
> if the issue is new to the reflector and technically valid, the
> odds of the WG Last Call failing are significantly increased.
> WG Last Call periods are measured in weeks (at least 2, but the
> initial WG Last Call period for each of the main protocol
> drafts is likely to be longer).  If a WG Last Call fails, the
> draft has to be revised, and the WG Last Call repeated; we went
> through one of these cycles with the iSCSI requirements draft.
>
> Thanks,
> --David
>
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------




From owner-ips@ece.cmu.edu  Wed Aug 22 16:26:17 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23113
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 16:26:17 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7MJmbJ17414
	for ips-outgoing; Wed, 22 Aug 2001 15:48:37 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from siaar1ab.compuserve.com (siaar1ab.compuserve.com [149.174.40.10])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7MJmZe17408
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 15:48:35 -0400 (EDT)
Received: (from mailgate@localhost)
	by siaar1ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id PAA18225
	for ips@ece.cmu.edu; Wed, 22 Aug 2001 15:48:29 -0400 (EDT)
Received: from compuserve.com (dal-tgn-tvq-vty50.as.wcom.net [216.192.240.50])
	by siaar1ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id PAA18130
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 15:48:21 -0400 (EDT)
Message-ID: <3B840D9B.D1E7CE55@compuserve.com>
Date: Wed, 22 Aug 2001 14:52:59 -0500
From: Ralph Weber <ralphoweber@compuserve.com>
Reply-To: ENDL_TX@computer.org
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47  (Win95; I)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: IPS Reflector <ips@ece.cmu.edu>
Subject: Re: IPS: FCIP & this list
References: <277DD60FB639D511AC0400B0D068B71ECAD641@CORPMX14>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

David,

This looks like progress to me.

} Actually sending the PDFs to the list or the I-D servers is a 
} no-no, but it would be ok to put them on a web site and post 
} URLs to the list, ...

Unless folks want to clutter the heck out of Julian's web site,
the only web site I can post them on is www.t11.org and to do
that I would have to give them T11 document numbers.  Is there
a problem with www.t11.org?  I doubt that T11 will mind, FCIP
concerns them in pretty serious ways.

} ...as long as new text versions of the draft do go to the I-D 
} servers at reasonable intervals.

Since I took over as editor, text versions have gone to the I-D
office at a rate of one per month.  I hope that is adequate.
Also, the text version can be made available for interim drafts,
but it will lack the PDF annotations that track ongoing issues,
what changes were made, and to some extent why.

} ... WG Last Call ...

I have to take your word for it regarding the WG Last Call issues.
Not ever having been there before, my view amounts to "what will be,
will be."

Also, resurrecting the Requirements Last Call does nothing in the
way of reassuring one that prior discussion on the reflector matters.

Thanks.

Ralph...


From owner-ips@ece.cmu.edu  Wed Aug 22 16:26:18 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23124
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 16:26:18 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7MJ7pi15210
	for ips-outgoing; Wed, 22 Aug 2001 15:07:51 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f7MJ7ne15205
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 15:07:49 -0400 (EDT)
Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Wed Aug 22 15:06:42 EDT 2001
Received: from aura.research.bell-labs.com ([135.104.46.10]) by grubby; Wed Aug 22 15:07:01 EDT 2001
Received: from research.bell-labs.com (IDENT:sandeepj@sandeepj-pcmh.research.bell-labs.com [135.104.47.90])
	by aura.research.bell-labs.com (8.9.1/8.9.1) with ESMTP id PAA23690
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 15:06:28 -0400 (EDT)
Message-ID: <3B8402B4.8886D192@research.bell-labs.com>
Date: Wed, 22 Aug 2001 15:06:28 -0400
From: Sandeep Joshi <sandeepj@research.bell-labs.com>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-3 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: ips@ece.cmu.edu
Subject: Re: FW: I-D ACTION:draft-aboba-ips-iscsi-security-00.txt
References: <277DD60FB639D511AC0400B0D068B71ECAD638@CORPMX14>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit



David,
 
> I hope this is what you were looking for in the way of comments.

Yes..and will await the ipsec WG's call :-)

Btw, the draft could add a section on this issue so the
point does not get lost.

-Sandeep

Black_David@emc.com wrote:
> 
> Sandeep,
> 
> There is a patent on it, and a license is required to ship product.
> The license should be available under fair, reasonable, and non-
> discriminatory terms, but will not be free.  A reasonable guess
> would be that iSCSI licensing terms would be similar to the 802.11
> terms, and that a suitable IETF intellectual property rights notice
> will be forthcoming.
> 
> OTOH, this does seem to run counter to the usual IETF preference
> for unpatented technology over patented technology provided that
> the unpatented technology is a functionally suitable replacement
> for the patented technology.  Whether there are functionally suitable
> unpatented replacements for OCB is an issue for further discussion,
> ditto the requirements and preferences that lead to the recommendation
> of OCB.  A draft on OCB would need to go through the ipsec WG if we
> were to use OCB, and my impression is that at least some portion of
> that community has a very strong preference for unpatented technology.
> 
> I hope this is what you were looking for in the way of comments.
> 
> Thanks,
> --David
> 
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------
> 
> > -----Original Message-----
> > From: sandeepj@research.bell-labs.com
> > [mailto:sandeepj@research.bell-labs.com]
> > Sent: Tuesday, August 21, 2001 7:49 PM
> > To: ips@ece.cmu.edu
> > Subject: Re: FW: I-D ACTION:draft-aboba-ips-iscsi-security-00.txt
> >
> >
> > David,
> >
> > Could you comment on the intellectual rights issues
> > here, particularly on AES-OCB, which will be mandatory
> > according to this draft (Sec 2.1)
> >
> > http://www.cs.ucdavis.edu/~rogaway/ocb/ocb-back.htm
> > mentions the licensing terms for 802.11 products.
> >
> > Secondly, appendix tables A.5 and A.6 seem to indicate
> > that AES-CTR+UMAC performance is better than AES-OCB.
> > Has AES-OCB been chosen since it requires lesser keying
> > material and memory ?
> >
> > thanks
> > -Sandeep
> >
> > > FYI - this is about use of IKE and IPsec algorithm selection
> > > considerations.  --David
> > >
> > > -----Original Message-----
> > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> > > Sent: Tuesday, August 21, 2001 7:25 AM
> > > Subject: I-D ACTION:draft-aboba-ips-iscsi-security-00.txt
> > >
> > > A New Internet-Draft is available from the on-line Internet-Drafts
> > > directories.
> > >
> > > Title           : Securing iSCSI using IPsec
> > > Author(s)       : B. Aboba et al.
> > > Filename        : draft-aboba-ips-iscsi-security-00.txt
> > > Pages           : 35
> > > Date            : 20-Aug-01
> > >
> > > This document discusses how iSCSI may utilize IPsec to provide
> > > authentication, integrity, confidentiality and replay protection.
> > >
> > > A URL for this Internet-Draft is:
> > >
> http://www.ietf.org/internet-drafts/draft-aboba-ips-iscsi-security-00.txt
> >
> > Internet-Drafts are also available by anonymous FTP. Login with the
> username
> > "anonymous" and a password of your e-mail address. After logging in,
> > type "cd internet-drafts" and then
> > "get draft-aboba-ips-iscsi-security-00.txt".
> >
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> > Internet-Drafts can also be obtained by e-mail.
> >
> > Send a message to:
> > mailserv@ietf.org.
> > In the body type:
> > "FILE /internet-drafts/draft-aboba-ips-iscsi-security-00.txt".
> >
> > NOTE:   The mail server at ietf.org can return the document in
> > MIME-encoded form by using the "mpack" utility.  To use this
> > feature, insert the command "ENCODING mime" before the "FILE"
> > command.  To decode the response(s), you will need "munpack" or
> > a MIME-compliant mail reader.  Different MIME-compliant mail readers
> > exhibit different behavior, especially when dealing with
> > "multipart" MIME messages (i.e. documents which have been split
> > up into multiple messages), so check your local documentation on
> > how to manipulate these messages.
> >
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> >
> > ---------------------------------------------------------
> > + Date: Tue, 21 Aug 2001 09:29:53 -0400
> > + Content-Type:
> > multipart/mixed;boundary="----_=_NextPart_002_01C12A44.418236C0"
> >
> > ATT36560
> >
> > <ftp://internet-drafts/>
> > Transfer-mode: ftp.ietf.org
> > ---------------------------------------------------------
> >


From owner-ips@ece.cmu.edu  Wed Aug 22 16:26:37 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23137
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 16:26:36 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7MJh2517090
	for ips-outgoing; Wed, 22 Aug 2001 15:43:02 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from c007.snv.cp.net (c007-h014.c007.snv.cp.net [209.228.33.221])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f7MJh1e17085
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 15:43:01 -0400 (EDT)
Received: (cpmta 26933 invoked from network); 22 Aug 2001 12:42:51 -0700
Received: from adsl-63-202-160-80.dsl.snfc21.pacbell.net (HELO littlejoy) (63.202.160.80)
  by smtp.telocity.com (209.228.33.221) with SMTP; 22 Aug 2001 12:42:51 -0700
X-Sent: 22 Aug 2001 19:42:51 GMT
From: "Douglas Otis" <dotis@sanlight.net>
To: "CAVANNA,VICENTE V \(A-Roseville,ex1\)" <vince_cavanna@agilent.com>,
        "'Julian Satran'" <Julian_Satran@il.ibm.com>,
        "'Mark Bakke'" <mbakke@cisco.com>
Cc: <Pat.Thaler@d12relay01.de.ibm.com>, <ips@ece.cmu.edu>
Subject: RE: iSCSI CRC: A CRC-checking example
Date: Wed, 22 Aug 2001 12:41:05 -0700
Message-ID: <NEBBJGDMMLHHCIKHGBEJCEKHCKAA.dotis@sanlight.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
In-Reply-To: <FEEBE78C8360D411ACFD00D0B74779719A892C@xsj02.sjs.agilent.com>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Vince,

The table reflection is a good thing as it actually reduces the instructions
required within the algorithm.

For the non-reflected table lookup you have:
CRC32(c,d) (c=(c<<8)^crc32tab[(c>>24)&0xFF])

For the reflected table lookup you have:
CRC32(c,d) (c=(c>>8)^crc32tab[(c^(d))&0xFF])

In addition, for storage with a little endian processor, there is no need to
exchange byte order to store in big endian order as the reflected table has
already provided that byte order.

The only thing that I think should be considered is whether the CRC is
stored inverted.

Julian has already responded to my query on this subject with this
statement:

"The 2 "additions" you will find in the CRC calculation:

   initializing the "remainder" field with all ones
   (instead of the implied shifting in of 0's) and
   XORing the result with a mask (usually "full house")

are done to improve the error correction capabilities of CRCs.
CRCs are weak in detecting the spurious addition of leading 0s (that can
result from clocking errors) and the deletion of initial 1 with spurious
insertion of a 1 at the end."

If the CRC is initialized with all one's at the beginning, I fail to see the
need to invert before storing the CRC as this ensures there will be a
pattern created even with an all zeros block.  How does inverting this
pattern aid in detecting errors?

Doug


> Julian and Mark and others,
>
> After I took into account the bit "reflection"  and the byte order (Big
> Endian on Bytes and Little Endian on bits) I did finally obtain, using
> polynomial math, the (corrected) results you show in the CRC examples. The
> results have also been confirmed independently by an implementor here at
> Agilent.
>
> I am the one who originally suggested to Julian that we specify the CRC
> algorithm the same way as in ethernet even though for iSCSI it is
> not really
> important to initialize the CRC register to all 1s and to
> complement the CRC
> before transmission since there are other means to detect extra or missing
> PDU bytes. However I had not realzied until recently that conformance with
> the ethernet algorithm implies bit reflection. I had not been
> aware that in
> ethernet the bits are sent out on the serial link with the least
> significant
> bit first AND that the corresponding message polynomial is formed from the
> bits in the sequence that they appear on the serial link; thus
> the need for
> bit "reflection".
>
> Now that I understand the need for bit reflection (taken into
> account in the
> rocksoft parameterized CRC generator by setting the in and out reflection
> flag parameters to TRUE) I am not sure I agree that we want it in
> iSCSI. The
> penalty for full conformity with ethernet seems too great. If people feel
> strongly that we must keep the bit reflection I think that to make the
> existing documentation clear and unambiguous we would need to explicitly
> show the mapping of bits in the iSCSI PDU to coefficients of the message
> polynomial that represents the iSCSI PDU. We would also need to show the
> mapping of the CRC bits to the coefficients of its representative
> polynomial.
>
> If you don't agree I will elaborate further later this week to try to
> convince you. My objective is to be able to easily and unambiguously
> describe the polynomial math behind the algorithm; right now, with the bit
> reflection and without the explicit mapping it is awkward.
>
> Vince
>
>



From owner-ips@ece.cmu.edu  Wed Aug 22 16:50:00 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23735
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 16:50:00 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7MKBdk18972
	for ips-outgoing; Wed, 22 Aug 2001 16:11:39 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from zcamail03.zca.compaq.com (zcamail03.zca.compaq.com [161.114.32.103])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7MKBZe18966
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 16:11:37 -0400 (EDT)
Received: by zcamail03.zca.compaq.com (Postfix, from userid 12345)
	id 3B39BB7E; Wed, 22 Aug 2001 13:11:14 -0700 (PDT)
Received: from exchou-gh03.cca.cpqcorp.net (exchou-gh03.cca.cpqcorp.net [16.110.248.203])
	by zcamail03.zca.compaq.com (Postfix) with ESMTP id E537CA0B
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 13:11:13 -0700 (PDT)
Received: by exchou-gh03.cca.cpqcorp.net with Internet Mail Service (5.5.2652.78)
	id <RN6KZNGB>; Wed, 22 Aug 2001 15:11:26 -0500
Message-ID: <08DC7D0912B46D4EBF224A34371D7BC21052B7@cxoexc12.americas.cpqcorp.net>
From: "Fraser, Don" <Don.Fraser@compaq.com>
To: ips@ece.cmu.edu
Subject: FW: draft-ietf-ips-fcovertcpip-05
Date: Wed, 22 Aug 2001 15:11:15 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


I've found a couple of nits that I found in the current FC over IP IEFT
draft.

on PDF page 16, I noticed that there are 26 tests in total mentioned in a)
through m), so the correct number on the last line of that page should be 24
instead of 21.

On PDF page 24, paragraph 8.3, I would like to see us add to the end of the
paragraph the words " and notification".  And based on our experiences with
a number of FC over ATM products the word SHOULD in the next to last line of
that paragraph needs to become a SHALL.  This way any FC over IP device will
inform the local switch it is attached to any time there is a loss of the
intersite link.  Without this forced notification the two switches connected
by the intersite link created with the FC over IP devices may never know if
the link fails once it is established.  

on the top of PDF page 25, I believe we should we add the following 3rd
paragraph:  

	3) When there are disparate windows / buffer sizes between the FC
network and the IP network.
		
		Even with compatible speeds there may conditions during
normal operation of the FC fabric or the IP network
		where congestion is caused by disparate window and/or buffer
sizes. For example a device on a short link with 
		a small buffer talking with a device that is a attached to a
long distance link and a corresponding large buffer.  

on the bottom of page 27, next to last line, we probably need to re-phrase
the words "low latency" to "low latency appropriate for the distances
involved".


on PD page 38, figure 10, add the words to the effect that on closing the
TCP/IP connection the device should also close the FC Switch connection.

Finally if we drop DLY_LIM, we need to modify paragraphs on pages 5, 18, 20,
and 23.

Don Fraser


From owner-ips@ece.cmu.edu  Wed Aug 22 16:58:30 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23850
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 16:58:30 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7MKEvW19160
	for ips-outgoing; Wed, 22 Aug 2001 16:14:57 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7MKEte19154
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 16:14:55 -0400 (EDT)
Received: from xparelay2.corp.hp.com (unknown [15.58.137.112])
	by palrel2.hp.com (Postfix) with ESMTP id F1254226A
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 13:14:50 -0700 (PDT)
Received: from xpabh4.corp.hp.com (xpabh4.corp.hp.com [15.58.136.1])
	by xparelay2.corp.hp.com (Postfix) with ESMTP id A78EB1F50D
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 13:14:50 -0700 (PDT)
Received: by xpabh4.corp.hp.com with Internet Mail Service (5.5.2653.19)
	id <QRC56THF>; Wed, 22 Aug 2001 13:14:50 -0700
Message-ID: <6BD67FFB937FD411A04F00D0B74FE87802A0925E@xrose06.rose.hp.com>
From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
To: ietf-ips <ips@ece.cmu.edu>
Subject: RE: iSCSI: Login Proposal
Date: Wed, 22 Aug 2001 13:14:46 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

I meant only to point out that it's the target that must dictate the
security environment, not the initiator.  The initiator is only
communicating a preference.  So yes, I agree with you, but Ron's comment was

> > 	I expect this to be under the control of the sys admin
> > through some kind of config at the initiator side. I think a
> > good guide to keep in mind with all this is that it is the
> > initiator's data, and so it seems reasonable to let the
> > initiator control connection security and integrity.

and I'm thinking it's the other way around.  The initiator has a role, but
it is the requestor of a service, not the "server" hence the target really
controls security.  Of course, ultimately, the system admin controls
everything, but we don't get to write his/her "protocol"  :-) 

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: marjorie_krueger@hp.com 

> -----Original Message-----
> From: Wheat, Stephen R [mailto:stephen.r.wheat@intel.com]
> Sent: Wednesday, August 22, 2001 11:02 AM
> To: ietf-ips
> Subject: RE: iSCSI: Login Proposal
> 
> 
> Marjorie,
> 
> I agree with your premise that the target must be allowed to 
> not just let
> anyone in.
> 
> But why isn't this already covered by the ability of the sys admin to
> configure the target to only agree to certain offerings?  Quoting from
> 1.2.4, with my
> emphasis,
>    "The responding party answers with the first value from the list it
> supports and
>     is **allowed** to use for the specific initiator."
> 
> 
> For some network interfaces,
> the sys admin could rely upon physical security and other 
> means inherent to
> the
> environment.  In such cases, the admin could configure the 
> target to follow
> the
> initiator's preferences, including "none".
> 
> For other network interfaces where the environment is not inherently
> trusted,
> the sysadmin would be motivated to not allow the target to
> connect without any authentication; so they'd set it up to not accept
> "none", even
> though the initiator may prefer "none".
> 
> Yes?
> 
> Stephen
> 
> -----Original Message-----
> From: KRUEGER,MARJORIE (HP-Roseville,ex1)
> [mailto:marjorie_krueger@hp.com]
> Sent: Wednesday, August 22, 2001 10:47 AM
> To: 'Rod Harrison'; ietf-ips
> Subject: RE: iSCSI: Login Proposal
> 
> 
> I'm thinking a little differently regarding which party has 
> priority in
> chosing security parameters - while it *may* be the 
> initiators data, this
> can't be established until the initiator is authenticated.  
> Since the target
> is the "server" side, I think the burden is on the target to 
> ensure that
> this is the intended initiator.  Therefore, the target must 
> dictate the
> authentication method used, since it has the security 
> responsibility and the
> "contact point" for potentially malicious entities.  Consider 
> the example
> where an initiator was previously authenticated using 
> Kerberos, the session
> was ended, and a new session is requested by what appears to 
> be the same
> initiator, but the authmethod requested is now "none".  Looks pretty
> suspicious to me.  It seems to me like the target has the 
> responsibility of
> maintaining a consistent authmethod with all initiators that 
> access it,
> therefore the target MUST force the minimum level 
> authorization it requires
> or reject the login request.
> 
> Marjorie Krueger
> Networked Storage Architecture
> Networked Storage Solutions Org.
> Hewlett-Packard
> tel: +1 916 785 2656
> fax: +1 916 785 0391
> email: marjorie_krueger@hp.com 
> 
> > -----Original Message-----
> > From: Rod Harrison [mailto:rod.harrison@windriver.com]
> > Sent: Wednesday, August 22, 2001 4:58 AM
> > To: Wheat, Stephen R; 'Steve Senum'; ietf-ips
> > Subject: RE: iSCSI: Login Proposal
> > 
> > 
> > 
> > 	I think we should view this as the order indicates the
> > initiators preference and the target SHOULD pick the first
> > item from the list it supports. Note that SHOULD allows the
> > target to do something other than pick the first item it
> > supports if it has a good reason to do so, e.g. If it would
> > otherwise terminate the session. The initiator can always
> > terminate the session if it doesn't like what the target
> > chooses.
> > 
> > 	So, to extend your example, as an initiator if I didn't
> > want to do CHAP at all I would send ...
> > 
> > AuthMethod=none
> > 
> > 	if I preferred not to do CHAP but I could tolerate it I
> > would send ...
> > 
> > AuthMethod=none,CHAP
> > 
> > 	and if I would prefer CHAP I would send ...
> > 
> > AuthMethod=CHAP,none
> > 
> > 	I expect this to be under the control of the sys admin
> > through some kind of config at the initiator side. I think a
> > good guide to keep in mind with all this is that it is the
> > initiator's data, and so it seems reasonable to let the
> > initiator control connection security and integrity.
> > 
> > 	- Rod
> > 
>  
> 


From owner-ips@ece.cmu.edu  Wed Aug 22 16:59:35 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23875
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 16:59:35 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7MJraL17724
	for ips-outgoing; Wed, 22 Aug 2001 15:53:36 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from c007.snv.cp.net (c007-h013.c007.snv.cp.net [209.228.33.220])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f7MJrYe17718
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 15:53:34 -0400 (EDT)
Received: (cpmta 15557 invoked from network); 22 Aug 2001 12:53:18 -0700
Received: from adsl-63-202-160-80.dsl.snfc21.pacbell.net (HELO littlejoy) (63.202.160.80)
  by smtp.telocity.com (209.228.33.220) with SMTP; 22 Aug 2001 12:53:18 -0700
X-Sent: 22 Aug 2001 19:53:18 GMT
From: "Douglas Otis" <dotis@sanlight.net>
To: "CAVANNA,VICENTE V \(A-Roseville,ex1\)" <vince_cavanna@agilent.com>,
        "'Julian Satran'" <Julian_Satran@il.ibm.com>,
        "'Mark Bakke'" <mbakke@cisco.com>
Cc: <Pat.Thaler@d12relay01.de.ibm.com>, <ips@ece.cmu.edu>
Subject: RE: iSCSI CRC: A CRC-checking example
Date: Wed, 22 Aug 2001 12:51:33 -0700
Message-ID: <NEBBJGDMMLHHCIKHGBEJOEKHCKAA.dotis@sanlight.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
In-Reply-To: <NEBBJGDMMLHHCIKHGBEJCEKHCKAA.dotis@sanlight.net>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Follow on:

Slight correction:

 For the non-reflected table lookup you have:
 CRC32(c,d) (c=(c<<8)^crc32tab[((c>>24)^(d))&0xFF])
 
 For the reflected table lookup you have:
 CRC32(c,d) (c=(c>>8)^crc32tab[(c^(d))&0xFF])
 
Doug


From owner-ips@ece.cmu.edu  Wed Aug 22 17:03:12 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23982
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 17:03:12 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7MKTJa20056
	for ips-outgoing; Wed, 22 Aug 2001 16:29:19 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7MKTHe20050
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 16:29:17 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id WAA135078;
	Wed, 22 Aug 2001 22:29:06 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7MKT6O178674;
	Wed, 22 Aug 2001 22:29:06 +0200
Importance: Normal
Subject: RE: iSCSI CRC: A CRC-checking example
To: "CAVANNA,VICENTE V (A-Roseville,ex1)" <vince_cavanna@agilent.com>
Cc: "'Mark Bakke'" <mbakke@cisco.com>,
        "CAVANNA,VICENTE V (A-Roseville,ex1)" <vince_cavanna@agilent.com>,
        Pat.Thaler@d12relay01.de.ibm.com, ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFB5EA0020.236B8098-ONC2256AB0.006F8B8E@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Wed, 22 Aug 2001 23:28:37 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 22/08/2001 23:29:05
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Vince & all,

I've added some statement about order (byte and bit) to the draft (you have
probably missed that piece of the mail).

I could be more graphic and less explicit as in SPI but I think that won't
help too much.

People did it for ethernet for years without too much ado.

And don't complain to me - IBM did consistent bit ordering for years
(Big-endian).  IBM even sent ASCII big endian (nobody else did and we had
to recode for VT100 access).

As for what to choose - It seems that we are in an are where almost
everybody does it now in this crazy way.
I strongly suspect that this was also the reason for the way SPI does it.
They have gone all the way to acommodate
x86 byte ordering in registers - so that the revert the bytes before
calculating -and do this on a parallel bus!
360 was certainly the last bastion of regularity.

Regards,
Julo


"CAVANNA,VICENTE V (A-Roseville,ex1)" <vince_cavanna@agilent.com> on
22-08-2001 20:42:50

Please respond to "CAVANNA,VICENTE V (A-Roseville,ex1)"
      <vince_cavanna@agilent.com>

To:   Julian Satran/Haifa/IBM@IBMIL, "'Mark Bakke'" <mbakke@cisco.com>
cc:   "CAVANNA,VICENTE V (A-Roseville,ex1)" <vince_cavanna@agilent.com>,
      Pat.Thaler@d12relay01.de.ibm.com, ips@ece.cmu.edu
Subject:  RE: iSCSI CRC: A CRC-checking example



Julian and Mark and others,

After I took into account the bit "reflection"  and the byte order (Big
Endian on Bytes and Little Endian on bits) I did finally obtain, using
polynomial math, the (corrected) results you show in the CRC examples. The
results have also been confirmed independently by an implementor here at
Agilent.

I am the one who originally suggested to Julian that we specify the CRC
algorithm the same way as in ethernet even though for iSCSI it is not
really
important to initialize the CRC register to all 1s and to complement the
CRC
before transmission since there are other means to detect extra or missing
PDU bytes. However I had not realzied until recently that conformance with
the ethernet algorithm implies bit reflection. I had not been aware that in
ethernet the bits are sent out on the serial link with the least
significant
bit first AND that the corresponding message polynomial is formed from the
bits in the sequence that they appear on the serial link; thus the need for
bit "reflection".

Now that I understand the need for bit reflection (taken into account in
the
rocksoft parameterized CRC generator by setting the in and out reflection
flag parameters to TRUE) I am not sure I agree that we want it in iSCSI.
The
penalty for full conformity with ethernet seems too great. If people feel
strongly that we must keep the bit reflection I think that to make the
existing documentation clear and unambiguous we would need to explicitly
show the mapping of bits in the iSCSI PDU to coefficients of the message
polynomial that represents the iSCSI PDU. We would also need to show the
mapping of the CRC bits to the coefficients of its representative
polynomial.

If you don't agree I will elaborate further later this week to try to
convince you. My objective is to be able to easily and unambiguously
describe the polynomial math behind the algorithm; right now, with the bit
reflection and without the explicit mapping it is awkward.

Vince






From owner-ips@ece.cmu.edu  Wed Aug 22 18:18:10 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25211
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 18:18:10 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7MLam623967
	for ips-outgoing; Wed, 22 Aug 2001 17:36:48 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from baucis.sc.intel.com (ns3.intel.com [143.183.152.22])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7MLake23961
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 17:36:46 -0400 (EDT)
Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203])
	by baucis.sc.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id VAA02161
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 21:36:40 GMT
Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.203
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Wed, 22 Aug 2001 21:36:39 0000 (GMT)
Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <RLP2FD28>; Wed, 22 Aug 2001 14:36:38 -0700
Message-ID: <638EC1B28663D211AC3E00A0C96B78A8086ABB46@orsmsx40.jf.intel.com>
From: "Wheat, Stephen R" <stephen.r.wheat@intel.com>
To: "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
Subject: RE: iSCSI: RE: Target record not to span PDUs?
Date: Wed, 22 Aug 2001 14:36:34 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Thanks for the reply, Julian.

But your answer didn't address why we should introduce such a restriction.

I don't see an initiator processing the text commands until it has received
the entirety of the concatenated packages.  So, why would we introduce the
complexity of ensuring a key=value pair does not span a PDU boundary?  I.e.,
we already have to deal with splitting the text response across multiple
messages, why complicate the check to include partitioning the PDUs on
intra-key-value boundaries?

Furthermore, we then preclude the ability to send huge key-value responses.
Though we cannot envision such huge responses now, doesn't mean they won't
appear in the future.  I'm usually against facilitating a future feature
that may never be realized, but that is when providing for that feature
costs something.  In this case, it doesn't.

Stephen

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, August 22, 2001 1:40 PM
To: Wheat, Stephen R
Subject: Re: iSCSI: RE: Target record not to span PDUs?


Every single key value pair is now restricted in size anyhow (64 key, 255
value).
With the  limitation we have introduced you can't have:

xxxx=zzzz+zzzz yyy=vvvv

where + is a PDU boundary.

We never stated this explicitly.

That's all.

Julo

"Wheat, Stephen R" <stephen.r.wheat@intel.com> on 22-08-2001 19:15:20

Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>

To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
cc:
Subject:  iSCSI: RE: Target record not to span PDUs?



Julian,

I'm not sure the problem case as stated is syntactically correct; maybe it
has to do with my interpretation of book marks.

As stated, the sequence looks like:
  [Begin data segment]
  ...
  TargetName=I.got.chopped.4096
  TargetAddress=10.1.1.45
  [End data segment]

My understanding of bookmark is that the packet would look like:
  [Begin data segment]
  ...
  TargetName=<incomplete target name>
  [End data segment]

Where the next message would simply be concatenated to the previous text.
And would look like:
  [Begin data segment]
  <rest of target name>
  ...
  TargetAddress=10.1.1.45
  [End data segment]

So, yes the host needs to buffer the last incomplete record, awaiting the
text to be concatenated, but there is no rewind or re-parse.

What am I missing?

If I'm right in my interpretation, then it would seem that your response is
overly restrictive.  Being concerned about buffer memory is one thing, but
when we are talking about a few kilobytes, that is getting too concerned.
If an initiator was really so limited in its memory, then it would probably
only be doing one login at a time anyway.

Stephen

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, August 22, 2001 3:23 AM
To: ips@ece.cmu.edu
Subject: Re: Target record not to span PDUs?



Good point. I think that we can do this as we have a limit on the size of
an individual record far lower than 4096.

I'll ad the following text to 2.9.5:

   A Key=value pair must be confined to a given text response even in the
   presence of bookmark - i.e., it must start and end within one Text
   Response.

Julo

Tow Wang <Tow_Wang@adaptec.com> on 22-08-2001 05:06:44

Please respond to Tow Wang <Tow_Wang@adaptec.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
Subject:  Target record not to span PDUs?



Julian (and all):

Hello. This is regarding draft 07; could we require that target records NOT
span across
PDU's if a text response for SendTargets is very long? Upon reading
appendix E, it seems
that a response (of 4096 bytes in length) could end with:

[Begin data segment]
...
TargetName=I.got.chopped.4096
TargetAddress=10.1.1.45
[End data segment]

In the above case, one could not determine whether the address is IP V4 or
V6. Even if it
had had enough space to put in the whole address, port and group tag, one
cannot parse and
process the record until inspecting the data segment of the next text
response PDU, and
this would involve cumulative buffering, back-parsing, etc. I think the
above complexity
could be avoided, as I can't imagine any single record exceeding 4096 bytes
in length.

Tow Wang











From owner-ips@ece.cmu.edu  Wed Aug 22 18:20:43 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25265
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 18:20:42 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7MLnWe24685
	for ips-outgoing; Wed, 22 Aug 2001 17:49:32 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f7MLnUe24679
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 17:49:30 -0400 (EDT)
Received: from grubby.research.bell-labs.com ([135.104.2.9]) by crufty; Wed Aug 22 17:44:49 EDT 2001
Received: from aura.research.bell-labs.com ([135.104.46.10]) by grubby; Wed Aug 22 17:48:49 EDT 2001
Received: from research.bell-labs.com (IDENT:sandeepj@sandeepj-pcmh.research.bell-labs.com [135.104.47.90])
	by aura.research.bell-labs.com (8.9.1/8.9.1) with ESMTP id RAA06388;
	Wed, 22 Aug 2001 17:48:17 -0400 (EDT)
Message-ID: <3B8428A1.B7F0AB5A@research.bell-labs.com>
Date: Wed, 22 Aug 2001 17:48:17 -0400
From: Sandeep Joshi <sandeepj@research.bell-labs.com>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-3 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Steve Senum <ssenum@cisco.com>
CC: ietf-ips <ips@ece.cmu.edu>
Subject: Re: iSCSI: Option Preference (was Login Proposal)
References: <6BD67FFB937FD411A04F00D0B74FE87802A0925E@xrose06.rose.hp.com> <3B842289.D34268CD@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


Steve,

That would be the initiator's preference...accept a "none"
or drop the connection.   

Marjorie's point is that conceptually user/IIN authentication 
would be controlled by the target (i.e. the server).

Once the endpoints are authenticated (e.g. by IPSec), then
ITN/IIN authentication will be driven by the server (target)

This is analogous to a RAS scenario in ipsra, 
http://www.ietf.org/internet-drafts/draft-ietf-ipsra-reqmts-03.txt)
( umm..please dont extend this analogy too far :-) )

regards,
-Sandeep 
 

Steve Senum wrote:
> 
> I disagree, at least somewhat.
> 
> If the Initiator sends AuthMethod=SRP,CHAP,none and
> the Target returns AuthMethod=none, the Initiator
> could still choose to abort the connection if
> it was configured to require authentication.
> I believe either or both sides can dictate the
> security environment.
> 
> Steve Senum
> 
> "KRUEGER,MARJORIE (HP-Roseville,ex1)" wrote:
> >
> > I meant only to point out that it's the target that must dictate the
> > security environment, not the initiator.  The initiator is only
> > communicating a preference.  So yes, I agree with you, but Ron's comment was
> >
> > > >     I expect this to be under the control of the sys admin
> > > > through some kind of config at the initiator side. I think a
> > > > good guide to keep in mind with all this is that it is the
> > > > initiator's data, and so it seems reasonable to let the
> > > > initiator control connection security and integrity.
> >
> > and I'm thinking it's the other way around.  The initiator has a role, but
> > it is the requestor of a service, not the "server" hence the target really
> > controls security.  Of course, ultimately, the system admin controls
> > everything, but we don't get to write his/her "protocol"  :-)
> >
> > Marjorie Krueger
> > Networked Storage Architecture
> > Networked Storage Solutions Org.
> > Hewlett-Packard
> > tel: +1 916 785 2656
> > fax: +1 916 785 0391
> > email: marjorie_krueger@hp.com
> >
> > > -----Original Message-----
> > > From: Wheat, Stephen R [mailto:stephen.r.wheat@intel.com]
> > > Sent: Wednesday, August 22, 2001 11:02 AM
> > > To: ietf-ips
> > > Subject: RE: iSCSI: Login Proposal
> > >
> > >
> > > Marjorie,
> > >
> > > I agree with your premise that the target must be allowed to
> > > not just let
> > > anyone in.
> > >
> > > But why isn't this already covered by the ability of the sys admin to
> > > configure the target to only agree to certain offerings?  Quoting from
> > > 1.2.4, with my
> > > emphasis,
> > >    "The responding party answers with the first value from the list it
> > > supports and
> > >     is **allowed** to use for the specific initiator."
> > >
> > >
> > > For some network interfaces,
> > > the sys admin could rely upon physical security and other
> > > means inherent to
> > > the
> > > environment.  In such cases, the admin could configure the
> > > target to follow
> > > the
> > > initiator's preferences, including "none".
> > >
> > > For other network interfaces where the environment is not inherently
> > > trusted,
> > > the sysadmin would be motivated to not allow the target to
> > > connect without any authentication; so they'd set it up to not accept
> > > "none", even
> > > though the initiator may prefer "none".
> > >
> > > Yes?
> > >
> > > Stephen
> > >
> > > -----Original Message-----
> > > From: KRUEGER,MARJORIE (HP-Roseville,ex1)
> > > [mailto:marjorie_krueger@hp.com]
> > > Sent: Wednesday, August 22, 2001 10:47 AM
> > > To: 'Rod Harrison'; ietf-ips
> > > Subject: RE: iSCSI: Login Proposal
> > >
> > >
> > > I'm thinking a little differently regarding which party has
> > > priority in
> > > chosing security parameters - while it *may* be the
> > > initiators data, this
> > > can't be established until the initiator is authenticated.
> > > Since the target
> > > is the "server" side, I think the burden is on the target to
> > > ensure that
> > > this is the intended initiator.  Therefore, the target must
> > > dictate the
> > > authentication method used, since it has the security
> > > responsibility and the
> > > "contact point" for potentially malicious entities.  Consider
> > > the example
> > > where an initiator was previously authenticated using
> > > Kerberos, the session
> > > was ended, and a new session is requested by what appears to
> > > be the same
> > > initiator, but the authmethod requested is now "none".  Looks pretty
> > > suspicious to me.  It seems to me like the target has the
> > > responsibility of
> > > maintaining a consistent authmethod with all initiators that
> > > access it,
> > > therefore the target MUST force the minimum level
> > > authorization it requires
> > > or reject the login request.
> > >
> > > Marjorie Krueger
> > > Networked Storage Architecture
> > > Networked Storage Solutions Org.
> > > Hewlett-Packard
> > > tel: +1 916 785 2656
> > > fax: +1 916 785 0391
> > > email: marjorie_krueger@hp.com
> > >
> > > > -----Original Message-----
> > > > From: Rod Harrison [mailto:rod.harrison@windriver.com]
> > > > Sent: Wednesday, August 22, 2001 4:58 AM
> > > > To: Wheat, Stephen R; 'Steve Senum'; ietf-ips
> > > > Subject: RE: iSCSI: Login Proposal
> > > >
> > > >
> > > >
> > > >     I think we should view this as the order indicates the
> > > > initiators preference and the target SHOULD pick the first
> > > > item from the list it supports. Note that SHOULD allows the
> > > > target to do something other than pick the first item it
> > > > supports if it has a good reason to do so, e.g. If it would
> > > > otherwise terminate the session. The initiator can always
> > > > terminate the session if it doesn't like what the target
> > > > chooses.
> > > >
> > > >     So, to extend your example, as an initiator if I didn't
> > > > want to do CHAP at all I would send ...
> > > >
> > > > AuthMethod=none
> > > >
> > > >     if I preferred not to do CHAP but I could tolerate it I
> > > > would send ...
> > > >
> > > > AuthMethod=none,CHAP
> > > >
> > > >     and if I would prefer CHAP I would send ...
> > > >
> > > > AuthMethod=CHAP,none
> > > >
> > > >     I expect this to be under the control of the sys admin
> > > > through some kind of config at the initiator side. I think a
> > > > good guide to keep in mind with all this is that it is the
> > > > initiator's data, and so it seems reasonable to let the
> > > > initiator control connection security and integrity.
> > > >
> > > >     - Rod
> > > >
> > >
> > >


From owner-ips@ece.cmu.edu  Wed Aug 22 18:21:11 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25277
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 18:21:11 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7MLds024116
	for ips-outgoing; Wed, 22 Aug 2001 17:39:54 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from smtp.alacritech.com (smtp.alacritech.com [209.10.208.82])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7MLdqe24112
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 17:39:52 -0400 (EDT)
Received: from alacritech.com (woking.alacritech.com [10.1.1.70])
	by smtp.alacritech.com (8.11.0/8.11.0) with ESMTP id f7MLYfO22477;
	Wed, 22 Aug 2001 14:34:41 -0700
Message-ID: <3B8426A8.6B9A147F@alacritech.com>
Date: Wed, 22 Aug 2001 14:39:52 -0700
From: Steve Blightman <steve@alacritech.com>
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Douglas Otis <dotis@sanlight.net>
CC: ips@ece.cmu.edu
Subject: Re: iSCSI CRC: A CRC-checking example
References: <NEBBJGDMMLHHCIKHGBEJOEKHCKAA.dotis@sanlight.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Just a small point -
If c is an unsigned 32 bit value and d is an unsigned 8 bit value, on
most machines for the non-reflected lookup I don't think the "&" is
necessary, is it?  Shifting right 24 places ensures the first 24 bits
are 0.

i.e For the non-reflected table lookup you have:
 CRC32(c,d) (c=(c<<8)^crc32tab[(c>>24)^(d)])

and the same number of instructions as for the reflected case.

As for all these issues about the reflection and the iversion, I suspect
we have all spent too much time worrying about this already.  These must
be very minor issues - the important thing is that the specification
clearly state which way it is to be done.  For those of us preparing to
implement the CRC in hardware, the arguments are very unsettling.  Must
I now add even more gates to make the reflection and the inversion
programmable, in case the committee changes its mind?

Steve


Douglas Otis wrote:

> Follow on:
>
> Slight correction:
>
>  For the non-reflected table lookup you have:
>  CRC32(c,d) (c=(c<<8)^crc32tab[((c>>24)^(d))&0xFF])
>
>  For the reflected table lookup you have:
>  CRC32(c,d) (c=(c>>8)^crc32tab[(c^(d))&0xFF])
>
> Doug



From owner-ips@ece.cmu.edu  Wed Aug 22 18:22:24 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25292
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 18:22:24 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7MLmr924644
	for ips-outgoing; Wed, 22 Aug 2001 17:48:53 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7MLmpe24638
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 17:48:51 -0400 (EDT)
Received: from fmsmsxvs041.fm.intel.com (fmsmsxv041-1.fm.intel.com [132.233.48.109])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id VAA08324
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 21:48:50 GMT
Received: from fmsmsx18.intel.com ([132.233.233.232])
 by fmsmsxvs041.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001082214503506187
 ; Wed, 22 Aug 2001 14:50:35 -0700
Received: by fmsmsx18.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <RBZTJDP8>; Wed, 22 Aug 2001 14:48:49 -0700
Message-ID: <638EC1B28663D211AC3E00A0C96B78A8086ABB47@orsmsx40.jf.intel.com>
From: "Wheat, Stephen R" <stephen.r.wheat@intel.com>
To: "'Steve Senum'" <ssenum@cisco.com>, ietf-ips <ips@ece.cmu.edu>
Subject: RE: iSCSI: Option Preference (was Login Proposal)
Date: Wed, 22 Aug 2001 14:48:45 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

This raises an interesting point.  Why would an initiator or target offer
something it was not willing to accept?  I.e., perhaps this should be
addressed in the spec.  Some statement like:

  The sender of a key=<v1>,<v2>,<v3> MUST not offer a Vx that it is
  unwilling for the recipient to choose.

Otherwise, it seems kind of like:
   I->T "pick curtain 1, curtain 2, or curtain 3"
   T->I "I pick curtain 2"
   I->T "Ooops, you lose.  Good bye."

Stephen

-----Original Message-----
From: Steve Senum [mailto:ssenum@cisco.com]
Sent: Wednesday, August 22, 2001 2:22 PM
To: ietf-ips
Subject: Re: iSCSI: Option Preference (was Login Proposal)


I disagree, at least somewhat.

If the Initiator sends AuthMethod=SRP,CHAP,none and
the Target returns AuthMethod=none, the Initiator
could still choose to abort the connection if
it was configured to require authentication.
I believe either or both sides can dictate the
security environment.

Steve Senum

"KRUEGER,MARJORIE (HP-Roseville,ex1)" wrote:
> 
> I meant only to point out that it's the target that must dictate the
> security environment, not the initiator.  The initiator is only
> communicating a preference.  So yes, I agree with you, but Ron's comment
was
> 
> > >     I expect this to be under the control of the sys admin
> > > through some kind of config at the initiator side. I think a
> > > good guide to keep in mind with all this is that it is the
> > > initiator's data, and so it seems reasonable to let the
> > > initiator control connection security and integrity.
> 
> and I'm thinking it's the other way around.  The initiator has a role, but
> it is the requestor of a service, not the "server" hence the target really
> controls security.  Of course, ultimately, the system admin controls
> everything, but we don't get to write his/her "protocol"  :-)
> 
> Marjorie Krueger
> Networked Storage Architecture
> Networked Storage Solutions Org.
> Hewlett-Packard
> tel: +1 916 785 2656
> fax: +1 916 785 0391
> email: marjorie_krueger@hp.com
> 
> > -----Original Message-----
> > From: Wheat, Stephen R [mailto:stephen.r.wheat@intel.com]
> > Sent: Wednesday, August 22, 2001 11:02 AM
> > To: ietf-ips
> > Subject: RE: iSCSI: Login Proposal
> >
> >
> > Marjorie,
> >
> > I agree with your premise that the target must be allowed to
> > not just let
> > anyone in.
> >
> > But why isn't this already covered by the ability of the sys admin to
> > configure the target to only agree to certain offerings?  Quoting from
> > 1.2.4, with my
> > emphasis,
> >    "The responding party answers with the first value from the list it
> > supports and
> >     is **allowed** to use for the specific initiator."
> >
> >
> > For some network interfaces,
> > the sys admin could rely upon physical security and other
> > means inherent to
> > the
> > environment.  In such cases, the admin could configure the
> > target to follow
> > the
> > initiator's preferences, including "none".
> >
> > For other network interfaces where the environment is not inherently
> > trusted,
> > the sysadmin would be motivated to not allow the target to
> > connect without any authentication; so they'd set it up to not accept
> > "none", even
> > though the initiator may prefer "none".
> >
> > Yes?
> >
> > Stephen
> >
> > -----Original Message-----
> > From: KRUEGER,MARJORIE (HP-Roseville,ex1)
> > [mailto:marjorie_krueger@hp.com]
> > Sent: Wednesday, August 22, 2001 10:47 AM
> > To: 'Rod Harrison'; ietf-ips
> > Subject: RE: iSCSI: Login Proposal
> >
> >
> > I'm thinking a little differently regarding which party has
> > priority in
> > chosing security parameters - while it *may* be the
> > initiators data, this
> > can't be established until the initiator is authenticated.
> > Since the target
> > is the "server" side, I think the burden is on the target to
> > ensure that
> > this is the intended initiator.  Therefore, the target must
> > dictate the
> > authentication method used, since it has the security
> > responsibility and the
> > "contact point" for potentially malicious entities.  Consider
> > the example
> > where an initiator was previously authenticated using
> > Kerberos, the session
> > was ended, and a new session is requested by what appears to
> > be the same
> > initiator, but the authmethod requested is now "none".  Looks pretty
> > suspicious to me.  It seems to me like the target has the
> > responsibility of
> > maintaining a consistent authmethod with all initiators that
> > access it,
> > therefore the target MUST force the minimum level
> > authorization it requires
> > or reject the login request.
> >
> > Marjorie Krueger
> > Networked Storage Architecture
> > Networked Storage Solutions Org.
> > Hewlett-Packard
> > tel: +1 916 785 2656
> > fax: +1 916 785 0391
> > email: marjorie_krueger@hp.com
> >
> > > -----Original Message-----
> > > From: Rod Harrison [mailto:rod.harrison@windriver.com]
> > > Sent: Wednesday, August 22, 2001 4:58 AM
> > > To: Wheat, Stephen R; 'Steve Senum'; ietf-ips
> > > Subject: RE: iSCSI: Login Proposal
> > >
> > >
> > >
> > >     I think we should view this as the order indicates the
> > > initiators preference and the target SHOULD pick the first
> > > item from the list it supports. Note that SHOULD allows the
> > > target to do something other than pick the first item it
> > > supports if it has a good reason to do so, e.g. If it would
> > > otherwise terminate the session. The initiator can always
> > > terminate the session if it doesn't like what the target
> > > chooses.
> > >
> > >     So, to extend your example, as an initiator if I didn't
> > > want to do CHAP at all I would send ...
> > >
> > > AuthMethod=none
> > >
> > >     if I preferred not to do CHAP but I could tolerate it I
> > > would send ...
> > >
> > > AuthMethod=none,CHAP
> > >
> > >     and if I would prefer CHAP I would send ...
> > >
> > > AuthMethod=CHAP,none
> > >
> > >     I expect this to be under the control of the sys admin
> > > through some kind of config at the initiator side. I think a
> > > good guide to keep in mind with all this is that it is the
> > > initiator's data, and so it seems reasonable to let the
> > > initiator control connection security and integrity.
> > >
> > >     - Rod
> > >
> >
> >


From owner-ips@ece.cmu.edu  Wed Aug 22 18:22:55 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25304
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 18:22:55 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7MLUCj23597
	for ips-outgoing; Wed, 22 Aug 2001 17:30:12 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mxic2.us.dg.com (mxic2.us.dg.com [128.221.31.40])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7MLUBe23591
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 17:30:11 -0400 (EDT)
Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19)
	id <QQ9Q5M7R>; Wed, 22 Aug 2001 17:27:54 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD64A@CORPMX14>
From: Black_David@emc.com
To: ips@ece.cmu.edu
Subject: IPS Draft Status and Schedule
Date: Wed, 22 Aug 2001 17:24:11 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Here's what the WG chairs think the current status and schedule
is for the drafts that the IP Storage WG is working on (including
three individual submissions that have agenda time in Orange
County).  This is probably not 100% accurate, but should be
close.  Draft authors - please send any corrections to me.

Apologies for being tardy on this - this should have been done
about a month ago, but I have negative "copious spare time".
Going forward, the intent is to produce an updated version of
this prior to each WG meeting.  Proposed revised charter will
be coming in the near future, with milestones based on the
completion guesstimates below.

Thanks,
--David

-- iSCSI

draft-ietf-ips-iscsi-07.txt
	To be a proposed standard RFC.
	Large portions are stable, major open security and login issues.
	-08 will be a functional/technical revision, document restructure/
		reorganization expected in -09 version.
	Hope to close all major issues by December 2001 IETF meeting

draft-ietf-ips-iscsi-boot-02.txt
	No major open issues, possible minor issues in DHCP usage.
		DHCP material to be extracted into a separate
standards-track draft.	
	Remainder to become an informational RFC, after the main iSCSI
document.

draft-ietf-ips-iscsi-reqmts-05.txt
	To be an informational RFC.
	Has completed WG Last Call, currently being considered by the IESG,
		IETF Last Call has not been issued.

draft-ietf-ips-iscsi-name-disc-02.txt
	To be an informational RFC.
	Specification portions that must be standards track are being added
		to the main iSCSI specification.
	No major open issues, hope to close any other issues by December
2001 IETF
		meeting.  Plan to issue WG Last Call for this with main
iSCSI draft.

draft-ietf-ips-iscsi-slp-01.txt
	To be a proposed standard RFC.
	Close to done.  Issues in this general area seem to come up in the
		context of the naming and discovery draft (name-disc-02)
rather
		than this draft.
	WG Last Call will be after the naming and discovery draft.

draft-ietf-ips-iscsi-mib-02.txt
	To be a proposed standard RFC.
	Next (-03) version expected in September, should be close to done.
	WG Last Call will follow main iSCSI draft.
	
draft-black-ips-iscsi-security-01.txt
draft-aboba-ips-iscsi-security-00.txt
	Unlikely to become RFCs in their current forms.
	New drafts on iSCSI Security for discussion at Orange County
meeting.
		Security requirements will be specified in the main iSCSI
document.
	Some remaining portions of one or both drafts may become an
		informational RFC.  Whether to do this and what portions to
use
		are subject to discussion.

-- FC Common Encapsulation

draft-ietf-ips-fcencapsulation-02.txt
	To be a proposed standard RFC.
	No major open issues.
	Will accompany FCIP and/or iFCP drafts in Last Call, probably after
		December 2001 IETF.

-- FCIP

draft-ietf-ips-fcovertcpip-05.txt
	To be a proposed standard RFC.
	Large portions are stable, major open security issues.
	Hope to close all major issues by December 2001 IETF meeting.

draft-ietf-ips-fcip-slp-00.txt
	To be a proposed standard RFC.
	New draft for discussion in Orange County.
	Hope to close all major issues by December 2001 IETF meeting.

draft-ietf-ips-fcip-mib-00.txt
	To be a proposed standard RFC.
	New draft for discussion in Orange County.
	Likely timeframe for closing final issues is March 2002 IETF
meeting.

-- iFCP

draft-ietf-ips-ifcp-04.txt
	To be a proposed standard RFC.
	Large portions are stable, major open security issues.
	Hope to close all major issues by December 2001 IETF meeting.

draft-tseng-ifcp-mib-00.txt
	To be a proposed standard RFC.
	New draft for consideration in Orange County, will be proposed for
		approval as an official WG draft.
	Likely timeframe for closing final issues is March 2002 IETF
meeting.

-- iSNS

draft-ietf-ips-isns-04.txt
	To be a proposed standard RFC.
	Relationship to SLP for use with iSCSI seems to be settled, no
		other major open issues.
	WG Last Call to follow iSCSI and iFCP drafts.
	Hope to close any remaining issues by December 2001 IETF meeting.

draft-gibbons-isnsmib-00.txt
	To be a proposed standard RFC.
	Relatively new draft, London meeting approved it as an official
		IPS WG work item, next version will be draft-ietf-ips-...
	Likely timeframe for closing final issues is March 2002 IETF
meeting.

-- Framework

draft-ietf-ips-framework-00.txt
	Has not been updated by author team since original revision.
	Likely to be abandoned in the absence of renewed interest.

-- SCSI MIB

There's been talk about working on this, but no draft has appeared, yet.


----- Document Completion Guesstimates ------

A rough guess is 3 waves of documents:

(1) Main protocol standards.  Close technical issues at December 2001 IETF
	(or before), WG Last Call in early 2002, submit to IESG before
	March 2002 IETF Meeting.
	- iSCSI
	- iSCSI Naming/Discovery
	- FC Encapsulation
	- FCIP
	- iFCP
	Last Call scheduling will be an issue, as there are at least two,
	and possibly more 4 week (or longer) WG Last Calls required for
	the above that probably should not overlap with each other.

(2) Supporting Protocol Documents.  Close technical issues at December
	IETF if possible (but above documents have priority).  WG Last
	Call to follow above, probably in March-April 2002.
	- iSCSI Boot
	- iSCSI SLP
	- FCIP SLP
	- iSNS
	iSNS Last Call should not overlap iSCSI Last Calls, hence at least
	two will be needed, but 2 week WG Last Call periods should suffice
	for these documents.

(3) MIBs.  To follow supporting documents.  Final opportunity to discuss
	at March 2002 IETF Meeting, with WG Last Call to follow shortly
	thereafter.
	- iSCSI MIB
	- FCIP MIB
	- iFCP MIB
	- iSNS MIB
	Probably need two Last Call periods, but again, 2 weeks each
	should be sufficient.  May move Last Call schedule up if
	MIBs are ready to go earlier (e.g., after December 2001 IETF
	meeting).

The waves will overlap in practice, but each main protocol document
needs to make it through WG Last Call before any WG Last Calls are
issued for documents that depend on it.  So for any protocol, wave
(1) has to come before (2) and (3), but (2) and (3) can run in
parallel, and the different protocols may run on different schedules.

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------



From owner-ips@ece.cmu.edu  Wed Aug 22 18:23:42 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25327
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 18:23:42 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7MLMXt23134
	for ips-outgoing; Wed, 22 Aug 2001 17:22:33 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7MLMWe23125
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 17:22:32 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-68-173.cisco.com [161.44.68.173]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA03136 for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 17:22:26 -0400 (EDT)
Message-ID: <3B842289.D34268CD@cisco.com>
Date: Wed, 22 Aug 2001 16:22:17 -0500
From: Steve Senum <ssenum@cisco.com>
X-Mailer: Mozilla 4.73 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-ips <ips@ece.cmu.edu>
Subject: Re: iSCSI: Option Preference (was Login Proposal)
References: <6BD67FFB937FD411A04F00D0B74FE87802A0925E@xrose06.rose.hp.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

I disagree, at least somewhat.

If the Initiator sends AuthMethod=SRP,CHAP,none and
the Target returns AuthMethod=none, the Initiator
could still choose to abort the connection if
it was configured to require authentication.
I believe either or both sides can dictate the
security environment.

Steve Senum

"KRUEGER,MARJORIE (HP-Roseville,ex1)" wrote:
> 
> I meant only to point out that it's the target that must dictate the
> security environment, not the initiator.  The initiator is only
> communicating a preference.  So yes, I agree with you, but Ron's comment was
> 
> > >     I expect this to be under the control of the sys admin
> > > through some kind of config at the initiator side. I think a
> > > good guide to keep in mind with all this is that it is the
> > > initiator's data, and so it seems reasonable to let the
> > > initiator control connection security and integrity.
> 
> and I'm thinking it's the other way around.  The initiator has a role, but
> it is the requestor of a service, not the "server" hence the target really
> controls security.  Of course, ultimately, the system admin controls
> everything, but we don't get to write his/her "protocol"  :-)
> 
> Marjorie Krueger
> Networked Storage Architecture
> Networked Storage Solutions Org.
> Hewlett-Packard
> tel: +1 916 785 2656
> fax: +1 916 785 0391
> email: marjorie_krueger@hp.com
> 
> > -----Original Message-----
> > From: Wheat, Stephen R [mailto:stephen.r.wheat@intel.com]
> > Sent: Wednesday, August 22, 2001 11:02 AM
> > To: ietf-ips
> > Subject: RE: iSCSI: Login Proposal
> >
> >
> > Marjorie,
> >
> > I agree with your premise that the target must be allowed to
> > not just let
> > anyone in.
> >
> > But why isn't this already covered by the ability of the sys admin to
> > configure the target to only agree to certain offerings?  Quoting from
> > 1.2.4, with my
> > emphasis,
> >    "The responding party answers with the first value from the list it
> > supports and
> >     is **allowed** to use for the specific initiator."
> >
> >
> > For some network interfaces,
> > the sys admin could rely upon physical security and other
> > means inherent to
> > the
> > environment.  In such cases, the admin could configure the
> > target to follow
> > the
> > initiator's preferences, including "none".
> >
> > For other network interfaces where the environment is not inherently
> > trusted,
> > the sysadmin would be motivated to not allow the target to
> > connect without any authentication; so they'd set it up to not accept
> > "none", even
> > though the initiator may prefer "none".
> >
> > Yes?
> >
> > Stephen
> >
> > -----Original Message-----
> > From: KRUEGER,MARJORIE (HP-Roseville,ex1)
> > [mailto:marjorie_krueger@hp.com]
> > Sent: Wednesday, August 22, 2001 10:47 AM
> > To: 'Rod Harrison'; ietf-ips
> > Subject: RE: iSCSI: Login Proposal
> >
> >
> > I'm thinking a little differently regarding which party has
> > priority in
> > chosing security parameters - while it *may* be the
> > initiators data, this
> > can't be established until the initiator is authenticated.
> > Since the target
> > is the "server" side, I think the burden is on the target to
> > ensure that
> > this is the intended initiator.  Therefore, the target must
> > dictate the
> > authentication method used, since it has the security
> > responsibility and the
> > "contact point" for potentially malicious entities.  Consider
> > the example
> > where an initiator was previously authenticated using
> > Kerberos, the session
> > was ended, and a new session is requested by what appears to
> > be the same
> > initiator, but the authmethod requested is now "none".  Looks pretty
> > suspicious to me.  It seems to me like the target has the
> > responsibility of
> > maintaining a consistent authmethod with all initiators that
> > access it,
> > therefore the target MUST force the minimum level
> > authorization it requires
> > or reject the login request.
> >
> > Marjorie Krueger
> > Networked Storage Architecture
> > Networked Storage Solutions Org.
> > Hewlett-Packard
> > tel: +1 916 785 2656
> > fax: +1 916 785 0391
> > email: marjorie_krueger@hp.com
> >
> > > -----Original Message-----
> > > From: Rod Harrison [mailto:rod.harrison@windriver.com]
> > > Sent: Wednesday, August 22, 2001 4:58 AM
> > > To: Wheat, Stephen R; 'Steve Senum'; ietf-ips
> > > Subject: RE: iSCSI: Login Proposal
> > >
> > >
> > >
> > >     I think we should view this as the order indicates the
> > > initiators preference and the target SHOULD pick the first
> > > item from the list it supports. Note that SHOULD allows the
> > > target to do something other than pick the first item it
> > > supports if it has a good reason to do so, e.g. If it would
> > > otherwise terminate the session. The initiator can always
> > > terminate the session if it doesn't like what the target
> > > chooses.
> > >
> > >     So, to extend your example, as an initiator if I didn't
> > > want to do CHAP at all I would send ...
> > >
> > > AuthMethod=none
> > >
> > >     if I preferred not to do CHAP but I could tolerate it I
> > > would send ...
> > >
> > > AuthMethod=none,CHAP
> > >
> > >     and if I would prefer CHAP I would send ...
> > >
> > > AuthMethod=CHAP,none
> > >
> > >     I expect this to be under the control of the sys admin
> > > through some kind of config at the initiator side. I think a
> > > good guide to keep in mind with all this is that it is the
> > > initiator's data, and so it seems reasonable to let the
> > > initiator control connection security and integrity.
> > >
> > >     - Rod
> > >
> >
> >


From owner-ips@ece.cmu.edu  Wed Aug 22 19:08:57 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25956
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 19:08:57 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7MMOUe26486
	for ips-outgoing; Wed, 22 Aug 2001 18:24:30 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7MMOTe26482
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 18:24:29 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-68-173.cisco.com [161.44.68.173]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id SAA06281 for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 18:24:22 -0400 (EDT)
Message-ID: <3B84310E.C01D7071@cisco.com>
Date: Wed, 22 Aug 2001 17:24:14 -0500
From: Steve Senum <ssenum@cisco.com>
X-Mailer: Mozilla 4.73 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-ips <ips@ece.cmu.edu>
Subject: Re: iSCSI: Option Preference (was Login Proposal)
References: <6BD67FFB937FD411A04F00D0B74FE87802A0925E@xrose06.rose.hp.com> <3B842289.D34268CD@cisco.com> <3B8428A1.B7F0AB5A@research.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Not to try to beat this into the ground anymore
then already has been done, but...

Many months ago, when I first looked over
the iSCSI spec, I remember thinking it was
kind of odd for the side being authenticated
to control the possible options.  Other
protocols I have worked with would have the
side driving the authentication (i.e., the Target)
control this.

If the IPS group wants to stay with the
current target-really-controls-authentication
notion, we might want to go a step further,
and allow only the Target to send the AuthMethod
key out.

Just a thought,
Steve Senum

Sandeep Joshi wrote:
> 
> Steve,
> 
> That would be the initiator's preference...accept a "none"
> or drop the connection.
> 
> Marjorie's point is that conceptually user/IIN authentication
> would be controlled by the target (i.e. the server).
> 
> Once the endpoints are authenticated (e.g. by IPSec), then
> ITN/IIN authentication will be driven by the server (target)
> 
> This is analogous to a RAS scenario in ipsra,
> http://www.ietf.org/internet-drafts/draft-ietf-ipsra-reqmts-03.txt)
> ( umm..please dont extend this analogy too far :-) )
> 
> regards,
> -Sandeep


From owner-ips@ece.cmu.edu  Wed Aug 22 19:11:20 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25997
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 19:11:19 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7MMKQm26251
	for ips-outgoing; Wed, 22 Aug 2001 18:20:26 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from c007.snv.cp.net (c007-h014.c007.snv.cp.net [209.228.33.221])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f7MMKPe26246
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 18:20:25 -0400 (EDT)
Received: (cpmta 27353 invoked from network); 22 Aug 2001 15:15:18 -0700
Received: from adsl-63-202-160-80.dsl.snfc21.pacbell.net (HELO littlejoy) (63.202.160.80)
  by smtp.telocity.com (209.228.33.221) with SMTP; 22 Aug 2001 15:15:18 -0700
X-Sent: 22 Aug 2001 22:15:18 GMT
From: "Douglas Otis" <dotis@sanlight.net>
To: "Steve Blightman" <steve@alacritech.com>
Cc: <ips@ece.cmu.edu>
Subject: RE: iSCSI CRC: A CRC-checking example
Date: Wed, 22 Aug 2001 15:13:32 -0700
Message-ID: <NEBBJGDMMLHHCIKHGBEJGEKKCKAA.dotis@sanlight.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
In-Reply-To: <3B8426A8.6B9A147F@alacritech.com>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Steve,

You are right, but a minor point in assembly, this masking issue can be
handled by a register designation rather than an actual instruction.  This
still leaves you with a 24 bit shift as an additional instruction to deal
with. I was suggesting that we not change the current approach and would not
support such a change.  I questioned the need for the inversion of the
stored CRC and if this is removed, it would mean fewer logic gates to
implement or perhaps an exclusive-or rather than an inverter if you wished
it to be programmable.  I have no great concern one way of the other, but in
reviewing all that is included in the CRC calculation, this inverted store
is perhaps one area that is perhaps not needed if we were wishing to reduce
complexity.

Doug

>
> Just a small point -
> If c is an unsigned 32 bit value and d is an unsigned 8 bit value, on
> most machines for the non-reflected lookup I don't think the "&" is
> necessary, is it?  Shifting right 24 places ensures the first 24 bits
> are 0.
>
> i.e For the non-reflected table lookup you have:
>  CRC32(c,d) (c=(c<<8)^crc32tab[(c>>24)^(d)])
>
> and the same number of instructions as for the reflected case.
>
> As for all these issues about the reflection and the iversion, I suspect
> we have all spent too much time worrying about this already.  These must
> be very minor issues - the important thing is that the specification
> clearly state which way it is to be done.  For those of us preparing to
> implement the CRC in hardware, the arguments are very unsettling.  Must
> I now add even more gates to make the reflection and the inversion
> programmable, in case the committee changes its mind?
>
> Steve
>
>
> Douglas Otis wrote:
>
> > Follow on:
> >
> > Slight correction:
> >
> >  For the non-reflected table lookup you have:
> >  CRC32(c,d) (c=(c<<8)^crc32tab[((c>>24)^(d))&0xFF])
> >
> >  For the reflected table lookup you have:
> >  CRC32(c,d) (c=(c>>8)^crc32tab[(c^(d))&0xFF])
> >
> > Doug
>
>



From owner-ips@ece.cmu.edu  Wed Aug 22 20:14:49 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26874
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 20:14:49 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7MNDEx29053
	for ips-outgoing; Wed, 22 Aug 2001 19:13:14 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from atlrel7.hp.com (atlrel7.hp.com [192.151.27.9])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7MNDDe29049
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 19:13:13 -0400 (EDT)
Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191])
	by atlrel7.hp.com (Postfix) with ESMTP id BF6C81F836
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 19:11:51 -0400 (EDT)
Received: from xatlbh3.atl.hp.com (xatlbh3.atl.hp.com [15.45.89.188])
	by xatlrelay2.atl.hp.com (Postfix) with ESMTP id 7A52B1F505
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 19:13:07 -0400 (EDT)
Received: by xatlbh3.atl.hp.com with Internet Mail Service (5.5.2653.19)
	id <RMA2B7S0>; Wed, 22 Aug 2001 19:13:07 -0400
Message-ID: <6BD67FFB937FD411A04F00D0B74FE87802A09265@xrose06.rose.hp.com>
From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
To: ietf-ips <ips@ece.cmu.edu>
Subject: RE: iSCSI: Option Preference (was Login Proposal)
Date: Wed, 22 Aug 2001 19:08:30 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

That really makes the most sense to me.  IMO, having the initiator "request"
authmethods is kind of a waste of bits.  The model I have in mind is that a
target basicly has one AuthMethod and all initiators that want to access it
either MUST use that AuthMethod (external "storage service provider" model)
or may either use that AuthMethod or none.  I'm having a hard time imagining
poor little targets implementing multiple authMethods in the same box and
actually allowing initiators with different authMethods to access it
simultaneously.  In any case, seems like there's little value in having the
initiator offer a list of AuthMethods.  Makes more sense for the initiator
to request login, and the target to return the required AuthMethod.  If the
initiator can't handle it, it terminates the exchange.  That's my
understanding of how client-server auth relationships usually work.
Actually, typically the client is simply expected to know the required
AuthMethod (thru configuration) and begins the exchange by requesting
authorization.

Marj

> -----Original Message-----
> From: Steve Senum [mailto:ssenum@cisco.com]
> Sent: Wednesday, August 22, 2001 3:24 PM
> To: ietf-ips
> Subject: Re: iSCSI: Option Preference (was Login Proposal)
> 
> 
> Not to try to beat this into the ground anymore
> then already has been done, but...
> 
> Many months ago, when I first looked over
> the iSCSI spec, I remember thinking it was
> kind of odd for the side being authenticated
> to control the possible options.  Other
> protocols I have worked with would have the
> side driving the authentication (i.e., the Target)
> control this.
> 
> If the IPS group wants to stay with the
> current target-really-controls-authentication
> notion, we might want to go a step further,
> and allow only the Target to send the AuthMethod
> key out.
> 
> Just a thought,
> Steve Senum
> 
> 


From owner-ips@ece.cmu.edu  Wed Aug 22 20:15:10 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26897
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 20:15:09 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7MNBF928971
	for ips-outgoing; Wed, 22 Aug 2001 19:11:15 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from clyde.stargateip.com ([209.237.5.66])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7MNBEe28967
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 19:11:14 -0400 (EDT)
Received: from bluestar (dhcp-101.stargateip.com [10.10.5.101])
	by clyde.stargateip.com (8.9.1/8.9.1) with SMTP id QAA24515;
	Wed, 22 Aug 2001 16:01:31 -0700 (PDT)
Reply-To: <deva@stargateip.com>
From: "Dev" <deva@stargateip.com>
To: <cbm@rose.hp.com>, <ips@ece.cmu.edu>
Subject: RE: iSCSI:Data Recovery from digest errors ...
Date: Wed, 22 Aug 2001 16:12:10 -0700
Message-ID: <NFBBKBDFJCDMGCBKJLCJKEEEFDAA.deva@stargateip.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <200108220204.TAA06516@core.rose.hp.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


Mallikarjun,

Thanks for the clarification.

Deva

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Mallikarjun C.
Sent: Tuesday, August 21, 2001 7:05 PM
To: ips@ece.cmu.edu
Subject: RE: iSCSI:Data Recovery from digest errors ...


Deva,

InitialR2T=no only implies that an *initial* unsolicited
burst is allowed by the target - _not_ that R2T is completely
disabled.  For complete details, see rev07, Appendix D, item 24.

Data sequence numbers always follow the rules clearly outlined
in section 1.2.2.3.  R2T is a request to transfer certain data
range, *not* PDU sequence range (as does a SNACK).

I hope that addresses your questions.
--
Mallikarjun


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


>Mallikarjun,
>
>Thanks for the input.  I thought about it. I like the way of using R2T
>to retry the data. But on further thoughts I have some
>clarifications/concerns.
>
>At the outset, it looks to me to open the door for having the
>target solicit for data (unless some restrictions are on the R2T) even
>though  R2T is disabled as initR2T is disabled.. But R2T PDU has all the
>relevant field
> data offset, data length etc and fits in to retry data. Now, If out of 64K
>received,
>target desires to choose to retry the 16K,say between 32K to 48K, what will
>be the data
>sequence numbers generated for the data PDUs sent as response to R2T. Will
>it be the
>same sequence number for Data PDUs when they were sent as unsolicited burst
>or a different
>one? What will be the value of the value of expR2TSN and expDataSN in the
>SCSI response PDU for this case. Probably a flag in the R2T header indicate
>that
>it is a retry for immediate and the initiator should resend the entire
>data..
>
>If an initiator/target have to still be capable of supporting R2T when it
is
>disabled,
>why would R2T and unsolicited data burst be mutually exclusive in the iSCSI
>spec? Meaning,
>if a command request is for 64K write and unsolicited burst size is 32K,
why
>not the target
>receive the rest of the data (the next 32K) through R2Ts?
>
>Am I missing something?
>Just my thoughts. what do you think? If Im on the wrong track, could you
>correct me?
>
>
>
>Thanks
>
>Deva
>Platys Communications
>
>
>
>-----Original Message-----
>From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
>Mallikarjun C.
>Sent: Tuesday, August 21, 2001 3:07 PM
>To: deva@stargateip.com
>Cc: ips@ece.cmu.edu
>Subject: Re: iSCSI:Data Recovery from digest errors ...
>
>
>Deva,
>
>Let me respond to your questions.
>
>Currently, the draft assumes that recovery R2Ts can be generated
>for digest errors on unsolicited data bursts in separate data PDUs.
>This will be explicitly called out as I said in a response to Sandeep:
>
>http://www.pdl.cmu.edu/mailinglists/ips/mail/msg05855.html
>
>The immediate data digest failures however, are not intended to
>be recoverable with R2Ts since an iSCSI (and SCSI) task is not
>instantiated in that case (rev07, section 7.2).  The rationale
>was that it is much easier for the initiator to re-ship the entire
>PDU (command+immediate) than build a new data PDU with a Write-data
>header (if only a part, command, of the rejected PDU were accepted
>on  the target).   Also, accepting partial PDUs didn't seem to make
>it easier for targets either.
>
>New wording dealing with immediate data digest failures had already
>been added to section 7.2, to appear in rev08.
>
>Thanks.
>--
>Mallikarjun
>
>
>Mallikarjun Chadalapaka
>Networked Storage Architecture
>Network Storage Solutions Organization
>MS 5668	Hewlett-Packard, Roseville.
>cbm@rose.hp.com
>
>>Julian,
>>
>>I dont know if this has been already discussed. If so forgive me and point
>>me to the link please.
>>
>>In Section 7.4, in draft 7 (page 115)it is stated that the target may
>>request retransmission
>>with a R2T. It then goes on to say that non-data PDU. It does not talk
>about
>>unsolicited data PDUs, explicitly.
>>I presume that data digest errors in unsolicited and immediate data PDUs
>>cannot be retried and should be responded
>>with delivery-subsystem failure. Is this correct? If so, why is this
>>requirement ?
>>
>>In section 7.11.1, page 119, the spec. implies that digest errors in data
>>PDUs may be recovered by issuing R2T. Once again,
>>it fails to talk about digest errors in immediate data unsolicited data
>>PDUs.
>>
>>Thanks
>>
>>Deva
>>Platys communications



From owner-ips@ece.cmu.edu  Wed Aug 22 20:15:20 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26908
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 20:15:20 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7MNmoD00646
	for ips-outgoing; Wed, 22 Aug 2001 19:48:50 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7MNmme00641
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 19:48:48 -0400 (EDT)
Received: from fmsmsxvs040.fm.intel.com (fmsmsxv040-1.fm.intel.com [132.233.48.108])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id XAA23116
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 23:48:46 GMT
Received: from fmsmsx17.intel.com ([132.233.48.17])
 by fmsmsxvs040.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001082216482603569
 for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 16:48:26 -0700
Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <RBZ4KYHX>; Wed, 22 Aug 2001 16:49:45 -0700
Message-ID: <638EC1B28663D211AC3E00A0C96B78A8086ABB4A@orsmsx40.jf.intel.com>
From: "Wheat, Stephen R" <stephen.r.wheat@intel.com>
To: ietf-ips <ips@ece.cmu.edu>
Subject: RE: iSCSI: Login Proposal
Date: Wed, 22 Aug 2001 16:48:39 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Matthew,

At the risk of violating IETF protocol, I have a new question on the Login
Proposal and a comment on Steve's earlier question.  Please let me know if I
should really have segregated these into two messages.

My question is: Does the Login Proposal propose Restart Login Command no
longer be implemented?  If so, ok fine.  If not, then where can I find the
logic of Restart and having it overlaid with Login versus having a message
type of its own?  E.g., CoalesceCIDs:

	CID 1 is in effect, but Initiator wants to restart it

	I->T  Login CID2
      T->I .... full login process, yadda, yadda
	I->T ....
	T->I  Login CID2 accepted

	I->T CoalesceCIDs CID1 to CID2

	Target verifies CID1 and CID2 are equivalent in all aspects,
		authentication, security, etc.  If so, Target Logs out CID1,
		moves all CID1 state to CID2, and closes TCP connection
associated with CID1.
		The target then replies with success.  Both parties then
mutually rename CID2
		to be CID1.
		If CID1 and CID2 are not equivalent, target logs out CID2
with coalesce failure.

Frankly, I don't know why we really would want Restart semantics, versus
just logging it out.  And as such, I'd prefer removing Restart Login from
the spec.

----------------------

Regarding your answer to Steve's second question...

Given the near consensus on the ability to have <none> listed first, second,
..., last, or not at all, it would appear that we could require an initiator
to include all auth and digest methods it supports AND is willing to have
selected by the target, in preferential order.

In this case, all required flexibility exists, and several protocol
scenarios are removed, thus simplifying the process.  Yes, this is at the
cost of an extra message exchange, but only in what both you and Steve
thought were rare cases.  Is the potential saving of that message exchange
worth the additional scenarios?  I think not.

Stephen

-----Original Message-----
From: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)
[mailto:matthew_burbridge@hp.com]
Sent: Wednesday, August 22, 2001 1:24 AM
To: 'Steve Senum'; ietf-ips
Subject: RE: iSCSI: Login Proposal


Hi Steve,

I forgot to answer your latter two questions in my earlier email!

Comments within:-

Cheers

Matthew

-----Original Message-----
From: Steve Senum [mailto:ssenum@cisco.com]
Sent: Tuesday, August 21, 2001 9:14 PM
To: ietf-ips
Subject: Re: iSCSI: Login Proposal


Matthew/Marjorie/Bob:

Some questions on your login proposal:

1. Why the following restriction?

    SecurityContextComplete=yes MUST NOT be present
    in the login command.

I don't see the benefit in not allowing something like:

I: AuthMethod:none
   HeaderDigest:crc-32c,none
   DataDigest:crc-32c,none
   SecurityContextComplete=yes
T: AuthMethod:none
   HeaderDigest:crc-32c
   DataDigest:crc-32c
   SecurityContextComlete=yes

2. In the following:

    If the login command does not contain security parameters
    the target MUST perform one of the two actions below:

    a) If the target requires security negotiation
       to be performed, then it MUST enter the security
       phase and MUST send a text response containing
       one or more security parameters and F=0.

    b)

Is this really needed?  Why not simply require the
initiator to offer security parameters if it supports them?
I would hope authentication would become the typical case
for login.

MATTHEW: So I was maintaining flexibility here.  If an initiator prefers not
to negotiate security then why force it? Also, the login is faster if
neither side want to negotiate security.  I think the majority of people
would go for flexibility and provided that the procedure caters for all four
scenarios of either side wanting/not wanting security then the flexibility
should be present.  In other words, as long as the flexibility does not
cause interoperability problems and allows everyone to do what they want to
do then the flexibility should be there. I agree that the typical case would
be to include authentication but some people will always want to skip it.

3. Is there only one Login Reponse then (just asking)?

MATTHEW: yes.  In deriving the proposal we came to the conclusion that the
partial login response is unnecessary so we removed it.  Also, some
implementers have said that this makes the implementation easier as they
will always return a text response unless login is completed (successfully
or otherwise).

Regards,
Steve Senum


From owner-ips@ece.cmu.edu  Wed Aug 22 20:19:35 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26930
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 20:19:34 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7MNgxS00380
	for ips-outgoing; Wed, 22 Aug 2001 19:42:59 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7MNgwe00375
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 19:42:58 -0400 (EDT)
Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191])
	by atlrel1.hp.com (Postfix) with ESMTP id DA348AE2
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 19:42:57 -0400 (EDT)
Received: from xatlbh2.atl.hp.com (xatlbh2.atl.hp.com [15.45.89.187])
	by xatlrelay2.atl.hp.com (Postfix) with ESMTP id C405C1F504
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 19:42:57 -0400 (EDT)
Received: by xatlbh2.atl.hp.com with Internet Mail Service (5.5.2653.19)
	id <RHJX7J2G>; Wed, 22 Aug 2001 19:42:57 -0400
Message-ID: <6BD67FFB937FD411A04F00D0B74FE87802A09266@xrose06.rose.hp.com>
From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
To: ietf-ips <ips@ece.cmu.edu>
Subject: RE: iSCSI: Option Preference (was Login Proposal)
Date: Wed, 22 Aug 2001 19:42:56 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

> In any case, seems like there's little value in having the
> initiator offer a list of AuthMethods.  Makes more sense for 
> the initiator to request login, and the target to return the required 
> AuthMethod. 

On second thought, the value in the initiator offering it's list of
supported AuthMethods is that the target can immediately terminate the
exchange if it's required AuthMethod is not offered, without an additional
exchange of text params.  Don't you love it when I disagree with myself ;-)

Marj


From owner-ips@ece.cmu.edu  Wed Aug 22 20:22:10 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26953
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 20:22:10 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7MNW5129843
	for ips-outgoing; Wed, 22 Aug 2001 19:32:05 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7MNW4e29838
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 19:32:04 -0400 (EDT)
Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <RNJ8MPSM>; Wed, 22 Aug 2001 19:31:59 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD64F@CORPMX14>
From: Black_David@emc.com
To: Julian_Satran@il.ibm.com
Cc: ips@ece.cmu.edu
Subject: RE: Security in iSCSI
Date: Wed, 22 Aug 2001 19:26:07 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Julian,

> I am certainly not confusing issues.  Removing cryptographic 
> digests was never a consensus call thing.

Between the Orlando and Nashua interim meetings and the following
email excerpt from you (my mailer says 8/2/2001 3:14am), I thought
we had not only WG consensus, but your agreement to remove these
in favor of using ESP:

> (2) The KRB5 and SPKM inband cryptographic integrity
> digests on p.136 seem to be relics of a prior inband
> approach to security.  Has anyone implemented them?
> Does anyone want them to remain?  Can we just delete
> them?
> 
> +++ Yes - I think we can take them out although UMAC may
> get-in at some point :-) +++

I'm reasonably certain that WG rough consensus exists to
remove these digests, specifically the following text from -07:

        Implementations MAY also negotiate digests with security
significance 
        for data authentication and integrity as detailed in the following 
        table: 
          
        +-------------------------------------------------------------+ 
        | Name          | Description                   | Definition  | 
        +-------------------------------------------------------------+ 
        | KRB5_MD5      | the SGN_CKSUM field (8 bytes) | RFC1964     | 
        |               | of the GSS_GetMIC() token in  |             | 
        |               | GSS_KRB5_INTEG_C_QOP_MD5 QOP  |             | 
        |               | (partial MD5 ("MD2.5") )      |             | 
        +-------------------------------------------------------------+ 
        | KRB5_DES_MD5  | the SGN_CKSUM field (8 bytes) | RFC1964     | 
        |               | of the GSS_GetMIC() token in  |             | 
        |               | GSS_KRB5_INTEG_C_QOP_DES_MD5  |             | 
        |               | QOP (DES MAC of MD5)          |             | 
        +-------------------------------------------------------------+ 
        | KRB5_DES_MAC  | the SGN_CKSUM field (8 bytes) | RFC1964     | 
        |               | of the GSS_GetMIC() token in  |             | 
        |               | GSS_KRB5_INTEG_C_QOP_ DES_MAC |             | 
        |               | QOP (DES MAC)                 |             | 
        +-------------------------------------------------------------+ 
        | SPKM          | the int-cksum field of the    | RFC2025     | 
        |               | SPKM-MIC token, calculated    |             | 
        |               | without the optional int-alg  |             | 
        |               | and snd-seq fields of the     |             | 
        |               | mic-header (i.e., the default |             | 
        |               | I-ALG is used, and sequencing |             |   
        |               | service is not used).         |             | 
        +-------------------------------------------------------------+ 
         
        Note: the KRB5_* digests are allowed only when combined with KRB5 
        authentication method (see below) (i.e., the initiator may offer one

        of these digests only if it also offers KRB5 as AuthMethod, and the 
        target may respond with one of these digests only if it also
responds 
        with KRB5 as the AuthMethod). Similarly, the SPKM digest is allowed 
        only when combined with SPKM-1 or SPKM-2 authentication methods (see

        below). 
         
        Other and proprietary algorithms MAY also be negotiated. 
        The none value is the only one that MUST be supported.

If necessary, I'm prepared to call consensus over your objection, as
there were no other comments on the list about this issue.  Keeping
these digests will only serve to confuse people (e.g., Howard reached
a basically incorrect conclusion about the current iSCSI security
direction), and the set of folks whom we may confuse includes those
with the ability to greatly complicate our efforts to get iSCSI
security specified.

FWIW, all three of the Kerberos digests are based on DES, and hence
rather weak from a cryptographic standpoint, and given that we're
starting from scratch here, SHA-1 is preferable to MD5.

I really think that text needs to come out.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


From owner-ips@ece.cmu.edu  Wed Aug 22 21:16:45 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27418
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 21:16:45 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7N0A1B01576
	for ips-outgoing; Wed, 22 Aug 2001 20:10:01 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from msgbas1t.cos.agilent.com (msgbas1tx.cos.agilent.com [192.6.9.34])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7N09xe01572
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 20:09:59 -0400 (EDT)
Received: from msgrel1t.cos.agilent.com (msgrel1t.cos.agilent.com [130.29.152.157])
	by msgbas1t.cos.agilent.com (Postfix) with ESMTP
	id 8CDC7BC5; Wed, 22 Aug 2001 18:09:58 -0600 (MDT)
Received: from axandbh3.and.agilent.com (axandbh3.and.agilent.com [130.30.32.200])
	by msgrel1t.cos.agilent.com (Postfix) with ESMTP
	id E2313625; Wed, 22 Aug 2001 18:09:57 -0600 (MDT)
Received: by axandbh3.and.agilent.com with Internet Mail Service (5.5.2653.19)
	id <Q9418CKH>; Wed, 22 Aug 2001 20:09:57 -0400
Message-ID: <FEEBE78C8360D411ACFD00D0B74779719A893A@xsj02.sjs.agilent.com>
From: "CAVANNA,VICENTE V (A-Roseville,ex1)" <vince_cavanna@agilent.com>
To: "'Julian Satran'" <Julian_Satran@il.ibm.com>
Cc: "'Mark Bakke'" <mbakke@cisco.com>,
        "CAVANNA,VICENTE V (A-Roseville,ex1)" <vince_cavanna@agilent.com>,
        ips@ece.cmu.edu, "'Steve Blightman'" <steve@alacritech.com>,
        "'Douglas Otis'" <dotis@sanlight.net>,
        "THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>
Subject: RE: iSCSI CRC: A CRC-checking example
Date: Wed, 22 Aug 2001 20:09:56 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Julian, Doug, Steve and others,

OK, I withdraw my recommendation to differ from ethernet in the bit
ordering. It will be easier (and I agree makes better sense) to document
than to convince . I will offer what is hopefully more explicit wording for
the iSCSI document in a couple of days for your consideration. 

In answer to Doug's question about the reason for using the COMPLEMENT of
the remainder of the division as the CRC ....

One reason I recall, is that this method permits the receiver to detect
extra trailing zeroes in the protected packet. If the remainder were sent
directly as the CRC, in the absence of errors the remainder of a similar
computation at the receiver would be expected to be zero. This means that
errors consisting of extra trailing zeroes would not be caught since zero
input bits would cause no changes in the CRC circuit once the CRC register
is in the so called "inaccessible state" consisting of all zeroes.  

Similarly, one reason for initializing the CRC register to 1s instead of
zeroes is to detect extra zeroes at the beginning of hte packet. Once again,
when the CRC register is in the "inaccessible" state of all zeroes it does
not begin to respond until a non-zero input is applied.

Of course this error detection enhancements are not important for iSCSI
since there are other ways to determine if the received packet is of the
expected size but we all agree there are advantages to "doing it the
ethernet way".

Vince




|-----Original Message-----
|From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
|Sent: Wednesday, August 22, 2001 1:29 PM
|To: CAVANNA,VICENTE V (A-Roseville,ex1)
|Cc: 'Mark Bakke'; CAVANNA,VICENTE V (A-Roseville,ex1);
|Pat.Thaler@d12relay01.de.ibm.com; ips@ece.cmu.edu
|Subject: RE: iSCSI CRC: A CRC-checking example
|
|
|Vince & all,
|
|I've added some statement about order (byte and bit) to the 
|draft (you have
|probably missed that piece of the mail).
|
|I could be more graphic and less explicit as in SPI but I 
|think that won't
|help too much.
|
|People did it for ethernet for years without too much ado.
|
|And don't complain to me - IBM did consistent bit ordering for years
|(Big-endian).  IBM even sent ASCII big endian (nobody else did 
|and we had
|to recode for VT100 access).
|
|As for what to choose - It seems that we are in an are where almost
|everybody does it now in this crazy way.
|I strongly suspect that this was also the reason for the way 
|SPI does it.
|They have gone all the way to acommodate
|x86 byte ordering in registers - so that the revert the bytes before
|calculating -and do this on a parallel bus!
|360 was certainly the last bastion of regularity.
|
|Regards,
|Julo
|
|
|"CAVANNA,VICENTE V (A-Roseville,ex1)" <vince_cavanna@agilent.com> on
|22-08-2001 20:42:50
|
|Please respond to "CAVANNA,VICENTE V (A-Roseville,ex1)"
|      <vince_cavanna@agilent.com>
|
|To:   Julian Satran/Haifa/IBM@IBMIL, "'Mark Bakke'" <mbakke@cisco.com>
|cc:   "CAVANNA,VICENTE V (A-Roseville,ex1)" 
|<vince_cavanna@agilent.com>,
|      Pat.Thaler@d12relay01.de.ibm.com, ips@ece.cmu.edu
|Subject:  RE: iSCSI CRC: A CRC-checking example
|
|
|
|Julian and Mark and others,
|
|After I took into account the bit "reflection"  and the byte order (Big
|Endian on Bytes and Little Endian on bits) I did finally obtain, using
|polynomial math, the (corrected) results you show in the CRC 
|examples. The
|results have also been confirmed independently by an 
|implementor here at
|Agilent.
|
|I am the one who originally suggested to Julian that we specify the CRC
|algorithm the same way as in ethernet even though for iSCSI it is not
|really
|important to initialize the CRC register to all 1s and to 
|complement the
|CRC
|before transmission since there are other means to detect 
|extra or missing
|PDU bytes. However I had not realzied until recently that 
|conformance with
|the ethernet algorithm implies bit reflection. I had not been 
|aware that in
|ethernet the bits are sent out on the serial link with the least
|significant
|bit first AND that the corresponding message polynomial is 
|formed from the
|bits in the sequence that they appear on the serial link; thus 
|the need for
|bit "reflection".
|
|Now that I understand the need for bit reflection (taken into 
|account in
|the
|rocksoft parameterized CRC generator by setting the in and out 
|reflection
|flag parameters to TRUE) I am not sure I agree that we want it 
|in iSCSI.
|The
|penalty for full conformity with ethernet seems too great. If 
|people feel
|strongly that we must keep the bit reflection I think that to make the
|existing documentation clear and unambiguous we would need to 
|explicitly
|show the mapping of bits in the iSCSI PDU to coefficients of 
|the message
|polynomial that represents the iSCSI PDU. We would also need 
|to show the
|mapping of the CRC bits to the coefficients of its representative
|polynomial.
|
|If you don't agree I will elaborate further later this week to try to
|convince you. My objective is to be able to easily and unambiguously
|describe the polynomial math behind the algorithm; right now, 
|with the bit
|reflection and without the explicit mapping it is awkward.
|
|Vince
|
|
|
|


From owner-ips@ece.cmu.edu  Wed Aug 22 21:49:34 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28825
	for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 21:49:34 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7N0ng103334
	for ips-outgoing; Wed, 22 Aug 2001 20:49:42 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from c007.snv.cp.net (c007-h011.c007.snv.cp.net [209.228.33.217])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f7N0nee03327
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 20:49:40 -0400 (EDT)
Received: (cpmta 25012 invoked from network); 22 Aug 2001 17:49:30 -0700
Received: from adsl-63-202-160-80.dsl.snfc21.pacbell.net (HELO littlejoy) (63.202.160.80)
  by smtp.telocity.com (209.228.33.217) with SMTP; 22 Aug 2001 17:49:30 -0700
X-Sent: 23 Aug 2001 00:49:30 GMT
From: "Douglas Otis" <dotis@sanlight.net>
To: "CAVANNA,VICENTE V \(A-Roseville,ex1\)" <vince_cavanna@agilent.com>,
        "'Julian Satran'" <Julian_Satran@il.ibm.com>
Cc: "'Mark Bakke'" <mbakke@cisco.com>, <ips@ece.cmu.edu>,
        "'Steve Blightman'" <steve@alacritech.com>,
        "THALER,PAT \(A-Roseville,ex1\)" <pat_thaler@agilent.com>
Subject: RE: iSCSI CRC: A CRC-checking example
Date: Wed, 22 Aug 2001 17:47:43 -0700
Message-ID: <NEBBJGDMMLHHCIKHGBEJEEKMCKAA.dotis@sanlight.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
In-Reply-To: <FEEBE78C8360D411ACFD00D0B74779719A893A@xsj02.sjs.agilent.com>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Vince,

Thanks for the explanation and here is how I understand your comments.  Even
with the CRC unlikely to find zero as a stable state with the all ones
initialization, in a rare event where a CRC value becomes zero over a
trailing list of zeros, then an inverted CRC store will create an all ones
as an ending value.  This is to better ensure detection of the end of the
block as there are encoding changes that help the underlying decoding
process.  It would seem that there is still the requirement to know the end
of the frame regardless of the CRC value but there may be an advantage to
this encoding change.  Again, thanks.

Doug


> In answer to Doug's question about the reason for using the COMPLEMENT of
> the remainder of the division as the CRC ....
>
> One reason I recall, is that this method permits the receiver to detect
> extra trailing zeroes in the protected packet. If the remainder were sent
> directly as the CRC, in the absence of errors the remainder of a similar
> computation at the receiver would be expected to be zero. This means that
> errors consisting of extra trailing zeroes would not be caught since zero
> input bits would cause no changes in the CRC circuit once the CRC register
> is in the so called "inaccessible state" consisting of all zeroes.



From owner-ips@ece.cmu.edu  Thu Aug 23 03:44:35 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19933
	for <ips-archive@odin.ietf.org>; Thu, 23 Aug 2001 03:44:34 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7N7Ajr25483
	for ips-outgoing; Thu, 23 Aug 2001 03:10:45 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from bramg1.net.external.hp.com (bramg1.net.external.hp.com [192.6.126.73])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7N7Aie25479
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 03:10:44 -0400 (EDT)
Received: from quasit.br.itc.hp.com (quasit.br.itc.hp.com [15.145.8.135])
	by bramg1.net.external.hp.com (Postfix) with ESMTP
	id 1917D32; Thu, 23 Aug 2001 09:11:04 +0200 (METDST)
Received: from fowey.BR.ITC.HP.COM (fowey.br.itc.hp.com [15.145.8.186])
	by quasit.br.itc.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id IAA03377;
	Thu, 23 Aug 2001 08:10:42 +0100 (BST)
Received: from 15.145.8.186 by fowey.BR.ITC.HP.COM (InterScan E-Mail VirusWall NT); Thu, 23 Aug 2001 08:10:09 +0100 (GMT Daylight Time)
Received: by fowey.br.itc.hp.com with Internet Mail Service (5.5.2653.19)
	id <Q94W3XCZ>; Thu, 23 Aug 2001 08:10:09 +0100
Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC101E7A839@dickens.bri.hp.com>
From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <matthew_burbridge@hp.com>
To: "'Wheat, Stephen R'" <stephen.r.wheat@intel.com>,
        ietf-ips <ips@ece.cmu.edu>
Subject: RE: iSCSI: Login Proposal
Date: Thu, 23 Aug 2001 08:10:39 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Stephen,

On the first point:

The proposal does not exclude the Restart Login Command which is still
required for error recovery (7.11.3).  The proposal is applicable to both as
is the current login procedure in 0.7 but if there is something that is
missing from the spec then please bring it up on the IPS.

If the restart bit is set and therefore 7.11.3 is coming into play then the
CID of the restart-connection must be the same as the CID of the initial
connection (2.10.1). In your example CID2=CID1.

I believe if security is required by either or both parties then it needs to
be negotiated on the new connection (otherwise when is it turned on?) and
the same argue applies to operation parameters. Unless I am barking up the
wrong tree, the out come of the two phases need not be the same as the
original connection (as long as the target and initiator agree!).

And the second point:

This is now a separate thread (RE: iSCSI: Option Preference (was Login
Proposal)). I am sitting back and waiting to see what happens.  However, my
thoughts are the IPS need to decide who has power of veto on security and I
think the general opinion is the target. I don't as yet see this effecting
the login proposal but more likely effect some aspect of text negotiation.

I still don't see why we should alienate those initiators/targets who do not
want to negotiate for security.  Security may be achieved by some other
means (e.g. IPsec) and therefore not required at the iSCSI level.

Cheers

Matthew


-----Original Message-----
From: Wheat, Stephen R [mailto:stephen.r.wheat@intel.com]
Sent: Thursday, August 23, 2001 12:49 AM
To: ietf-ips
Subject: RE: iSCSI: Login Proposal


Matthew,

At the risk of violating IETF protocol, I have a new question on the Login
Proposal and a comment on Steve's earlier question.  Please let me know if I
should really have segregated these into two messages.

My question is: Does the Login Proposal propose Restart Login Command no
longer be implemented?  If so, ok fine.  If not, then where can I find the
logic of Restart and having it overlaid with Login versus having a message
type of its own?  E.g., CoalesceCIDs:

	CID 1 is in effect, but Initiator wants to restart it

	I->T  Login CID2
      T->I .... full login process, yadda, yadda
	I->T ....
	T->I  Login CID2 accepted

	I->T CoalesceCIDs CID1 to CID2

	Target verifies CID1 and CID2 are equivalent in all aspects,
		authentication, security, etc.  If so, Target Logs out CID1,
		moves all CID1 state to CID2, and closes TCP connection
associated with CID1.
		The target then replies with success.  Both parties then
mutually rename CID2
		to be CID1.
		If CID1 and CID2 are not equivalent, target logs out CID2
with coalesce failure.

Frankly, I don't know why we really would want Restart semantics, versus
just logging it out.  And as such, I'd prefer removing Restart Login from
the spec.

----------------------

Regarding your answer to Steve's second question...

Given the near consensus on the ability to have <none> listed first, second,
..., last, or not at all, it would appear that we could require an initiator
to include all auth and digest methods it supports AND is willing to have
selected by the target, in preferential order.

In this case, all required flexibility exists, and several protocol
scenarios are removed, thus simplifying the process.  Yes, this is at the
cost of an extra message exchange, but only in what both you and Steve
thought were rare cases.  Is the potential saving of that message exchange
worth the additional scenarios?  I think not.

Stephen

-----Original Message-----
From: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)
[mailto:matthew_burbridge@hp.com]
Sent: Wednesday, August 22, 2001 1:24 AM
To: 'Steve Senum'; ietf-ips
Subject: RE: iSCSI: Login Proposal


Hi Steve,

I forgot to answer your latter two questions in my earlier email!

Comments within:-

Cheers

Matthew

-----Original Message-----
From: Steve Senum [mailto:ssenum@cisco.com]
Sent: Tuesday, August 21, 2001 9:14 PM
To: ietf-ips
Subject: Re: iSCSI: Login Proposal


Matthew/Marjorie/Bob:

Some questions on your login proposal:

1. Why the following restriction?

    SecurityContextComplete=yes MUST NOT be present
    in the login command.

I don't see the benefit in not allowing something like:

I: AuthMethod:none
   HeaderDigest:crc-32c,none
   DataDigest:crc-32c,none
   SecurityContextComplete=yes
T: AuthMethod:none
   HeaderDigest:crc-32c
   DataDigest:crc-32c
   SecurityContextComlete=yes

2. In the following:

    If the login command does not contain security parameters
    the target MUST perform one of the two actions below:

    a) If the target requires security negotiation
       to be performed, then it MUST enter the security
       phase and MUST send a text response containing
       one or more security parameters and F=0.

    b)

Is this really needed?  Why not simply require the
initiator to offer security parameters if it supports them?
I would hope authentication would become the typical case
for login.

MATTHEW: So I was maintaining flexibility here.  If an initiator prefers not
to negotiate security then why force it? Also, the login is faster if
neither side want to negotiate security.  I think the majority of people
would go for flexibility and provided that the procedure caters for all four
scenarios of either side wanting/not wanting security then the flexibility
should be present.  In other words, as long as the flexibility does not
cause interoperability problems and allows everyone to do what they want to
do then the flexibility should be there. I agree that the typical case would
be to include authentication but some people will always want to skip it.

3. Is there only one Login Reponse then (just asking)?

MATTHEW: yes.  In deriving the proposal we came to the conclusion that the
partial login response is unnecessary so we removed it.  Also, some
implementers have said that this makes the implementation easier as they
will always return a text response unless login is completed (successfully
or otherwise).

Regards,
Steve Senum


From owner-ips@ece.cmu.edu  Thu Aug 23 03:44:38 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19944
	for <ips-archive@odin.ietf.org>; Thu, 23 Aug 2001 03:44:38 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7N6p2324746
	for ips-outgoing; Thu, 23 Aug 2001 02:51:02 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7N6p1e24742
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 02:51:01 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id IAA298968
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 08:50:54 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7N6or9142732
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 08:50:54 +0200
Importance: Normal
Subject: RE: iSCSI: Option Preference (was Login Proposal)
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF5C3C9920.29E41FC0-ONC2256AB1.0024B76C@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Thu, 23 Aug 2001 09:50:23 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 23/08/2001 09:50:53
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Marjorie,

If you'll take the time and go through all the scenarios (I know that your
time is precious :-))
you'll find that the order of "exposing" preferences in a negotiation does
not matter if the negotiation is symmetric (and it is).
As we are bound to a certain order of things by the main function (command
processing) we start all exchanges at initiator.
Having the initiator send an empty request only because you think that in
most cases the target dictates authentication
seems a vaste of bits (and time) - contrary to your assertion. This is why
we never gave any example involving it.
But it is certainly a legal sequence in the current draft.  To force
everybody to use it - BAD IDEA.
I assume that as storage gets more decoupled from systems the need for
mutual authentication will increase (why would you believe that
the volume given to you over the net is where you wrote your precious data
last time?).

Julo



"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>@ece.cmu.edu
on 23-08-2001 02:08:30

Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"
      <marjorie_krueger@hp.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ietf-ips <ips@ece.cmu.edu>
cc:
Subject:  RE: iSCSI: Option Preference (was Login Proposal)



That really makes the most sense to me.  IMO, having the initiator
"request"
authmethods is kind of a waste of bits.  The model I have in mind is that a
target basicly has one AuthMethod and all initiators that want to access it
either MUST use that AuthMethod (external "storage service provider" model)
or may either use that AuthMethod or none.  I'm having a hard time
imagining
poor little targets implementing multiple authMethods in the same box and
actually allowing initiators with different authMethods to access it
simultaneously.  In any case, seems like there's little value in having the
initiator offer a list of AuthMethods.  Makes more sense for the initiator
to request login, and the target to return the required AuthMethod.  If the
initiator can't handle it, it terminates the exchange.  That's my
understanding of how client-server auth relationships usually work.
Actually, typically the client is simply expected to know the required
AuthMethod (thru configuration) and begins the exchange by requesting
authorization.

Marj

> -----Original Message-----
> From: Steve Senum [mailto:ssenum@cisco.com]
> Sent: Wednesday, August 22, 2001 3:24 PM
> To: ietf-ips
> Subject: Re: iSCSI: Option Preference (was Login Proposal)
>
>
> Not to try to beat this into the ground anymore
> then already has been done, but...
>
> Many months ago, when I first looked over
> the iSCSI spec, I remember thinking it was
> kind of odd for the side being authenticated
> to control the possible options.  Other
> protocols I have worked with would have the
> side driving the authentication (i.e., the Target)
> control this.
>
> If the IPS group wants to stay with the
> current target-really-controls-authentication
> notion, we might want to go a step further,
> and allow only the Target to send the AuthMethod
> key out.
>
> Just a thought,
> Steve Senum
>
>





From owner-ips@ece.cmu.edu  Thu Aug 23 03:44:59 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19961
	for <ips-archive@odin.ietf.org>; Thu, 23 Aug 2001 03:44:59 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7N733425198
	for ips-outgoing; Thu, 23 Aug 2001 03:03:03 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7N731e25194
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 03:03:02 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id JAA129266
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 09:02:55 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7N72t9197322
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 09:02:55 +0200
Importance: Normal
Subject: RE: Security in iSCSI
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFDD6A10B9.AD0B45DC-ONC2256AB1.002613C4@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Thu, 23 Aug 2001 10:02:25 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 23/08/2001 10:02:53
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

David,

You seem to missing my main point. I am ready to take out the table but not
the general notion of a cryptographic digest.
To do the later I have to have the community understand that their are left
with no protocol provided means to authenticate
data that pass through iSCSI proxies.

Julo

Black_David@emc.com on 23-08-2001 02:26:07

Please respond to Black_David@emc.com

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   ips@ece.cmu.edu
Subject:  RE: Security in iSCSI



Julian,

> I am certainly not confusing issues.  Removing cryptographic
> digests was never a consensus call thing.

Between the Orlando and Nashua interim meetings and the following
email excerpt from you (my mailer says 8/2/2001 3:14am), I thought
we had not only WG consensus, but your agreement to remove these
in favor of using ESP:

> (2) The KRB5 and SPKM inband cryptographic integrity
> digests on p.136 seem to be relics of a prior inband
> approach to security.  Has anyone implemented them?
> Does anyone want them to remain?  Can we just delete
> them?
>
> +++ Yes - I think we can take them out although UMAC may
> get-in at some point :-) +++

I'm reasonably certain that WG rough consensus exists to
remove these digests, specifically the following text from -07:

        Implementations MAY also negotiate digests with security
significance
        for data authentication and integrity as detailed in the following
        table:

        +-------------------------------------------------------------+
        | Name          | Description                   | Definition  |
        +-------------------------------------------------------------+
        | KRB5_MD5      | the SGN_CKSUM field (8 bytes) | RFC1964     |
        |               | of the GSS_GetMIC() token in  |             |
        |               | GSS_KRB5_INTEG_C_QOP_MD5 QOP  |             |
        |               | (partial MD5 ("MD2.5") )      |             |
        +-------------------------------------------------------------+
        | KRB5_DES_MD5  | the SGN_CKSUM field (8 bytes) | RFC1964     |
        |               | of the GSS_GetMIC() token in  |             |
        |               | GSS_KRB5_INTEG_C_QOP_DES_MD5  |             |
        |               | QOP (DES MAC of MD5)          |             |
        +-------------------------------------------------------------+
        | KRB5_DES_MAC  | the SGN_CKSUM field (8 bytes) | RFC1964     |
        |               | of the GSS_GetMIC() token in  |             |
        |               | GSS_KRB5_INTEG_C_QOP_ DES_MAC |             |
        |               | QOP (DES MAC)                 |             |
        +-------------------------------------------------------------+
        | SPKM          | the int-cksum field of the    | RFC2025     |
        |               | SPKM-MIC token, calculated    |             |
        |               | without the optional int-alg  |             |
        |               | and snd-seq fields of the     |             |
        |               | mic-header (i.e., the default |             |
        |               | I-ALG is used, and sequencing |             |
        |               | service is not used).         |             |
        +-------------------------------------------------------------+

        Note: the KRB5_* digests are allowed only when combined with KRB5
        authentication method (see below) (i.e., the initiator may offer
one

        of these digests only if it also offers KRB5 as AuthMethod, and the
        target may respond with one of these digests only if it also
responds
        with KRB5 as the AuthMethod). Similarly, the SPKM digest is allowed
        only when combined with SPKM-1 or SPKM-2 authentication methods
(see

        below).

        Other and proprietary algorithms MAY also be negotiated.
        The none value is the only one that MUST be supported.

If necessary, I'm prepared to call consensus over your objection, as
there were no other comments on the list about this issue.  Keeping
these digests will only serve to confuse people (e.g., Howard reached
a basically incorrect conclusion about the current iSCSI security
direction), and the set of folks whom we may confuse includes those
with the ability to greatly complicate our efforts to get iSCSI
security specified.

FWIW, all three of the Kerberos digests are based on DES, and hence
rather weak from a cryptographic standpoint, and given that we're
starting from scratch here, SHA-1 is preferable to MD5.

I really think that text needs to come out.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------





From owner-ips@ece.cmu.edu  Thu Aug 23 10:29:16 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24276
	for <ips-archive@odin.ietf.org>; Thu, 23 Aug 2001 10:29:16 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7NDgiX25639
	for ips-outgoing; Thu, 23 Aug 2001 09:42:44 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7NDgfe25630
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 09:42:42 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id PAA163502
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 15:42:35 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7NDgYh74222
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 15:42:34 +0200
Importance: Normal
Subject: Re:iSCSI A Question on "Full Feature Phase" of iSCSI 07
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF96A7895F.61DDD3D1-ONC2256AB1.004A952F@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Thu, 23 Aug 2001 16:37:59 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 23/08/2001 16:42:34
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Thanu,

No name, default or otherwise, is required for the discovery session.
The text will be fixed to show this (the current was not completely aligned
with the naming and discovery team).
Only the type discovery is needed.

The name iSCSI is reserved.

Julo

Thanu Skariah <tskariah@npd.hcltech.com>@npd.hcltech.com on 23-08-2001
16:18:20

Please respond to Thanu Skariah <tskariah@npd.hcltech.com>

Sent by:  thanu@npd.hcltech.com


To:   Julian Satran/Haifa/IBM@IBMIL
cc:   ips@ece.cmu.edu
Subject:  Re:iSCSI A Question on "Full Feature Phase" of iSCSI 07



Julian,

In the session of type discovery, the only command that can be  accepted by
a
target is a text command with a SendTargets key ( Appendix D, 34, page
167).

In  Appendix E. SendTargets operation, the second and third paragraphs say,

" To make use of SendTargets, an initiator must be logged into one of the
two
types of targets. If the initiator is logged into the deafault target
(target
name "iSCSI"), the only session type that it can be used is a discovery
session. If it logs into any other target, the session can be either a
discovery session or a normal operational session.
A system containing targets MUST support login to the default "iSCSI"
target,
and MUST support the SendTargets command for this target. "

Confused with your reply and this part in the 07 draft. Kindly clarify.

Thank You,
Thanu



Julian Satran wrote:

> There is no default target anymore. The default target has been replaced
by
> a session of type discovery in which you don't have to give a target
name.
>
> Julo
>
> "Lee Xing" <lxing@Crossroads.com>@ece.cmu.edu on 21-08-2001 01:56:29
>
> Please respond to "Lee Xing" <lxing@Crossroads.com>
>
> Sent by:  owner-ips@ece.cmu.edu
>
> To:   <ips@ece.cmu.edu>
> cc:
> Subject:  A Question on "Full Feature Phase" of iSCSI 07
>
> Hi,
>
> On iSCSI 07 page 23 (section 1.2.5), it says "... A session is in full
> feature phase after successfully finishing the login phase on the first
> (leading) connection of a session. A connection is in full feature phase
> if the session in full feature phase and the connection login has
> completed successfully."
>
> I assume that the above statements are not true after logging into the
> default target "iSCSI", right?  If so, should we make them clearer?
>
> Thank you.
>
> Lee Xing
> Sr. Software Engineer
> Crossroads Systems, Inc.






From owner-ips@ece.cmu.edu  Thu Aug 23 10:32:19 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24347
	for <ips-archive@odin.ietf.org>; Thu, 23 Aug 2001 10:32:19 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7NDEpU24299
	for ips-outgoing; Thu, 23 Aug 2001 09:14:51 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mailnpd.hcltech.com ([203.197.145.76])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f7NDEme24294
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 09:14:48 -0400 (EDT)
Received: from npd.hcltech.com (tskariah-pc.hcltech.com [192.168.100.72])
	by mailnpd.hcltech.com (8.11.0/8.11.0) with ESMTP id f7NDFJC11404;
	Thu, 23 Aug 2001 18:45:20 +0530
Message-ID: <3B85029C.8F12DE4E@npd.hcltech.com>
Date: Thu, 23 Aug 2001 18:48:20 +0530
From: Thanu Skariah <tskariah@npd.hcltech.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Julian Satran <Julian_Satran@il.ibm.com>
CC: ips@ece.cmu.edu
Subject: Re:iSCSI A Question on "Full Feature Phase" of iSCSI 07
References: <OFCBC716A9.9B25A5D2-ONC2256AB0.0014197E@telaviv.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Julian,

In the session of type discovery, the only command that can be  accepted by a
target is a text command with a SendTargets key ( Appendix D, 34, page 167).

In  Appendix E. SendTargets operation, the second and third paragraphs say,

" To make use of SendTargets, an initiator must be logged into one of the two
types of targets. If the initiator is logged into the deafault target (target
name "iSCSI"), the only session type that it can be used is a discovery
session. If it logs into any other target, the session can be either a
discovery session or a normal operational session.
A system containing targets MUST support login to the default "iSCSI" target,
and MUST support the SendTargets command for this target. "

Confused with your reply and this part in the 07 draft. Kindly clarify.

Thank You,
Thanu



Julian Satran wrote:

> There is no default target anymore. The default target has been replaced by
> a session of type discovery in which you don't have to give a target name.
>
> Julo
>
> "Lee Xing" <lxing@Crossroads.com>@ece.cmu.edu on 21-08-2001 01:56:29
>
> Please respond to "Lee Xing" <lxing@Crossroads.com>
>
> Sent by:  owner-ips@ece.cmu.edu
>
> To:   <ips@ece.cmu.edu>
> cc:
> Subject:  A Question on "Full Feature Phase" of iSCSI 07
>
> Hi,
>
> On iSCSI 07 page 23 (section 1.2.5), it says "... A session is in full
> feature phase after successfully finishing the login phase on the first
> (leading) connection of a session. A connection is in full feature phase
> if the session in full feature phase and the connection login has
> completed successfully."
>
> I assume that the above statements are not true after logging into the
> default target "iSCSI", right?  If so, should we make them clearer?
>
> Thank you.
>
> Lee Xing
> Sr. Software Engineer
> Crossroads Systems, Inc.



From owner-ips@ece.cmu.edu  Thu Aug 23 13:51:54 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28057
	for <ips-archive@odin.ietf.org>; Thu, 23 Aug 2001 13:51:53 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7NGdwD06712
	for ips-outgoing; Thu, 23 Aug 2001 12:39:58 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from atlrel6.hp.com (atlrel6.hp.com [192.151.27.8])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7NGdve06708
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 12:39:57 -0400 (EDT)
Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190])
	by atlrel6.hp.com (Postfix) with ESMTP id C3DDF1F61B
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 12:39:51 -0400 (EDT)
Received: from xatlbh2.atl.hp.com (xatlbh2.atl.hp.com [15.45.89.187])
	by xatlrelay1.atl.hp.com (Postfix) with ESMTP id 8112D1F53F
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 12:39:47 -0400 (EDT)
Received: by xatlbh2.atl.hp.com with Internet Mail Service (5.5.2653.19)
	id <RHJX8RF4>; Thu, 23 Aug 2001 12:39:47 -0400
Message-ID: <6BD67FFB937FD411A04F00D0B74FE87802A09269@xrose06.rose.hp.com>
From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
To: ips@ece.cmu.edu
Subject: RE: iSCSI: Option Preference (was Login Proposal)
Date: Thu, 23 Aug 2001 12:39:46 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Agreed, I've already disagreed with myself in a subsequent email :-)  Good
point regarding mutual authentication, the possibilities for malicious
behavior are miriad (masquerading as a target to intercept your precious
data).

Marj

> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Wednesday, August 22, 2001 11:50 PM
> To: ips@ece.cmu.edu
> Subject: RE: iSCSI: Option Preference (was Login Proposal)
> 
> 
> 
> Marjorie,
> 
> If you'll take the time and go through all the scenarios (I 
> know that your
> time is precious :-))
> you'll find that the order of "exposing" preferences in a 
> negotiation does
> not matter if the negotiation is symmetric (and it is).
> As we are bound to a certain order of things by the main 
> function (command
> processing) we start all exchanges at initiator.
> Having the initiator send an empty request only because you 
> think that in
> most cases the target dictates authentication
> seems a vaste of bits (and time) - contrary to your 
> assertion. This is why
> we never gave any example involving it.
> But it is certainly a legal sequence in the current draft.  To force
> everybody to use it - BAD IDEA.
> I assume that as storage gets more decoupled from systems the need for
> mutual authentication will increase (why would you believe that
> the volume given to you over the net is where you wrote your 
> precious data
> last time?).
> 
> Julo
> 
> 
> 
> "KRUEGER,MARJORIE (HP-Roseville,ex1)" 
> <marjorie_krueger@hp.com>@ece.cmu.edu
> on 23-08-2001 02:08:30
> 
> Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"
>       <marjorie_krueger@hp.com>
> 
> Sent by:  owner-ips@ece.cmu.edu
> 
> 
> To:   ietf-ips <ips@ece.cmu.edu>
> cc:
> Subject:  RE: iSCSI: Option Preference (was Login Proposal)
> 
> 
> 
> That really makes the most sense to me.  IMO, having the initiator
> "request"
> authmethods is kind of a waste of bits.  The model I have in 
> mind is that a
> target basicly has one AuthMethod and all initiators that 
> want to access it
> either MUST use that AuthMethod (external "storage service 
> provider" model)
> or may either use that AuthMethod or none.  I'm having a hard time
> imagining
> poor little targets implementing multiple authMethods in the 
> same box and
> actually allowing initiators with different authMethods to access it
> simultaneously.  In any case, seems like there's little value 
> in having the
> initiator offer a list of AuthMethods.  Makes more sense for 
> the initiator
> to request login, and the target to return the required 
> AuthMethod.  If the
> initiator can't handle it, it terminates the exchange.  That's my
> understanding of how client-server auth relationships usually work.
> Actually, typically the client is simply expected to know the required
> AuthMethod (thru configuration) and begins the exchange by requesting
> authorization.
> 
> Marj
> 
> > -----Original Message-----
> > From: Steve Senum [mailto:ssenum@cisco.com]
> > Sent: Wednesday, August 22, 2001 3:24 PM
> > To: ietf-ips
> > Subject: Re: iSCSI: Option Preference (was Login Proposal)
> >
> >
> > Not to try to beat this into the ground anymore
> > then already has been done, but...
> >
> > Many months ago, when I first looked over
> > the iSCSI spec, I remember thinking it was
> > kind of odd for the side being authenticated
> > to control the possible options.  Other
> > protocols I have worked with would have the
> > side driving the authentication (i.e., the Target)
> > control this.
> >
> > If the IPS group wants to stay with the
> > current target-really-controls-authentication
> > notion, we might want to go a step further,
> > and allow only the Target to send the AuthMethod
> > key out.
> >
> > Just a thought,
> > Steve Senum
> >
> >
> 
> 
> 


From owner-ips@ece.cmu.edu  Thu Aug 23 13:52:29 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28075
	for <ips-archive@odin.ietf.org>; Thu, 23 Aug 2001 13:52:28 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7NGwlK07689
	for ips-outgoing; Thu, 23 Aug 2001 12:58:47 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from hypnos.cps.intel.com (hypnos.cps.intel.com [192.198.165.17])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7NGwje07683
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 12:58:45 -0400 (EDT)
Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201])
	by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id QAA13730
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 16:58:38 GMT
Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.201
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Thu, 23 Aug 2001 16:58:38 0000 (GMT)
Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <RBZV1GC5>; Thu, 23 Aug 2001 09:58:37 -0700
Message-ID: <638EC1B28663D211AC3E00A0C96B78A8086ABB4E@orsmsx40.jf.intel.com>
From: "Wheat, Stephen R" <stephen.r.wheat@intel.com>
To: ips@ece.cmu.edu
Subject: Re: iSCSI - Change - Login/Text commands with the binary stage co
	de
Date: Thu, 23 Aug 2001 09:58:34 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Julian,

1.3.6 ISID states that the target should check to see if the old session is
still active when a duplicate session is detected.

I have two questions, the second only if you answer in the affirmative on
the first ;^)

1. Is there a properly executed sequence of events (i.e., no coding error on
the target side) where the session is not active, but the target hadn't
taken notice of it?  It appears this as a protocol-specified means to work
around a flaw in a target's implementation.  I interpret the state diagram
transitions as being atomic wrt other commands.  I.e., the last logout would
result in the various transitions of the connection/session prior to the
initiator starting the session up again.  And the target would have
completed the transitions prior to handling a new session request.

2. If you answered (1) in the affirmative, then the word "Active" is not
consistent with the 6.3 Session State Diagram.  Does this mean the target
got lost, due to transport failures of any sort, in its transition from
Q3-to-Q2-to-Q1?  It sounds like the intent is to close the old session if
the session was in Q2 or Q4, presuming if it were in Q1,  it would not have
been found as a duplicate.

Stephen



From owner-ips@ece.cmu.edu  Thu Aug 23 13:53:45 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28098
	for <ips-archive@odin.ietf.org>; Thu, 23 Aug 2001 13:53:45 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7NHKX209016
	for ips-outgoing; Thu, 23 Aug 2001 13:20:33 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7NHKWe09012
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 13:20:32 -0400 (EDT)
Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <RNJ83QL5>; Thu, 23 Aug 2001 13:20:23 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD656@CORPMX14>
From: Black_David@emc.com
To: Julian_Satran@il.ibm.com, ips@ece.cmu.edu
Subject: iSCSI: Proxies (was Security in iSCSI)
Date: Thu, 23 Aug 2001 13:14:30 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Julian,

> You seem to missing my main point. I am ready to take out the
> table but not the general notion of a cryptographic digest.
> To do the later I have to have the community understand that 
> their are left with no protocol provided means to authenticate
> data that pass through iSCSI proxies.

Actually, I was hoping that you weren't going there.  Just when
one thinks one has obtained a good understanding of a network
technology/protocol/solution/etc., adding the notion of proxies
is almost certain to restore the previous state of confusion.
Multicast also has this property, but fortunately, I haven't
seen anyone in the WG take any serious interest in it (and
woe betide anyone who takes this as an invitation ;-) ).

My primary concern is one of schedule - if full support for
proxies is a requirement for the first version of the iSCSI
RFC, the schedule guesstimate I posted yesterday is probably
optimistic by 6+ months.  Issues that come up in the area of
proxies that will take a while to resolve will likely include:

- What's the right scope of proxy support?  How much
	consideration for SCSI level proxies to which other
	transports needs to be reflected in the iSCSI standard?
- SCSI is not an end-to-end transport independent protocol.
	T10 had the opportunity to go in this direction in the
	SCSI GPP work) and chose not to do so. Extensive iSCSI
	work on proxies risks running into SCSI architecture,
	and our experience with ACA suggests that they'll take
	a while to resolve.
- Security interaction with proxies is a very complicated
	subject.  IPsec and NATs is a well-known tarpit that
	is finally getting resolved years later.  I hesitate
	to promise that the iSCSI proxy issues will be significantly
	simpler by comparison.
- There is precedent for proxies adapting to the requirements
	of protocols - TLS requires http proxies to accommodate
	it rather than the other way around.  Whether proxies
	should drive iSCSI security architecture or iSCSI
	security architecture should drive proxy design will
	at the minimum be fodder for serious debate.

If we want to get the iSCSI spec done in a reasonable timeframe,
I suggest closing the lid on this Pandora's box labeled
"proxies" and deferring serious work on iSCSI proxy support
to a future revision.  The separate header and data CRCs are a
useful step towards making life better for those who want to
build proxies, but I hesitate to go much further in that
direction, particularly in the area of security.  As things
currently stand, one way to authenticate data passing through
an iSCSI proxy is to have the iSCSI proxy participate in the
authentication which seems like an acceptable situation (and
one that has a straightforward security explanation).

Comments?

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


From owner-ips@ece.cmu.edu  Thu Aug 23 14:38:50 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28886
	for <ips-archive@odin.ietf.org>; Thu, 23 Aug 2001 14:38:50 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7NI8uF11836
	for ips-outgoing; Thu, 23 Aug 2001 14:08:56 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from c007.snv.cp.net (c007-h012.c007.snv.cp.net [209.228.33.219])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f7NI8se11831
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 14:08:54 -0400 (EDT)
Received: (cpmta 6359 invoked from network); 23 Aug 2001 11:08:47 -0700
Received: from adsl-63-202-160-80.dsl.snfc21.pacbell.net (HELO littlejoy) (63.202.160.80)
  by smtp.telocity.com (209.228.33.219) with SMTP; 23 Aug 2001 11:08:47 -0700
X-Sent: 23 Aug 2001 18:08:47 GMT
From: "Douglas Otis" <dotis@sanlight.net>
To: "CAVANNA,VICENTE V \(A-Roseville,ex1\)" <vince_cavanna@agilent.com>,
        "'Julian Satran'" <Julian_Satran@il.ibm.com>
Cc: "'Mark Bakke'" <mbakke@cisco.com>, <ips@ece.cmu.edu>,
        "'Steve Blightman'" <steve@alacritech.com>,
        "THALER,PAT \(A-Roseville,ex1\)" <pat_thaler@agilent.com>
Subject: RE: iSCSI CRC: A CRC-checking example
Date: Thu, 23 Aug 2001 11:06:58 -0700
Message-ID: <NEBBJGDMMLHHCIKHGBEJGELBCKAA.dotis@sanlight.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <FEEBE78C8360D411ACFD00D0B74779719A893D@xsj02.sjs.agilent.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Vince,

Thanks again as you have made this issue clear.  It would be beneficial to
maintain the "Ethernet" techniques even if only to ensure an accurate length
of packet detection.

Doug

> Doug,
>
> If the transmit side CRC generator used for the frame check sequence the
> remainder of the polynomial division directly (without complementing) the
> receiver-side CRC checker would be expected to end up with zeroes after
> processing an error-free frame. Unfortunately the receiver side
> CRC checker
> would also end up with zeroes after processing a frame whose only "errors"
> are extra trailing zeroes. Thus this type of error would not be
> detected by
> the CRC checker.
>
> Note that the expected final state of the receiver-side CRC checker is
> expected to be zero if hte remainder is not complemented even though both
> transmit and receiver sides initialize their CRC register to 1s. It is the
> operation of complementing the remainder that causes the receiver
> to have a
> non-zero (but constant) ending state after processing an error-free frame.
>
> If I understand you correctly, you have described another type of
> error that
> would be undetected were the remainder not complemented. Whenever the
> receiver CRC register is in its zero state (perhaps partially through a
> packet) the receiver checker would be blind to extra zeroes
> inserted in the
> packet at that point. I agree.
>
> Again, the improved protection resulting from initializing the
> CRC to 1s and
> complementing the remainder is not important for iSCSI because the packet
> length can be checked independently but I suppose it is advantageous to do
> things the ethernet way.
>
>
> Vince



From owner-ips@ece.cmu.edu  Thu Aug 23 14:39:39 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28922
	for <ips-archive@odin.ietf.org>; Thu, 23 Aug 2001 14:39:39 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7NHoLO10866
	for ips-outgoing; Thu, 23 Aug 2001 13:50:21 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7NHoJe10861
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 13:50:19 -0400 (EDT)
Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id RAA21358
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 17:50:18 GMT
Received: from fmsmsx17.intel.com ([132.233.48.17])
 by fmsmsxvs040.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001082310495723413
 for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 10:49:57 -0700
Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <RBZ4MY8S>; Thu, 23 Aug 2001 10:51:17 -0700
Message-ID: <638EC1B28663D211AC3E00A0C96B78A8086ABB55@orsmsx40.jf.intel.com>
From: "Wheat, Stephen R" <stephen.r.wheat@intel.com>
To: ips@ece.cmu.edu
Subject: iSCSI: CmdSN in Login-retry
Date: Thu, 23 Aug 2001 10:50:08 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Hi Julian,

My questions pale in comparison to the very interesting security digest
debate.  BTW, I hope David's Pandora's box does stay closed for 1.0.

Section 7.1 states that a Retry command MUST use the original CmdSN.  This
doesn't make sense for a Login Retry.

Is there an exception here?  If not, please briefly explain the logic of a
Login Retry having the original CmdSN.

How does this enter into the debate on whether Login and Login-Text messages
should be sent Immediate?  Has consensus been met on that yet?

BTW, is there an occasional forum where several people meet to thrash out
subtle details, or is this the only forum for questions, tiny and big?
Obviously people can meet FTF or on the phone whenever they want, but is
there a scheduled forum?

Thanks,
Stephen


From owner-ips@ece.cmu.edu  Thu Aug 23 14:41:07 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28971
	for <ips-archive@odin.ietf.org>; Thu, 23 Aug 2001 14:41:07 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7NHfjC10340
	for ips-outgoing; Thu, 23 Aug 2001 13:41:45 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7NHfie10336
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 13:41:44 -0400 (EDT)
Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <RNJ83SSX>; Thu, 23 Aug 2001 13:41:35 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD657@CORPMX14>
From: Black_David@emc.com
To: ips@ece.cmu.edu
Subject: IPS: (very) DRAFT(y) London Minutes
Date: Thu, 23 Aug 2001 13:35:41 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Apologies for some glitches in taking these minutes -
there are some areas in which they're less than complete
(noted with double square brackets [[..]] below).  Please
send additions/corrections/etc. to me and/or the list.

Presenters - please send me the slides used in London
if you have not already done so.

Thanks,
--David

IP Storage (IPS) Working Group
DRAFT Minutes
London Meeting - August 6 and 7, 2001
-------------------------------------

-----> Monday, August 6 <---------

Administrivia and Agenda Bash - see bashed agenda.

Discussion of IETF last call.  Process will involve emailed comments
directly to authors, so draft editors need to make sure author addresses
(including email) are up to date.  There is no formal process akin to a
T10 or T11 letter ballot and comment resolution.

-- Plugfest - Robert Russell, UNH

Testing of implementations against each other, a reference implementation,
and a conformance test suite (latter two focused on Login).

Many implementations did not do any Login, most who did only implemented 2
or 3 keys, DataPDULength, InitialR2T, ImmediateData were the most common.

Login was a disaster - all kinds of things not done right, ignored,
instability.  Most systems wanted to go to full feature phase based on
default login values rather than actually engage in negotiation.

Set of 20 points were posted to mailing list, most have been dealt with
(e.g., strings are null-terminated, not null-separated).

CmdSN/StatSN increment at once, not after completion of Login.
[[NOTE: There may have been other items that are missing from my notes.]]

Resolved on list - can Initiator stop short of max amount of unsolicited
data?
	A: Initiator can do what it wants.

Open Issue - Simplification of Login.  Separate security sub-phase,
OpParamReset.
	Can operational parameters be exchanged before security phase?

[[ There may be some things missing here. ]]

Login needs state diagram, specification of legal combinations and
sequences.

At least one implementation did perform error recovery.

-- iSCSI Login - Julian Satran, IBM

Login Structure: Lots of parameters.  List request for two phases - the two
phases
	are currently implicit, separated by SecurityContextComplete.

Design concern is minimizing number of handshakes, not minimizing
programming
	complexity.
Comments from audience that simpler is better.  Complex things tend to have
complex
	failure modes.  Need to be careful about adding too many new
handshakes.

Julian's Proposals:  (1) SecurityContextComplete by itself in message
exchange.
		         (2) Should always have a security exchange.
                     (3) Both phases explicit but optional.

Discussion: Need a much more structured description.  Has too much branching
	complexity at the moment.  Two separate phases with defined
transitions
	between them would help greatly.

Discussion of whether to use SecurityContextComplete key to indicate end of
	security phase vs. a byte in the command.  Direction is to keep
using the
	key.

The spec needs to include a state machine (and transition table), and a much
	more organized (e.g., in one place) description of the login
process.

State in the command would help make it clear.  The WG sense of the room was
that
	explicitly indicating the login state (e.g., in security or
operational
	negotiation phase) via state in the command was preferred to
requiring
	the participants to implicitly track the state (provides a check
that
	things are where the participant thinks they are).

-- iSCSI Security - David Black

I noted two important questions and answers:

(1) What about corporate firewalls?  Will they block ESP traffic.
A: If they do, have to sent iSCSI without ESP to the firewall.

(2) How does one get SPI values and keys from iSCSI negotiation into ESP?
A: Manual key interface, which most IPsec implementations have.

[[Notes are sketchy on this because I have a hard time taking notes and
	presenting at the same time.  Please add anything important.]]

-- IKE and IPsec - William Dixon, Microsoft

Preview of draft-aboba-ips-iscsi-security-00.txt.  See that draft (now
available).

-- Framing - Steph Bailey, Sandburst

All specification of framing mechanisms is being taken out of the main
	iSCSI draft and will reside in
draft-ietf-tsvwg-tcp-ulp-frame-00.txt.
	A -01 version should be coming in the near future.

Two framing mechanisms are described in that draft:

(1) Periodic Markers - modified receivers, but no modifications to sender's
	TCP stack.  Probabilistic bound on required buffering, but much less
than
	a window per active connection.  Hardware will be complex.

(2) PDU Alignment - modified receivers, modified senders to align PDUs to
TCP
	segments.  Cleanly bounded buffering, unless alignment fails.
Modifications
	to TCP are needed to detect a middlebox that has resegmented and
destroyed
	alignment.

Each mechanism is applicable to different situations, hence both are in the
	tsvwg draft.  Common interface to both mechanisms.

iSCSI recommendations:
	- Remove marker annex and refer to tsvwg draft
	- Define negotiation for PDU alignment
	- Strongly encourage PDU alignment implementation (SHOULD).

Summary of proposal on what iSCSI should require for framing:
	- Receivers can do nothing, PDU alignment, or all 3.  Marker impl.
requires
		PDU alignment framing
	- Senders should implement all 3, MUST implement markers.

	These don't match because want receivers to call the shots.  Markers
are
	easy to implement on send, hard to implement on receive.

It was not possible to obtain rough consensus in the room on this proposal
or
a revised version of it presented the following day.  Will have to be
resolved
on list starting from a reasonably detailed explanation of the rationale for
these requirements from the framing folks.

-- Error Recovery - Mallikarjun, HP

Reality is somewhere between "Trust but verify" and "can't trust transport".

Four levels of recovery - within-command, -connection, -session, and full
session
	recovery.  Only the last is required, others are options.

Command counting is needed for both ordering AND flow control.

Error recovery tools:
	- Header and Data digests
	- SNACK
	- Recovery R2T (negotiable)
	- Unsolicited NOP-IN (e.g., sequence fixup)
	- Retry (command replay, failover, and hole-plugging)

Topic 1: SNACK issues (slide 8)  Alternatives
	- Assign a CmdSN (deadlock issues)
	- Accept non-determinism [e.g., lost SNACK] (odds of loss are low)
	- Allow SNACK retransmit (may get data retransmit)
	- Define timer-based SNACK retransmit (Ouch!)
	- Drop SNACK
Seems to be important for tapes (partial I/O recovery).

Proposal: Keep SNACK, if we drop it we're betting on the TCP checksum
	(or the ESP MAC).  Problem with moderate rate of checksum failure
	to detect errors

------> Tuesday <---------

SNACK discussion centered on the need for iSCSI error recovery for
existing tape.  Some current tape devices do things that make SCSI
level recovery from a failed command impossible (e.g., send successful
completion to write command before actually writing to the tape).
There is a new tape command set in the works that will improve this
situation by using absolute block addressing for tapes rather than
the current relative addressing, but there's a need to deal with
existing tape devices.

Sense of the room - keep SNACK, keep it optional, keep it for existing
	tape because consequences of not having it are horrendous.

Topic 2 - Error Recovery levels, one key to say which level rather than
	key per type of recovery.  0 would be required recovery, 1-4 are
options
	up to command replay.

Sense of the room - Adopt hierarchical approach to error recovery
specification.
	Number of levels and order thereof to be worked out on list.

Mallikarjun will send paragraphs to list describing each level, what it does
over and above the one below it, and what features of iSCSI that it uses.
There was a comment that level 1 in Mallikarjun's chart may need to be a
MUST
to provide effective support for tape.  Needs to be discussed on the list.

--- Main Document - Julian Satran, IBM

NOP issue - NOP may close command window.  Proposed changes:
	- Remove P bit.  If there's data, DataSegment length indicates.
	- If task tag is valid, response is required (ITT valid = Initiator
		wants answer, TTT valid = Target wants answer, NOP-In cannot
		have both tags valid).
In addition, the I bit must be set when immediate data is present

Sense of room is to make these changes - objections should be sent to the
list.

Serialization Interlock; this is about being able to preserve
command ordering in the presence of things like a CHECK CONDITION
caused by a temporary queue full situation.  The T10 advice that ACA is
not the right solution has been accepted.  Julian will follow this up
with T10 at their September meeting.  The alternative appears to be to
use Unit Attention (which has changed in the past year to have properties
more useful in this situation) as it only affects a single initiator.

-- Simplification Ideas - David Black

Four proposals resulting from a solicitation for "radical simplification"
ideas
on the list.

1] Eliminate Multiple Connection sessions - no real interest in pursuing
this.
2] Login Templates - take up on list as part of general discussion of Login.
	This is about organizing all the login keys into a small number of
sets
	where if one key from the set is present, all the keys must be
present,
	and possibly requiring the keys to appear in a particular order.
3] Eliminate CRCs in favor of MACs - take up at interim meeting.
4] Eliminate Immediate data - take to list, at a minimum consider removing
	the ability to use both immediate and unsolicited data in the same
command.

-- Naming and Discovery - John Hufferd, IBM

Specification pieces of N&D are now in main document.  Want N&D to
	become an informational RFC.
Sense of Room - approve this direction, N&D draft to become an informational
RFC.

IQN Uniqueness.  This is about making sure that the new holder of a domain
name
doesn't define any iSCSI names that match ones defined by the old holder.
	Two choices:
	- Enterprise Number
	- Date (yyyy-mm)

The Area Director commented that IANA is not set up to handle a large number
of enterprise number allocation requests, making the second approach
preferable.

Sense of room - use date of assignment of domain name to naming authority.
	Details to be worked out and posted to list.

Case Sensitivity
	- Currently case-sensitive.  Now recommend NAMEPREP
case-insensitivity,
	draft-ietf-idn-nameprep-05.txt.  Use NAMEPREP in admin tools,
byte-wise
	compare in implementations.

The Area Director noted that the right thing to do was to allow the IDN WG
to standardize NAMEPREP.  If they abandon it, IPS could pick it up.

Sense of room - Wire format is NAMEPREP'ed names, receivers do bytewise
compare,
	admin tools MUST ensure that all names are in NAMEPREP format (i.e.,
	iSCSI implementations don't have to check this).

Send Targets issues - Bookmarks vs. Option 5 issue will go to the list.  N&D
team
	(Mark Bakke?) needs to generate summary of current alternatives to
start
	discussion.

Sense of room - "iscsi" target canonical name MUST NOT be used (reserved).

Issue of whether to include Alias support in protocol.  Room was
approximately
	evenly split on this, hence the issue was taken to the list, where
the
	first attempt to resolve it subsequently failed.  

-- iSNS - Josh Tseng, Nishan

Relationship of SLP and iSNS: SLP for discovery, iSNS for active management.

iSNS + SLP is better than SLP alone (SLP to discover iSNS, use iSNS
services).
Will work with SLP community to improve SLP.  SLP DA integrates will with
iSNS
server, providing centralized management of SLP discovery (can still use SLP
on wire).  Full integration with iSNS client on each iSCSI device improves
further (e.g., access list configuration).

iSNS open source will integrate with other databases, e.g. LDAP, MS Active
Directory

Sense of room to approve iSNS MIB as an official IPS WG work item - next
version
	will be an official WG draft (draft-ietf-ips-...).

-- SLP Discovery for iSCSI - Marjorie Krueger, HP

Document is getting close to done.  Recent changes were to add portal group
tags
	and describe unicast SLP.  SLP is moving from proposed to draft
standard.
	 RFC 3082 provides SLP notification (currently Experimental).

-- iSCSI MIB - Marjorie Kreuger, HP

UML is done, lots of counters have been discarded.  Is mostly consistent
with -07.

Need to get work started on SCSI MIB - volunteers should see Marj.

NOTE: did not take up SCSI model mapping to iSCSI - Marj will post
recommended
	rules and pointer to presentation to list.


From owner-ips@ece.cmu.edu  Thu Aug 23 14:42:26 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28992
	for <ips-archive@odin.ietf.org>; Thu, 23 Aug 2001 14:42:26 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7NI2gL11476
	for ips-outgoing; Thu, 23 Aug 2001 14:02:42 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7NI2ee11472
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 14:02:40 -0400 (EDT)
Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA18711; Thu, 23 Aug 2001 14:02:27 -0400 (EDT)
Message-ID: <3B854394.D7B9BCF@cisco.com>
Date: Thu, 23 Aug 2001 12:55:32 -0500
From: Mark Bakke <mbakke@cisco.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686)
X-Accept-Language: en, de
MIME-Version: 1.0
To: Jim Hafner <hafner@almaden.ibm.com>
CC: Black_David@emc.com, ips@ece.cmu.edu
Subject: Re: iSCSI: Proxies (was Security in iSCSI)
References: <OF47BAFD1A.1444AC27-ON88256AB1.006084FF@boulder.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

I agree with Jim.  Since an iSCSI initiator's discovery (or configuration)
of a set of targets makes use of address-independent iSCSI names, iSCSI
does not have the same problems implementing proxies as HTTP.  The
"proxy required" status code is unnecessary for the reasons that Jim
provided.

The only concession we do need to make a proxy or gateway work is the
one we already have, which is the separation of the header and data
CRC.  Since a proxy will almost certainly be the end-point for any
change in security environments between an initiator and a target,
attempting to create a "secure" end-to-end data integrity check will
probably not work anyway.

I also vote that we put a lid on this one.

--
Mark

Jim Hafner wrote:
> 
> David,
> 
> I entirely agree with all the points you make.  I have argued that there is
> in the current draft no definition of a proxy, no model for such things and
> only vague references to them.  I have even suggested that the term "proxy"
> and all related text be removed from the document (including the vague
> status code of "proxy required").
> 
> It turns out that for the purposes of iSCSI, proxies can be implemented
> without any change to the protocol (provided you have a fairly intelligent
> iSCSI-aware proxy).  All you need to do is have the actual target advertise
> (via th normal discovery mechanisms, like SLP, iSNS, admin, etc.) that it's
> network addresses are those of the proxy machine and only allow the actual
> proxy to make direct connection to the target (the target would not
> authenticate and allow login from any other source).  You get proxy
> function without any protocol changes.  Security is initiator to proxy (by
> the rules configured for that proxy) and proxy to target (by the rules
> configured for that proxy-target pair).  The rest is completely transparent
> to the protocol and to the host.   This description fits yours where the
> proxy participates in the security context directly.
> 
> If this model of proxy requires too much function in the proxy boxes, then
> we can revisit this issue latter in the iSCSI layer directly.  In the
> meantime, I vote (with you) that we put a lid on this issue of proxy (by
> removing the notion) and get on with completing the hard issues that are
> still on the table for basic operation.
> 
> Jim Hafner
> 
> Black_David@emc.com@ece.cmu.edu on 08/23/2001 10:14:30 am
> 
> Sent by:  owner-ips@ece.cmu.edu
> 
> To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> cc:
> Subject:  iSCSI: Proxies (was Security in iSCSI)
> 
> Julian,
> 
> > You seem to missing my main point. I am ready to take out the
> > table but not the general notion of a cryptographic digest.
> > To do the later I have to have the community understand that
> > their are left with no protocol provided means to authenticate
> > data that pass through iSCSI proxies.
> 
> Actually, I was hoping that you weren't going there.  Just when
> one thinks one has obtained a good understanding of a network
> technology/protocol/solution/etc., adding the notion of proxies
> is almost certain to restore the previous state of confusion.
> Multicast also has this property, but fortunately, I haven't
> seen anyone in the WG take any serious interest in it (and
> woe betide anyone who takes this as an invitation ;-) ).
> 
> My primary concern is one of schedule - if full support for
> proxies is a requirement for the first version of the iSCSI
> RFC, the schedule guesstimate I posted yesterday is probably
> optimistic by 6+ months.  Issues that come up in the area of
> proxies that will take a while to resolve will likely include:
> 
> - What's the right scope of proxy support?  How much
>      consideration for SCSI level proxies to which other
>      transports needs to be reflected in the iSCSI standard?
> - SCSI is not an end-to-end transport independent protocol.
>      T10 had the opportunity to go in this direction in the
>      SCSI GPP work) and chose not to do so. Extensive iSCSI
>      work on proxies risks running into SCSI architecture,
>      and our experience with ACA suggests that they'll take
>      a while to resolve.
> - Security interaction with proxies is a very complicated
>      subject.  IPsec and NATs is a well-known tarpit that
>      is finally getting resolved years later.  I hesitate
>      to promise that the iSCSI proxy issues will be significantly
>      simpler by comparison.
> - There is precedent for proxies adapting to the requirements
>      of protocols - TLS requires http proxies to accommodate
>      it rather than the other way around.  Whether proxies
>      should drive iSCSI security architecture or iSCSI
>      security architecture should drive proxy design will
>      at the minimum be fodder for serious debate.
> 
> If we want to get the iSCSI spec done in a reasonable timeframe,
> I suggest closing the lid on this Pandora's box labeled
> "proxies" and deferring serious work on iSCSI proxy support
> to a future revision.  The separate header and data CRCs are a
> useful step towards making life better for those who want to
> build proxies, but I hesitate to go much further in that
> direction, particularly in the area of security.  As things
> currently stand, one way to authenticate data passing through
> an iSCSI proxy is to have the iSCSI proxy participate in the
> authentication which seems like an acceptable situation (and
> one that has a straightforward security explanation).
> 
> Comments?
> 
> Thanks,
> --David
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054


From owner-ips@ece.cmu.edu  Thu Aug 23 14:42:27 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28995
	for <ips-archive@odin.ietf.org>; Thu, 23 Aug 2001 14:42:26 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7NIFQJ12236
	for ips-outgoing; Thu, 23 Aug 2001 14:15:26 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7NIFOe12232
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 14:15:24 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id UAA39348
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 20:15:18 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7NIFHs57408
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 20:15:17 +0200
Importance: Normal
Subject: Re: iSCSI - Change - Login/Text commands with the binary stage co	de
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFA761893E.BD56BDEA-ONC2256AB1.0063E4DB@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Thu, 23 Aug 2001 21:14:46 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 23/08/2001 21:15:17
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Stephen,

1.If the initiator goes away for a while and reboots and there was no
activity on the connections
the target may see a session alive (I am not sure that it has to appear on
the state diagram but maybe).

2.Again - I am not sure that the curent state diagram includes death of the
initiator

Julo

"Wheat, Stephen R" <stephen.r.wheat@intel.com>@ece.cmu.edu on 23-08-2001
19:58:34

Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  Re: iSCSI - Change - Login/Text commands with the binary stage co
      de



Julian,

1.3.6 ISID states that the target should check to see if the old session is
still active when a duplicate session is detected.

I have two questions, the second only if you answer in the affirmative on
the first ;^)

1. Is there a properly executed sequence of events (i.e., no coding error
on
the target side) where the session is not active, but the target hadn't
taken notice of it?  It appears this as a protocol-specified means to work
around a flaw in a target's implementation.  I interpret the state diagram
transitions as being atomic wrt other commands.  I.e., the last logout
would
result in the various transitions of the connection/session prior to the
initiator starting the session up again.  And the target would have
completed the transitions prior to handling a new session request.

2. If you answered (1) in the affirmative, then the word "Active" is not
consistent with the 6.3 Session State Diagram.  Does this mean the target
got lost, due to transport failures of any sort, in its transition from
Q3-to-Q2-to-Q1?  It sounds like the intent is to close the old session if
the session was in Q2 or Q4, presuming if it were in Q1,  it would not have
been found as a duplicate.

Stephen






From owner-ips@ece.cmu.edu  Thu Aug 23 14:44:44 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29087
	for <ips-archive@odin.ietf.org>; Thu, 23 Aug 2001 14:44:44 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7NHnRP10790
	for ips-outgoing; Thu, 23 Aug 2001 13:49:27 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7NHnOe10781
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 13:49:24 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA53830;
	Thu, 23 Aug 2001 13:47:10 -0400
Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7NHmvZ186206;
	Thu, 23 Aug 2001 11:48:57 -0600
Importance: Normal
Subject: Re: iSCSI: Proxies (was Security in iSCSI)
To: Black_David@emc.com
Cc: ips@ece.cmu.edu
From: "Jim Hafner" <hafner@almaden.ibm.com>
Date: Thu, 23 Aug 2001 10:48:54 -0700
Message-ID: <OF47BAFD1A.1444AC27-ON88256AB1.006084FF@boulder.ibm.com>
X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at
 08/23/2001 10:48:57 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


David,

I entirely agree with all the points you make.  I have argued that there is
in the current draft no definition of a proxy, no model for such things and
only vague references to them.  I have even suggested that the term "proxy"
and all related text be removed from the document (including the vague
status code of "proxy required").

It turns out that for the purposes of iSCSI, proxies can be implemented
without any change to the protocol (provided you have a fairly intelligent
iSCSI-aware proxy).  All you need to do is have the actual target advertise
(via th normal discovery mechanisms, like SLP, iSNS, admin, etc.) that it's
network addresses are those of the proxy machine and only allow the actual
proxy to make direct connection to the target (the target would not
authenticate and allow login from any other source).  You get proxy
function without any protocol changes.  Security is initiator to proxy (by
the rules configured for that proxy) and proxy to target (by the rules
configured for that proxy-target pair).  The rest is completely transparent
to the protocol and to the host.   This description fits yours where the
proxy participates in the security context directly.

If this model of proxy requires too much function in the proxy boxes, then
we can revisit this issue latter in the iSCSI layer directly.  In the
meantime, I vote (with you) that we put a lid on this issue of proxy (by
removing the notion) and get on with completing the hard issues that are
still on the table for basic operation.

Jim Hafner


Black_David@emc.com@ece.cmu.edu on 08/23/2001 10:14:30 am

Sent by:  owner-ips@ece.cmu.edu


To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
cc:
Subject:  iSCSI: Proxies (was Security in iSCSI)



Julian,

> You seem to missing my main point. I am ready to take out the
> table but not the general notion of a cryptographic digest.
> To do the later I have to have the community understand that
> their are left with no protocol provided means to authenticate
> data that pass through iSCSI proxies.

Actually, I was hoping that you weren't going there.  Just when
one thinks one has obtained a good understanding of a network
technology/protocol/solution/etc., adding the notion of proxies
is almost certain to restore the previous state of confusion.
Multicast also has this property, but fortunately, I haven't
seen anyone in the WG take any serious interest in it (and
woe betide anyone who takes this as an invitation ;-) ).

My primary concern is one of schedule - if full support for
proxies is a requirement for the first version of the iSCSI
RFC, the schedule guesstimate I posted yesterday is probably
optimistic by 6+ months.  Issues that come up in the area of
proxies that will take a while to resolve will likely include:

- What's the right scope of proxy support?  How much
     consideration for SCSI level proxies to which other
     transports needs to be reflected in the iSCSI standard?
- SCSI is not an end-to-end transport independent protocol.
     T10 had the opportunity to go in this direction in the
     SCSI GPP work) and chose not to do so. Extensive iSCSI
     work on proxies risks running into SCSI architecture,
     and our experience with ACA suggests that they'll take
     a while to resolve.
- Security interaction with proxies is a very complicated
     subject.  IPsec and NATs is a well-known tarpit that
     is finally getting resolved years later.  I hesitate
     to promise that the iSCSI proxy issues will be significantly
     simpler by comparison.
- There is precedent for proxies adapting to the requirements
     of protocols - TLS requires http proxies to accommodate
     it rather than the other way around.  Whether proxies
     should drive iSCSI security architecture or iSCSI
     security architecture should drive proxy design will
     at the minimum be fodder for serious debate.

If we want to get the iSCSI spec done in a reasonable timeframe,
I suggest closing the lid on this Pandora's box labeled
"proxies" and deferring serious work on iSCSI proxy support
to a future revision.  The separate header and data CRCs are a
useful step towards making life better for those who want to
build proxies, but I hesitate to go much further in that
direction, particularly in the area of security.  As things
currently stand, one way to authenticate data passing through
an iSCSI proxy is to have the iSCSI proxy participate in the
authentication which seems like an acceptable situation (and
one that has a straightforward security explanation).

Comments?

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------





From owner-ips@ece.cmu.edu  Thu Aug 23 14:51:19 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29170
	for <ips-archive@odin.ietf.org>; Thu, 23 Aug 2001 14:51:17 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7NHtIk11140
	for ips-outgoing; Thu, 23 Aug 2001 13:55:18 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7NHtGe11133
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 13:55:16 -0400 (EDT)
Received: from msgrel1t.cos.agilent.com (msgrel1t.cos.agilent.com [130.29.152.157])
	by msgbas1.cos.agilent.com (Postfix) with ESMTP
	id 3545A3F4; Thu, 23 Aug 2001 11:55:08 -0600 (MDT)
Received: from axandbh3.and.agilent.com (axandbh3.and.agilent.com [130.30.32.200])
	by msgrel1t.cos.agilent.com (Postfix) with ESMTP
	id 92B4B586; Thu, 23 Aug 2001 11:55:07 -0600 (MDT)
Received: by axandbh3.and.agilent.com with Internet Mail Service (5.5.2653.19)
	id <Q9419APP>; Thu, 23 Aug 2001 13:55:07 -0400
Message-ID: <FEEBE78C8360D411ACFD00D0B74779719A893D@xsj02.sjs.agilent.com>
From: "CAVANNA,VICENTE V (A-Roseville,ex1)" <vince_cavanna@agilent.com>
To: "'Douglas Otis'" <dotis@sanlight.net>,
        "CAVANNA,VICENTE V (A-Roseville,ex1)" <vince_cavanna@agilent.com>,
        "'Julian Satran'" <Julian_Satran@il.ibm.com>
Cc: "'Mark Bakke'" <mbakke@cisco.com>, ips@ece.cmu.edu,
        "'Steve Blightman'" <steve@alacritech.com>,
        "THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>
Subject: RE: iSCSI CRC: A CRC-checking example
Date: Thu, 23 Aug 2001 13:55:03 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Doug,

If the transmit side CRC generator used for the frame check sequence the
remainder of the polynomial division directly (without complementing) the
receiver-side CRC checker would be expected to end up with zeroes after
processing an error-free frame. Unfortunately the receiver side CRC checker
would also end up with zeroes after processing a frame whose only "errors"
are extra trailing zeroes. Thus this type of error would not be detected by
the CRC checker.

Note that the expected final state of the receiver-side CRC checker is
expected to be zero if hte remainder is not complemented even though both
transmit and receiver sides initialize their CRC register to 1s. It is the
operation of complementing the remainder that causes the receiver to have a
non-zero (but constant) ending state after processing an error-free frame.

If I understand you correctly, you have described another type of error that
would be undetected were the remainder not complemented. Whenever the
receiver CRC register is in its zero state (perhaps partially through a
packet) the receiver checker would be blind to extra zeroes inserted in the
packet at that point. I agree.

Again, the improved protection resulting from initializing the CRC to 1s and
complementing the remainder is not important for iSCSI because the packet
length can be checked independently but I suppose it is advantageous to do
things the ethernet way.


Vince

|-----Original Message-----
|From: Douglas Otis [mailto:dotis@sanlight.net]
|Sent: Wednesday, August 22, 2001 5:48 PM
|To: CAVANNA,VICENTE V (A-Roseville,ex1); 'Julian Satran'
|Cc: 'Mark Bakke'; ips@ece.cmu.edu; 'Steve Blightman'; THALER,PAT
|(A-Roseville,ex1)
|Subject: RE: iSCSI CRC: A CRC-checking example
|
|
|Vince,
|
|Thanks for the explanation and here is how I understand your 
|comments.  Even
|with the CRC unlikely to find zero as a stable state with the all ones
|initialization, in a rare event where a CRC value becomes zero over a
|trailing list of zeros, then an inverted CRC store will create 
|an all ones
|as an ending value.  This is to better ensure detection of the 
|end of the
|block as there are encoding changes that help the underlying decoding
|process.  It would seem that there is still the requirement to 
|know the end
|of the frame regardless of the CRC value but there may be an 
|advantage to
|this encoding change.  Again, thanks.
|
|Doug
|
|
|> In answer to Doug's question about the reason for using the 
|COMPLEMENT of
|> the remainder of the division as the CRC ....
|>
|> One reason I recall, is that this method permits the 
|receiver to detect
|> extra trailing zeroes in the protected packet. If the 
|remainder were sent
|> directly as the CRC, in the absence of errors the remainder 
|of a similar
|> computation at the receiver would be expected to be zero. 
|This means that
|> errors consisting of extra trailing zeroes would not be 
|caught since zero
|> input bits would cause no changes in the CRC circuit once 
|the CRC register
|> is in the so called "inaccessible state" consisting of all zeroes.
|


From owner-ips@ece.cmu.edu  Thu Aug 23 15:29:39 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29828
	for <ips-archive@odin.ietf.org>; Thu, 23 Aug 2001 15:29:38 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7NIufa14824
	for ips-outgoing; Thu, 23 Aug 2001 14:56:41 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7NIuee14820
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 14:56:40 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id UAA79702
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 20:56:33 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7NIuWN46070
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 20:56:32 +0200
Importance: Normal
Subject: Re: iSCSI: CmdSN in Login-retry
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF0F9B4CA5.DA2B63C9-ONC2256AB1.00672B8D@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Thu, 23 Aug 2001 21:55:02 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 23/08/2001 21:56:32
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Stephen,

Your question IS more relevant than the security digest.

I am not sure that we ever envisioned retrying a Login.  (except completely
restarting it).
The only definite thing discussed  was that a failed Login should leave no
traces (no partial changes).

In 08 we intend to make Login a SHOULD be immediate (the 0 in immediate was
a typo - that I catched only when making it I).
That is already expressed in the change material I've sent out (including
text req/resp and login req/resp).

There are no scheduled phone calls except for some ongoing work on security
of which you are probably aware and updates of which appear on the list all
the time.

Julo



"Wheat, Stephen R" <stephen.r.wheat@intel.com>@ece.cmu.edu on 23-08-2001
20:50:08

Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  iSCSI: CmdSN in Login-retry



Hi Julian,

My questions pale in comparison to the very interesting security digest
debate.  BTW, I hope David's Pandora's box does stay closed for 1.0.

Section 7.1 states that a Retry command MUST use the original CmdSN.  This
doesn't make sense for a Login Retry.

Is there an exception here?  If not, please briefly explain the logic of a
Login Retry having the original CmdSN.

How does this enter into the debate on whether Login and Login-Text
messages
should be sent Immediate?  Has consensus been met on that yet?

BTW, is there an occasional forum where several people meet to thrash out
subtle details, or is this the only forum for questions, tiny and big?
Obviously people can meet FTF or on the phone whenever they want, but is
there a scheduled forum?

Thanks,
Stephen





From owner-ips@ece.cmu.edu  Thu Aug 23 15:29:53 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29839
	for <ips-archive@odin.ietf.org>; Thu, 23 Aug 2001 15:29:51 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7NIMaW12651
	for ips-outgoing; Thu, 23 Aug 2001 14:22:36 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7NIMYe12646
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 14:22:35 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id UAA45046
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 20:22:28 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7NIMRs140874
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 20:22:28 +0200
Importance: Normal
Subject: Re: iSCSI: Proxies (was Security in iSCSI)
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF1C549F1A.E0D48397-ONC2256AB1.00645FA7@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Thu, 23 Aug 2001 21:21:57 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 23/08/2001 21:22:27
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

David,

I agree with every point you make wholeheartedly and I thing that we should
not have
had to deal with them to begin with. But I want this decision to be stated
as clear as possible
and not become an issue for a long debate at the last call.
Your change of subject line goes  in this direction.

Julo

Black_David@emc.com on 23-08-2001 20:14:30

Please respond to Black_David@emc.com

To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
cc:
Subject:  iSCSI: Proxies (was Security in iSCSI)



Julian,

> You seem to missing my main point. I am ready to take out the
> table but not the general notion of a cryptographic digest.
> To do the later I have to have the community understand that
> their are left with no protocol provided means to authenticate
> data that pass through iSCSI proxies.

Actually, I was hoping that you weren't going there.  Just when
one thinks one has obtained a good understanding of a network
technology/protocol/solution/etc., adding the notion of proxies
is almost certain to restore the previous state of confusion.
Multicast also has this property, but fortunately, I haven't
seen anyone in the WG take any serious interest in it (and
woe betide anyone who takes this as an invitation ;-) ).

My primary concern is one of schedule - if full support for
proxies is a requirement for the first version of the iSCSI
RFC, the schedule guesstimate I posted yesterday is probably
optimistic by 6+ months.  Issues that come up in the area of
proxies that will take a while to resolve will likely include:

- What's the right scope of proxy support?  How much
     consideration for SCSI level proxies to which other
     transports needs to be reflected in the iSCSI standard?
- SCSI is not an end-to-end transport independent protocol.
     T10 had the opportunity to go in this direction in the
     SCSI GPP work) and chose not to do so. Extensive iSCSI
     work on proxies risks running into SCSI architecture,
     and our experience with ACA suggests that they'll take
     a while to resolve.
- Security interaction with proxies is a very complicated
     subject.  IPsec and NATs is a well-known tarpit that
     is finally getting resolved years later.  I hesitate
     to promise that the iSCSI proxy issues will be significantly
     simpler by comparison.
- There is precedent for proxies adapting to the requirements
     of protocols - TLS requires http proxies to accommodate
     it rather than the other way around.  Whether proxies
     should drive iSCSI security architecture or iSCSI
     security architecture should drive proxy design will
     at the minimum be fodder for serious debate.

If we want to get the iSCSI spec done in a reasonable timeframe,
I suggest closing the lid on this Pandora's box labeled
"proxies" and deferring serious work on iSCSI proxy support
to a future revision.  The separate header and data CRCs are a
useful step towards making life better for those who want to
build proxies, but I hesitate to go much further in that
direction, particularly in the area of security.  As things
currently stand, one way to authenticate data passing through
an iSCSI proxy is to have the iSCSI proxy participate in the
authentication which seems like an acceptable situation (and
one that has a straightforward security explanation).

Comments?

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------





From owner-ips@ece.cmu.edu  Thu Aug 23 15:58:05 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00350
	for <ips-archive@odin.ietf.org>; Thu, 23 Aug 2001 15:57:59 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7NJ7Nl15409
	for ips-outgoing; Thu, 23 Aug 2001 15:07:23 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7NJ7Je15403
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 15:07:19 -0400 (EDT)
Received: by ATLOPS with Internet Mail Service (5.5.2448.0)
	id <QMJCNF2P>; Thu, 23 Aug 2001 15:07:13 -0400
Message-ID: <25369470B6F0D41194820002B328BDD2116251@ATLOPS>
From: Sanjay Goyal <sanjay_goyal@ivivity.com>
To: "'CAVANNA,VICENTE V (A-Roseville,ex1)'" <vince_cavanna@agilent.com>
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI CRC: A CRC-checking example
Date: Thu, 23 Aug 2001 15:07:03 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

The last line says
 "but I suppose it is advantageous to do
things the ethernet way."
May I know in what ways it would be advantageous.

Regards
Sanjay Goyal

 

-----Original Message-----
From: CAVANNA,VICENTE V (A-Roseville,ex1)
[mailto:vince_cavanna@agilent.com]
Sent: Thursday, August 23, 2001 1:55 PM
To: 'Douglas Otis'; CAVANNA,VICENTE V (A-Roseville,ex1); 'Julian Satran'
Cc: 'Mark Bakke'; ips@ece.cmu.edu; 'Steve Blightman'; THALER,PAT
(A-Roseville,ex1)
Subject: RE: iSCSI CRC: A CRC-checking example


Doug,

If the transmit side CRC generator used for the frame check sequence the
remainder of the polynomial division directly (without complementing) the
receiver-side CRC checker would be expected to end up with zeroes after
processing an error-free frame. Unfortunately the receiver side CRC checker
would also end up with zeroes after processing a frame whose only "errors"
are extra trailing zeroes. Thus this type of error would not be detected by
the CRC checker.

Note that the expected final state of the receiver-side CRC checker is
expected to be zero if hte remainder is not complemented even though both
transmit and receiver sides initialize their CRC register to 1s. It is the
operation of complementing the remainder that causes the receiver to have a
non-zero (but constant) ending state after processing an error-free frame.

If I understand you correctly, you have described another type of error that
would be undetected were the remainder not complemented. Whenever the
receiver CRC register is in its zero state (perhaps partially through a
packet) the receiver checker would be blind to extra zeroes inserted in the
packet at that point. I agree.

Again, the improved protection resulting from initializing the CRC to 1s and
complementing the remainder is not important for iSCSI because the packet
length can be checked independently but I suppose it is advantageous to do
things the ethernet way.


Vince

|-----Original Message-----
|From: Douglas Otis [mailto:dotis@sanlight.net]
|Sent: Wednesday, August 22, 2001 5:48 PM
|To: CAVANNA,VICENTE V (A-Roseville,ex1); 'Julian Satran'
|Cc: 'Mark Bakke'; ips@ece.cmu.edu; 'Steve Blightman'; THALER,PAT
|(A-Roseville,ex1)
|Subject: RE: iSCSI CRC: A CRC-checking example
|
|
|Vince,
|
|Thanks for the explanation and here is how I understand your 
|comments.  Even
|with the CRC unlikely to find zero as a stable state with the all ones
|initialization, in a rare event where a CRC value becomes zero over a
|trailing list of zeros, then an inverted CRC store will create 
|an all ones
|as an ending value.  This is to better ensure detection of the 
|end of the
|block as there are encoding changes that help the underlying decoding
|process.  It would seem that there is still the requirement to 
|know the end
|of the frame regardless of the CRC value but there may be an 
|advantage to
|this encoding change.  Again, thanks.
|
|Doug
|
|
|> In answer to Doug's question about the reason for using the 
|COMPLEMENT of
|> the remainder of the division as the CRC ....
|>
|> One reason I recall, is that this method permits the 
|receiver to detect
|> extra trailing zeroes in the protected packet. If the 
|remainder were sent
|> directly as the CRC, in the absence of errors the remainder 
|of a similar
|> computation at the receiver would be expected to be zero. 
|This means that
|> errors consisting of extra trailing zeroes would not be 
|caught since zero
|> input bits would cause no changes in the CRC circuit once 
|the CRC register
|> is in the so called "inaccessible state" consisting of all zeroes.
|


From owner-ips@ece.cmu.edu  Thu Aug 23 16:13:23 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00620
	for <ips-archive@odin.ietf.org>; Thu, 23 Aug 2001 16:13:21 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7NIp5714463
	for ips-outgoing; Thu, 23 Aug 2001 14:51:05 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7NIp2e14458
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 14:51:02 -0400 (EDT)
Received: from xparelay2.corp.hp.com (unknown [15.58.137.112])
	by palrel1.hp.com (Postfix) with ESMTP id C63591A9F
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 11:51:01 -0700 (PDT)
Received: from xpabh1.corp.hp.com (xpabh1.corp.hp.com [15.58.136.191])
	by xparelay2.corp.hp.com (Postfix) with ESMTP id 6F53D1F519
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 11:51:01 -0700 (PDT)
Received: by xpabh1.corp.hp.com with Internet Mail Service (5.5.2653.19)
	id <QVBAWFHX>; Thu, 23 Aug 2001 11:51:01 -0700
Message-ID: <6BD67FFB937FD411A04F00D0B74FE87802A0926F@xrose06.rose.hp.com>
From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
To: ips@ece.cmu.edu
Subject: RE: iSCSI: Proxies (was Security in iSCSI)
Date: Thu, 23 Aug 2001 11:51:00 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Is this a call for concensus on removing references to proxies (except where
pertaining to digests) and deferring any discussion of proxy issues until
after the draft is complete?

If so, I agree it's the right thing to do. (I agree w/Jim)

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: marjorie_krueger@hp.com 

> -----Original Message-----
> From: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Thursday, August 23, 2001 10:15 AM
> To: Julian_Satran@il.ibm.com; ips@ece.cmu.edu
> Subject: iSCSI: Proxies (was Security in iSCSI)
> 
> 
> Julian,
> 
> > You seem to missing my main point. I am ready to take out the
> > table but not the general notion of a cryptographic digest.
> > To do the later I have to have the community understand that 
> > their are left with no protocol provided means to authenticate
> > data that pass through iSCSI proxies.
> 
> Actually, I was hoping that you weren't going there.  Just when
> one thinks one has obtained a good understanding of a network
> technology/protocol/solution/etc., adding the notion of proxies
> is almost certain to restore the previous state of confusion.
> Multicast also has this property, but fortunately, I haven't
> seen anyone in the WG take any serious interest in it (and
> woe betide anyone who takes this as an invitation ;-) ).
> 
> My primary concern is one of schedule - if full support for
> proxies is a requirement for the first version of the iSCSI
> RFC, the schedule guesstimate I posted yesterday is probably
> optimistic by 6+ months.  Issues that come up in the area of
> proxies that will take a while to resolve will likely include:
> 
> - What's the right scope of proxy support?  How much
> 	consideration for SCSI level proxies to which other
> 	transports needs to be reflected in the iSCSI standard?
> - SCSI is not an end-to-end transport independent protocol.
> 	T10 had the opportunity to go in this direction in the
> 	SCSI GPP work) and chose not to do so. Extensive iSCSI
> 	work on proxies risks running into SCSI architecture,
> 	and our experience with ACA suggests that they'll take
> 	a while to resolve.
> - Security interaction with proxies is a very complicated
> 	subject.  IPsec and NATs is a well-known tarpit that
> 	is finally getting resolved years later.  I hesitate
> 	to promise that the iSCSI proxy issues will be significantly
> 	simpler by comparison.
> - There is precedent for proxies adapting to the requirements
> 	of protocols - TLS requires http proxies to accommodate
> 	it rather than the other way around.  Whether proxies
> 	should drive iSCSI security architecture or iSCSI
> 	security architecture should drive proxy design will
> 	at the minimum be fodder for serious debate.
> 
> If we want to get the iSCSI spec done in a reasonable timeframe,
> I suggest closing the lid on this Pandora's box labeled
> "proxies" and deferring serious work on iSCSI proxy support
> to a future revision.  The separate header and data CRCs are a
> useful step towards making life better for those who want to
> build proxies, but I hesitate to go much further in that
> direction, particularly in the area of security.  As things
> currently stand, one way to authenticate data passing through
> an iSCSI proxy is to have the iSCSI proxy participate in the
> authentication which seems like an acceptable situation (and
> one that has a straightforward security explanation).
> 
> Comments?
> 
> Thanks,
> --David
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------
> 


From owner-ips@ece.cmu.edu  Thu Aug 23 16:15:40 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00684
	for <ips-archive@odin.ietf.org>; Thu, 23 Aug 2001 16:15:38 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7NJLdG16271
	for ips-outgoing; Thu, 23 Aug 2001 15:21:39 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7NJLae16261
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 15:21:36 -0400 (EDT)
Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA14117; Thu, 23 Aug 2001 15:21:29 -0400 (EDT)
Message-ID: <3B855619.637C201@cisco.com>
Date: Thu, 23 Aug 2001 14:14:33 -0500
From: Mark Bakke <mbakke@cisco.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686)
X-Accept-Language: en, de
MIME-Version: 1.0
To: Jim Hafner <hafner@almaden.ibm.com>, ips@ece.cmu.edu
Subject: Re: iSCSI: Status'es (clause 2.11.6)
References: <OF55314842.211D8AD6-ON88256A94.00648923@boulder.ibm.com> <3B7C2F49.4D52E75A@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


I have not seen any responses other than from Julian and
Jim on the status codes, so I assume that we can go ahead
and make these modifications.

I had proposed five 030x status codes before; Julian was
concerned that these were getting to be too fine-grained,
and I think he's right.  I plan to change the 030x status
codes to:

0300 - Target Error - Target hardware or software error

0301 - Unavailable - The target is not operational

We can keep 0302 the way it is, and delete the 0303, 0304,
and 0305 I had added below.

--
Mark


Mark Bakke wrote:
> 
> Jim and I talked on the phone about this, and here's pretty
> much what we came up with for status code changes.
> 
> After thinking about the Proxy Required message, I agree that
> we no longer need it.  Since all iSCSI targets have unique
> names, which are not tied to addresses as in HTTP, the client
> does not need to be aware of a proxy for it to work.
> 
> Also, since the main definition of the 030X codes is "my bad"
> from the target's point of view, and 020X is "your bad", this
> means that login requests causing an 030X should be re-tryable
> by the initiator at some point in the future, and that 020X
> requests won't get anywhere if they keep trying.  This caused
> us to want to move a few status codes around.
> 
> So here are some proposed changes to the iSCSI status codes
> that should clean things up:
> 
> In the status class definitions, add the following sentence
> to "2 - Initiator error":
> 
>   The request should not be tried again as-is.
> 
> And change "3 - Target Error" to:
> 
>   indicates that the target sees no errors in the initiator's
>   login request, but is currently incapable of fulfilling the
>   requesst.  The client may re-try the same login request at
>   a later time.
> 
> Remove code 0103 "Proxy Required".
> 
> Rename 0201 "Security Negotiation Failed" to "Authentication Failure".
> 
>   Change its description to:
> 
>   The initiator could not be successfully authenticated by the target.
> 
> Rename 0202 "Forbidden Target" to "Authorization Failure".
> 
>   Change its description to:
> 
>   The initiator was authenticated, but is not authorized to access
>   the target.
> 
> Remove 0205 "Target Conflict".
> 
>   This one had specified that the target would not accept another
>   connection, but since this may be a temporary and re-tryable
>   condition, it should really belong in the 0300s.
> 
> Move 0302 "Unsupported Version" to 0205, since this is not a login
> request that the client has any hope of re-trying, so it belongs
> in the 0200s.
> 
> Add new 030X codes to be somewhat more precise as to the reason
> the target might be unavailable.
> 
> 0300 - Target Error - Miscellaneous target error
> 
> 0301 - Service Unavailable - The current target is not operational.
> 
> 0302 - Out of Resources - The target currently has insufficient
> connection or session resources.
> 
> 0303 - Not Ready - The target is not yet ready to accept connections.
> 
> 0304 - Software Failure - The target has experienced a software
> failure.
> 
> 0305 - Hardware Failure - The target has experienced a hardware
> failure.
> 
> Note that none of the 030X status codes should require different
> treatment; they are mainly broken out to allow the client to
> complain more precisely to its user or administrator.
> 
> --
> Mark
> 
> Jim Hafner wrote:
> >
> > Mark,
> >
> > Comments in line.  But for closure on some things and to tagged the still
> > open issues, I'll summarize my comments.
> >
> > There are three independent issues (and a few minor ones I'll skip):
> > 1) Proxy Required - I think this is just a placeholder and need not be
> > there -- save it for generation 2 (still open).
> > 2) Security Negotiation Failed and Forbidden Target - thanks for the
> > clarification, I think I like the name changes (closed)
> > 3) Target Conflict - what about "n->n+1" -- we have no status code for
> > that.  I suggest alternate names for this and that it cover not just the
> > 1->2 problem but the n->n+1 (still open).
> >
> > All other issues are agreed.
> >
> > Jim Hafner
> >
> > Mark Bakke <mbakke@cisco.com>@ece.cmu.edu on 07-25-2001 08:53:23 AM
> >
> > Sent by:  owner-ips@ece.cmu.edu
> >
> > To:   Jim Hafner/Almaden/IBM@IBMUS
> > cc:   ips@ece.cmu.edu
> > Subject:  Re: iSCSI: Status'es (clause 2.11.6)
> >
> > Jim-
> >
> > Comments are below.
> >
> > --
> > Mark
> >
> > Jim Hafner wrote:
> > >
> > > Folks,
> > >
> > > I have some questions, recommendations and editorial comments about the
> > > status codes for iSCSI in clause 2.11.6.
> > >
> > > Proxy Required is defined as the response when "the initiator must use an
> > > ISCSI proxy for this target".  But that isn't defined anywhere in the
> > > document, so I recommend deleting this status code.
> >
> > We should define this, then.  If a target is accessible only through
> > an iSCSI proxy, perhaps for security purposes, an initiator attempting
> > to log in to it directly should get an error.  If the target is aware
> > of the proxy, it can return the proxy's address in this type of redirect
> > response.  This is similar to what was done in HTTP/1.1.
> > <JLH>
> > If the target is aware of this (undefined) thing, then a simple redirect
> > would suffice and we don't need the status code.  If the target is not
> > aware, then how can it know to return this status code?   Does it just know
> > that there should be one but doesn't know the address?  How can it know
> > whether to accept the login from any old initiator vs the initiator that
> > lives in the proxy?  It will be configured (I assume) to allow login by the
> > proxy and reject all other logins.  It doesn't really help the initiator to
> > get back "can't login in here, use a proxy but it's up to you (the
> > initiator) to find the right address".
> >
> > Until we define this, I strongly suggest we take it out the status code --
> > it adds no value to the protocol.  We can't have placeholders for things
> > that are undefined (except perhaps reserved values or keywords).   You
> > clearly have an idea in your mind of what an iSCSI Proxy is, but I searched
> > for "proxy" in the document and the ONLY occurrances are in this clause.
> >
> > My suggestion then is (a) take it out for now (and reserve the code value)
> > and (b) table the whole definition/description/model, etc for an iSCSI
> > proxy is to "iSCSI-the sequel".   I expect that this will be a complex
> > issue (as I've hinted at above), and I don't want it to delay this draft.
> > </JLH>
> >
> > Although this status code likely won't be used right away, it does
> > have utility long-term when we start building larger storage networks
> > with this stuff.  I still don't believe that all iSCSI devices will
> > provide all of their own security code; other devices may have to
> > provide this on their behalf, which was why we had added iSCSI proxy
> > capabilities in the first place.
> > <JLH>
> > This is yet to be proven and in the meantime, we don't need the
> > placeholder.
> > </JLH>
> >
> > > What's the functional difference between the following: "Security
> > > negotiation failed" and "Forbidden Target"?  In both cases, the initiator
> > > doesn't get to use what it thinks is there.  I would think that
> > "Forbidden
> > > Target" might be a security leak as it admits the fact that the target is
> > > there, whereas if the initiator only got back failed security, that
> > > admission wouldn't be made.
> >
> > Security Negotiation Failed means that the initiator could not
> > be successfully authenticated.
> >
> > Forbidden Target means that the initiator was authenticated, but
> > is not authorized to access the target.
> >
> > These are two different reasons for an initiator not to be able
> > to get to a target, and would more useful to someone configuring
> > an initiator than simply returning "not found".
> >
> > Keep in mind that when returning Forbidden Target, the initiator
> > has been authenticated, so it's likely to be somewhere within
> > the realm of things that the target trusts.  If the target wants
> > to be more tight-lipped about this one, it could certainly return
> > "Not Found" instead.  This adds a bit more security at the expense
> > of making it easier to troubleshoot a mis-configured initiator.
> >
> > The names for these two status codes are perhaps a bit clumsy; perhaps
> > renaming them will help.  How about:
> >
> > Authentication Failure instead of Security Negotiation Failed
> >
> > and
> >
> > Authorization Failure instead of Forbidden Target?
> >
> > <JLH>
> > Thanks for the explanation.  I can live with this; the alternative wording
> > might be more clear.
> > </JLH>
> >
> > > "Target Conflict" and "Service Unavailable" both look more like
> > > "insufficient resources".  In particular, "Target Conflict" should not be
> > > limited to a response in the 1->2 or more initiators case but in the
> > n->n+1
> > > initiators case.  That is, if the target has resources for 'n' logins, it
> > > can reject another login with "insufficient resources", whether n=1 or
> > > n=10.   So, I'd suggest that "insufficient resources" is a better
> > catch-all
> > > for both of these cases.
> >
> > We had this discussion on the list a long time ago.  Target Conflict
> > is the initiator's problem; it should not be asking to connect to
> > a target that someone else is using (assuming it supports only one
> > initiator at a time).  Service Unavailable is the target's problem;
> > it is used when the target is not working at all.
> >
> > <JLH>
> > Apologies if I didn't follow or absorb all of that previous thread.
> >
> > I can see the subtle difference between Target Conflict and Service
> > Unavailable.  But what do we do if the target supports "n" logins (only)
> > and an "n+1" guy tries to login?  We have no status code for that.  I also
> > don't see how the name "Target Conflict" carries the meaning you want.  I
> > would suggest "Insufficient Login Resources" or "Target In Use" and use
> > this for anytime the target can't support an additional login (either from
> > 1 to 2 or from n to n+1).
> > </JLH>
> >
> > > We need to clarify the "Session already open" to include language that
> > says
> > > "with this initiator to this target portal group".
> >
> > Agree.
> >
> > > The sentence immediately after the table says that "accept" means the
> > > initiator may proceed to issue SCSI commands.  This is only true in a
> > > Normal session type and is not true for the Discovery session type.  This
> > > should be clarified.
> >
> > Agree here, too.
> >
> > > Jim Hafner
> >
> > --
> > Mark A. Bakke
> > Cisco Systems
> > mbakke@cisco.com
> > 763.398.1054
> 
> --
> Mark A. Bakke
> Cisco Systems
> mbakke@cisco.com
> 763.398.1054

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054


From owner-ips@ece.cmu.edu  Thu Aug 23 17:08:08 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01706
	for <ips-archive@odin.ietf.org>; Thu, 23 Aug 2001 17:08:06 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7NKL2u25620
	for ips-outgoing; Thu, 23 Aug 2001 16:21:02 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7MG0ee03642
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 12:00:40 -0400 (EDT)
Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35])
	by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id JAA21250;
	Wed, 22 Aug 2001 09:00:30 -0700 (PDT)
Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19)
	id <Q8DQ6G35>; Wed, 22 Aug 2001 09:00:29 -0700
Message-ID: <FFD40DB4943CD411876500508BAD02790380023A@sj5-ex2.brocade.com>
From: Robert Snively <rsnively@Brocade.COM>
To: Tow Wang <Tow_Wang@adaptec.com>,
        "'Julian Satran'"
	 <Julian_Satran@il.ibm.com>
Cc: "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
Subject: RE: Target record not to span PDUs?
Date: Wed, 22 Aug 2001 09:00:18 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

It sounds like there may be some confusion between "physical 
data unit" (the TCP/IP frame) and "iSCSI Protocol Data Unit" 
(the messaging unit for iSCSI).  I cannot see where Tom's 
problem arises, since Protocol Data Units are very well 
behaved and should not have the problems he is discussing. 
You cannot complete Protocol Data Unit processing until you
know you have all of them and that useful information does not
span them.  The assembly of protocol data units into useful
complete messages should be done at a layer below that where
you interpret the contiguous bytes of data in the context of
the complete messages.  I think as a general rule that any
iSCSI action should be able to span PDUs, including the 
Target Record.

Bob 

> -----Original Message-----
> From: Tow Wang [mailto:Tow_Wang@adaptec.com]
> Sent: Tuesday, August 21, 2001 7:07 PM
> To: 'Julian Satran'
> Cc: 'ips@ece.cmu.edu'
> Subject: Target record not to span PDUs?
> 
> 
> Julian (and all):
> 
> Hello. This is regarding draft 07; could we require that 
> target records NOT span across
> PDU's if a text response for SendTargets is very long? Upon 
> reading appendix E, it seems
> that a response (of 4096 bytes in length) could end with:
> 
> [Begin data segment]
> ...
> TargetName=I.got.chopped.4096
> TargetAddress=10.1.1.45
> [End data segment]
> 
> In the above case, one could not determine whether the 
> address is IP V4 or V6. Even if it
> had had enough space to put in the whole address, port and 
> group tag, one cannot parse and
> process the record until inspecting the data segment of the 
> next text response PDU, and
> this would involve cumulative buffering, back-parsing, etc. I 
> think the above complexity
> could be avoided, as I can't imagine any single record 
> exceeding 4096 bytes in length.
> 
> Tow Wang
> 
> 


From owner-ips@ece.cmu.edu  Thu Aug 23 17:08:10 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01717
	for <ips-archive@odin.ietf.org>; Thu, 23 Aug 2001 17:08:10 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7NJv8t21732
	for ips-outgoing; Thu, 23 Aug 2001 15:57:08 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from ganymede.or.intel.com (jffdns01.or.intel.com [134.134.248.3])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7NJv5e21723
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 15:57:05 -0400 (EDT)
Received: from SMTP (orsmsxvs02-1.jf.intel.com [192.168.65.201])
	by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id TAA10087;
	Thu, 23 Aug 2001 19:56:57 GMT
Received: from orsmsx26.jf.intel.com ([192.168.70.26]) by 192.168.70.201
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Thu, 23 Aug 2001 19:56:57 0000 (GMT)
Received: by orsmsx26.jf.intel.com with Internet Mail Service (5.5.2653.19)
	id <RN8Y6P9Q>; Thu, 23 Aug 2001 12:56:55 -0700
Message-ID: <638EC1B28663D211AC3E00A0C96B78A80B7B5EF6@orsmsx40.jf.intel.com>
From: "Wheat, Stephen R" <stephen.r.wheat@intel.com>
To: Julian Satran <Julian_Satran@il.ibm.com>, ips@ece.cmu.edu
Subject: RE: iSCSI - Change - Login/Text commands with the binary stage co
		de
Date: Thu, 23 Aug 2001 12:50:56 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Julian,

I don't understand your answer.  For the scenario given, I would presume
then that the target would reject the new session attempt, as it sees the
previous session still "alive".  What is there to tell the target that this
is any different from when the Initiator is erroneously using the repetitive
session id?

Thanks,
Stephen

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, August 23, 2001 11:15 AM
To: ips@ece.cmu.edu
Subject: Re: iSCSI - Change - Login/Text commands with the binary stage
co de


Stephen,

1.If the initiator goes away for a while and reboots and there was no
activity on the connections
the target may see a session alive (I am not sure that it has to appear on
the state diagram but maybe).

2.Again - I am not sure that the curent state diagram includes death of the
initiator

Julo

"Wheat, Stephen R" <stephen.r.wheat@intel.com>@ece.cmu.edu on 23-08-2001
19:58:34

Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  Re: iSCSI - Change - Login/Text commands with the binary stage co
      de



Julian,

1.3.6 ISID states that the target should check to see if the old session is
still active when a duplicate session is detected.

I have two questions, the second only if you answer in the affirmative on
the first ;^)

1. Is there a properly executed sequence of events (i.e., no coding error
on
the target side) where the session is not active, but the target hadn't
taken notice of it?  It appears this as a protocol-specified means to work
around a flaw in a target's implementation.  I interpret the state diagram
transitions as being atomic wrt other commands.  I.e., the last logout
would
result in the various transitions of the connection/session prior to the
initiator starting the session up again.  And the target would have
completed the transitions prior to handling a new session request.

2. If you answered (1) in the affirmative, then the word "Active" is not
consistent with the 6.3 Session State Diagram.  Does this mean the target
got lost, due to transport failures of any sort, in its transition from
Q3-to-Q2-to-Q1?  It sounds like the intent is to close the old session if
the session was in Q2 or Q4, presuming if it were in Q1,  it would not have
been found as a duplicate.

Stephen






From owner-ips@ece.cmu.edu  Thu Aug 23 17:08:12 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01728
	for <ips-archive@odin.ietf.org>; Thu, 23 Aug 2001 17:08:12 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7NKQwp25962
	for ips-outgoing; Thu, 23 Aug 2001 16:26:58 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7MMSRe26670
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 18:28:27 -0400 (EDT)
Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35])
	by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id PAA25255;
	Wed, 22 Aug 2001 15:26:32 -0700 (PDT)
Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19)
	id <Q8DQ6Q6V>; Wed, 22 Aug 2001 15:26:31 -0700
Message-ID: <FFD40DB4943CD411876500508BAD027903800270@sj5-ex2.brocade.com>
From: Robert Snively <rsnively@Brocade.COM>
To: Robert Snively <rsnively@Brocade.COM>,
        "'ENDL_TX@computer.org'"
	 <ENDL_TX@computer.org>,
        "'Lamers, Larry'" <ljlamers@ieee.org>,
        Steve Wilson <swilson@Brocade.COM>,
        "'Neil Wanamaker'"
	 <nwanamaker@akara.com>,
        "'David Peterson'" <dap@cisco.com>,
        "'Rodriguez, Elizabeth'" <egrodriguez@lucent.com>,
        "'Murali Rajagopal'"
	 <muralir@lightsand.com>,
        "'Craig Carlson'" <craig.carlson@qlogic.com>,
        "'ghecht@gadzoox.com'" <ghecht@gadzoox.com>,
        "'khirata@vixel.com'"
	 <khirata@Vixel.com>,
        "'modonnell@mcdata.com'" <modonnell@mcdata.com>,
        "'rajb@lightsand.com'" <rajb@lightsand.com>,
        "'skipp@mcdata.com'"
	 <skipp@mcdata.com>,
        "'vchau@gadzoox.com'" <vchau@gadzoox.com>,
        "'mmerhar@Pirus.com'" <mmerhar@pirus.com>,
        "'venkat@rhapsodynetworks.com'" <venkat@rhapsodynetworks.com>,
        "'Don.Fraser@compaq.com'" <Don.Fraser@compaq.com>,
        "'sriramr@aarohi-inc.com'" <sriramr@aarohi-inc.com>,
        "'jim.nelson@vixel.com'" <jim.nelson@Vixel.com>,
        "'Anil Rijhsinghani'"
	 <anil.rijhsinghani@mcdata.com>,
        "'andyh@lightsand.com'"
	 <andyh@lightsand.com>
Cc: "Fibre Channel T11 reflector (E-mail)" <fc@network.com>,
        "IPS Reflector (E-mail)" <ips@ece.cmu.edu>
Subject: Draft minutes of the FCIP teleconference, 8/22/01
Date: Wed, 22 Aug 2001 15:26:24 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


1)  Administrative work

	All minutes will now be posted on the ips reflector.
	The PDF supporting documents will be posted on the web-site 
	www.t11.org referenced to the FC-BB-2 project.

2)  Discussion of security

	The Aboba document is apparently the principal choice for
	iSCSI security.  Larry will post the document to the authors.
	The iSCSI approach is to actually include ULP level
	security.  Our approach has been to use traditional
	IPSec level security underneath TCP/IP.

3)  FCIP_DE to FC Entity communication requirements
	
	Murali has provided a document that lists all the
	possible communications that may need to take place
	between the FCIP entity and the FC entity.  This would
	logically be in Annex D.  These are reminders about
	the communications that need to be performed, but they
	are not specifications of the communications.  These
	are not interoperability points.

   a) 6.6.2.2  Notification by FCIP_DE that packets are discarded.
			(accepted)  It was noted that these are not
			APIs.  There may be one indication for 
			the discard of multiple frames in a vendor
			specific manner.  
   b) 6.6.2.3  IP network transmit time cannot be determined.
			(this line will be removed, and rewriting may
			be needed)
   c) 6.6.2.3  FC frame encapsulation does not contain a valid
			time stamp.
			(accepted)
   d) 6.6.2.3  Synchronized time value is not well synchronized.
			(accepted)
   e) 7	   Maintaining synchronized time value
			(tells FCIP Entity not to stuff time value)
			(accepted)
   f) 7	   Unreliable time value is corrected
			(tells FCIP Entity to stuff time value)
			(accepted)
   g) 8.1.2    Request creation of TCP connection
			(accepted)
   h) 8.1.2    Creation is rejected
			(accepted)
   i) 8.1.2	   Creation of second connection is accepted
			(accepted)
   j) 8.1.3    Dynamic creation of new connection
			(accepted (4 items))
   k) 8.1.4    Processing of TCP Connect requests
			(accepted)  This one is already contained and
			needs to be modified in the table.
   l) 8.4      FC entity uses FC Flow control (accepted)
   m) 8.4	   FCIP entity uses TCP Flow control (accepted)
			Note that these may need some internal flow
			control mechanisms.  These are not specifically
			defined, but these are not interoperability 
			points.
   n) 10.1     Multiple TCP Connections within an FCIP_LEP
			(accepted)

   Murali noted that none of these are related to Fibre Channel.
   The distinction is not useful for implementation purposes.
   I don't think it will be a constructive exercise to try
   to move the boundaries.  One of the two documents will know
   more about the other.  At present, FC-BB-2 must be cognizant
   of the FCIP entity's behavior.  There was some work on
   this in Hawaii at the FC-BB-2 meeting.  Murali will study
   this possibility.  Routing is part of the issue.

4)  Discussion of security

   Don Fraser has started a discussion about some nits on the
   security stuff.

5)  Discussion of time server

   The FC fabric time server is an SNTP type time server.
   It was asked whether we should be using the IP or FC
   time server.  It was noted that the SNTP IP time server
   may or may not exist.  

6)  8.1.4 problem

   The acceptance of a connection.  The FCIP entity creates
   an FCIP_DE when a new connection is made.  This text is
   already included, and Murali accepted the resolution.
   Ralph indicated that an additional sentence was required to
   take care of this.

7)  B_Port definitions

   Can B_Ports get time services?  B_Ports really only work
   in constrained configurations where generic management is
   not required.

8)  SAN island interconnections

   Two SAN islands joined by a link may not be notified
   if the link fails.  The notification process needs to
   be included from the FCIP to the FC Entity.  FC procedures
   should be successful in recovering.  A LSR needs to be
   generated.  Note that loss of signal is not necessarily
   a symptom of a loss of TCP/IP continuity.  HELLO timers
   may be the ultimate catcher for this.  The longest latency
   between connections is on the order of 300 msec with satellites.

9) Next week's meeting

   Power will be provided
   Computer projectors will be provided
   Vi will provide an overhead projector
   The MIB meeting will be arranged for Monday evening.
   The next teleconference will be scheduled at the interim
   meeting next week.


ACTION ITEMS:

1)  Murali will study the possibility of modifying the
    boundary between FC and FCIP entities with a view toward
    simplifying the structure.  There is some skepticism that
    this will turn out helpful. 

2)  Ralph will add the correction required to 8.1.4.



Attendees:

Elizabeth Rodriguez		Lucent
Robert Snively			Brocade
Neil Wanamaker			Akara
Vi Chau				Gadzoox
Gaby Hecht				Gadzoox
Ralph Weber				ENDL Texas / Brocade
Dave Peterson			Cisco
Dan Fraser				Compaq
Venkat Rangan			Rhapsody Network
Andy Helland			LightSand
Anil Rijhsinghani			McData
Jim Nelson				Vixel
Ken Hirata				Vixel
Scott Kipp				McData
Raj Bhagwat				LightSand
Murali Rajagopal			LightSand
Larry Lamers			SANValley


From owner-ips@ece.cmu.edu  Thu Aug 23 17:09:50 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01781
	for <ips-archive@odin.ietf.org>; Thu, 23 Aug 2001 17:09:50 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7NKKs625603
	for ips-outgoing; Thu, 23 Aug 2001 16:20:54 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7MG0We03608
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 12:00:33 -0400 (EDT)
Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35])
	by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id JAA21225;
	Wed, 22 Aug 2001 09:00:19 -0700 (PDT)
Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19)
	id <Q8DQ6G3S>; Wed, 22 Aug 2001 09:00:19 -0700
Message-ID: <FFD40DB4943CD411876500508BAD027903800239@sj5-ex2.brocade.com>
From: Robert Snively <rsnively@Brocade.COM>
To: Stephen Bailey <steph@cs.uchicago.edu>, ips@ece.cmu.edu
Subject: RE: iSCSI: Support Alias in the protocol
Date: Wed, 22 Aug 2001 09:00:16 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Yes, though I lost that vote.

Aliases for this type of device identification are
only relevant in the well-defined management environment
that formulates the aliases.  Posting them in the device is
an invitation to confuse their meaning among two management
environments having access to the same set of devices.

If one administrator likes the characters in popular songs
for his names and another likes planets, wait till you find
two Venuses in the system.

The thing that computers do best is keep track of unique
numbers and associate them with convenient human oriented
symbols.  Let the architecture define the unique numbers
and the management environment relate them to human
oriented symbols.

Bob

> -----Original Message-----
> From: Stephen Bailey [mailto:steph@cs.uchicago.edu]
> Sent: Tuesday, August 21, 2001 7:38 PM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI: Support Alias in the protocol
> 
> 
> Bob,
> 
> > That we call our car Skeezix (human useable, for management
> > purposes within the tightly constrained context of our own
> > family) is non-architected information.
> 
> What's your position on the SCSI LU alias?  Do you think that was a
> bad idea too?
> 


From owner-ips@ece.cmu.edu  Thu Aug 23 17:10:26 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01803
	for <ips-archive@odin.ietf.org>; Thu, 23 Aug 2001 17:10:25 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7NKMN625696
	for ips-outgoing; Thu, 23 Aug 2001 16:22:23 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from spectrum2.osicom.com (spectrum2.osicom.com [131.143.8.10])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7MH3Pe07337
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 13:03:25 -0400 (EDT)
Received: from aj-mail.aj.osicom.com (aj-mail.aj.entradanet.com [131.143.44.5])
	by spectrum2.osicom.com (8.9.2/8.9.2) with ESMTP id NAA26323
	for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 13:05:44 -0400 (EDT)
Received: by aj-mail.aj.entradanet.com with Internet Mail Service (5.5.2448.0)
	id <NY41S8SW>; Wed, 22 Aug 2001 13:00:28 -0400
Message-ID: <A52554628CFFD31193D400508B4433EA04316A@aj-mail.aj.entradanet.com>
From: "Harmon, Robert" <rharmon@entradanet.com>
To: IPS Reflector <ips@ece.cmu.edu>
Subject: RE: IPS: FCIP & this list
Date: Wed, 22 Aug 2001 13:00:28 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C12B2B.F1D6DB24"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C12B2B.F1D6DB24
Content-Type: text/plain;
	charset="windows-1252"


Perhaps the IETF IPS web page could be updated 
to point to an FCIP/iFCP site.

-----Original Message-----
From: Ralph Weber [mailto:ralphoweber@compuserve.com]
Sent: Wednesday, August 22, 2001 12:04 PM
To: IPS Reflector
Subject: Re: IPS: FCIP & this list


David,

Your responses are most excellent.

There are minutes (well, more like discussion notes) from the 
conference call and I will ask that they be posted to this 
reflector.

The interim FCIP drafts and issues lists are maintained in PDF
format, amounting to between .2M and .5M of new material per 
week. Since this is Rome, they cannot be posted to this reflector.
It is totally impractical to translate the PDFs to text, sorry.

} WG Last Call will be conducted on this reflector for FCIP
} and iFCP.  If the FCIP authors continue in their current
} direction, those WG Last Calls could take a very long time.

There appears to be no alternative, however, I doubt that the
WG Last Calls time requirement would be shortened by more than
10% even if everything done by the FCIP authors was posted
to this reflector.  In particular, I see no reason to believe 
that the people who will raise Last Call issues will remember
earlier postings here, or bother to participate on this 
reflector prior to Last Call.  You are the sole exception 
to this perception.

Thanks for the well written, thoughtful response. I regret
that I see so few ways to be more accommodating.

Ralph...

Black_David@emc.com wrote:

>
> Ralph,
>
> > On 17 August 2001, David Black wrote:
> >
> > > While I'm at it, it appears to me that the FCIP authors
> > > are reverting to the unfortunate habit of holding technical
> > > discussions off-line and not sharing them with the list.
> >
> > First, the FCIP authors are posting their works to this
> > reflector.  Otherwise, there would have been nothing
> > to complain about vis-a-vis the content of the FCIP
> > draft on 17 August.
>
> Unfortunately, posting the "works" is not enough.  The rationale
> behind the design decisions needs to be visible and open to
> discussion on the list.  The fact that the FCIP authors have
> discussed an issue offline will not be sufficient to resolve
> a related WG Last Call objection on the list - to oversimplify
> things slightly, the choice is between doing this right and
> doing it over.
>
> > Second, this reflector is clearly the ALL iSCSI ALL THE
> > TIME reflector.  In the last 24 hours, no fewer than two
> > new postings to this reflector have failed to include the
> > project identifier in the subject as requested by John
> > Hufferd and myself less than two weeks ago.
>
> There's a chicken and egg problem here in that the FCIP
> authors have chosen to do their technical work offline
> and invite anyone who expresses any interest in FCIP into
> that offline community including the conference calls.
> That is a major contributing factor to the current traffic
> mix on the reflector, as anyone with an FCIP issue will take
> it to the conference call.  My attitude towards the conference
> calls has been one of tolerating them *as long as*
> the issues/discussion/results are summarized to the list,
> which has not been happening.  I can't promise that the
> Area Directors will be as accommodating.
>
> > And why should people bother to prefix iSCSI postings with
> > "iSCSI:" when one of the co-chairs violated the protocol
> > as recently as yesterday morning with a posting titled
> > "FW: I-D ACTION:draft-black-ips-iscsi-security-01.txt".
>
> IIRC, the FCIP authors have stated an intention to follow
> iSCSI's security direction, making iSCSI security drafts
> (both that and draft-aboba) relevant to FCIP.  If the FCIP
> authors have made an offline decision that iSCSI security
> is no longer relevant to FCIP, than I apologize for the
> lack of tag, but I do wish someone had paid me the courtesy
> of letting me know about this change in direction ...
>
> > The FCIP authors are trying to complete their draft
> > under clearly disadvantaged circumstances.  Due diligence
> > is being made to bring issues to this reflector and to
> > respond to the concerns raised here.  And, I have no
> > doubt that the issue raised on 17 August will be addressed
> > in due course.
> >
> > But it is patent nonsense to claim that the FCIP authors
> > should be trying to use this reflector in the traditional
> > IETF manner.  This reflector belongs to iSCSI, and to all
> > practical purposes it belongs ONLY to iSCSI.
>
> When in Rome ...
>
> > FCIP (and for that matter iFCP) are barely tolerated,
> > uninvited guests, or at least that is how it feels
> > every time I review the directory the day's new messages.
>
> WG Last Call will be conducted on this reflector for FCIP
> and iFCP.  If the FCIP authors continue in their current
> direction, those WG Last Calls could take a very long time.
>
> Thanks,
> --David
>
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------

------_=_NextPart_001_01C12B2B.F1D6DB24
Content-Type: text/html;
	charset="windows-1252"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1252">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2448.0">
<TITLE>RE: IPS: FCIP &amp; this list</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=2>Perhaps the IETF IPS web page could be updated </FONT>
<BR><FONT SIZE=2>to point to an FCIP/iFCP site.</FONT>
</P>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Ralph Weber [<A HREF="mailto:ralphoweber@compuserve.com">mailto:ralphoweber@compuserve.com</A>]</FONT>
<BR><FONT SIZE=2>Sent: Wednesday, August 22, 2001 12:04 PM</FONT>
<BR><FONT SIZE=2>To: IPS Reflector</FONT>
<BR><FONT SIZE=2>Subject: Re: IPS: FCIP &amp; this list</FONT>
</P>
<BR>

<P><FONT SIZE=2>David,</FONT>
</P>

<P><FONT SIZE=2>Your responses are most excellent.</FONT>
</P>

<P><FONT SIZE=2>There are minutes (well, more like discussion notes) from the </FONT>
<BR><FONT SIZE=2>conference call and I will ask that they be posted to this </FONT>
<BR><FONT SIZE=2>reflector.</FONT>
</P>

<P><FONT SIZE=2>The interim FCIP drafts and issues lists are maintained in PDF</FONT>
<BR><FONT SIZE=2>format, amounting to between .2M and .5M of new material per </FONT>
<BR><FONT SIZE=2>week. Since this is Rome, they cannot be posted to this reflector.</FONT>
<BR><FONT SIZE=2>It is totally impractical to translate the PDFs to text, sorry.</FONT>
</P>

<P><FONT SIZE=2>} WG Last Call will be conducted on this reflector for FCIP</FONT>
<BR><FONT SIZE=2>} and iFCP.&nbsp; If the FCIP authors continue in their current</FONT>
<BR><FONT SIZE=2>} direction, those WG Last Calls could take a very long time.</FONT>
</P>

<P><FONT SIZE=2>There appears to be no alternative, however, I doubt that the</FONT>
<BR><FONT SIZE=2>WG Last Calls time requirement would be shortened by more than</FONT>
<BR><FONT SIZE=2>10% even if everything done by the FCIP authors was posted</FONT>
<BR><FONT SIZE=2>to this reflector.&nbsp; In particular, I see no reason to believe </FONT>
<BR><FONT SIZE=2>that the people who will raise Last Call issues will remember</FONT>
<BR><FONT SIZE=2>earlier postings here, or bother to participate on this </FONT>
<BR><FONT SIZE=2>reflector prior to Last Call.&nbsp; You are the sole exception </FONT>
<BR><FONT SIZE=2>to this perception.</FONT>
</P>

<P><FONT SIZE=2>Thanks for the well written, thoughtful response. I regret</FONT>
<BR><FONT SIZE=2>that I see so few ways to be more accommodating.</FONT>
</P>

<P><FONT SIZE=2>Ralph...</FONT>
</P>

<P><FONT SIZE=2>Black_David@emc.com wrote:</FONT>
</P>

<P><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; Ralph,</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; On 17 August 2001, David Black wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; While I'm at it, it appears to me that the FCIP authors</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; are reverting to the unfortunate habit of holding technical</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; discussions off-line and not sharing them with the list.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; First, the FCIP authors are posting their works to this</FONT>
<BR><FONT SIZE=2>&gt; &gt; reflector.&nbsp; Otherwise, there would have been nothing</FONT>
<BR><FONT SIZE=2>&gt; &gt; to complain about vis-a-vis the content of the FCIP</FONT>
<BR><FONT SIZE=2>&gt; &gt; draft on 17 August.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; Unfortunately, posting the &quot;works&quot; is not enough.&nbsp; The rationale</FONT>
<BR><FONT SIZE=2>&gt; behind the design decisions needs to be visible and open to</FONT>
<BR><FONT SIZE=2>&gt; discussion on the list.&nbsp; The fact that the FCIP authors have</FONT>
<BR><FONT SIZE=2>&gt; discussed an issue offline will not be sufficient to resolve</FONT>
<BR><FONT SIZE=2>&gt; a related WG Last Call objection on the list - to oversimplify</FONT>
<BR><FONT SIZE=2>&gt; things slightly, the choice is between doing this right and</FONT>
<BR><FONT SIZE=2>&gt; doing it over.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; Second, this reflector is clearly the ALL iSCSI ALL THE</FONT>
<BR><FONT SIZE=2>&gt; &gt; TIME reflector.&nbsp; In the last 24 hours, no fewer than two</FONT>
<BR><FONT SIZE=2>&gt; &gt; new postings to this reflector have failed to include the</FONT>
<BR><FONT SIZE=2>&gt; &gt; project identifier in the subject as requested by John</FONT>
<BR><FONT SIZE=2>&gt; &gt; Hufferd and myself less than two weeks ago.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; There's a chicken and egg problem here in that the FCIP</FONT>
<BR><FONT SIZE=2>&gt; authors have chosen to do their technical work offline</FONT>
<BR><FONT SIZE=2>&gt; and invite anyone who expresses any interest in FCIP into</FONT>
<BR><FONT SIZE=2>&gt; that offline community including the conference calls.</FONT>
<BR><FONT SIZE=2>&gt; That is a major contributing factor to the current traffic</FONT>
<BR><FONT SIZE=2>&gt; mix on the reflector, as anyone with an FCIP issue will take</FONT>
<BR><FONT SIZE=2>&gt; it to the conference call.&nbsp; My attitude towards the conference</FONT>
<BR><FONT SIZE=2>&gt; calls has been one of tolerating them *as long as*</FONT>
<BR><FONT SIZE=2>&gt; the issues/discussion/results are summarized to the list,</FONT>
<BR><FONT SIZE=2>&gt; which has not been happening.&nbsp; I can't promise that the</FONT>
<BR><FONT SIZE=2>&gt; Area Directors will be as accommodating.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; And why should people bother to prefix iSCSI postings with</FONT>
<BR><FONT SIZE=2>&gt; &gt; &quot;iSCSI:&quot; when one of the co-chairs violated the protocol</FONT>
<BR><FONT SIZE=2>&gt; &gt; as recently as yesterday morning with a posting titled</FONT>
<BR><FONT SIZE=2>&gt; &gt; &quot;FW: I-D ACTION:draft-black-ips-iscsi-security-01.txt&quot;.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; IIRC, the FCIP authors have stated an intention to follow</FONT>
<BR><FONT SIZE=2>&gt; iSCSI's security direction, making iSCSI security drafts</FONT>
<BR><FONT SIZE=2>&gt; (both that and draft-aboba) relevant to FCIP.&nbsp; If the FCIP</FONT>
<BR><FONT SIZE=2>&gt; authors have made an offline decision that iSCSI security</FONT>
<BR><FONT SIZE=2>&gt; is no longer relevant to FCIP, than I apologize for the</FONT>
<BR><FONT SIZE=2>&gt; lack of tag, but I do wish someone had paid me the courtesy</FONT>
<BR><FONT SIZE=2>&gt; of letting me know about this change in direction ...</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; The FCIP authors are trying to complete their draft</FONT>
<BR><FONT SIZE=2>&gt; &gt; under clearly disadvantaged circumstances.&nbsp; Due diligence</FONT>
<BR><FONT SIZE=2>&gt; &gt; is being made to bring issues to this reflector and to</FONT>
<BR><FONT SIZE=2>&gt; &gt; respond to the concerns raised here.&nbsp; And, I have no</FONT>
<BR><FONT SIZE=2>&gt; &gt; doubt that the issue raised on 17 August will be addressed</FONT>
<BR><FONT SIZE=2>&gt; &gt; in due course.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; But it is patent nonsense to claim that the FCIP authors</FONT>
<BR><FONT SIZE=2>&gt; &gt; should be trying to use this reflector in the traditional</FONT>
<BR><FONT SIZE=2>&gt; &gt; IETF manner.&nbsp; This reflector belongs to iSCSI, and to all</FONT>
<BR><FONT SIZE=2>&gt; &gt; practical purposes it belongs ONLY to iSCSI.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; When in Rome ...</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; FCIP (and for that matter iFCP) are barely tolerated,</FONT>
<BR><FONT SIZE=2>&gt; &gt; uninvited guests, or at least that is how it feels</FONT>
<BR><FONT SIZE=2>&gt; &gt; every time I review the directory the day's new messages.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; WG Last Call will be conducted on this reflector for FCIP</FONT>
<BR><FONT SIZE=2>&gt; and iFCP.&nbsp; If the FCIP authors continue in their current</FONT>
<BR><FONT SIZE=2>&gt; direction, those WG Last Calls could take a very long time.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; Thanks,</FONT>
<BR><FONT SIZE=2>&gt; --David</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; ---------------------------------------------------</FONT>
<BR><FONT SIZE=2>&gt; David L. Black, Senior Technologist</FONT>
<BR><FONT SIZE=2>&gt; EMC Corporation, 42 South St., Hopkinton, MA&nbsp; 01748</FONT>
<BR><FONT SIZE=2>&gt; +1 (508) 435-1000 x75140&nbsp;&nbsp;&nbsp;&nbsp; FAX: +1 (508) 497-8500</FONT>
<BR><FONT SIZE=2>&gt; black_david@emc.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Mobile: +1 (978) 394-7754</FONT>
<BR><FONT SIZE=2>&gt; ---------------------------------------------------</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C12B2B.F1D6DB24--


From owner-ips@ece.cmu.edu  Thu Aug 23 17:14:46 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01868
	for <ips-archive@odin.ietf.org>; Thu, 23 Aug 2001 17:14:44 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7NKv6t27696
	for ips-outgoing; Thu, 23 Aug 2001 16:57:06 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7NKv4e27691
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 16:57:05 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id WAA13362
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 22:56:58 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7NKuvK19022
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 22:56:57 +0200
Importance: Normal
Subject: RE: iSCSI - Change - Login/Text commands with the binary stage co		de
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF98A1535C.5093BB98-ONC2256AB1.00728BA9@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Thu, 23 Aug 2001 23:56:27 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 23/08/2001 23:56:56
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Stephen,

That can happen as the target may set-up completely new TCP connections
(the old sockets are still there and look OK).
Untill the login is  progessing he assumes that this is just another
open-session attempt. Then he checks the old session and the session is
dead (initiator has closed the connections).

The target has to distinguish only between a session that is alive (and
reject the new one) and one that its dead in which case it can clean-up.

Julo

"Wheat, Stephen R" <stephen.r.wheat@intel.com> on 23-08-2001 22:50:56

Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>

To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI - Change - Login/Text commands with the binary stage co
          de



Julian,

I don't understand your answer.  For the scenario given, I would presume
then that the target would reject the new session attempt, as it sees the
previous session still "alive".  What is there to tell the target that this
is any different from when the Initiator is erroneously using the
repetitive
session id?

Thanks,
Stephen

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, August 23, 2001 11:15 AM
To: ips@ece.cmu.edu
Subject: Re: iSCSI - Change - Login/Text commands with the binary stage
co de


Stephen,

1.If the initiator goes away for a while and reboots and there was no
activity on the connections
the target may see a session alive (I am not sure that it has to appear on
the state diagram but maybe).

2.Again - I am not sure that the curent state diagram includes death of the
initiator

Julo

"Wheat, Stephen R" <stephen.r.wheat@intel.com>@ece.cmu.edu on 23-08-2001
19:58:34

Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  Re: iSCSI - Change - Login/Text commands with the binary stage co
      de



Julian,

1.3.6 ISID states that the target should check to see if the old session is
still active when a duplicate session is detected.

I have two questions, the second only if you answer in the affirmative on
the first ;^)

1. Is there a properly executed sequence of events (i.e., no coding error
on
the target side) where the session is not active, but the target hadn't
taken notice of it?  It appears this as a protocol-specified means to work
around a flaw in a target's implementation.  I interpret the state diagram
transitions as being atomic wrt other commands.  I.e., the last logout
would
result in the various transitions of the connection/session prior to the
initiator starting the session up again.  And the target would have
completed the transitions prior to handling a new session request.

2. If you answered (1) in the affirmative, then the word "Active" is not
consistent with the 6.3 Session State Diagram.  Does this mean the target
got lost, due to transport failures of any sort, in its transition from
Q3-to-Q2-to-Q1?  It sounds like the intent is to close the old session if
the session was in Q2 or Q4, presuming if it were in Q1,  it would not have
been found as a duplicate.

Stephen









From owner-ips@ece.cmu.edu  Thu Aug 23 17:16:40 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01911
	for <ips-archive@odin.ietf.org>; Thu, 23 Aug 2001 17:16:40 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7NKbSv26585
	for ips-outgoing; Thu, 23 Aug 2001 16:37:28 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from internaut.com ([64.38.134.99])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7NIbfe13526
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 14:37:41 -0400 (EDT)
Received: from localhost (aboba@localhost)
	by internaut.com (8.9.3/8.9.3) with ESMTP id LAA22516;
	Thu, 23 Aug 2001 11:29:55 -0700 (PDT)
	(envelope-from aboba@internaut.com)
Date: Thu, 23 Aug 2001 11:29:54 -0700 (PDT)
From: Bernard Aboba <aboba@internaut.com>
To: Black_David@emc.com
cc: Julian_Satran@il.ibm.com, ips@ece.cmu.edu
Subject: Re: iSCSI: Proxies (was Security in iSCSI)
In-Reply-To: <277DD60FB639D511AC0400B0D068B71ECAD656@CORPMX14>
Message-ID: <Pine.BSF.4.21.0108231126310.22381-100000@internaut.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Agree with David. Proxies cause enormous complications. it has taken 3+
years to figure out a strategy for dealing with them in AAA WG, and we're
still not completely done yet. Be afraid. Be very afraid. 



From owner-ips@ece.cmu.edu  Thu Aug 23 17:31:42 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02234
	for <ips-archive@odin.ietf.org>; Thu, 23 Aug 2001 17:31:42 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7NL24S28029
	for ips-outgoing; Thu, 23 Aug 2001 17:02:04 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7NL21e28024
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 17:02:01 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id XAA05684
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 23:01:55 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7NL1s2100744
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 23:01:55 +0200
Importance: Normal
Subject: RE: Target record not to span PDUs?
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF98C9E021.35CB37A1-ONC2256AB1.0073200E@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Fri, 24 Aug 2001 00:00:35 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 24/08/2001 00:01:54
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Bob,

The record in question is a key=value pair. What Tow was asking is a about
a way to avoid having to "concatenate
strings" from two Text responses that carry the SendTargets answers one
after another and we have stated that
explicitly now.

Julo

Robert Snively <rsnively@Brocade.COM>@ece.cmu.edu on 22-08-2001 19:00:18

Please respond to Robert Snively <rsnively@Brocade.COM>

Sent by:  owner-ips@ece.cmu.edu


To:   Tow Wang <Tow_Wang@adaptec.com>, Julian Satran/Haifa/IBM@IBMIL
cc:   "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
Subject:  RE: Target record not to span PDUs?



It sounds like there may be some confusion between "physical
data unit" (the TCP/IP frame) and "iSCSI Protocol Data Unit"
(the messaging unit for iSCSI).  I cannot see where Tom's
problem arises, since Protocol Data Units are very well
behaved and should not have the problems he is discussing.
You cannot complete Protocol Data Unit processing until you
know you have all of them and that useful information does not
span them.  The assembly of protocol data units into useful
complete messages should be done at a layer below that where
you interpret the contiguous bytes of data in the context of
the complete messages.  I think as a general rule that any
iSCSI action should be able to span PDUs, including the
Target Record.

Bob

> -----Original Message-----
> From: Tow Wang [mailto:Tow_Wang@adaptec.com]
> Sent: Tuesday, August 21, 2001 7:07 PM
> To: 'Julian Satran'
> Cc: 'ips@ece.cmu.edu'
> Subject: Target record not to span PDUs?
>
>
> Julian (and all):
>
> Hello. This is regarding draft 07; could we require that
> target records NOT span across
> PDU's if a text response for SendTargets is very long? Upon
> reading appendix E, it seems
> that a response (of 4096 bytes in length) could end with:
>
> [Begin data segment]
> ...
> TargetName=I.got.chopped.4096
> TargetAddress=10.1.1.45
> [End data segment]
>
> In the above case, one could not determine whether the
> address is IP V4 or V6. Even if it
> had had enough space to put in the whole address, port and
> group tag, one cannot parse and
> process the record until inspecting the data segment of the
> next text response PDU, and
> this would involve cumulative buffering, back-parsing, etc. I
> think the above complexity
> could be avoided, as I can't imagine any single record
> exceeding 4096 bytes in length.
>
> Tow Wang
>
>





From owner-ips@ece.cmu.edu  Thu Aug 23 17:38:06 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02313
	for <ips-archive@odin.ietf.org>; Thu, 23 Aug 2001 17:38:06 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7NKbLU26575
	for ips-outgoing; Thu, 23 Aug 2001 16:37:21 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7NIaIe13449
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 14:36:19 -0400 (EDT)
Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35])
	by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id LAA20812;
	Thu, 23 Aug 2001 11:35:53 -0700 (PDT)
Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19)
	id <Q8DQ7AJ7>; Thu, 23 Aug 2001 11:35:52 -0700
Message-ID: <FFD40DB4943CD411876500508BAD027903B66D9A@sj5-ex2.brocade.com>
From: Robert Snively <rsnively@Brocade.COM>
To: Black_David@emc.com, ENDL_TX@computer.org, ips@ece.cmu.edu
Subject: RE: IPS: FCIP & this list
Date: Thu, 23 Aug 2001 11:35:48 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Dave,

At the open-mic session at the last IETF meeting, I specifically 
raised the issue of pdf as a documentation capability.  If I
interpreted the reply correctly, the primary document must
be text only.  However, versions of the documents in pdf format
were explicitly allowed in order to bring graphics and
better text formatting to the task of making the document
clearer.

>From that, I would have expected that, as long as you provided
paired txt and pdf documents, that they should both be
available on the IETF web-sites and registered through the
I-D servers.  In the case of personal drafts, it would be
even possible that only the pdf existed, since they would be
notes and supplemental texts to the txt formal drafts.

I would like to push the IETF to step up to their stated
flexibility in this area, if they have not already done so.

Bob

> That's a judgment call.  Actually sending the PDFs to the list
> or the I-D servers is a no-no, but it would be ok to put them
> on a web site and post URLs to the list, as long as new text
> versions of the draft do go to the I-D servers at reasonable
> intervals.  It would also be ok to keep the interim PDF versions
> private among the authors until the next major revision of
> the draft is ready for the I-D servers.  There's
> no requirement to make all working notes visible.


From owner-ips@ece.cmu.edu  Thu Aug 23 18:29:54 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03128
	for <ips-archive@odin.ietf.org>; Thu, 23 Aug 2001 18:29:53 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7NLjFW00383
	for ips-outgoing; Thu, 23 Aug 2001 17:45:15 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from c007.snv.cp.net (c007-h000.c007.snv.cp.net [209.228.33.206])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f7NLjDe00378
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 17:45:14 -0400 (EDT)
Received: (cpmta 8538 invoked from network); 23 Aug 2001 14:45:04 -0700
Received: from adsl-63-202-160-80.dsl.snfc21.pacbell.net (HELO littlejoy) (63.202.160.80)
  by smtp.telocity.com (209.228.33.206) with SMTP; 23 Aug 2001 14:45:04 -0700
X-Sent: 23 Aug 2001 21:45:04 GMT
From: "Douglas Otis" <dotis@sanlight.net>
To: "Sanjay Goyal" <sanjay_goyal@ivivity.com>,
        "'CAVANNA,VICENTE V \(A-Roseville,ex1\)'" <vince_cavanna@agilent.com>
Cc: <ips@ece.cmu.edu>
Subject: RE: iSCSI CRC: A CRC-checking example
Date: Thu, 23 Aug 2001 14:43:17 -0700
Message-ID: <NEBBJGDMMLHHCIKHGBEJCELGCKAA.dotis@sanlight.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <25369470B6F0D41194820002B328BDD2116251@ATLOPS>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Sanjay,

In short, the reflected table is likely to require fewer instructions to
implement a lookup than a non-reflected table.  Secondly, if the processor
is Little Endian, then the result is already in network order without byte
swapping.  Obviously this last point only helps if you are using a Little
Endian processor but this happens only once per packet whereas the lookup
may happen every byte.  Third, the inverted store improves the sensitivity
to the packet length.  All these Ethernet techniques seems to be good
things.  One difference however is the polynomial.

Doug

> The last line says
>  "but I suppose it is advantageous to do
> things the ethernet way."
> May I know in what ways it would be advantageous.
>
> Regards
> Sanjay Goyal
>
>
>
> -----Original Message-----
> From: CAVANNA,VICENTE V (A-Roseville,ex1)
> [mailto:vince_cavanna@agilent.com]
> Sent: Thursday, August 23, 2001 1:55 PM
> To: 'Douglas Otis'; CAVANNA,VICENTE V (A-Roseville,ex1); 'Julian Satran'
> Cc: 'Mark Bakke'; ips@ece.cmu.edu; 'Steve Blightman'; THALER,PAT
> (A-Roseville,ex1)
> Subject: RE: iSCSI CRC: A CRC-checking example
>
>
> Doug,
>
> If the transmit side CRC generator used for the frame check sequence the
> remainder of the polynomial division directly (without complementing) the
> receiver-side CRC checker would be expected to end up with zeroes after
> processing an error-free frame. Unfortunately the receiver side
> CRC checker
> would also end up with zeroes after processing a frame whose only "errors"
> are extra trailing zeroes. Thus this type of error would not be
> detected by
> the CRC checker.
>
> Note that the expected final state of the receiver-side CRC checker is
> expected to be zero if hte remainder is not complemented even though both
> transmit and receiver sides initialize their CRC register to 1s. It is the
> operation of complementing the remainder that causes the receiver
> to have a
> non-zero (but constant) ending state after processing an error-free frame.
>
> If I understand you correctly, you have described another type of
> error that
> would be undetected were the remainder not complemented. Whenever the
> receiver CRC register is in its zero state (perhaps partially through a
> packet) the receiver checker would be blind to extra zeroes
> inserted in the
> packet at that point. I agree.
>
> Again, the improved protection resulting from initializing the
> CRC to 1s and
> complementing the remainder is not important for iSCSI because the packet
> length can be checked independently but I suppose it is advantageous to do
> things the ethernet way.
>




From owner-ips@ece.cmu.edu  Thu Aug 23 18:29:59 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03139
	for <ips-archive@odin.ietf.org>; Thu, 23 Aug 2001 18:29:59 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7NM9fv01677
	for ips-outgoing; Thu, 23 Aug 2001 18:09:41 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from hypnos.cps.intel.com (hypnos.cps.intel.com [192.198.165.17])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7NM9de01672
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 18:09:39 -0400 (EDT)
Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201])
	by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id WAA09297
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 22:09:33 GMT
Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.201
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Thu, 23 Aug 2001 22:09:33 0000 (GMT)
Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <RBZV13DA>; Thu, 23 Aug 2001 15:09:31 -0700
Message-ID: <638EC1B28663D211AC3E00A0C96B78A80B7B5F22@orsmsx40.jf.intel.com>
From: "Wheat, Stephen R" <stephen.r.wheat@intel.com>
To: ips@ece.cmu.edu
Subject: RE: iSCSI: CmdSN in Login-retry
Date: Thu, 23 Aug 2001 15:09:27 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Julian,

Your patience (as well as everyone else's) is much appreciated.

My misdirection (and perhaps others who follow us) was that the X bit in one
message header means retry, and in the Login, it means Restart, just as
2.2.2.1 states.  So, then 7.1 does not apply to Login.  Perhaps I'm the only
one that would ever start applying 7.1 to Login simply because it is the X
bit in action.  Sorry about the distraction.

Thanks again,
Stephen

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, August 23, 2001 11:55 AM
To: ips@ece.cmu.edu
Subject: Re: iSCSI: CmdSN in Login-retry



Stephen,

Your question IS more relevant than the security digest.

I am not sure that we ever envisioned retrying a Login.  (except completely
restarting it).
The only definite thing discussed  was that a failed Login should leave no
traces (no partial changes).

In 08 we intend to make Login a SHOULD be immediate (the 0 in immediate was
a typo - that I catched only when making it I).
That is already expressed in the change material I've sent out (including
text req/resp and login req/resp).

There are no scheduled phone calls except for some ongoing work on security
of which you are probably aware and updates of which appear on the list all
the time.

Julo



"Wheat, Stephen R" <stephen.r.wheat@intel.com>@ece.cmu.edu on 23-08-2001
20:50:08

Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  iSCSI: CmdSN in Login-retry



Hi Julian,

My questions pale in comparison to the very interesting security digest
debate.  BTW, I hope David's Pandora's box does stay closed for 1.0.

Section 7.1 states that a Retry command MUST use the original CmdSN.  This
doesn't make sense for a Login Retry.

Is there an exception here?  If not, please briefly explain the logic of a
Login Retry having the original CmdSN.

How does this enter into the debate on whether Login and Login-Text
messages
should be sent Immediate?  Has consensus been met on that yet?

BTW, is there an occasional forum where several people meet to thrash out
subtle details, or is this the only forum for questions, tiny and big?
Obviously people can meet FTF or on the phone whenever they want, but is
there a scheduled forum?

Thanks,
Stephen






From owner-ips@ece.cmu.edu  Thu Aug 23 18:33:10 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03209
	for <ips-archive@odin.ietf.org>; Thu, 23 Aug 2001 18:33:10 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7NLYn829794
	for ips-outgoing; Thu, 23 Aug 2001 17:34:49 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7NLYge29785
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 17:34:43 -0400 (EDT)
Received: from fmsmsxvs040.fm.intel.com (fmsmsxv040-1.fm.intel.com [132.233.48.108])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id VAA08099
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 21:34:41 GMT
Received: from fmsmsx17.intel.com ([132.233.48.17])
 by fmsmsxvs040.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001082314342110891
 for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 14:34:21 -0700
Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <RBZ4NN47>; Thu, 23 Aug 2001 14:35:40 -0700
Message-ID: <638EC1B28663D211AC3E00A0C96B78A80B7B5F1E@orsmsx40.jf.intel.com>
From: "Wheat, Stephen R" <stephen.r.wheat@intel.com>
To: ips@ece.cmu.edu
Subject: RE: Target record not to span PDUs?
Date: Thu, 23 Aug 2001 14:34:39 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Julian,

Not to be pedantic, but, again, the arbitrary decision to avoid the
concatenation adds burden to the target side and restricts the future
capability of key=values that exceed the max text PDU length.

Again, the host side will need to buffer the input until it has all arrived
anyway.  Is there a stronger technical reason for this other than the
avoidance of concatenation?

The approach you propose adds processing burden to every action on a target
side to put a key=action into a PDU.  I envision the target side having
contiguous memory to formulate the entire text response, and it then sends
this in sequential PDUs.  Having to search for where a key=value pair spans
the PDU boundary is work.

Furthermore, being able to span PDUs facilitates a simpler specification.

Maybe Tow can explain the burden of concatenation.  If Tow really doesn't
care, can we go back to allowing the records to span PDUs?

Does anyone else care about this?

Stephen

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, August 23, 2001 2:01 PM
To: ips@ece.cmu.edu
Subject: RE: Target record not to span PDUs?



Bob,

The record in question is a key=value pair. What Tow was asking is a about
a way to avoid having to "concatenate
strings" from two Text responses that carry the SendTargets answers one
after another and we have stated that
explicitly now.

Julo

Robert Snively <rsnively@Brocade.COM>@ece.cmu.edu on 22-08-2001 19:00:18

Please respond to Robert Snively <rsnively@Brocade.COM>

Sent by:  owner-ips@ece.cmu.edu


To:   Tow Wang <Tow_Wang@adaptec.com>, Julian Satran/Haifa/IBM@IBMIL
cc:   "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
Subject:  RE: Target record not to span PDUs?



It sounds like there may be some confusion between "physical
data unit" (the TCP/IP frame) and "iSCSI Protocol Data Unit"
(the messaging unit for iSCSI).  I cannot see where Tom's
problem arises, since Protocol Data Units are very well
behaved and should not have the problems he is discussing.
You cannot complete Protocol Data Unit processing until you
know you have all of them and that useful information does not
span them.  The assembly of protocol data units into useful
complete messages should be done at a layer below that where
you interpret the contiguous bytes of data in the context of
the complete messages.  I think as a general rule that any
iSCSI action should be able to span PDUs, including the
Target Record.

Bob

> -----Original Message-----
> From: Tow Wang [mailto:Tow_Wang@adaptec.com]
> Sent: Tuesday, August 21, 2001 7:07 PM
> To: 'Julian Satran'
> Cc: 'ips@ece.cmu.edu'
> Subject: Target record not to span PDUs?
>
>
> Julian (and all):
>
> Hello. This is regarding draft 07; could we require that
> target records NOT span across
> PDU's if a text response for SendTargets is very long? Upon
> reading appendix E, it seems
> that a response (of 4096 bytes in length) could end with:
>
> [Begin data segment]
> ...
> TargetName=I.got.chopped.4096
> TargetAddress=10.1.1.45
> [End data segment]
>
> In the above case, one could not determine whether the
> address is IP V4 or V6. Even if it
> had had enough space to put in the whole address, port and
> group tag, one cannot parse and
> process the record until inspecting the data segment of the
> next text response PDU, and
> this would involve cumulative buffering, back-parsing, etc. I
> think the above complexity
> could be avoided, as I can't imagine any single record
> exceeding 4096 bytes in length.
>
> Tow Wang
>
>




From owner-ips@ece.cmu.edu  Thu Aug 23 19:13:08 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03721
	for <ips-archive@odin.ietf.org>; Thu, 23 Aug 2001 19:13:08 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7NMbNO03199
	for ips-outgoing; Thu, 23 Aug 2001 18:37:23 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mxic2.us.dg.com (mxic2.us.dg.com [128.221.31.40])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7NMbMe03195
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 18:37:22 -0400 (EDT)
Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19)
	id <QQ9Q7J1Q>; Thu, 23 Aug 2001 18:35:08 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD659@CORPMX14>
From: Black_David@emc.com
To: sanjay_goyal@ivivity.com, ips@ece.cmu.edu
Subject: RE: iSCSI CRC: A CRC-checking example
Date: Thu, 23 Aug 2001 18:31:23 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

From a practical standpoint, using the same implementation framework
(for lack of a better word) as Ethernet reduces the opportunity
to get this wrong - a designer who's done an Ethernet CRC does
the same thing with the new CRC polynomial and the result works.

If this aspect of CRC usage "ain't broke", I would think
that "don't fix it" is the preferred course of action ;-).

Thanks,
--David

> -----Original Message-----
> From: Douglas Otis [mailto:dotis@sanlight.net]
> Sent: Thursday, August 23, 2001 5:43 PM
> To: Sanjay Goyal; 'CAVANNA,VICENTE V (A-Roseville,ex1)'
> Cc: ips@ece.cmu.edu
> Subject: RE: iSCSI CRC: A CRC-checking example
> 
> 
> Sanjay,
> 
> In short, the reflected table is likely to require fewer instructions to
> implement a lookup than a non-reflected table.  Secondly, if the processor
> is Little Endian, then the result is already in network order without byte
> swapping.  Obviously this last point only helps if you are using a Little
> Endian processor but this happens only once per packet whereas the lookup
> may happen every byte.  Third, the inverted store improves the sensitivity
> to the packet length.  All these Ethernet techniques seems to be good
> things.  One difference however is the polynomial.
> 
> Doug
> 
> > The last line says
> >  "but I suppose it is advantageous to do things the ethernet way."
> > May I know in what ways it would be advantageous.
> >
> > Regards
> > Sanjay Goyal
> >


From owner-ips@ece.cmu.edu  Thu Aug 23 19:14:52 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03745
	for <ips-archive@odin.ietf.org>; Thu, 23 Aug 2001 19:14:52 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7NMlhv03665
	for ips-outgoing; Thu, 23 Aug 2001 18:47:43 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from magic.adaptec.com (magic.adaptec.com [208.236.45.80])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7NMlfe03660
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 18:47:41 -0400 (EDT)
Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11])
	by magic.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id PAA22324;
	Thu, 23 Aug 2001 15:45:40 -0700 (PDT)
Received: from aimexc02.corp.adaptec.com (aimexc02.corp.adaptec.com [162.62.62.40])
	by redfish.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id PAA17778;
	Thu, 23 Aug 2001 15:33:12 -0700 (PDT)
Received: from adaptec.com (ws116-206.corp.adaptec.com [162.62.116.206]) by aimexc02.corp.adaptec.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id RFSQJS16; Thu, 23 Aug 2001 15:45:39 -0700
Message-ID: <3B85885C.240BFC87@adaptec.com>
Date: Thu, 23 Aug 2001 15:49:00 -0700
From: Tow Wang <Tow_Wang@adaptec.com>
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Wheat, Stephen R" <stephen.r.wheat@intel.com>, ips@ece.cmu.edu
Subject: Re: Target record not to span PDUs?
References: <638EC1B28663D211AC3E00A0C96B78A80B7B5F1E@orsmsx40.jf.intel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Stephen and all:

Hello. Let me explain myself further, as I do care about this issue. As I
interpret the appendix E, the amount of data (bytes) generated in response to
"SendTargets" can be arbitrarily long, and thus may require an unpredictable
number of text command/text response exchanges until all target records have
been delivered to the initiator.

I don't think it is a good idea to have to buffer all the data segments of
these text responses (until seeing a final bit) before parsing the target
records and freeing the buffers. I was not confusing between the concepts of
"having to buffer all TCP frames until all bytes of a single PDU have been
received"
and
"having to buffer and hold all PDU's sent in response to SendTargets"
The former is a given due to the nature of networking, but the latter is bad,
and likely unfeasible, if one has limited buffering memory. It is more
memory-efficient (and slightly improves performance) to FULLY process each
INDIVIDUAL PDU that has been delivered to the recipient, so one can release the
buffering resources and prepare to process the following PDUs coming in.

Also, in this situation the target is much better informed about the sizes,
starting points and end points of the target records. While the target writes
each record into the "contiguous memory" buffer alluded to, it must keep track
of the offset for the amount of space already used in the buffer (as it
certainly is not infinite in size!). That will give an immediate indication of
whether a record will fit within the a PDU, or should be shipped in the
following PDU.

Tow


"Wheat, Stephen R" wrote:

> Julian,
>
> Not to be pedantic, but, again, the arbitrary decision to avoid the
> concatenation adds burden to the target side and restricts the future
> capability of key=values that exceed the max text PDU length.
>
> Again, the host side will need to buffer the input until it has all arrived
> anyway.  Is there a stronger technical reason for this other than the
> avoidance of concatenation?
>
> The approach you propose adds processing burden to every action on a target
> side to put a key=action into a PDU.  I envision the target side having
> contiguous memory to formulate the entire text response, and it then sends
> this in sequential PDUs.  Having to search for where a key=value pair spans
> the PDU boundary is work.
>
> Furthermore, being able to span PDUs facilitates a simpler specification.
>
> Maybe Tow can explain the burden of concatenation.  If Tow really doesn't
> care, can we go back to allowing the records to span PDUs?
>
> Does anyone else care about this?
>
> Stephen
>
> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Thursday, August 23, 2001 2:01 PM
> To: ips@ece.cmu.edu
> Subject: RE: Target record not to span PDUs?
>
> Bob,
>
> The record in question is a key=value pair. What Tow was asking is a about
> a way to avoid having to "concatenate
> strings" from two Text responses that carry the SendTargets answers one
> after another and we have stated that
> explicitly now.
>
> Julo
>
> Robert Snively <rsnively@Brocade.COM>@ece.cmu.edu on 22-08-2001 19:00:18
>
> Please respond to Robert Snively <rsnively@Brocade.COM>
>
> Sent by:  owner-ips@ece.cmu.edu
>
> To:   Tow Wang <Tow_Wang@adaptec.com>, Julian Satran/Haifa/IBM@IBMIL
> cc:   "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
> Subject:  RE: Target record not to span PDUs?
>
> It sounds like there may be some confusion between "physical
> data unit" (the TCP/IP frame) and "iSCSI Protocol Data Unit"
> (the messaging unit for iSCSI).  I cannot see where Tom's
> problem arises, since Protocol Data Units are very well
> behaved and should not have the problems he is discussing.
> You cannot complete Protocol Data Unit processing until you
> know you have all of them and that useful information does not
> span them.  The assembly of protocol data units into useful
> complete messages should be done at a layer below that where
> you interpret the contiguous bytes of data in the context of
> the complete messages.  I think as a general rule that any
> iSCSI action should be able to span PDUs, including the
> Target Record.
>
> Bob
>
> > -----Original Message-----
> > From: Tow Wang [mailto:Tow_Wang@adaptec.com]
> > Sent: Tuesday, August 21, 2001 7:07 PM
> > To: 'Julian Satran'
> > Cc: 'ips@ece.cmu.edu'
> > Subject: Target record not to span PDUs?
> >
> >
> > Julian (and all):
> >
> > Hello. This is regarding draft 07; could we require that
> > target records NOT span across
> > PDU's if a text response for SendTargets is very long? Upon
> > reading appendix E, it seems
> > that a response (of 4096 bytes in length) could end with:
> >
> > [Begin data segment]
> > ...
> > TargetName=I.got.chopped.4096
> > TargetAddress=10.1.1.45
> > [End data segment]
> >
> > In the above case, one could not determine whether the
> > address is IP V4 or V6. Even if it
> > had had enough space to put in the whole address, port and
> > group tag, one cannot parse and
> > process the record until inspecting the data segment of the
> > next text response PDU, and
> > this would involve cumulative buffering, back-parsing, etc. I
> > think the above complexity
> > could be avoided, as I can't imagine any single record
> > exceeding 4096 bytes in length.
> >
> > Tow Wang
> >
> >



From owner-ips@ece.cmu.edu  Thu Aug 23 19:15:21 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03762
	for <ips-archive@odin.ietf.org>; Thu, 23 Aug 2001 19:15:20 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7NMjc503572
	for ips-outgoing; Thu, 23 Aug 2001 18:45:38 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from atlrel7.hp.com (atlrel7.hp.com [192.151.27.9])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7NMjWe03567
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 18:45:37 -0400 (EDT)
Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100])
	by atlrel7.hp.com (Postfix) with ESMTP id 6B77F1F55A
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 18:44:06 -0400 (EDT)
Received: (from cbm@localhost) by core.rose.hp.com (8.8.6 (PHNE_14041)/8.8.6 SMKit7.02) id PAA18368 for ips@ece.cmu.edu; Thu, 23 Aug 2001 15:46:40 -0700 (PDT)
Message-Id: <200108232246.PAA18368@core.rose.hp.com>
Subject: iSCSI: reusing ISID for recovery (Was: RE: iSCSI - Change - Login/Text...)
To: ips@ece.cmu.edu
Date: Thu, 23 Aug 2001 15:46:40 PDT
Reply-To: cbm@rose.hp.com
From: "Mallikarjun C." <cbm@rose.hp.com>
X-Mailer: Elm [revision: 212.4]
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Julian and all:

This thread mirrors another discussion some of us are 
having in a different forum.  Following (two bullets 1
& 2 below) is what I proposed there, attempting to address 
two issues -
	a) how to recover sessions when target and the initiator
           have conflicting views of the same TCP connection(s)? 
           (Initiator NIC fails, but there's no I/O activity,
           and the target doesn't see any connection failure.)
	b) More specifically, how to address the above problem
           when the initiator *does not want* to re-instate failed
           connections since it only implements the mandatory 
           session recovery?

This could add clarity or muddle things up here, though hopefully
the former...

1 If login is sent with the same ISID, same TSID, same CID and X-bit,
  then it means a failed connection is being re-instated (whether
  or not there are multiple connections in the session).  This login
  attempt must be done before the connection timeout (transition M1),
  or if this is the only connection in the session, also before the
  session timeout (transition N6) - to be counted as a connection
  reinstatement effort.
           o CmdSN counters (CmdSN, ExpCmdSN) are continued.  Initiator
             must do command plugging when there's a mismatch
             between its CmdSN and ExpCmdSN in the login response.
           o Since this is an implicit connection logout, all the active
             tasks on the connection are either internally terminated,
             or made non-allegiant (based on ErrorRecoveryLevel=x/y,
             TBD) for recovery.

2 If login is sent with the same ISID and TSID=0, the session (if it
  exists on the target) is being cleared and any active connections
  that the target sees must be immediately (at the end of the login
  process including any initiator authentication) transport reset.  
  Initiator may attempt this only after it ascertains a session failure 
  on its end (ie. all connections entered RECOVERY_START).
           o CmdSN counters get reset.  Initiator has to perform the
             currently defined session recovery actions.
           o All active tasks of the session are internally terminated.


Essentially, I was proposing extending the same notion of "implicit
logout" of a connection to the session level.  The options that I
see are -

       A) Should iSCSI let it happen by default as stated above (ie. 
          same ISID, TSID=0 always wipes out the pre-existing session 
          on target, since we are mandating it to be used only when 
          initiator sees a session failure)?
       B) Should iSCSI mandate making this intended cleanup explicit 
          by setting a bit (Say C-bit, for Clear) in the Login Command 
          PDU to prevent an accidental session cleanup with a buggy 
          initiator code? 
       C) Should iSCSI merely state that targets must ascertain 
          the connection state(s) whenever a new session creation
          attempt is made with a known ISID and TSID=0?  (sort of
          defeats the intention of the initiator wanting quicker 
          session recovery since the Login command PDU would have
          to idle till target ascertains the connection state(s)).

I prefer A, or B.

Going with A or B means that the description of transition N3
in the session state diagram would have to change to: 
	Last LOGGED_IN connection had ceased to be LOGGED_IN, 
        or a Login Command requesting clearing the session (also
        with C-bit set, if option B) was received by the target.

The transition N7's description would have to be augmented as
well to:
        Session recovery attempt with an implicit logout, 
        or connection reinstatement/new CID addition. 

Comments?
--
Mallikarjun 


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


>Stephen,
>
>That can happen as the target may set-up completely new TCP connections
>(the old sockets are still there and look OK).
>Untill the login is  progessing he assumes that this is just another
>open-session attempt. Then he checks the old session and the session is
>dead (initiator has closed the connections).
>
>The target has to distinguish only between a session that is alive (and
>reject the new one) and one that its dead in which case it can clean-up.
>
>Julo
>
>"Wheat, Stephen R" <stephen.r.wheat@intel.com> on 23-08-2001 22:50:56
>
>Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
>
>To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
>cc:
>Subject:  RE: iSCSI - Change - Login/Text commands with the binary stage co
>          de
>
>
>
>Julian,
>
>I don't understand your answer.  For the scenario given, I would presume
>then that the target would reject the new session attempt, as it sees the
>previous session still "alive".  What is there to tell the target that this
>is any different from when the Initiator is erroneously using the
>repetitive
>session id?
>
>Thanks,
>Stephen
>
>-----Original Message-----
>From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
>Sent: Thursday, August 23, 2001 11:15 AM
>To: ips@ece.cmu.edu
>Subject: Re: iSCSI - Change - Login/Text commands with the binary stage
>co de
>
>
>Stephen,
>
>1.If the initiator goes away for a while and reboots and there was no
>activity on the connections
>the target may see a session alive (I am not sure that it has to appear on
>the state diagram but maybe).
>
>2.Again - I am not sure that the curent state diagram includes death of the
>initiator
>
>Julo
>
>"Wheat, Stephen R" <stephen.r.wheat@intel.com>@ece.cmu.edu on 23-08-2001
>19:58:34
>
>Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
>
>Sent by:  owner-ips@ece.cmu.edu
>
>
>To:   ips@ece.cmu.edu
>cc:
>Subject:  Re: iSCSI - Change - Login/Text commands with the binary stage co
>      de
>
>
>
>Julian,
>
>1.3.6 ISID states that the target should check to see if the old session is
>still active when a duplicate session is detected.
>
>I have two questions, the second only if you answer in the affirmative on
>the first ;^)
>
>1. Is there a properly executed sequence of events (i.e., no coding error
>on
>the target side) where the session is not active, but the target hadn't
>taken notice of it?  It appears this as a protocol-specified means to work
>around a flaw in a target's implementation.  I interpret the state diagram
>transitions as being atomic wrt other commands.  I.e., the last logout
>would
>result in the various transitions of the connection/session prior to the
>initiator starting the session up again.  And the target would have
>completed the transitions prior to handling a new session request.
>
>2. If you answered (1) in the affirmative, then the word "Active" is not
>consistent with the 6.3 Session State Diagram.  Does this mean the target
>got lost, due to transport failures of any sort, in its transition from
>Q3-to-Q2-to-Q1?  It sounds like the intent is to close the old session if
>the session was in Q2 or Q4, presuming if it were in Q1,  it would not have
>been found as a duplicate.
>
>Stephen
>
>
>
>
>
>
>
>




From owner-ips@ece.cmu.edu  Thu Aug 23 19:16:15 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03780
	for <ips-archive@odin.ietf.org>; Thu, 23 Aug 2001 19:16:15 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7NMLLu02323
	for ips-outgoing; Thu, 23 Aug 2001 18:21:21 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7NMLKe02318
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 18:21:21 -0400 (EDT)
Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <RNJ8PKFQ>; Thu, 23 Aug 2001 18:21:15 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD658@CORPMX14>
From: Black_David@emc.com
To: rsnively@Brocade.COM, ips@ece.cmu.edu
Subject: RE: IPS: FCIP & this list
Date: Thu, 23 Aug 2001 18:15:22 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Bob,

You left out the piece of Ralph's email which said
that converting the intermediate PDFs to text was not
feasible, hence only a PDF version will be available:

> The interim FCIP drafts and issues lists are maintained in PDF
> format, amounting to between .2M and .5M of new material per 
> week. Since this is Rome, they cannot be posted to this reflector.
> It is totally impractical to translate the PDFs to text, sorry.

Submitting paired text and PDF documents to the I-D servers
is fine, but keep in mind that the text version must be
self-contained by the time it is last called in the WG (i.e.,
only figures that are not crucial to understanding the
document can be omitted from the text version).

> I would like to push the IETF to step up to their stated
> flexibility in this area, if they have not already done so.

If you want those intermediate PDF versions on the I-D servers,
you need to push Ralph to generate their text counterparts.
The IETF secretariat stands ready to do what was promised.

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------

> -----Original Message-----
> From: Robert Snively [mailto:rsnively@Brocade.COM]
> Sent: Thursday, August 23, 2001 2:36 PM
> To: Black_David@emc.com; ENDL_TX@computer.org; ips@ece.cmu.edu
> Subject: RE: IPS: FCIP & this list
> 
> 
> 
> Dave,
> 
> At the open-mic session at the last IETF meeting, I specifically 
> raised the issue of pdf as a documentation capability.  If I
> interpreted the reply correctly, the primary document must
> be text only.  However, versions of the documents in pdf format
> were explicitly allowed in order to bring graphics and
> better text formatting to the task of making the document
> clearer.
> 
> >From that, I would have expected that, as long as you provided
> paired txt and pdf documents, that they should both be
> available on the IETF web-sites and registered through the
> I-D servers.  In the case of personal drafts, it would be
> even possible that only the pdf existed, since they would be
> notes and supplemental texts to the txt formal drafts.
> 
> I would like to push the IETF to step up to their stated
> flexibility in this area, if they have not already done so.
> 
> Bob
> 
> > That's a judgment call.  Actually sending the PDFs to the list
> > or the I-D servers is a no-no, but it would be ok to put them
> > on a web site and post URLs to the list, as long as new text
> > versions of the draft do go to the I-D servers at reasonable
> > intervals.  It would also be ok to keep the interim PDF versions
> > private among the authors until the next major revision of
> > the draft is ready for the I-D servers.  There's
> > no requirement to make all working notes visible.
> 


From owner-ips@ece.cmu.edu  Thu Aug 23 20:00:24 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04142
	for <ips-archive@odin.ietf.org>; Thu, 23 Aug 2001 20:00:24 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7NN9id04776
	for ips-outgoing; Thu, 23 Aug 2001 19:09:44 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7NN9he04772
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 19:09:43 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-68-173.cisco.com [161.44.68.173]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id TAA04275 for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 19:09:38 -0400 (EDT)
Message-ID: <3B858D29.642FE08B@cisco.com>
Date: Thu, 23 Aug 2001 18:09:29 -0500
From: Steve Senum <ssenum@cisco.com>
X-Mailer: Mozilla 4.73 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-ips <ips@ece.cmu.edu>
Subject: Re: iSCSI: Login Proposal
References: <0B9A57FF1D57D411B47500D0B73E5CC101E7A839@dickens.bri.hp.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Julian and Matthew:

Is was wondering what the status of this issue is?
Are both proposals still on the table?

Regards,
Steve Senum


From owner-ips@ece.cmu.edu  Thu Aug 23 20:04:51 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04174
	for <ips-archive@odin.ietf.org>; Thu, 23 Aug 2001 20:04:51 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7NNQ1I07873
	for ips-outgoing; Thu, 23 Aug 2001 19:26:01 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7NNPxe07868
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 19:25:59 -0400 (EDT)
Received: from phys-ha0nwka.ebay.sun.com ([129.149.1.90])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA28124
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 17:25:54 -0600 (MDT)
Received: from sonnet (sonnet [129.149.161.67])
	by phys-ha0nwka.ebay.sun.com (8.10.2+Sun/8.10.2/ENSMAIL,v2.1p1) with SMTP id f7NNPuY25661
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 16:25:56 -0700 (PDT)
Message-Id: <200108232325.f7NNPuY25661@phys-ha0nwka.ebay.sun.com>
Date: Thu, 23 Aug 2001 16:25:58 -0700 (PDT)
From: jp.raghavendra@EBay.Sun.COM
Reply-To: jp.raghavendra@EBay.Sun.COM
Subject: RE: Target record not to span PDUs?
To: ips@ece.cmu.edu
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: Ua/lpXF/M5ai5FzA6KEtnA==
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


> The approach you propose adds processing burden to every action on a target
> side to put a key=action into a PDU.  I envision the target side having
> contiguous memory to formulate the entire text response, and it then sends
> this in sequential PDUs. 

I may have to disagree with this statement. The response is dynamic and
is based on the request (the keys that the initiator is interested in)
and it is already doing some work here, in decoding the key and deciding
an appropriate action/value for the key. Therefore, I don't believe it is
either difficult or too much work to adjust the PDU to contain a complete
key/value pair in one PDU. If they span multiple PDUs, the initiator
has to do additional to work to coalesce them into meaningful pairs,
and I don't see any major gains in trying to do that.

-JP

> 
> Bob,
> 
> The record in question is a key=value pair. What Tow was asking is a about
> a way to avoid having to "concatenate
> strings" from two Text responses that carry the SendTargets answers one
> after another and we have stated that
> explicitly now.
> 
> Julo
> 
> Robert Snively <rsnively@Brocade.COM>@ece.cmu.edu on 22-08-2001 19:00:18
> 
> Please respond to Robert Snively <rsnively@Brocade.COM>
> 
> Sent by:  owner-ips@ece.cmu.edu
> 
> 
> To:   Tow Wang <Tow_Wang@adaptec.com>, Julian Satran/Haifa/IBM@IBMIL
> cc:   "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
> Subject:  RE: Target record not to span PDUs?
> 
> 
> 
> It sounds like there may be some confusion between "physical
> data unit" (the TCP/IP frame) and "iSCSI Protocol Data Unit"
> (the messaging unit for iSCSI).  I cannot see where Tom's
> problem arises, since Protocol Data Units are very well
> behaved and should not have the problems he is discussing.
> You cannot complete Protocol Data Unit processing until you
> know you have all of them and that useful information does not
> span them.  The assembly of protocol data units into useful
> complete messages should be done at a layer below that where
> you interpret the contiguous bytes of data in the context of
> the complete messages.  I think as a general rule that any
> iSCSI action should be able to span PDUs, including the
> Target Record.
> 
> Bob
> 
> > -----Original Message-----
> > From: Tow Wang [mailto:Tow_Wang@adaptec.com]
> > Sent: Tuesday, August 21, 2001 7:07 PM
> > To: 'Julian Satran'
> > Cc: 'ips@ece.cmu.edu'
> > Subject: Target record not to span PDUs?
> >
> >
> > Julian (and all):
> >
> > Hello. This is regarding draft 07; could we require that
> > target records NOT span across
> > PDU's if a text response for SendTargets is very long? Upon
> > reading appendix E, it seems
> > that a response (of 4096 bytes in length) could end with:
> >
> > [Begin data segment]
> > ...
> > TargetName=I.got.chopped.4096
> > TargetAddress=10.1.1.45
> > [End data segment]
> >
> > In the above case, one could not determine whether the
> > address is IP V4 or V6. Even if it
> > had had enough space to put in the whole address, port and
> > group tag, one cannot parse and
> > process the record until inspecting the data segment of the
> > next text response PDU, and
> > this would involve cumulative buffering, back-parsing, etc. I
> > think the above complexity
> > could be avoided, as I can't imagine any single record
> > exceeding 4096 bytes in length.
> >
> > Tow Wang
> >
> >
> 



From owner-ips@ece.cmu.edu  Thu Aug 23 21:56:07 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06113
	for <ips-archive@odin.ietf.org>; Thu, 23 Aug 2001 21:56:06 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7O13TX13823
	for ips-outgoing; Thu, 23 Aug 2001 21:03:29 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7NMoCe03801
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 18:50:12 -0400 (EDT)
Received: from phys-ha0nwka.ebay.sun.com ([129.149.1.90])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA24662
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 15:50:06 -0700 (PDT)
Received: from sonnet (sonnet [129.149.161.67])
	by phys-ha0nwka.ebay.sun.com (8.10.2+Sun/8.10.2/ENSMAIL,v2.1p1) with SMTP id f7NMo4Y20952
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 15:50:04 -0700 (PDT)
Message-Id: <200108232250.f7NMo4Y20952@phys-ha0nwka.ebay.sun.com>
Date: Thu, 23 Aug 2001 15:50:06 -0700 (PDT)
From: JP Raghavendra Rao <Jp.Raghavendra@sun.com>
Reply-To: JP Raghavendra Rao <Jp.Raghavendra@sun.com>
Subject: RE: Target record not to span PDUs?
To: ips@ece.cmu.edu
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: iPEqdPJsTNN2uxgG3hHkiw==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc 
Sender: owner-ips@ece.cmu.edu
Precedence: bulk



> The approach you propose adds processing burden to every action on a target
> side to put a key=action into a PDU.  I envision the target side having
> contiguous memory to formulate the entire text response, and it then sends
> this in sequential PDUs. 

I may have to disagree with this statement. The response is dynamic and
is based on the request (the keys that the initiator is interested in)
and it is already doing some work here, in decoding the key and deciding
an appropriate action/value for the key. Therefore, I don't believe it is
either difficult or too much work to adjust the PDU to contain a complete
key/value pair in one PDU. If they span multiple PDUs, the initiator
has to do additional to work to coalesce them into meaningful pairs,
and I don't see any major gains in trying to do that.

-JP

> 
> Bob,
> 
> The record in question is a key=value pair. What Tow was asking is a about
> a way to avoid having to "concatenate
> strings" from two Text responses that carry the SendTargets answers one
> after another and we have stated that
> explicitly now.
> 
> Julo
> 
> Robert Snively <rsnively@Brocade.COM>@ece.cmu.edu on 22-08-2001 19:00:18
> 
> Please respond to Robert Snively <rsnively@Brocade.COM>
> 
> Sent by:  owner-ips@ece.cmu.edu
> 
> 
> To:   Tow Wang <Tow_Wang@adaptec.com>, Julian Satran/Haifa/IBM@IBMIL
> cc:   "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
> Subject:  RE: Target record not to span PDUs?
> 
> 
> 
> It sounds like there may be some confusion between "physical
> data unit" (the TCP/IP frame) and "iSCSI Protocol Data Unit"
> (the messaging unit for iSCSI).  I cannot see where Tom's
> problem arises, since Protocol Data Units are very well
> behaved and should not have the problems he is discussing.
> You cannot complete Protocol Data Unit processing until you
> know you have all of them and that useful information does not
> span them.  The assembly of protocol data units into useful
> complete messages should be done at a layer below that where
> you interpret the contiguous bytes of data in the context of
> the complete messages.  I think as a general rule that any
> iSCSI action should be able to span PDUs, including the
> Target Record.
> 
> Bob
> 
> > -----Original Message-----
> > From: Tow Wang [mailto:Tow_Wang@adaptec.com]
> > Sent: Tuesday, August 21, 2001 7:07 PM
> > To: 'Julian Satran'
> > Cc: 'ips@ece.cmu.edu'
> > Subject: Target record not to span PDUs?
> >
> >
> > Julian (and all):
> >
> > Hello. This is regarding draft 07; could we require that
> > target records NOT span across
> > PDU's if a text response for SendTargets is very long? Upon
> > reading appendix E, it seems
> > that a response (of 4096 bytes in length) could end with:
> >
> > [Begin data segment]
> > ...
> > TargetName=I.got.chopped.4096
> > TargetAddress=10.1.1.45
> > [End data segment]
> >
> > In the above case, one could not determine whether the
> > address is IP V4 or V6. Even if it
> > had had enough space to put in the whole address, port and
> > group tag, one cannot parse and
> > process the record until inspecting the data segment of the
> > next text response PDU, and
> > this would involve cumulative buffering, back-parsing, etc. I
> > think the above complexity
> > could be avoided, as I can't imagine any single record
> > exceeding 4096 bytes in length.
> >
> > Tow Wang
> >
> >
> 


From owner-ips@ece.cmu.edu  Thu Aug 23 21:58:21 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06161
	for <ips-archive@odin.ietf.org>; Thu, 23 Aug 2001 21:58:20 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7O14LP13896
	for ips-outgoing; Thu, 23 Aug 2001 21:04:21 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7O09re11611
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 20:09:53 -0400 (EDT)
Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35])
	by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id RAA19443;
	Thu, 23 Aug 2001 17:09:46 -0700 (PDT)
Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19)
	id <Q8DQ72WF>; Thu, 23 Aug 2001 17:09:45 -0700
Message-ID: <FFD40DB4943CD411876500508BAD027902993762@sj5-ex2.brocade.com>
From: Robert Snively <rsnively@Brocade.COM>
To: "'Tow Wang'" <Tow_Wang@adaptec.com>,
        "Wheat, Stephen R"
	 <stephen.r.wheat@intel.com>, ips@ece.cmu.edu
Subject: RE: Target record not to span PDUs?
Date: Thu, 23 Aug 2001 17:09:34 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Folks,

Welcome to storage.

I am with Stephen on this one.  The choice of how to 
transmit a set of information is done at a relatively low layer,
often in hardware.  
That choice is made independent of what useful boundaries
may or may not exist in the data itself.  His vision of an
assemblage of data that is logically contiguous transmitted
by a layer that will cut it on arbitrary protocol data unit
boundaries is correct.

This same argument (and the same resolution) will naturally
be made for disk data blocks, tape data blocks, and everything
else which has an interesting internal boundary.  The
internal boundary is not part of the formation of the IP
packet, the TCP segment, or the iSCSI protocol data unit.

On those special cases where this is very important, each
data unit should be requested and transmitted in a separate
small interchange.  As an example, if you don't like the 
key=data to span a PDU, just ask for a single key=data unit
in each request.  Then the data will be small enough that,
no matter how many PDUs it uses in the transmission process,
you don't chew up very much buffer.

Once you have requested a set of data, you have committed to
accepting ALL the data that fits in the specified allocation
size.  You have also committed to processing that data only
after all retries and out-of-order transmissions have been
completed and the data buffer has been returned to you.  Looking
ahead based on knowledge of the PDU (whose boundaries are 
not exposed at the standard delivery interface) can be useful
only if you are willing to consider such look-aheads as 
provisional.  You cannot fully use the data until you have
accounted for and completed the analysis of any ambiguities
that were temporarily created by spanning of PDUs.

Note that part of this discussion seems to center on whether
you expect PDU transmission to be hardware or software.  I
expect it to be hardware, so creating the proposed restriction
is very burdensome.

Bob Snively                        e-mail:    rsnively@brocade.com
Brocade Communications Systems     phone:  408 487 8135
1745 Technology Drive
San Jose, CA 95110




> -----Original Message-----
> From: Tow Wang [mailto:Tow_Wang@adaptec.com]
> Sent: Thursday, August 23, 2001 3:49 PM
> To: Wheat, Stephen R; ips@ece.cmu.edu
> Subject: Re: Target record not to span PDUs?
> 
> 
> Stephen and all:
> 
> Hello. Let me explain myself further, as I do care about this 
> issue. As I
> interpret the appendix E, the amount of data (bytes) 
> generated in response to
> "SendTargets" can be arbitrarily long, and thus may require 
> an unpredictable
> number of text command/text response exchanges until all 
> target records have
> been delivered to the initiator.
> 
> I don't think it is a good idea to have to buffer all the 
> data segments of
> these text responses (until seeing a final bit) before 
> parsing the target
> records and freeing the buffers. I was not confusing between 
> the concepts of
> "having to buffer all TCP frames until all bytes of a single 
> PDU have been
> received"
> and
> "having to buffer and hold all PDU's sent in response to SendTargets"
> The former is a given due to the nature of networking, but 
> the latter is bad,
> and likely unfeasible, if one has limited buffering memory. It is more
> memory-efficient (and slightly improves performance) to FULLY 
> process each
> INDIVIDUAL PDU that has been delivered to the recipient, so 
> one can release the
> buffering resources and prepare to process the following PDUs 
> coming in.
> 
> Also, in this situation the target is much better informed 
> about the sizes,
> starting points and end points of the target records. While 
> the target writes
> each record into the "contiguous memory" buffer alluded to, 
> it must keep track
> of the offset for the amount of space already used in the 
> buffer (as it
> certainly is not infinite in size!). That will give an 
> immediate indication of
> whether a record will fit within the a PDU, or should be 
> shipped in the
> following PDU.
> 
> Tow
> 
> 
> "Wheat, Stephen R" wrote:
> 
> > Julian,
> >
> > Not to be pedantic, but, again, the arbitrary decision to avoid the
> > concatenation adds burden to the target side and restricts 
> the future
> > capability of key=values that exceed the max text PDU length.
> >
> > Again, the host side will need to buffer the input until it 
> has all arrived
> > anyway.  Is there a stronger technical reason for this 
> other than the
> > avoidance of concatenation?
> >
> > The approach you propose adds processing burden to every 
> action on a target
> > side to put a key=action into a PDU.  I envision the target 
> side having
> > contiguous memory to formulate the entire text response, 
> and it then sends
> > this in sequential PDUs.  Having to search for where a 
> key=value pair spans
> > the PDU boundary is work.
> >
> > Furthermore, being able to span PDUs facilitates a simpler 
> specification.
> >
> > Maybe Tow can explain the burden of concatenation.  If Tow 
> really doesn't
> > care, can we go back to allowing the records to span PDUs?
> >
> > Does anyone else care about this?
> >
> > Stephen
> >
> > -----Original Message-----
> > From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > Sent: Thursday, August 23, 2001 2:01 PM
> > To: ips@ece.cmu.edu
> > Subject: RE: Target record not to span PDUs?
> >
> > Bob,
> >
> > The record in question is a key=value pair. What Tow was 
> asking is a about
> > a way to avoid having to "concatenate
> > strings" from two Text responses that carry the SendTargets 
> answers one
> > after another and we have stated that
> > explicitly now.
> >
> > Julo
> >
> > Robert Snively <rsnively@Brocade.COM>@ece.cmu.edu on 
> 22-08-2001 19:00:18
> >
> > Please respond to Robert Snively <rsnively@Brocade.COM>
> >
> > Sent by:  owner-ips@ece.cmu.edu
> >
> > To:   Tow Wang <Tow_Wang@adaptec.com>, Julian Satran/Haifa/IBM@IBMIL
> > cc:   "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
> > Subject:  RE: Target record not to span PDUs?
> >
> > It sounds like there may be some confusion between "physical
> > data unit" (the TCP/IP frame) and "iSCSI Protocol Data Unit"
> > (the messaging unit for iSCSI).  I cannot see where Tom's
> > problem arises, since Protocol Data Units are very well
> > behaved and should not have the problems he is discussing.
> > You cannot complete Protocol Data Unit processing until you
> > know you have all of them and that useful information does not
> > span them.  The assembly of protocol data units into useful
> > complete messages should be done at a layer below that where
> > you interpret the contiguous bytes of data in the context of
> > the complete messages.  I think as a general rule that any
> > iSCSI action should be able to span PDUs, including the
> > Target Record.
> >
> > Bob
> >
> > > -----Original Message-----
> > > From: Tow Wang [mailto:Tow_Wang@adaptec.com]
> > > Sent: Tuesday, August 21, 2001 7:07 PM
> > > To: 'Julian Satran'
> > > Cc: 'ips@ece.cmu.edu'
> > > Subject: Target record not to span PDUs?
> > >
> > >
> > > Julian (and all):
> > >
> > > Hello. This is regarding draft 07; could we require that
> > > target records NOT span across
> > > PDU's if a text response for SendTargets is very long? Upon
> > > reading appendix E, it seems
> > > that a response (of 4096 bytes in length) could end with:
> > >
> > > [Begin data segment]
> > > ...
> > > TargetName=I.got.chopped.4096
> > > TargetAddress=10.1.1.45
> > > [End data segment]
> > >
> > > In the above case, one could not determine whether the
> > > address is IP V4 or V6. Even if it
> > > had had enough space to put in the whole address, port and
> > > group tag, one cannot parse and
> > > process the record until inspecting the data segment of the
> > > next text response PDU, and
> > > this would involve cumulative buffering, back-parsing, etc. I
> > > think the above complexity
> > > could be avoided, as I can't imagine any single record
> > > exceeding 4096 bytes in length.
> > >
> > > Tow Wang
> > >
> > >
> 
> 


From owner-ips@ece.cmu.edu  Thu Aug 23 21:58:30 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06172
	for <ips-archive@odin.ietf.org>; Thu, 23 Aug 2001 21:58:30 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7O16iN14045
	for ips-outgoing; Thu, 23 Aug 2001 21:06:44 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7O15ne13991
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 21:05:49 -0400 (EDT)
Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35])
	by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id SAA22639;
	Thu, 23 Aug 2001 18:05:36 -0700 (PDT)
Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19)
	id <Q8DQ7JY3>; Thu, 23 Aug 2001 18:05:35 -0700
Message-ID: <FFD40DB4943CD411876500508BAD027902993767@sj5-ex2.brocade.com>
From: Robert Snively <rsnively@Brocade.COM>
To: "'Black_David@emc.com'" <Black_David@emc.com>,
        Robert Snively
	 <rsnively@Brocade.COM>, ips@ece.cmu.edu
Subject: RE: IPS: FCIP & this list
Date: Thu, 23 Aug 2001 18:05:32 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

David,

That is perfect.  Ralph already provides both the text and
pdf versions of the standards path documents.  Shall he 
just send both up together next time?  For non-standards
path documents or for informational RFCs, would we be
able to use pdf alone?  The pdf format seems to be particularly
handy for tutorial diagrams which may be found in such 
documents.

Bob

> -----Original Message-----
> From: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Thursday, August 23, 2001 3:15 PM
> To: rsnively@brocade.com; ips@ece.cmu.edu
> Subject: RE: IPS: FCIP & this list
> 
> 
> Bob,
> 
> You left out the piece of Ralph's email which said
> that converting the intermediate PDFs to text was not
> feasible, hence only a PDF version will be available:
> 
> > The interim FCIP drafts and issues lists are maintained in PDF
> > format, amounting to between .2M and .5M of new material per 
> > week. Since this is Rome, they cannot be posted to this reflector.
> > It is totally impractical to translate the PDFs to text, sorry.
> 
> Submitting paired text and PDF documents to the I-D servers
> is fine, but keep in mind that the text version must be
> self-contained by the time it is last called in the WG (i.e.,
> only figures that are not crucial to understanding the
> document can be omitted from the text version).
> 
> > I would like to push the IETF to step up to their stated
> > flexibility in this area, if they have not already done so.
> 
> If you want those intermediate PDF versions on the I-D servers,
> you need to push Ralph to generate their text counterparts.
> The IETF secretariat stands ready to do what was promised.
> 
> Thanks,
> --David
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------
> 
> > -----Original Message-----
> > From: Robert Snively [mailto:rsnively@Brocade.COM]
> > Sent: Thursday, August 23, 2001 2:36 PM
> > To: Black_David@emc.com; ENDL_TX@computer.org; ips@ece.cmu.edu
> > Subject: RE: IPS: FCIP & this list
> > 
> > 
> > 
> > Dave,
> > 
> > At the open-mic session at the last IETF meeting, I specifically 
> > raised the issue of pdf as a documentation capability.  If I
> > interpreted the reply correctly, the primary document must
> > be text only.  However, versions of the documents in pdf format
> > were explicitly allowed in order to bring graphics and
> > better text formatting to the task of making the document
> > clearer.
> > 
> > >From that, I would have expected that, as long as you provided
> > paired txt and pdf documents, that they should both be
> > available on the IETF web-sites and registered through the
> > I-D servers.  In the case of personal drafts, it would be
> > even possible that only the pdf existed, since they would be
> > notes and supplemental texts to the txt formal drafts.
> > 
> > I would like to push the IETF to step up to their stated
> > flexibility in this area, if they have not already done so.
> > 
> > Bob
> > 
> > > That's a judgment call.  Actually sending the PDFs to the list
> > > or the I-D servers is a no-no, but it would be ok to put them
> > > on a web site and post URLs to the list, as long as new text
> > > versions of the draft do go to the I-D servers at reasonable
> > > intervals.  It would also be ok to keep the interim PDF versions
> > > private among the authors until the next major revision of
> > > the draft is ready for the I-D servers.  There's
> > > no requirement to make all working notes visible.
> > 
> 


From owner-ips@ece.cmu.edu  Thu Aug 23 21:59:21 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06187
	for <ips-archive@odin.ietf.org>; Thu, 23 Aug 2001 21:59:21 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7O12Vr13772
	for ips-outgoing; Thu, 23 Aug 2001 21:02:31 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7NMIWe02165
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 18:18:32 -0400 (EDT)
Received: from phys-ha0nwka.ebay.sun.com ([129.149.1.90])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA15189
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 16:18:27 -0600 (MDT)
Received: from sonnet (sonnet [129.149.161.67])
	by phys-ha0nwka.ebay.sun.com (8.10.2+Sun/8.10.2/ENSMAIL,v2.1p1) with SMTP id f7NMISY16614
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 15:18:29 -0700 (PDT)
Message-Id: <200108232218.f7NMISY16614@phys-ha0nwka.ebay.sun.com>
Date: Thu, 23 Aug 2001 15:18:30 -0700 (PDT)
From: JP Raghavendra Rao <Jp.Raghavendra@sun.com>
Reply-To: JP Raghavendra Rao <Jp.Raghavendra@sun.com>
Subject: RE: Target record not to span PDUs?
To: ips@ece.cmu.edu
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: bDyOHGIfMcNWC1ZsmB60FA==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc 
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


> The approach you propose adds processing burden to every action on a target
> side to put a key=action into a PDU.  I envision the target side having
> contiguous memory to formulate the entire text response, and it then sends
> this in sequential PDUs. 

I may have to disagree with this statement. The response is dynamic and
is based on the request (the keys that the initiator is interested in)
and it is already doing some work here, in decoding the key and deciding
an appropriate action/value for the key. Therefore, I don't believe it is
either difficult or too much work to adjust the PDU to contain a complete
key/value pair in one PDU. If they span multiple PDUs, the initiator
has to do additional to work to coalesce them into meaningful pairs,
and I don't see any major gains in trying to do that.

-JP

> 
> Bob,
> 
> The record in question is a key=value pair. What Tow was asking is a about
> a way to avoid having to "concatenate
> strings" from two Text responses that carry the SendTargets answers one
> after another and we have stated that
> explicitly now.
> 
> Julo
> 
> Robert Snively <rsnively@Brocade.COM>@ece.cmu.edu on 22-08-2001 19:00:18
> 
> Please respond to Robert Snively <rsnively@Brocade.COM>
> 
> Sent by:  owner-ips@ece.cmu.edu
> 
> 
> To:   Tow Wang <Tow_Wang@adaptec.com>, Julian Satran/Haifa/IBM@IBMIL
> cc:   "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
> Subject:  RE: Target record not to span PDUs?
> 
> 
> 
> It sounds like there may be some confusion between "physical
> data unit" (the TCP/IP frame) and "iSCSI Protocol Data Unit"
> (the messaging unit for iSCSI).  I cannot see where Tom's
> problem arises, since Protocol Data Units are very well
> behaved and should not have the problems he is discussing.
> You cannot complete Protocol Data Unit processing until you
> know you have all of them and that useful information does not
> span them.  The assembly of protocol data units into useful
> complete messages should be done at a layer below that where
> you interpret the contiguous bytes of data in the context of
> the complete messages.  I think as a general rule that any
> iSCSI action should be able to span PDUs, including the
> Target Record.
> 
> Bob
> 
> > -----Original Message-----
> > From: Tow Wang [mailto:Tow_Wang@adaptec.com]
> > Sent: Tuesday, August 21, 2001 7:07 PM
> > To: 'Julian Satran'
> > Cc: 'ips@ece.cmu.edu'
> > Subject: Target record not to span PDUs?
> >
> >
> > Julian (and all):
> >
> > Hello. This is regarding draft 07; could we require that
> > target records NOT span across
> > PDU's if a text response for SendTargets is very long? Upon
> > reading appendix E, it seems
> > that a response (of 4096 bytes in length) could end with:
> >
> > [Begin data segment]
> > ...
> > TargetName=I.got.chopped.4096
> > TargetAddress=10.1.1.45
> > [End data segment]
> >
> > In the above case, one could not determine whether the
> > address is IP V4 or V6. Even if it
> > had had enough space to put in the whole address, port and
> > group tag, one cannot parse and
> > process the record until inspecting the data segment of the
> > next text response PDU, and
> > this would involve cumulative buffering, back-parsing, etc. I
> > think the above complexity
> > could be avoided, as I can't imagine any single record
> > exceeding 4096 bytes in length.
> >
> > Tow Wang
> >
> >
> 


-JP


From owner-ips@ece.cmu.edu  Thu Aug 23 22:07:50 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06266
	for <ips-archive@odin.ietf.org>; Thu, 23 Aug 2001 22:07:50 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7O14fg13924
	for ips-outgoing; Thu, 23 Aug 2001 21:04:41 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7O0sIe13403
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 20:54:18 -0400 (EDT)
Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35])
	by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id RAA22104;
	Thu, 23 Aug 2001 17:54:03 -0700 (PDT)
Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19)
	id <Q8DQ7JSY>; Thu, 23 Aug 2001 17:54:03 -0700
Message-ID: <FFD40DB4943CD411876500508BAD027902993764@sj5-ex2.brocade.com>
From: Robert Snively <rsnively@Brocade.COM>
To: "'Black_David@emc.com'" <Black_David@emc.com>, sanjay_goyal@ivivity.com,
        ips@ece.cmu.edu
Subject: RE: iSCSI CRC: A CRC-checking example
Date: Thu, 23 Aug 2001 17:54:01 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

I've only been following this discussion loosely, but
it seems to me that the Ethernet byte and bit ordering
is dictated by a series of hardware choices made long ago.
On the other hand, the iSCSI byte and bit ordering is
taken from (or placed in) memory in a contiguous
byte/bit stream which is basically big-endian, regardless
of how it happens to be manipulated by the attached
processor.

I would imagine that we would choose the bit and byte
ordering convenient to the DMAing of the data into and
from memory.  I believe that most of these functions will
wind up in hardware that delivers a big-endian byte stream
to a TCP processor.  

So I would have expected that we would avoid any choice that
makes that less convenient.  The Ethernet approach to those
bytes would strike me as being the second-least convenient
approach.  Clearly, throwing hardware at this could correct
for that inconvenience, but it seems to me that any
optimizations we make should focus on what we want to do, not
what Ethernet did.

Bob

> -----Original Message-----
> From: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Thursday, August 23, 2001 3:31 PM
> To: sanjay_goyal@ivivity.com; ips@ece.cmu.edu
> Subject: RE: iSCSI CRC: A CRC-checking example
> 
> 
> From a practical standpoint, using the same implementation framework
> (for lack of a better word) as Ethernet reduces the opportunity
> to get this wrong - a designer who's done an Ethernet CRC does
> the same thing with the new CRC polynomial and the result works.
> 
> If this aspect of CRC usage "ain't broke", I would think
> that "don't fix it" is the preferred course of action ;-).
> 
> Thanks,
> --David
> 
> > -----Original Message-----
> > From: Douglas Otis [mailto:dotis@sanlight.net]
> > Sent: Thursday, August 23, 2001 5:43 PM
> > To: Sanjay Goyal; 'CAVANNA,VICENTE V (A-Roseville,ex1)'
> > Cc: ips@ece.cmu.edu
> > Subject: RE: iSCSI CRC: A CRC-checking example
> > 
> > 
> > Sanjay,
> > 
> > In short, the reflected table is likely to require fewer 
> instructions to
> > implement a lookup than a non-reflected table.  Secondly, 
> if the processor
> > is Little Endian, then the result is already in network 
> order without byte
> > swapping.  Obviously this last point only helps if you are 
> using a Little
> > Endian processor but this happens only once per packet 
> whereas the lookup
> > may happen every byte.  Third, the inverted store improves 
> the sensitivity
> > to the packet length.  All these Ethernet techniques seems 
> to be good
> > things.  One difference however is the polynomial.
> > 
> > Doug
> > 
> > > The last line says
> > >  "but I suppose it is advantageous to do things the ethernet way."
> > > May I know in what ways it would be advantageous.
> > >
> > > Regards
> > > Sanjay Goyal
> > >
> 


From owner-ips@ece.cmu.edu  Thu Aug 23 22:44:08 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07483
	for <ips-archive@odin.ietf.org>; Thu, 23 Aug 2001 22:44:08 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7O214J16315
	for ips-outgoing; Thu, 23 Aug 2001 22:01:04 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from c007.snv.cp.net (c007-h000.c007.snv.cp.net [209.228.33.206])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f7O212e16310
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 22:01:02 -0400 (EDT)
Received: (cpmta 2403 invoked from network); 23 Aug 2001 19:00:56 -0700
Received: from adsl-63-202-160-80.dsl.snfc21.pacbell.net (HELO littlejoy) (63.202.160.80)
  by smtp.telocity.com (209.228.33.206) with SMTP; 23 Aug 2001 19:00:56 -0700
X-Sent: 24 Aug 2001 02:00:56 GMT
From: "Douglas Otis" <dotis@sanlight.net>
To: "Robert Snively" <rsnively@Brocade.COM>, <Black_David@emc.com>,
        <sanjay_goyal@ivivity.com>, <ips@ece.cmu.edu>
Subject: RE: iSCSI CRC: A CRC-checking example
Date: Thu, 23 Aug 2001 18:59:09 -0700
Message-ID: <NEBBJGDMMLHHCIKHGBEJMELLCKAA.dotis@sanlight.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <FFD40DB4943CD411876500508BAD027902993764@sj5-ex2.brocade.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Bob,

If there is a hardware implementation at the memory bus level, then the
gates assembled to provide a workable solution will not be greatly affected
by the bit order except of course to accommodate whatever bit order was
defined.  In hardware, the polynomial will play a greater role than the bit
order as this becomes a parallel conversion.  It may mean tightening the
straps on the thinking cap when assigning terms.

Doug

> I've only been following this discussion loosely, but
> it seems to me that the Ethernet byte and bit ordering
> is dictated by a series of hardware choices made long ago.
> On the other hand, the iSCSI byte and bit ordering is
> taken from (or placed in) memory in a contiguous
> byte/bit stream which is basically big-endian, regardless
> of how it happens to be manipulated by the attached
> processor.
>
> I would imagine that we would choose the bit and byte
> ordering convenient to the DMAing of the data into and
> from memory.  I believe that most of these functions will
> wind up in hardware that delivers a big-endian byte stream
> to a TCP processor.
>
> So I would have expected that we would avoid any choice that
> makes that less convenient.  The Ethernet approach to those
> bytes would strike me as being the second-least convenient
> approach.  Clearly, throwing hardware at this could correct
> for that inconvenience, but it seems to me that any
> optimizations we make should focus on what we want to do, not
> what Ethernet did.
>
> Bob
>
> > -----Original Message-----
> > From: Black_David@emc.com [mailto:Black_David@emc.com]
> > Sent: Thursday, August 23, 2001 3:31 PM
> > To: sanjay_goyal@ivivity.com; ips@ece.cmu.edu
> > Subject: RE: iSCSI CRC: A CRC-checking example
> >
> >
> > From a practical standpoint, using the same implementation framework
> > (for lack of a better word) as Ethernet reduces the opportunity
> > to get this wrong - a designer who's done an Ethernet CRC does
> > the same thing with the new CRC polynomial and the result works.
> >
> > If this aspect of CRC usage "ain't broke", I would think
> > that "don't fix it" is the preferred course of action ;-).
> >
> > Thanks,
> > --David
> >
> > > -----Original Message-----
> > > From: Douglas Otis [mailto:dotis@sanlight.net]
> > > Sent: Thursday, August 23, 2001 5:43 PM
> > > To: Sanjay Goyal; 'CAVANNA,VICENTE V (A-Roseville,ex1)'
> > > Cc: ips@ece.cmu.edu
> > > Subject: RE: iSCSI CRC: A CRC-checking example
> > >
> > >
> > > Sanjay,
> > >
> > > In short, the reflected table is likely to require fewer
> > instructions to
> > > implement a lookup than a non-reflected table.  Secondly,
> > if the processor
> > > is Little Endian, then the result is already in network
> > order without byte
> > > swapping.  Obviously this last point only helps if you are
> > using a Little
> > > Endian processor but this happens only once per packet
> > whereas the lookup
> > > may happen every byte.  Third, the inverted store improves
> > the sensitivity
> > > to the packet length.  All these Ethernet techniques seems
> > to be good
> > > things.  One difference however is the polynomial.
> > >
> > > Doug
> > >
> > > > The last line says
> > > >  "but I suppose it is advantageous to do things the ethernet way."
> > > > May I know in what ways it would be advantageous.
> > > >
> > > > Regards
> > > > Sanjay Goyal
> > > >
> >
>



From owner-ips@ece.cmu.edu  Thu Aug 23 22:50:42 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07564
	for <ips-archive@odin.ietf.org>; Thu, 23 Aug 2001 22:50:42 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7O1moI15809
	for ips-outgoing; Thu, 23 Aug 2001 21:48:50 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from c007.snv.cp.net (c007-h011.c007.snv.cp.net [209.228.33.217])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f7O1mne15805
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 21:48:49 -0400 (EDT)
Received: (cpmta 11257 invoked from network); 23 Aug 2001 18:48:43 -0700
Received: from adsl-63-202-160-80.dsl.snfc21.pacbell.net (HELO littlejoy) (63.202.160.80)
  by smtp.telocity.com (209.228.33.217) with SMTP; 23 Aug 2001 18:48:43 -0700
X-Sent: 24 Aug 2001 01:48:43 GMT
From: "Douglas Otis" <dotis@sanlight.net>
To: "Tsvwg" <tsvwg@ietf.org>, "Ips" <ips@ece.cmu.edu>
Subject: SCTP CRC preliminary document
Date: Thu, 23 Aug 2001 18:46:56 -0700
Message-ID: <NEBBJGDMMLHHCIKHGBEJGELKCKAA.dotis@sanlight.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

All,

I have posted a preliminary document which implements the CRC algorithm used
in iSCSI for SCTP.  I would be interested in any comments or contributions.
For that matter, anyone that wants to be included in this effort is welcome.

ftp://ftp.sanlight.net/pub/draft-otis-sctp-crc32-00.txt

Doug



From owner-ips@ece.cmu.edu  Thu Aug 23 23:31:23 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08161
	for <ips-archive@odin.ietf.org>; Thu, 23 Aug 2001 23:31:19 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7O2VqW17732
	for ips-outgoing; Thu, 23 Aug 2001 22:31:52 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from smtp.alacritech.com (smtp.alacritech.com [209.10.208.82])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7O2Voe17728
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 22:31:51 -0400 (EDT)
Received: from hightop (hightop.alacritech.com [10.1.1.55])
	by smtp.alacritech.com (8.11.0/8.11.0) with SMTP id f7O2QcO02445;
	Thu, 23 Aug 2001 19:26:38 -0700
Reply-To: <joeg@alacritech.com>
From: "Joe Gervais" <joeg@alacritech.com>
To: "Robert Snively" <rsnively@Brocade.COM>, <Black_David@emc.com>,
        <sanjay_goyal@ivivity.com>, <ips@ece.cmu.edu>
Subject: RE: iSCSI CRC: A CRC-checking example
Date: Thu, 23 Aug 2001 19:21:21 -0700
Message-ID: <NEBBICMMGDBLDBIOBLPNMEDKEAAA.joeg@alacritech.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <FFD40DB4943CD411876500508BAD027902993764@sj5-ex2.brocade.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Bob,

If the data was going on token ring or some other media, sure, who cares
about an Ethernet approach, but the data is generally being sent and
received over Ethernet, and there is advantage at least in some
implementations to be in Ethernet bit/byte order.

Additionally, as David said earlier today, if it isn't broke, let's not fix
it. Can we get consensus and move on?

Joe
-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Robert Snively

... snip ...
So I would have expected that we would avoid any choice that
makes that less convenient.  The Ethernet approach to those
bytes would strike me as being the second-least convenient
approach.  Clearly, throwing hardware at this could correct
for that inconvenience, but it seems to me that any
optimizations we make should focus on what we want to do, not
what Ethernet did.

Bob




From owner-ips@ece.cmu.edu  Fri Aug 24 01:21:11 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11233
	for <ips-archive@odin.ietf.org>; Fri, 24 Aug 2001 01:21:11 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7O4Lmj22088
	for ips-outgoing; Fri, 24 Aug 2001 00:21:48 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7O24ce16496
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 22:04:38 -0400 (EDT)
Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35])
	by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id TAA26129
	for <ips@ece.cmu.edu>; Thu, 23 Aug 2001 19:04:31 -0700 (PDT)
Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19)
	id <Q8DQ7K9R>; Thu, 23 Aug 2001 19:04:31 -0700
Message-ID: <FFD40DB4943CD411876500508BAD02790299376C@sj5-ex2.brocade.com>
From: Robert Snively <rsnively@Brocade.COM>
To: ips@ece.cmu.edu
Subject: RE: iSCSI CRC: A CRC-checking example
Date: Thu, 23 Aug 2001 19:04:25 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

But Doug, that was what Dave was proposing we would not have to
do by copying Ethernet  :-)

> It may mean tightening the
> straps on the thinking cap when assigning terms.
> 
> Doug


From owner-ips@ece.cmu.edu  Fri Aug 24 01:23:38 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11608
	for <ips-archive@odin.ietf.org>; Fri, 24 Aug 2001 01:23:37 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7O4dgS22886
	for ips-outgoing; Fri, 24 Aug 2001 00:39:42 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7O4dee22877
	for <ips@ece.cmu.edu>; Fri, 24 Aug 2001 00:39:40 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id GAA116414
	for <ips@ece.cmu.edu>; Fri, 24 Aug 2001 06:39:33 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7O4dW436966
	for <ips@ece.cmu.edu>; Fri, 24 Aug 2001 06:39:32 +0200
Importance: Normal
Subject: Re: iSCSI: reusing ISID for recovery (Was: RE: iSCSI - Change - Login/Text...)
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF92C6B37D.D3C0EAE1-ONC2256AB2.0018DF5A@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Fri, 24 Aug 2001 07:39:00 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 24/08/2001 07:39:32
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Mallikarjun,

On  your point 1 that is what is stated today in the draft.

On your point 2 option C is the one we took in the draft, after some
debate.

Option A is prone to "wild closing of sessions" and option B is also
relaying to much on the good behaviour of the
client. It also introduces a "feature" that complicates login/logout.

Our postion on this is  that the initiator should logout the session
explicitly if it can (and in this case it can as the target has ascertained
that the session is alive).

I agree that you may want to update the stayte diagram to reflect this.

Julo


"Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on 24-08-2001 01:46:40

Please respond to cbm@rose.hp.com

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  iSCSI: reusing ISID for recovery (Was: RE: iSCSI - Change -
      Login/Text...)



Julian and all:

This thread mirrors another discussion some of us are
having in a different forum.  Following (two bullets 1
& 2 below) is what I proposed there, attempting to address
two issues -
     a) how to recover sessions when target and the initiator
           have conflicting views of the same TCP connection(s)?
           (Initiator NIC fails, but there's no I/O activity,
           and the target doesn't see any connection failure.)
     b) More specifically, how to address the above problem
           when the initiator *does not want* to re-instate failed
           connections since it only implements the mandatory
           session recovery?

This could add clarity or muddle things up here, though hopefully
the former...

1 If login is sent with the same ISID, same TSID, same CID and X-bit,
  then it means a failed connection is being re-instated (whether
  or not there are multiple connections in the session).  This login
  attempt must be done before the connection timeout (transition M1),
  or if this is the only connection in the session, also before the
  session timeout (transition N6) - to be counted as a connection
  reinstatement effort.
           o CmdSN counters (CmdSN, ExpCmdSN) are continued.  Initiator
             must do command plugging when there's a mismatch
             between its CmdSN and ExpCmdSN in the login response.
           o Since this is an implicit connection logout, all the active
             tasks on the connection are either internally terminated,
             or made non-allegiant (based on ErrorRecoveryLevel=x/y,
             TBD) for recovery.

2 If login is sent with the same ISID and TSID=0, the session (if it
  exists on the target) is being cleared and any active connections
  that the target sees must be immediately (at the end of the login
  process including any initiator authentication) transport reset.
  Initiator may attempt this only after it ascertains a session failure
  on its end (ie. all connections entered RECOVERY_START).
           o CmdSN counters get reset.  Initiator has to perform the
             currently defined session recovery actions.
           o All active tasks of the session are internally terminated.


Essentially, I was proposing extending the same notion of "implicit
logout" of a connection to the session level.  The options that I
see are -

       A) Should iSCSI let it happen by default as stated above (ie.
          same ISID, TSID=0 always wipes out the pre-existing session
          on target, since we are mandating it to be used only when
          initiator sees a session failure)?
       B) Should iSCSI mandate making this intended cleanup explicit
          by setting a bit (Say C-bit, for Clear) in the Login Command
          PDU to prevent an accidental session cleanup with a buggy
          initiator code?
       C) Should iSCSI merely state that targets must ascertain
          the connection state(s) whenever a new session creation
          attempt is made with a known ISID and TSID=0?  (sort of
          defeats the intention of the initiator wanting quicker
          session recovery since the Login command PDU would have
          to idle till target ascertains the connection state(s)).

I prefer A, or B.

Going with A or B means that the description of transition N3
in the session state diagram would have to change to:
     Last LOGGED_IN connection had ceased to be LOGGED_IN,
        or a Login Command requesting clearing the session (also
        with C-bit set, if option B) was received by the target.

The transition N7's description would have to be augmented as
well to:
        Session recovery attempt with an implicit logout,
        or connection reinstatement/new CID addition.

Comments?
--
Mallikarjun


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


>Stephen,
>
>That can happen as the target may set-up completely new TCP connections
>(the old sockets are still there and look OK).
>Untill the login is  progessing he assumes that this is just another
>open-session attempt. Then he checks the old session and the session is
>dead (initiator has closed the connections).
>
>The target has to distinguish only between a session that is alive (and
>reject the new one) and one that its dead in which case it can clean-up.
>
>Julo
>
>"Wheat, Stephen R" <stephen.r.wheat@intel.com> on 23-08-2001 22:50:56
>
>Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
>
>To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
>cc:
>Subject:  RE: iSCSI - Change - Login/Text commands with the binary stage
co
>          de
>
>
>
>Julian,
>
>I don't understand your answer.  For the scenario given, I would presume
>then that the target would reject the new session attempt, as it sees the
>previous session still "alive".  What is there to tell the target that
this
>is any different from when the Initiator is erroneously using the
>repetitive
>session id?
>
>Thanks,
>Stephen
>
>-----Original Message-----
>From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
>Sent: Thursday, August 23, 2001 11:15 AM
>To: ips@ece.cmu.edu
>Subject: Re: iSCSI - Change - Login/Text commands with the binary stage
>co de
>
>
>Stephen,
>
>1.If the initiator goes away for a while and reboots and there was no
>activity on the connections
>the target may see a session alive (I am not sure that it has to appear on
>the state diagram but maybe).
>
>2.Again - I am not sure that the curent state diagram includes death of
the
>initiator
>
>Julo
>
>"Wheat, Stephen R" <stephen.r.wheat@intel.com>@ece.cmu.edu on 23-08-2001
>19:58:34
>
>Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
>
>Sent by:  owner-ips@ece.cmu.edu
>
>
>To:   ips@ece.cmu.edu
>cc:
>Subject:  Re: iSCSI - Change - Login/Text commands with the binary stage
co
>      de
>
>
>
>Julian,
>
>1.3.6 ISID states that the target should check to see if the old session
is
>still active when a duplicate session is detected.
>
>I have two questions, the second only if you answer in the affirmative on
>the first ;^)
>
>1. Is there a properly executed sequence of events (i.e., no coding error
>on
>the target side) where the session is not active, but the target hadn't
>taken notice of it?  It appears this as a protocol-specified means to work
>around a flaw in a target's implementation.  I interpret the state diagram
>transitions as being atomic wrt other commands.  I.e., the last logout
>would
>result in the various transitions of the connection/session prior to the
>initiator starting the session up again.  And the target would have
>completed the transitions prior to handling a new session request.
>
>2. If you answered (1) in the affirmative, then the word "Active" is not
>consistent with the 6.3 Session State Diagram.  Does this mean the target
>got lost, due to transport failures of any sort, in its transition from
>Q3-to-Q2-to-Q1?  It sounds like the intent is to close the old session if
>the session was in Q2 or Q4, presuming if it were in Q1,  it would not
have
>been found as a duplicate.
>
>Stephen
>
>
>
>
>
>
>
>







From owner-ips@ece.cmu.edu  Fri Aug 24 01:23:57 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11668
	for <ips-archive@odin.ietf.org>; Fri, 24 Aug 2001 01:23:57 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7O4nEP23362
	for ips-outgoing; Fri, 24 Aug 2001 00:49:14 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7O4nCe23357
	for <ips@ece.cmu.edu>; Fri, 24 Aug 2001 00:49:12 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id GAA27304
	for <ips@ece.cmu.edu>; Fri, 24 Aug 2001 06:49:05 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7O4n4481668
	for <ips@ece.cmu.edu>; Fri, 24 Aug 2001 06:49:04 +0200
Importance: Normal
Subject: Re: iSCSI: Login Proposal
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF8312EBA5.800C466F-ONC2256AB2.0019BCC0@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Fri, 24 Aug 2001 07:48:33 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 24/08/2001 07:49:04
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Steve,

Reading Mathew's note regarding the fact that he knew and supported
introduction of explicit state
I thought that we are discussing only the modified parts as I sent them out
to the  list.

Julo

Steve Senum <ssenum@cisco.com>@ece.cmu.edu on 24-08-2001 02:09:29

Please respond to Steve Senum <ssenum@cisco.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ietf-ips <ips@ece.cmu.edu>
cc:
Subject:  Re: iSCSI: Login Proposal



Julian and Matthew:

Is was wondering what the status of this issue is?
Are both proposals still on the table?

Regards,
Steve Senum





From owner-ips@ece.cmu.edu  Fri Aug 24 02:14:40 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26084
	for <ips-archive@odin.ietf.org>; Fri, 24 Aug 2001 02:14:39 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7O56Sk24113
	for ips-outgoing; Fri, 24 Aug 2001 01:06:28 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7O56Pe24106
	for <ips@ece.cmu.edu>; Fri, 24 Aug 2001 01:06:26 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id HAA12570
	for <ips@ece.cmu.edu>; Fri, 24 Aug 2001 07:06:19 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7O56Ij222486
	for <ips@ece.cmu.edu>; Fri, 24 Aug 2001 07:06:18 +0200
Importance: Normal
Subject: RE: iSCSI - Change - Login/Text commands with the binary stage co	de
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFAD42E910.6D4D0019-ONC2256AB2.001A72E4@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Fri, 24 Aug 2001 08:04:38 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 24/08/2001 08:06:17
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Stephen,

I wonder if 123 words (your note) are really needed to say that bookmarks
have no role at all.

For an exchange going well  and on a single connection bookmarks are not
doing more that their paper counterpart. It is when things go wrong that
you need them.

Assume that you have the following sequence:

a)I->T text B=0
b)T->I text B=1 Bkmk1
c)I->T text B=1 Bkmk1
d)T->I text B=1 Bkmk2
e)I ->T...

Assume now that D got lost (digest) and the initiator reissues C.  Without
a Bookmark
the target will think that he got a prompt after D when in fact he got a
replay of C

In summary the bit acts like the paper bookmark and the bookmark field is
more like the word-processor bookmarks - it hold information relevant to
the party that built it.

Julo


"Wheat, Stephen R" <stephen.r.wheat@intel.com> on 24-08-2001 01:21:04

Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:
Subject:  RE: iSCSI - Change - Login/Text commands with the binary stage co
      de



OK; that makes more sense.

But now, why do we have it?  This whole discussion could have been avoided
if it wasn't there in the first place.  How many that follow me in reading
this will have the same questions?  Why should the spec provide something
that has no value in the execution of the spec?  It seems to me that this
is
superfluous, and as such doesn't belong in the spec.  I.e., this seems more
clearly a unnecessary item ever-more-so than alias.

Would you mind doing a query of the group as to who has objection to
removing the bookmark field?

I really hope my relatively new exposure to all of this has value to you
and
the other authors on the readability/clarity of the spec.

Thanks,
Stephen

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, August 23, 2001 11:10 AM
To: Wheat, Stephen R
Subject: RE: iSCSI - Change - Login/Text commands with the binary stage
co de


Stephen,

Bookmark is an opaque thing.  The initiator copies it dutifully from the
target.
The target may choose to put some information there or leave it 0 etc.

Regards,
Julo

"Wheat, Stephen R" <stephen.r.wheat@intel.com> on 23-08-2001 18:03:45

Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:
Subject:  RE: iSCSI - Change - Login/Text commands with the binary stage co
          de



Julian,

Thanks for your response.

OK, then if you follow your temptation, then the bookmark field goes away
and the B-bit does it all, yes?  Otherwise, I'm still missing the sequence
of events where the bookmark fields contributes to syncronization or
segregation or both.

Stephen

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, August 22, 2001 11:10 PM
To: Wheat, Stephen R
Subject: RE: iSCSI - Change - Login/Text commands with the binary stage
co de


Stephen,

I've fixed the 2 offending occurrences of Initiator Text Tag (It was a typo
- thanks).

The bookmark  was introduced to:

   relieve the target from the need to maintain state for a number of
   pending sequences - you can have only one bookmark (with some state in
   it) I am tempted to make it one bookmark/initiator
   allow to certify to the target that the initiator is still there and
   willing to get more information (when you clear the bookmark you can
   delete whatever state you maintained).


Regards,
Julo



"Wheat, Stephen R" <stephen.r.wheat@intel.com> on 22-08-2001 20:48:25

Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:
Subject:  RE: iSCSI - Change - Login/Text commands with the binary stage co
      de



Julian, just to you.

In a couple of places, this refers to "Initiator Text Tag".  What is that?
Is it a typo?

Also, I've been pondering the bookmark field.  Why does this field exist
beyond the B bit, if the bookmark's validity is invalidated by having
received a command with a different ITT?  There must be a scenario where
the
following doesn't work.  Please advise.


      I->T Text SendTargets=all (F=1,B=0)
      T->I Text <part 1> (F=0,B=1)
      I->T Text <empty> (F=1,B=1)
      T->I Text <part 2> (F=0,B=1)
      I->T Text <empty> (F=1,B=1)
      ...
      T->I Text <part n> (F=1,B=0)

Thanks,
Stephen

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, August 22, 2001 1:30 AM
To: ips@ece.cmu.edu
Subject: iSCSI - Change - Login/Text commands with the binary stage code


1.1.5     Bookmark

   An opaque handle copied from a previous text response.  It is supposed
   to allow a target to transfer a large amount of textual data over a
   sequence of text-command/text-response exchanges.  The target associates
   the bookmark it issues with the Initiator Task Tag and a received
   Bookmark is considered valid by the Target only if received with the
   same Initiator Task Tag and if the target did not receive on the same
   connection a text command with a different Initiator Text Tag since it
*************                                           ^^^^ ????
   issued the Bookmark.













From owner-ips@ece.cmu.edu  Fri Aug 24 07:47:05 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00511
	for <ips-archive@odin.ietf.org>; Fri, 24 Aug 2001 07:47:04 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7OAr8O22358
	for ips-outgoing; Fri, 24 Aug 2001 06:53:08 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from chmls16.mediaone.net (chmls16.mediaone.net [24.147.1.151])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7OAr6e22354
	for <ips@ece.cmu.edu>; Fri, 24 Aug 2001 06:53:06 -0400 (EDT)
Received: from breinhold ([140.186.66.73])
	by chmls16.mediaone.net (8.11.1/8.11.1) with SMTP id f7OAqrT11458;
	Fri, 24 Aug 2001 06:52:53 -0400 (EDT)
From: "Barry Reinhold" <bbrtrebia@mediaone.net>
To: "Julian Satran" <Julian_Satran@il.ibm.com>, <ips@ece.cmu.edu>
Subject: RE: iSCSI: Login Proposal
Date: Fri, 24 Aug 2001 06:54:02 -0400
Message-ID: <BJEIKPAFDFPFNCPPBCGPIEKECKAA.bbrtrebia@mediaone.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
In-Reply-To: <OF8312EBA5.800C466F-ONC2256AB2.0019BCC0@telaviv.ibm.com>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Does this mean that we are not considering the login code sent out by
Matthew as a proposal?

>-----Original Message-----
>From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
>Julian Satran
>Sent: Friday, August 24, 2001 12:49 AM
>To: ips@ece.cmu.edu
>Subject: Re: iSCSI: Login Proposal
>
>
>
>Steve,
>
>Reading Mathew's note regarding the fact that he knew and supported
>introduction of explicit state
>I thought that we are discussing only the modified parts as I sent them out
>to the  list.
>
>Julo
>
>Steve Senum <ssenum@cisco.com>@ece.cmu.edu on 24-08-2001 02:09:29
>
>Please respond to Steve Senum <ssenum@cisco.com>
>
>Sent by:  owner-ips@ece.cmu.edu
>
>
>To:   ietf-ips <ips@ece.cmu.edu>
>cc:
>Subject:  Re: iSCSI: Login Proposal
>
>
>
>Julian and Matthew:
>
>Is was wondering what the status of this issue is?
>Are both proposals still on the table?
>
>Regards,
>Steve Senum
>
>
>



From owner-ips@ece.cmu.edu  Fri Aug 24 09:48:20 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04981
	for <ips-archive@odin.ietf.org>; Fri, 24 Aug 2001 09:48:20 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7OCvgq28396
	for ips-outgoing; Fri, 24 Aug 2001 08:57:42 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7OCvfe28391
	for <ips@ece.cmu.edu>; Fri, 24 Aug 2001 08:57:41 -0400 (EDT)
Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <RNJ8QSHY>; Fri, 24 Aug 2001 08:57:35 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD663@CORPMX14>
From: Black_David@emc.com
To: rsnively@Brocade.COM, ips@ece.cmu.edu
Subject: RE: IPS: FCIP & this list
Date: Fri, 24 Aug 2001 08:51:39 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

> That is perfect.  Ralph already provides both the text and
> pdf versions of the standards path documents.  Shall he 
> just send both up together next time?

I presume this refers to submission of the next version of
the draft to the Internet-Draft servers.  The answer is "yes"
- send both versions to internet-drafts@ietf.org in one message.

> For non-standards
> path documents or for informational RFCs, would we be
> able to use pdf alone?  The pdf format seems to be particularly
> handy for tutorial diagrams which may be found in such 
> documents.

A text version is still required, but there should be significantly
more leeway available in leaving diagrams out of the text version
because the document's not standards track.

--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


From owner-ips@ece.cmu.edu  Fri Aug 24 09:52:24 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05036
	for <ips-archive@odin.ietf.org>; Fri, 24 Aug 2001 09:52:24 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7ODC8i29197
	for ips-outgoing; Fri, 24 Aug 2001 09:12:08 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7ODC6e29191
	for <ips@ece.cmu.edu>; Fri, 24 Aug 2001 09:12:06 -0400 (EDT)
Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <RNJ8QTL0>; Fri, 24 Aug 2001 09:12:01 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD664@CORPMX14>
From: Black_David@emc.com
To: ips@ece.cmu.edu
Subject: RE: iSCSI: Login Proposal
Date: Fri, 24 Aug 2001 09:06:05 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

> Does this mean that we are not considering the login code sent out by
> Matthew as a proposal?

I'm not sure.  The revised text that Julian sent out is in accordance
with the direction set in the London meeting.  I would suggest that the
right thing is for Matthew and team to update their proposal to be based
on the new text from Julian and submit the result as an Internet-Draft
so that we can track changes to their proposal.  The biggest virtue
of an internet draft is that it provides a stable point of reference
for a multi-week discussion on the list, which may be necessary for
login.  Ok?

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


From owner-ips@ece.cmu.edu  Fri Aug 24 11:06:27 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06557
	for <ips-archive@odin.ietf.org>; Fri, 24 Aug 2001 11:06:27 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7OE0Ig02017
	for ips-outgoing; Fri, 24 Aug 2001 10:00:18 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7OE0Ge02008
	for <ips@ece.cmu.edu>; Fri, 24 Aug 2001 10:00:16 -0400 (EDT)
Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA20922; Fri, 24 Aug 2001 09:56:13 -0400 (EDT)
Message-ID: <3B865B5B.AC276F90@cisco.com>
Date: Fri, 24 Aug 2001 08:49:15 -0500
From: Mark Bakke <mbakke@cisco.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686)
X-Accept-Language: en, de
MIME-Version: 1.0
To: joeg@alacritech.com
CC: Robert Snively <rsnively@Brocade.COM>, Black_David@emc.com,
        sanjay_goyal@ivivity.com, ips@ece.cmu.edu
Subject: Re: iSCSI CRC: A CRC-checking example
References: <NEBBICMMGDBLDBIOBLPNMEDKEAAA.joeg@alacritech.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

I agree with Joe.  Whether to reflect, complement, or
whatever makes no important difference for either a table-
driven software implementation, nor for a hardware
implementation; at least not important enough to tell our
grandkids about someday.

The important thing is that we have finally specified
the algorithm, and have clear examples that everyone's
implementation matches, so this will actually interoperate.

The rest just doesn't matter.

Let's please move on.

--
Mark

Joe Gervais wrote:
> 
> Bob,
> 
> If the data was going on token ring or some other media, sure, who cares
> about an Ethernet approach, but the data is generally being sent and
> received over Ethernet, and there is advantage at least in some
> implementations to be in Ethernet bit/byte order.
> 
> Additionally, as David said earlier today, if it isn't broke, let's not fix
> it. Can we get consensus and move on?
> 
> Joe
> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Robert Snively
> 
> ... snip ...
> So I would have expected that we would avoid any choice that
> makes that less convenient.  The Ethernet approach to those
> bytes would strike me as being the second-least convenient
> approach.  Clearly, throwing hardware at this could correct
> for that inconvenience, but it seems to me that any
> optimizations we make should focus on what we want to do, not
> what Ethernet did.
> 
> Bob

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054


From owner-ips@ece.cmu.edu  Fri Aug 24 15:02:24 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12599
	for <ips-archive@odin.ietf.org>; Fri, 24 Aug 2001 15:02:20 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7OHaKD16670
	for ips-outgoing; Fri, 24 Aug 2001 13:36:20 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7OHaFP16663
	for <ips@ece.cmu.edu>; Fri, 24 Aug 2001 13:36:15 -0400 (EDT)
Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77])
	by msgbas2.cos.agilent.com (Postfix) with ESMTP
	id E2362AA2; Fri, 24 Aug 2001 11:36:14 -0600 (MDT)
Received: from axcsbh2.cos.agilent.com (axcsbh2.cos.agilent.com [130.29.152.144])
	by msgrel1.cos.agilent.com (Postfix) with SMTP
	id AFE2E7C5; Fri, 24 Aug 2001 11:36:04 -0600 (MDT)
Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Fri, 24 Aug 2001 11:36:04 -0600 (Mountain Daylight Time)
Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19)
	id <Q9QTXY54>; Fri, 24 Aug 2001 11:36:04 -0600
Message-ID: <1BEBA5E8600DD4119A50009027AF54A007811CEA@axcs04.cos.agilent.com>
From: "THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>
To: joeg@alacritech.com, Robert Snively <rsnively@Brocade.COM>,
        Black_David@emc.com, sanjay_goyal@ivivity.com, ips@ece.cmu.edu
Subject: RE: iSCSI CRC: A CRC-checking example
Date: Fri, 24 Aug 2001 11:36:02 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Joe and Bob,

I doubt that any implementation today will be doing CRC computation in a bit
serial circuit. The computation is generally done either byte parallel or,
increasingly, multi-byte parallel. The order in which the bits of a byte are
assigned to polynomial coefficients makes no difference to byte parallel CRC
implementation complexity. The only time complexity would be effected by bit
order is when one was doing a serial shift register implementation of the
CRC generator as some of the earliest Ethernet implementations did. The
technical reasons which applied to Ethernet in chosing the CRC bit checking
order, burst protection and serial implementation complexity, don't apply to
iSCSI.

The only reason for choosing one bit order over another for iSCSI CRC
checking is the limits of human comprehension. Which bit order is most
likely to be gotten right by the humans implementing the standard?

 Ethernet 
          + many people are already accustomed to its bit order
          - most significant byte first, least significant bit first can
cause confusion
 Most significant everything first 
          + more internally consistent than Ethernet
          - different from Ethernet

The most important thing is that we specify whichever one we chose as
clearly as possible.

Regards,
Pat 
             

-----Original Message-----
From: Joe Gervais [mailto:joeg@alacritech.com]
Sent: Thursday, August 23, 2001 7:21 PM
To: Robert Snively; Black_David@emc.com; sanjay_goyal@ivivity.com;
ips@ece.cmu.edu
Subject: RE: iSCSI CRC: A CRC-checking example


Bob,

If the data was going on token ring or some other media, sure, who cares
about an Ethernet approach, but the data is generally being sent and
received over Ethernet, and there is advantage at least in some
implementations to be in Ethernet bit/byte order.

Additionally, as David said earlier today, if it isn't broke, let's not fix
it. Can we get consensus and move on?

Joe
-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Robert Snively

... snip ...
So I would have expected that we would avoid any choice that
makes that less convenient.  The Ethernet approach to those
bytes would strike me as being the second-least convenient
approach.  Clearly, throwing hardware at this could correct
for that inconvenience, but it seems to me that any
optimizations we make should focus on what we want to do, not
what Ethernet did.

Bob



From owner-ips@ece.cmu.edu  Fri Aug 24 15:51:50 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13928
	for <ips-archive@odin.ietf.org>; Fri, 24 Aug 2001 15:51:50 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7OIXMG20584
	for ips-outgoing; Fri, 24 Aug 2001 14:33:22 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7OIXHP20576
	for <ips@ece.cmu.edu>; Fri, 24 Aug 2001 14:33:17 -0400 (EDT)
Received: from nc8220exchange.ral.lucent.com (h135-92-100-21.lucent.com [135.92.100.21])
	by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f7OIXBw15909
	for <ips@ece.cmu.edu>; Fri, 24 Aug 2001 14:33:11 -0400 (EDT)
Content-Class: urn:content-classes:message
Subject:  Interim meeting MIB working session
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Fri, 24 Aug 2001 14:33:10 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Message-ID: <9410A0F67DFE7F4D998D45382364983604085A@nc8220exchange.ral.lucent.com>
Thread-Topic: Attendance at Interim meeting/MIB working session
Thread-Index: AcEkLoqZ0DtwBdceSqSElY+LIk2WSQAk9mpAAgCeTnA=
From: "Elizabeth Rodriguez" <egrodriguez@lucent.com>
To: "Elizabeth Rodriguez" <Elizabeth.Rodriguez@nc8220exch1.ral.lucent.com>,
        "Anil Rijhsinghani (E-mail)" <anil.rijhsinghani@mcdata.com>,
        "Mark Bakke" <mbakke@cisco.com>,
        "Marjorie Krueger (E-mail)" <marjorie_krueger@hp.com>,
        "Kevin Gibbons" <kgibbons@NishanSystems.com>,
        "Joshua Tseng" <jtseng@NishanSystems.com>,
        "Charles Monia" <cmonia@NishanSystems.com>,
        "ISCSI MIB" <iscsi-mib@external.cisco.com>,
        "Ravi Natarajan (E-mail)" <ravin@lightsand.com>,
        "Sudar Akkala (E-mail)" <sudara@lightsand.com>,
        "Todd Sperry (E-mail)" <Todd_Sperry@adaptec.com>
Cc: "David Black (E-mail)" <black_david@emc.com>,
        "Keith McCloghrie (E-mail)" <kzm@cisco.com>,
        "Franco Travostino (E-mail)" <travos@nortelnetworks.com>,
        "Murali Rajagopal (E-mail)" <muralir@lightsand.com>,
        "John Harper (E-mail)" <jharper2@lucent.com>,
        "IPS Mailing List (E-mail)" <ips@ece.cmu.edu>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f7OIXIP20577
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit

Hi all,

Keith McCloghrie is a Technical Advisor to the IPS Working Group, with
expertise in MIB development.  He has agreed to hold a working session
on Monday evening next week for those people involved in MIB work.
(Exact room and time still being determined.  Likely to start at around
7 pm.  Notice will be put on IPS WG Meeting room to indicate location.)

This will be held outside the IPS WG interim meeting, since it is a
educational type of meeting, focusing on MIB structure type issues, in
other words, SMI, syntax, structure, IETF recommendations for MIBs, and
general advice.  It is not going to focus on the content of the MIBs
themselves.

In order to prepare, Keith has asked for questions from MIB authors.  He
does not know what is the experience levels and backgrounds of the MIB
authors in this area and needs a better understanding of what kinds of
questions the authors have.

IPS WG:  This email is targeted to known IPS MIB authors.  If there are
others that are working/going to be working on IPS MIBs.

Thanks,

Elizabeth Rodriguez & 
David Black


From owner-ips@ece.cmu.edu  Fri Aug 24 20:11:54 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17199
	for <ips-archive@odin.ietf.org>; Fri, 24 Aug 2001 20:11:54 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7OMt5j09114
	for ips-outgoing; Fri, 24 Aug 2001 18:55:05 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7OMt4P09110
	for <ips@ece.cmu.edu>; Fri, 24 Aug 2001 18:55:04 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-68-173.cisco.com [161.44.68.173]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id SAA01662 for <ips@ece.cmu.edu>; Fri, 24 Aug 2001 18:54:58 -0400 (EDT)
Message-ID: <3B86DB37.FD2DDDFB@cisco.com>
Date: Fri, 24 Aug 2001 17:54:47 -0500
From: Steve Senum <ssenum@cisco.com>
X-Mailer: Mozilla 4.73 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-ips <ips@ece.cmu.edu>
Subject: Re: iSCSI - Change - Login/Text commands with the binary stage code
References: <OF82FB686A.05CE2141-ONC2256AB0.002CEF1A@telaviv.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Julian,

A have two questions on your proposal with respect to the
new CNxSG field.

1. In the section:

>    Stage transition is performed through a command exchange
>    (request/response) carrying the F bit and the same current stage code.
>    During this exchange, the next stage selected is the lower of the two
>    next stage codes.  The initiator can request a transition whenever it is
>    ready but a target can respond with a transition only after it is
>    offered one by the initiator.

I assume from this that the target must always return the
same "current stage" as the initiator, so there is no
way for the stages to go backwards (which is fine with me).

2. In the section:

>    If the initiator is willing no negotiate security but it is unwilling to
>    make the initial parameter offer and may accept a connection without
>    security it issues the Login with the F bit set to 1, the CNxSG set to
>    SecurityNegotiation in the current stage and LoginOperationalNegotiation
>    in the next stage. If the target is also ready to forego security the
>    Login response is empty and has F bit is set to 1 and the CNxSG set to
>    SecurityNegotiation in the current stage and LoginOperationalNegotiation
>    in the next stage.

So, if the initiator opens with:

I-> Login (CNxSG=0,1 F=1)

And the target responds with:

T-> Login-PR (CNxSG=0,1 F=0) AuthMethod=CHAP

And the initiator responds with:

I-> Text (CNxSG=0,1 F=0) AuthMethod=CHAP

The target should respond with a blank text message?

T-> Text (CNxSG=0,1 F=0)

Since all of the AuthMethods in Appendix A specify
that the initiator MUST start the authentication sequence
(which is fine with me).

Regards,
Steve Senum


From owner-ips@ece.cmu.edu  Fri Aug 24 20:15:05 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17239
	for <ips-archive@odin.ietf.org>; Fri, 24 Aug 2001 20:15:04 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7ONURL10595
	for ips-outgoing; Fri, 24 Aug 2001 19:30:27 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7ONUPP10590
	for <ips@ece.cmu.edu>; Fri, 24 Aug 2001 19:30:25 -0400 (EDT)
Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id XAA26231
	for <ips@ece.cmu.edu>; Fri, 24 Aug 2001 23:30:24 GMT
Received: from fmsmsx19.fm.intel.com ([132.233.48.19])
 by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001082416291732073
 for <ips@ece.cmu.edu>; Fri, 24 Aug 2001 16:29:17 -0700
Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <RJ8VPP6K>; Fri, 24 Aug 2001 16:30:23 -0700
Message-ID: <C763901E8272D411962F009027AE9D3E0905D396@FMSMSX36>
From: "Harbin, Donald B" <donald.b.harbin@intel.com>
To: "Ietf-Ips (E-mail)" <ips@ece.cmu.edu>
Subject: iSCSI: Text Keys
Date: Fri, 24 Aug 2001 16:30:21 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

two questions:
1) section 2.8.5: "Some basic key=value pairs are described in Appendix A
and D. All of these keys, except for the X- extension format, MUST be
supported by iSCSI initiators and targets."
This led me on a hunt to find the "other" basic pairs.  I don't beleive
there are any others after reviewing the spec(s). Thus, my question.  Are
there "other" (excluding the X- extensions) basic pairs defined somewhere
else?  If not, I would like the group to consider rewording the above to be
more absolute.
                   "ALL basic key=value pairs are DEFINED in Appendix A and
D."
2) App D #'s 12 & 17 both have the same name {TargetAddress}.  Is it
possible to either combine them OR give them unique names?
thanks don


From owner-ips@ece.cmu.edu  Fri Aug 24 21:37:11 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18809
	for <ips-archive@odin.ietf.org>; Fri, 24 Aug 2001 21:37:10 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7P0SEf12916
	for ips-outgoing; Fri, 24 Aug 2001 20:28:14 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from siaar1ab.compuserve.com (siaar1ab.compuserve.com [149.174.40.10])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7P0SCP12911
	for <ips@ece.cmu.edu>; Fri, 24 Aug 2001 20:28:12 -0400 (EDT)
Received: (from mailgate@localhost)
	by siaar1ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id UAA07664
	for ips@ece.cmu.edu; Fri, 24 Aug 2001 20:28:05 -0400 (EDT)
Received: from compuserve.com (dal-tgn-tvq-vty5.as.wcom.net [216.192.240.5])
	by siaar1ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id UAA07633
	for <ips@ece.cmu.edu>; Fri, 24 Aug 2001 20:27:52 -0400 (EDT)
Message-ID: <3B86F21D.F5617302@compuserve.com>
Date: Fri, 24 Aug 2001 19:32:29 -0500
From: Ralph Weber <ralphoweber@compuserve.com>
Reply-To: ENDL_TX@computer.org
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47  (Win95; I)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: IPS Reflector <ips@ece.cmu.edu>
Subject: FCIP: PDF files
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

David, Bob,

There are many PDF files generated in relation to the
FCIP work, just ask Larry Lamers he is keeping a tally
of the megabytes.

A pair of TXT/PDF files can be and has been generated
for the 05 revision of FCIP.  Both of these files can
be found on Julian's web site. The text in both is
identical (and the pagination is close to +/- three words).
However, the PDF file contains changes bars.  In the case
of the draft-ietf-ips-fcovertcpip-05 on Julian's web site,
the change bars reflect changes since 04.

Hopefully, change bars are considered non-substantive
by the I-D office and the PDF can still go through.

The development process for FCIP employs several other
PDF files.  In all cases, the text is the text for the
interim draft (and a .txt file can easily be generated
with the same text).  What is missing from the text files
are the working notes and discussion issues.

My understanding is that it is the working notes that
are of key importance to this reflector, and that the
I-D office is not the issue here.

Still, I would guess that the I-D office would judge the
working notes annotations in the PDF files as non-substantive
too, as what the draft says is still available in text form.

What is not available in text form and what I am not willing
to convert to text form in any meaningful way are the working
notes, which as noted above appear to be the critical issue
vis-a-vis this reflector.

One would not put these in the draft and the notes without
pointers to the draft text (implicit in the PDF) are meaningless.

Having heard no objections to posting the interim PDF
files on the T11 web site and mailing pointers to this
reflector, I plan to implement that mechanism following
the interim meeting.

Thanks.

Ralph...




From owner-ips@ece.cmu.edu  Fri Aug 24 21:38:58 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18824
	for <ips-archive@odin.ietf.org>; Fri, 24 Aug 2001 21:38:58 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7P0vwA14102
	for ips-outgoing; Fri, 24 Aug 2001 20:57:58 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7P0vvP14097
	for <ips@ece.cmu.edu>; Fri, 24 Aug 2001 20:57:57 -0400 (EDT)
Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190])
	by atlrel1.hp.com (Postfix) with ESMTP id DD4BC4D3
	for <ips@ece.cmu.edu>; Fri, 24 Aug 2001 20:57:52 -0400 (EDT)
Received: from xatlbh3.atl.hp.com (xatlbh3.atl.hp.com [15.45.89.188])
	by xatlrelay1.atl.hp.com (Postfix) with ESMTP id 82C561F550
	for <ips@ece.cmu.edu>; Fri, 24 Aug 2001 20:57:51 -0400 (EDT)
Received: by xatlbh3.atl.hp.com with Internet Mail Service (5.5.2653.19)
	id <RMA2GXA0>; Fri, 24 Aug 2001 20:57:51 -0400
Message-ID: <6BD67FFB937FD411A04F00D0B74FE87802A0927D@xrose06.rose.hp.com>
From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
To: ips@ece.cmu.edu
Subject: RE: iSCSI: reusing ISID for recovery
Date: Fri, 24 Aug 2001 20:51:43 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

I don't see how Option A is prone to "wild closing of sessions".  The target
is only looking for sessions with this particular initiator and closing them
if the ISID matches.

If an initiator doesn't have a valid TSID (login w/TSID=0), it means it has
lost state entirely (reboot) or knows it wants to immediately reset a
session (NIC failure).  How could there possibly be a case where the
initiator has an active valid session with the same ISID, but just doesn't
know about it??  Rejecting the login seems pointless, since obviously the
initiator either has a bug or intends to quickly reset the session. 

The behavior chosen (Option C) will cause the initiator's recovery to be
delayed while the target NOPs all the connections and waits for them to time
out - this will only delay the initiators recovery unnecessarily.  I can't
help but think this will cause long term problems for the protocol.

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: marjorie_krueger@hp.com 

> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Thursday, August 23, 2001 9:39 PM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI: reusing ISID for recovery (Was: RE: iSCSI 
> - Change -
> Login/Text...)
> 
> 
> 
> Mallikarjun,
> 
> On  your point 1 that is what is stated today in the draft.
> 
> On your point 2 option C is the one we took in the draft, after some
> debate.
> 
> Option A is prone to "wild closing of sessions" and option B is also
> relaying to much on the good behaviour of the
> client. It also introduces a "feature" that complicates login/logout.
> 
> Our postion on this is  that the initiator should logout the session
> explicitly if it can (and in this case it can as the target 
> has ascertained
> that the session is alive).
> 
> I agree that you may want to update the stayte diagram to 
> reflect this.
> 
> Julo
> 
> 
> "Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on 24-08-2001 01:46:40
> 
> Please respond to cbm@rose.hp.com
> 
> Sent by:  owner-ips@ece.cmu.edu
> 
> 
> To:   ips@ece.cmu.edu
> cc:
> Subject:  iSCSI: reusing ISID for recovery (Was: RE: iSCSI - Change -
>       Login/Text...)
> 
> 
> 
> Julian and all:
> 
> This thread mirrors another discussion some of us are
> having in a different forum.  Following (two bullets 1
> & 2 below) is what I proposed there, attempting to address
> two issues -
>      a) how to recover sessions when target and the initiator
>            have conflicting views of the same TCP connection(s)?
>            (Initiator NIC fails, but there's no I/O activity,
>            and the target doesn't see any connection failure.)
>      b) More specifically, how to address the above problem
>            when the initiator *does not want* to re-instate failed
>            connections since it only implements the mandatory
>            session recovery?
> 
> This could add clarity or muddle things up here, though hopefully
> the former...
> 
> 1 If login is sent with the same ISID, same TSID, same CID and X-bit,
>   then it means a failed connection is being re-instated (whether
>   or not there are multiple connections in the session).  This login
>   attempt must be done before the connection timeout (transition M1),
>   or if this is the only connection in the session, also before the
>   session timeout (transition N6) - to be counted as a connection
>   reinstatement effort.
>            o CmdSN counters (CmdSN, ExpCmdSN) are continued.  
> Initiator
>              must do command plugging when there's a mismatch
>              between its CmdSN and ExpCmdSN in the login response.
>            o Since this is an implicit connection logout, all 
> the active
>              tasks on the connection are either internally terminated,
>              or made non-allegiant (based on ErrorRecoveryLevel=x/y,
>              TBD) for recovery.
> 
> 2 If login is sent with the same ISID and TSID=0, the session (if it
>   exists on the target) is being cleared and any active connections
>   that the target sees must be immediately (at the end of the login
>   process including any initiator authentication) transport reset.
>   Initiator may attempt this only after it ascertains a 
> session failure
>   on its end (ie. all connections entered RECOVERY_START).
>            o CmdSN counters get reset.  Initiator has to perform the
>              currently defined session recovery actions.
>            o All active tasks of the session are internally 
> terminated.
> 
> 
> Essentially, I was proposing extending the same notion of "implicit
> logout" of a connection to the session level.  The options that I
> see are -
> 
>        A) Should iSCSI let it happen by default as stated above (ie.
>           same ISID, TSID=0 always wipes out the pre-existing session
>           on target, since we are mandating it to be used only when
>           initiator sees a session failure)?
>        B) Should iSCSI mandate making this intended cleanup explicit
>           by setting a bit (Say C-bit, for Clear) in the Login Command
>           PDU to prevent an accidental session cleanup with a buggy
>           initiator code?
>        C) Should iSCSI merely state that targets must ascertain
>           the connection state(s) whenever a new session creation
>           attempt is made with a known ISID and TSID=0?  (sort of
>           defeats the intention of the initiator wanting quicker
>           session recovery since the Login command PDU would have
>           to idle till target ascertains the connection state(s)).
> 
> I prefer A, or B.
> 
> Going with A or B means that the description of transition N3
> in the session state diagram would have to change to:
>      Last LOGGED_IN connection had ceased to be LOGGED_IN,
>         or a Login Command requesting clearing the session (also
>         with C-bit set, if option B) was received by the target.
> 
> The transition N7's description would have to be augmented as
> well to:
>         Session recovery attempt with an implicit logout,
>         or connection reinstatement/new CID addition.
> 
> Comments?
> --
> Mallikarjun
> 
> 
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> MS 5668   Hewlett-Packard, Roseville.
> cbm@rose.hp.com
> 
> 
> >Stephen,
> >
> >That can happen as the target may set-up completely new TCP 
> connections
> >(the old sockets are still there and look OK).
> >Untill the login is  progessing he assumes that this is just another
> >open-session attempt. Then he checks the old session and the 
> session is
> >dead (initiator has closed the connections).
> >
> >The target has to distinguish only between a session that is 
> alive (and
> >reject the new one) and one that its dead in which case it 
> can clean-up.
> >
> >Julo
> >
> >"Wheat, Stephen R" <stephen.r.wheat@intel.com> on 23-08-2001 22:50:56
> >
> >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> >
> >To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> >cc:
> >Subject:  RE: iSCSI - Change - Login/Text commands with the 
> binary stage
> co
> >          de
> >
> >
> >
> >Julian,
> >
> >I don't understand your answer.  For the scenario given, I 
> would presume
> >then that the target would reject the new session attempt, 
> as it sees the
> >previous session still "alive".  What is there to tell the 
> target that
> this
> >is any different from when the Initiator is erroneously using the
> >repetitive
> >session id?
> >
> >Thanks,
> >Stephen
> >
> >-----Original Message-----
> >From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> >Sent: Thursday, August 23, 2001 11:15 AM
> >To: ips@ece.cmu.edu
> >Subject: Re: iSCSI - Change - Login/Text commands with the 
> binary stage
> >co de
> >
> >
> >Stephen,
> >
> >1.If the initiator goes away for a while and reboots and there was no
> >activity on the connections
> >the target may see a session alive (I am not sure that it 
> has to appear on
> >the state diagram but maybe).
> >
> >2.Again - I am not sure that the curent state diagram 
> includes death of
> the
> >initiator
> >
> >Julo
> >
> >"Wheat, Stephen R" <stephen.r.wheat@intel.com>@ece.cmu.edu 
> on 23-08-2001
> >19:58:34
> >
> >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> >
> >Sent by:  owner-ips@ece.cmu.edu
> >
> >
> >To:   ips@ece.cmu.edu
> >cc:
> >Subject:  Re: iSCSI - Change - Login/Text commands with the 
> binary stage
> co
> >      de
> >
> >
> >
> >Julian,
> >
> >1.3.6 ISID states that the target should check to see if the 
> old session
> is
> >still active when a duplicate session is detected.
> >
> >I have two questions, the second only if you answer in the 
> affirmative on
> >the first ;^)
> >
> >1. Is there a properly executed sequence of events (i.e., no 
> coding error
> >on
> >the target side) where the session is not active, but the 
> target hadn't
> >taken notice of it?  It appears this as a protocol-specified 
> means to work
> >around a flaw in a target's implementation.  I interpret the 
> state diagram
> >transitions as being atomic wrt other commands.  I.e., the 
> last logout
> >would
> >result in the various transitions of the connection/session 
> prior to the
> >initiator starting the session up again.  And the target would have
> >completed the transitions prior to handling a new session request.
> >
> >2. If you answered (1) in the affirmative, then the word 
> "Active" is not
> >consistent with the 6.3 Session State Diagram.  Does this 
> mean the target
> >got lost, due to transport failures of any sort, in its 
> transition from
> >Q3-to-Q2-to-Q1?  It sounds like the intent is to close the 
> old session if
> >the session was in Q2 or Q4, presuming if it were in Q1,  it 
> would not
> have
> >been found as a duplicate.
> >
> >Stephen
> >
> >
> >
> >
> >
> >
> >
> >
> 
> 
> 
> 
> 


From owner-ips@ece.cmu.edu  Sat Aug 25 01:15:12 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22748
	for <ips-archive@odin.ietf.org>; Sat, 25 Aug 2001 01:15:12 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7P4G1v21587
	for ips-outgoing; Sat, 25 Aug 2001 00:16:01 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7OHboP16785
	for <ips@ece.cmu.edu>; Fri, 24 Aug 2001 13:37:50 -0400 (EDT)
Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35])
	by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id KAA08147;
	Fri, 24 Aug 2001 10:04:17 -0700 (PDT)
Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19)
	id <Q8DQ7ZXH>; Fri, 24 Aug 2001 10:04:16 -0700
Message-ID: <FFD40DB4943CD411876500508BAD02790299377F@sj5-ex2.brocade.com>
From: Robert Snively <rsnively@Brocade.COM>
To: "'Joshua Tseng'" <jtseng@NishanSystems.com>,
        "'Theodore Tso'"
	 <tytso@mit.edu>
Cc: "'Williams, Jim'" <Jim.Williams@emulex.com>,
        "'Black_David@emc.com'"
	 <Black_David@emc.com>, ips@ece.cmu.edu
Subject: RE: saag whyenc draft (was RE: Security Gateways)
Date: Fri, 24 Aug 2001 10:04:16 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Folks,

I am in agreement with Joshua in this discussion.

> > Even behind my corporate firewall of my company, I maintain my
> > personal machines as if there were no firewall, and use
> > encrypted connections for everything. 

Ted,

This sounds like very helpful news.  How can I set that
up and still maintain access to informative web and ftp sites of
dubious trustworthiness (which are always trying to 
get registrations from me, capture my web-browsing 
habits, and are not responsible for the integrity of their files)?
I would also like to be sure that all my e-mail sources
were also encrypted and authenticated, since e-mail is
the principal source of attacks.  How can I arrange that?

Bob


From owner-ips@ece.cmu.edu  Sat Aug 25 01:16:44 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22990
	for <ips-archive@odin.ietf.org>; Sat, 25 Aug 2001 01:16:44 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7P4GCC21596
	for ips-outgoing; Sat, 25 Aug 2001 00:16:12 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7OHi0P17288
	for <ips@ece.cmu.edu>; Fri, 24 Aug 2001 13:44:00 -0400 (EDT)
Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35])
	by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id KAA11793;
	Fri, 24 Aug 2001 10:43:38 -0700 (PDT)
Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19)
	id <Q8DQ756X>; Fri, 24 Aug 2001 10:43:37 -0700
Message-ID: <FFD40DB4943CD411876500508BAD027902993783@sj5-ex2.brocade.com>
From: Robert Snively <rsnively@Brocade.COM>
To: "'THALER,PAT (A-Roseville,ex1)'" <pat_thaler@agilent.com>,
        joeg@alacritech.com, Robert Snively <rsnively@Brocade.COM>,
        Black_David@emc.com, sanjay_goyal@ivivity.com, ips@ece.cmu.edu
Subject: RE: iSCSI CRC: A CRC-checking example
Date: Fri, 24 Aug 2001 10:43:36 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Pat,

I agree with you.

Bob

> -----Original Message-----
> From: THALER,PAT (A-Roseville,ex1) [mailto:pat_thaler@agilent.com]
> Sent: Friday, August 24, 2001 10:36 AM
> To: joeg@alacritech.com; Robert Snively; Black_David@emc.com;
> sanjay_goyal@ivivity.com; ips@ece.cmu.edu
> Subject: RE: iSCSI CRC: A CRC-checking example
> 
> 
> Joe and Bob,
> 
> I doubt that any implementation today will be doing CRC 
> computation in a bit
> serial circuit. The computation is generally done either byte 
> parallel or,
> increasingly, multi-byte parallel. The order in which the 
> bits of a byte are
> assigned to polynomial coefficients makes no difference to 
> byte parallel CRC
> implementation complexity. The only time complexity would be 
> effected by bit
> order is when one was doing a serial shift register 
> implementation of the
> CRC generator as some of the earliest Ethernet 
> implementations did. The
> technical reasons which applied to Ethernet in chosing the 
> CRC bit checking
> order, burst protection and serial implementation complexity, 
> don't apply to
> iSCSI.
> 
> The only reason for choosing one bit order over another for iSCSI CRC
> checking is the limits of human comprehension. Which bit order is most
> likely to be gotten right by the humans implementing the standard?
> 
>  Ethernet 
>           + many people are already accustomed to its bit order
>           - most significant byte first, least significant 
> bit first can
> cause confusion
>  Most significant everything first 
>           + more internally consistent than Ethernet
>           - different from Ethernet
> 
> The most important thing is that we specify whichever one we chose as
> clearly as possible.
> 
> Regards,
> Pat 
>              
> 
> -----Original Message-----
> From: Joe Gervais [mailto:joeg@alacritech.com]
> Sent: Thursday, August 23, 2001 7:21 PM
> To: Robert Snively; Black_David@emc.com; sanjay_goyal@ivivity.com;
> ips@ece.cmu.edu
> Subject: RE: iSCSI CRC: A CRC-checking example
> 
> 
> Bob,
> 
> If the data was going on token ring or some other media, 
> sure, who cares
> about an Ethernet approach, but the data is generally being sent and
> received over Ethernet, and there is advantage at least in some
> implementations to be in Ethernet bit/byte order.
> 
> Additionally, as David said earlier today, if it isn't broke, 
> let's not fix
> it. Can we get consensus and move on?
> 
> Joe
> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Robert Snively
> 
> ... snip ...
> So I would have expected that we would avoid any choice that
> makes that less convenient.  The Ethernet approach to those
> bytes would strike me as being the second-least convenient
> approach.  Clearly, throwing hardware at this could correct
> for that inconvenience, but it seems to me that any
> optimizations we make should focus on what we want to do, not
> what Ethernet did.
> 
> Bob
> 
> 


From owner-ips@ece.cmu.edu  Sat Aug 25 03:25:16 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08668
	for <ips-archive@odin.ietf.org>; Sat, 25 Aug 2001 03:25:16 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7P6Ys426554
	for ips-outgoing; Sat, 25 Aug 2001 02:34:54 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7P6YqP26549
	for <ips@ece.cmu.edu>; Sat, 25 Aug 2001 02:34:52 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id IAA16938
	for <ips@ece.cmu.edu>; Sat, 25 Aug 2001 08:34:44 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7P6Yic32220
	for <ips@ece.cmu.edu>; Sat, 25 Aug 2001 08:34:44 +0200
Importance: Normal
Subject: Re: iSCSI: Text Keys
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF9735D206.A6BC8374-ONC2256AB3.0023C9F8@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Sat, 25 Aug 2001 09:34:01 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 25/08/2001 09:34:44
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


comments in text - Julo

"Harbin, Donald B" <donald.b.harbin@intel.com>@ece.cmu.edu on 25-08-2001
02:30:21

Please respond to "Harbin, Donald B" <donald.b.harbin@intel.com>

Sent by:  owner-ips@ece.cmu.edu


To:   "Ietf-Ips (E-mail)" <ips@ece.cmu.edu>
cc:
Subject:  iSCSI: Text Keys



two questions:
1) section 2.8.5: "Some basic key=value pairs are described in Appendix A
and D. All of these keys, except for the X- extension format, MUST be
supported by iSCSI initiators and targets."
This led me on a hunt to find the "other" basic pairs.  I don't beleive
there are any others after reviewing the spec(s). Thus, my question.  Are
there "other" (excluding the X- extensions) basic pairs defined somewhere
else?  If not, I would like the group to consider rewording the above to be
more absolute.
                   "ALL basic key=value pairs are DEFINED in Appendix A and
D."
+++ will consider it +++

2) App D #'s 12 & 17 both have the same name {TargetAddress}.  Is it
possible to either combine them OR give them unique names?
thanks don

+++ TargetAddress now (08) appears only in SendTargets  +++



From owner-ips@ece.cmu.edu  Sat Aug 25 03:25:55 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08681
	for <ips-archive@odin.ietf.org>; Sat, 25 Aug 2001 03:25:55 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7P6Qk926285
	for ips-outgoing; Sat, 25 Aug 2001 02:26:46 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7P6QiP26280
	for <ips@ece.cmu.edu>; Sat, 25 Aug 2001 02:26:44 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id IAA08610
	for <ips@ece.cmu.edu>; Sat, 25 Aug 2001 08:26:36 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7P6QZN49354
	for <ips@ece.cmu.edu>; Sat, 25 Aug 2001 08:26:36 +0200
Importance: Normal
Subject: Re: iSCSI - Change - Login/Text commands with the binary stage code
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF88AAECCB.EA2695E6-ONC2256AB3.0022BC92@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Sat, 25 Aug 2001 09:26:04 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 25/08/2001 09:26:35
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Steve,

my comments in text - Julo



Steve Senum <ssenum@cisco.com>@ece.cmu.edu on 25-08-2001 01:54:47

Please respond to Steve Senum <ssenum@cisco.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ietf-ips <ips@ece.cmu.edu>
cc:
Subject:  Re: iSCSI - Change - Login/Text commands with the binary stage
      code



Hi Julian,

A have two questions on your proposal with respect to the
new CNxSG field.

1. In the section:

>    Stage transition is performed through a command exchange
>    (request/response) carrying the F bit and the same current stage code.
>    During this exchange, the next stage selected is the lower of the two
>    next stage codes.  The initiator can request a transition whenever it
is
>    ready but a target can respond with a transition only after it is
>    offered one by the initiator.

I assume from this that the target must always return the
same "current stage" as the initiator, so there is no
way for the stages to go backwards (which is fine with me).

+++ that is correct. Stages can't go backwards +++

2. In the section:

>    If the initiator is willing no negotiate security but it is unwilling
to
>    make the initial parameter offer and may accept a connection without
>    security it issues the Login with the F bit set to 1, the CNxSG set to
>    SecurityNegotiation in the current stage and
LoginOperationalNegotiation
>    in the next stage. If the target is also ready to forego security the
>    Login response is empty and has F bit is set to 1 and the CNxSG set to
>    SecurityNegotiation in the current stage and
LoginOperationalNegotiation
>    in the next stage.

So, if the initiator opens with:

I-> Login (CNxSG=0,1 F=1)

And the target responds with:

T-> Login-PR (CNxSG=0,1 F=0) AuthMethod=CHAP

And the initiator responds with:

I-> Text (CNxSG=0,1 F=0) AuthMethod=CHAP

The target should respond with a blank text message?

T-> Text (CNxSG=0,1 F=0)

Since all of the AuthMethods in Appendix A specify
that the initiator MUST start the authentication sequence
(which is fine with me).
++++ that is a correct sequence but the initiator could as well start the
parameters on the same PDU it is acking the use of CHAP like:

I-> Text (CNxSG=0,1 F=0) AuthMethod=CHAP A=<A1,A2...>

True the sequences are not symmetric as we decided early on that the target
has to reject and say why while the initiator will drop connections.

+++++
Regards,
Steve Senum





From owner-ips@ece.cmu.edu  Sat Aug 25 04:23:06 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08934
	for <ips-archive@odin.ietf.org>; Sat, 25 Aug 2001 04:23:06 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7P7NG028111
	for ips-outgoing; Sat, 25 Aug 2001 03:23:16 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7P7NEP28105
	for <ips@ece.cmu.edu>; Sat, 25 Aug 2001 03:23:14 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id JAA14436
	for <ips@ece.cmu.edu>; Sat, 25 Aug 2001 09:23:07 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7P7N6c52846
	for <ips@ece.cmu.edu>; Sat, 25 Aug 2001 09:23:06 +0200
Importance: Normal
Subject: RE: iSCSI: reusing ISID for recovery
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFE2E4D9C3.09271563-ONC2256AB3.0027F237@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Sat, 25 Aug 2001 10:22:33 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 25/08/2001 10:23:06
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


It may be another OS running on the same machine or CPU complex or it could
be an attack.
In any case if the initiator is up and fine he can as well do logout.
It is a rare enough event for us not to try to optimize.

The reboot is the only case in which the initiator can't logout and about
which we care.

And I would like to remind you all that we where on this exact thread more
tan 3 months ago (other players).
I just restated the rationale for an (apparent) newcomer.

Julo

"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>@ece.cmu.edu
on 25-08-2001 03:51:43

Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"
      <marjorie_krueger@hp.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery



I don't see how Option A is prone to "wild closing of sessions".  The
target
is only looking for sessions with this particular initiator and closing
them
if the ISID matches.

If an initiator doesn't have a valid TSID (login w/TSID=0), it means it has
lost state entirely (reboot) or knows it wants to immediately reset a
session (NIC failure).  How could there possibly be a case where the
initiator has an active valid session with the same ISID, but just doesn't
know about it??  Rejecting the login seems pointless, since obviously the
initiator either has a bug or intends to quickly reset the session.

The behavior chosen (Option C) will cause the initiator's recovery to be
delayed while the target NOPs all the connections and waits for them to
time
out - this will only delay the initiators recovery unnecessarily.  I can't
help but think this will cause long term problems for the protocol.

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: marjorie_krueger@hp.com

> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Thursday, August 23, 2001 9:39 PM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI: reusing ISID for recovery (Was: RE: iSCSI
> - Change -
> Login/Text...)
>
>
>
> Mallikarjun,
>
> On  your point 1 that is what is stated today in the draft.
>
> On your point 2 option C is the one we took in the draft, after some
> debate.
>
> Option A is prone to "wild closing of sessions" and option B is also
> relaying to much on the good behaviour of the
> client. It also introduces a "feature" that complicates login/logout.
>
> Our postion on this is  that the initiator should logout the session
> explicitly if it can (and in this case it can as the target
> has ascertained
> that the session is alive).
>
> I agree that you may want to update the stayte diagram to
> reflect this.
>
> Julo
>
>
> "Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on 24-08-2001 01:46:40
>
> Please respond to cbm@rose.hp.com
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   ips@ece.cmu.edu
> cc:
> Subject:  iSCSI: reusing ISID for recovery (Was: RE: iSCSI - Change -
>       Login/Text...)
>
>
>
> Julian and all:
>
> This thread mirrors another discussion some of us are
> having in a different forum.  Following (two bullets 1
> & 2 below) is what I proposed there, attempting to address
> two issues -
>      a) how to recover sessions when target and the initiator
>            have conflicting views of the same TCP connection(s)?
>            (Initiator NIC fails, but there's no I/O activity,
>            and the target doesn't see any connection failure.)
>      b) More specifically, how to address the above problem
>            when the initiator *does not want* to re-instate failed
>            connections since it only implements the mandatory
>            session recovery?
>
> This could add clarity or muddle things up here, though hopefully
> the former...
>
> 1 If login is sent with the same ISID, same TSID, same CID and X-bit,
>   then it means a failed connection is being re-instated (whether
>   or not there are multiple connections in the session).  This login
>   attempt must be done before the connection timeout (transition M1),
>   or if this is the only connection in the session, also before the
>   session timeout (transition N6) - to be counted as a connection
>   reinstatement effort.
>            o CmdSN counters (CmdSN, ExpCmdSN) are continued.
> Initiator
>              must do command plugging when there's a mismatch
>              between its CmdSN and ExpCmdSN in the login response.
>            o Since this is an implicit connection logout, all
> the active
>              tasks on the connection are either internally terminated,
>              or made non-allegiant (based on ErrorRecoveryLevel=x/y,
>              TBD) for recovery.
>
> 2 If login is sent with the same ISID and TSID=0, the session (if it
>   exists on the target) is being cleared and any active connections
>   that the target sees must be immediately (at the end of the login
>   process including any initiator authentication) transport reset.
>   Initiator may attempt this only after it ascertains a
> session failure
>   on its end (ie. all connections entered RECOVERY_START).
>            o CmdSN counters get reset.  Initiator has to perform the
>              currently defined session recovery actions.
>            o All active tasks of the session are internally
> terminated.
>
>
> Essentially, I was proposing extending the same notion of "implicit
> logout" of a connection to the session level.  The options that I
> see are -
>
>        A) Should iSCSI let it happen by default as stated above (ie.
>           same ISID, TSID=0 always wipes out the pre-existing session
>           on target, since we are mandating it to be used only when
>           initiator sees a session failure)?
>        B) Should iSCSI mandate making this intended cleanup explicit
>           by setting a bit (Say C-bit, for Clear) in the Login Command
>           PDU to prevent an accidental session cleanup with a buggy
>           initiator code?
>        C) Should iSCSI merely state that targets must ascertain
>           the connection state(s) whenever a new session creation
>           attempt is made with a known ISID and TSID=0?  (sort of
>           defeats the intention of the initiator wanting quicker
>           session recovery since the Login command PDU would have
>           to idle till target ascertains the connection state(s)).
>
> I prefer A, or B.
>
> Going with A or B means that the description of transition N3
> in the session state diagram would have to change to:
>      Last LOGGED_IN connection had ceased to be LOGGED_IN,
>         or a Login Command requesting clearing the session (also
>         with C-bit set, if option B) was received by the target.
>
> The transition N7's description would have to be augmented as
> well to:
>         Session recovery attempt with an implicit logout,
>         or connection reinstatement/new CID addition.
>
> Comments?
> --
> Mallikarjun
>
>
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> MS 5668   Hewlett-Packard, Roseville.
> cbm@rose.hp.com
>
>
> >Stephen,
> >
> >That can happen as the target may set-up completely new TCP
> connections
> >(the old sockets are still there and look OK).
> >Untill the login is  progessing he assumes that this is just another
> >open-session attempt. Then he checks the old session and the
> session is
> >dead (initiator has closed the connections).
> >
> >The target has to distinguish only between a session that is
> alive (and
> >reject the new one) and one that its dead in which case it
> can clean-up.
> >
> >Julo
> >
> >"Wheat, Stephen R" <stephen.r.wheat@intel.com> on 23-08-2001 22:50:56
> >
> >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> >
> >To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> >cc:
> >Subject:  RE: iSCSI - Change - Login/Text commands with the
> binary stage
> co
> >          de
> >
> >
> >
> >Julian,
> >
> >I don't understand your answer.  For the scenario given, I
> would presume
> >then that the target would reject the new session attempt,
> as it sees the
> >previous session still "alive".  What is there to tell the
> target that
> this
> >is any different from when the Initiator is erroneously using the
> >repetitive
> >session id?
> >
> >Thanks,
> >Stephen
> >
> >-----Original Message-----
> >From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> >Sent: Thursday, August 23, 2001 11:15 AM
> >To: ips@ece.cmu.edu
> >Subject: Re: iSCSI - Change - Login/Text commands with the
> binary stage
> >co de
> >
> >
> >Stephen,
> >
> >1.If the initiator goes away for a while and reboots and there was no
> >activity on the connections
> >the target may see a session alive (I am not sure that it
> has to appear on
> >the state diagram but maybe).
> >
> >2.Again - I am not sure that the curent state diagram
> includes death of
> the
> >initiator
> >
> >Julo
> >
> >"Wheat, Stephen R" <stephen.r.wheat@intel.com>@ece.cmu.edu
> on 23-08-2001
> >19:58:34
> >
> >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> >
> >Sent by:  owner-ips@ece.cmu.edu
> >
> >
> >To:   ips@ece.cmu.edu
> >cc:
> >Subject:  Re: iSCSI - Change - Login/Text commands with the
> binary stage
> co
> >      de
> >
> >
> >
> >Julian,
> >
> >1.3.6 ISID states that the target should check to see if the
> old session
> is
> >still active when a duplicate session is detected.
> >
> >I have two questions, the second only if you answer in the
> affirmative on
> >the first ;^)
> >
> >1. Is there a properly executed sequence of events (i.e., no
> coding error
> >on
> >the target side) where the session is not active, but the
> target hadn't
> >taken notice of it?  It appears this as a protocol-specified
> means to work
> >around a flaw in a target's implementation.  I interpret the
> state diagram
> >transitions as being atomic wrt other commands.  I.e., the
> last logout
> >would
> >result in the various transitions of the connection/session
> prior to the
> >initiator starting the session up again.  And the target would have
> >completed the transitions prior to handling a new session request.
> >
> >2. If you answered (1) in the affirmative, then the word
> "Active" is not
> >consistent with the 6.3 Session State Diagram.  Does this
> mean the target
> >got lost, due to transport failures of any sort, in its
> transition from
> >Q3-to-Q2-to-Q1?  It sounds like the intent is to close the
> old session if
> >the session was in Q2 or Q4, presuming if it were in Q1,  it
> would not
> have
> >been found as a duplicate.
> >
> >Stephen
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
>





From owner-ips@ece.cmu.edu  Sat Aug 25 18:23:27 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14851
	for <ips-archive@odin.ietf.org>; Sat, 25 Aug 2001 18:23:27 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7PLDY406617
	for ips-outgoing; Sat, 25 Aug 2001 17:13:34 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f7PLDWP06612
	for <ips@ece.cmu.edu>; Sat, 25 Aug 2001 17:13:32 -0400 (EDT)
Received: from scummy.research.bell-labs.com ([135.104.2.10]) by crufty; Sat Aug 25 17:08:11 EDT 2001
Received: from aura.research.bell-labs.com (aura.research.bell-labs.com [135.104.46.10])
	by scummy.research.bell-labs.com (8.11.4/8.11.4) with ESMTP id f7PLBdl51344;
	Sat, 25 Aug 2001 17:11:40 -0400 (EDT)
Received: from research.bell-labs.com (IDENT:sandeepj@sandeepj-pcmh.research.bell-labs.com [135.104.47.90])
	by aura.research.bell-labs.com (8.9.1/8.9.1) with ESMTP id RAA19297;
	Sat, 25 Aug 2001 17:11:39 -0400 (EDT)
Message-ID: <3B88148B.AB308BF9@research.bell-labs.com>
Date: Sat, 25 Aug 2001 17:11:39 -0400
From: Sandeep Joshi <sandeepj@research.bell-labs.com>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-3 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Dave Sheehy <dbs@acropora.rose.agilent.com>
CC: IETF IP SAN Reflector <ips@ece.cmu.edu>
Subject: Re: iSCSI: draft 7: remove S bit and Status field from the Data-i
References: <200108150435.VAA00369@acropora.rose.agilent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


Julian,

I wonder if Dave's last paragraph in this email has been considered.
Here it is again..

> This does help some. It eliminates the situation where a target can receive
> an essentially unlimited number of immediate data commands prior to receiving
> *any* data PDUs.

in reference to Section 1.2.5
> Unsolicited data MUST be sent on 
> every connection in the same order in which commands were sent.

The draft currently allows 
   c-1,c-2,c-3, (SEP-1-1),(SEP-1-2),(SEP-2-1,SEP-2-2),..
where c-N = command {N}
and   SEP-N-M = unsolicited (non-immediate) PDU number {M} for command
{N}

It would be simplify target login (ITT lookup) if we only permitted
this sequence. 
   c-1, SEP-1-1, SEP-1-2, c-2, SEP-2-1, SEP-2-2,..

-Sandeep


Dave Sheehy wrote:
> 
> David,
> 
> > I think you've taken a wrong turn.
> 
> I think John hit the nail on the head.
> 
> > > Second, thoughts of removing the immediate data seem not to be
> > > simplification, since all the information to tie the data to the command
> > is
> > > right there with the command.  That has got to be easier than matching up
> > > separate PDUs of data with the appropriate commands.
> >
> > Actually, that was the point, since the logic for "matching up separate
> > PDUs of data with the appropriate commands" has to exist for inbound
> > Data PDUs already.
> 
> Except that there is a target context present in the solicited case to route
> the data. That doesn't exist in the unsolicited case.
> 
> > The slide I presented in London was about replacing
> > immediate data with an unsolicited data PDU immediately following the
> > command, thus removing the immediate data case in favor of reusing the
> > logic for dealing with separate Data PDUs.  Remember that this was presented
> > as a simplification possibility.
> 
> This does help some. It eliminates the situation where a target can receive
> an essentially unlimited number of immediate data commands prior to receiving
> *any* data PDUs.
> 
> But, do you mean to say that *one* unsolicited data PDU would follow the
> command? Wouldn't that be unnecessarily restrictive if the PDU size is small?
> Simply guaranteeing that the data PDUs will immediately follow the command
> seems like an adequate improvement.
> 
> Dave Sheehy


From owner-ips@ece.cmu.edu  Sun Aug 26 01:17:33 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20863
	for <ips-archive@odin.ietf.org>; Sun, 26 Aug 2001 01:17:33 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7Q48SP20543
	for ips-outgoing; Sun, 26 Aug 2001 00:08:28 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7Q48PP20539
	for <ips@ece.cmu.edu>; Sun, 26 Aug 2001 00:08:26 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id GAA10644
	for <ips@ece.cmu.edu>; Sun, 26 Aug 2001 06:08:19 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7Q48Cc27866
	for <ips@ece.cmu.edu>; Sun, 26 Aug 2001 06:08:18 +0200
Importance: Normal
Subject: Re: iSCSI: draft 7: remove S bit and Status field from the Data-i
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF6D417708.84792326-ONC2256AB4.0016197F@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Sun, 26 Aug 2001 07:07:39 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 26/08/2001 07:08:18
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


I am sure we don't want to enter this. The sequencing rules are there to
asure:

   that there is no deadlock (order of data must follow the order of
   commands)
   that the target command buffer does not overflow (MaxCmdSN) - this will
   eliminate an "unlimited number of immediate"

Any additional rules will interfere with performance, multiplexing policy
etc. and I see no great
value in enforcing them (and enforcing means checking and that means
expense).

Julo

Sandeep Joshi <sandeepj@research.bell-labs.com>@ece.cmu.edu on 26-08-2001
00:11:39

Please respond to Sandeep Joshi <sandeepj@research.bell-labs.com>

Sent by:  owner-ips@ece.cmu.edu


To:   Dave Sheehy <dbs@acropora.rose.agilent.com>
cc:   IETF IP SAN Reflector <ips@ece.cmu.edu>
Subject:  Re: iSCSI: draft 7: remove S bit and Status field from the Data-i




Julian,

I wonder if Dave's last paragraph in this email has been considered.
Here it is again..

> This does help some. It eliminates the situation where a target can
receive
> an essentially unlimited number of immediate data commands prior to
receiving
> *any* data PDUs.

in reference to Section 1.2.5
> Unsolicited data MUST be sent on
> every connection in the same order in which commands were sent.

The draft currently allows
   c-1,c-2,c-3, (SEP-1-1),(SEP-1-2),(SEP-2-1,SEP-2-2),..
where c-N = command {N}
and   SEP-N-M = unsolicited (non-immediate) PDU number {M} for command
{N}

It would be simplify target login (ITT lookup) if we only permitted
this sequence.
   c-1, SEP-1-1, SEP-1-2, c-2, SEP-2-1, SEP-2-2,..

-Sandeep


Dave Sheehy wrote:
>
> David,
>
> > I think you've taken a wrong turn.
>
> I think John hit the nail on the head.
>
> > > Second, thoughts of removing the immediate data seem not to be
> > > simplification, since all the information to tie the data to the
command
> > is
> > > right there with the command.  That has got to be easier than
matching up
> > > separate PDUs of data with the appropriate commands.
> >
> > Actually, that was the point, since the logic for "matching up separate
> > PDUs of data with the appropriate commands" has to exist for inbound
> > Data PDUs already.
>
> Except that there is a target context present in the solicited case to
route
> the data. That doesn't exist in the unsolicited case.
>
> > The slide I presented in London was about replacing
> > immediate data with an unsolicited data PDU immediately following the
> > command, thus removing the immediate data case in favor of reusing the
> > logic for dealing with separate Data PDUs.  Remember that this was
presented
> > as a simplification possibility.
>
> This does help some. It eliminates the situation where a target can
receive
> an essentially unlimited number of immediate data commands prior to
receiving
> *any* data PDUs.
>
> But, do you mean to say that *one* unsolicited data PDU would follow the
> command? Wouldn't that be unnecessarily restrictive if the PDU size is
small?
> Simply guaranteeing that the data PDUs will immediately follow the
command
> seems like an adequate improvement.
>
> Dave Sheehy





From owner-ips@ece.cmu.edu  Sun Aug 26 03:29:20 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03310
	for <ips-archive@odin.ietf.org>; Sun, 26 Aug 2001 03:29:20 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7Q6Vu525235
	for ips-outgoing; Sun, 26 Aug 2001 02:31:56 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7Q6VsP25230
	for <ips@ece.cmu.edu>; Sun, 26 Aug 2001 02:31:54 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id IAA09034
	for <ips@ece.cmu.edu>; Sun, 26 Aug 2001 08:31:47 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7Q6Vlr229974
	for <ips@ece.cmu.edu>; Sun, 26 Aug 2001 08:31:47 +0200
Importance: Normal
Subject: iSCSI - change - parameter segregation
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFD8139FC2.38B34464-ONC2256AB4.00211DF4@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Sun, 26 Aug 2001 09:31:13 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 26/08/2001 09:31:46
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

According to the consesus reached on this list to attempt to segregate (if
possible) SCSI mode page parameters that are iSCSI specific or have an
"iSCSI flavor/interpretation" I suggest the following new version for
chapter 3:

1.   SCSI Mode Parameters for iSCSI

   This chapter describes fields and mode pages that control and report the
   behavior of the iSCSI protocol. All fields not described here MUST
   control the behavior of iSCSI devices as defined by the corresponding
   command set standard.

   The iSCSI specific parameter change MUST be performed following the SCSI
   rules as stated by [SAM2] and [SPC].


1.1  SCSI Disconnect-Reconnect Mode Page use in iSCSI

   The following outlines the SCSI Disconnect-Reconnect mode page usage for
   iSCSI:


   Byte /    0       |       1       |       2       |       3       |
      /              |               |               |               |
     |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
     +---------------+---------------+---------------+---------------+
    0|P|0| 0x02      | 0x0e          | Reserved(0)                   |
     +---------------+---------------+---------------+---------------+
    4| Reserved (0)                                                  |
     +---------------+---------------+---------------+---------------+
    8| Reserved (0)                  | MaximumBurstSize              |
     +---------------+---------------+---------------+---------------+
   12|E| Reserved (0)                | FirstBurstSize                |
     +---------------+---------------+---------------+---------------+

1.1.1     MaximumBurstSize Field (16 bit)

   This field defines the maximum SCSI data payload in an iSCSI sequence (a
   sequence of Data-In or Data-Out PDUs ending with a Data-In or Data-Out
   PDU with the F bit set to one) in units of 512 bytes.

1.1.2     E - Enable Modify Data Pointers Bit (EMDP)

   Data PDU Sequences (a sequence of Data-In or Data-Out PDUs ending with a
   Data-In or Data-Out PDU with the F bit set to one) can be in any order
   (EMDP = 1) or at continuously increasing addresses (EMDP = 0).

1.1.3     FirstBurstSize Field (16 bit)

   This field defines the maximum amount of unsolicited data an iSCSI
   initiator may to send to the target in units of 512 bytes.

1.1.4     Other Fields

   No other fields in this page are used by iSCSI.

1.2  iSCSI Logical Unit Control Mode Page

   The following outlines the iSCSI Port mode page:



   Byte /    0       |       1       |       2       |       3       |
      /              |               |               |               |
     |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
     +---------------+---------------+---------------+---------------+
    0|P|0| 0x18      | 0x02          | 0x05          | Reserved (0)|C|
     +---------------+---------------+---------------+---------------+

1.2.1     Enable CRN (C)

   When C is set to 1 the CRN field is considered by LU.



 DataPDULength (in appendix D) becomes:

01   DataPDULength

   Use: LO
   Who can send: Initiator and Target

   DataPDULength=<number-0-to-(2**15-1)>

   Default is 16 units.

   Initiator and target negotiate the maximum data payload supported for
   SCSI command or data PDUs in units of 512 bytes. The minimum of the 2
   numbers is selected.

   A value of 0 indicates no limit.


 FirstBurstSize (in Appendix D) is removed.
 DataSequenceOrder (in Appendix D) is removed

 Comments?

 Julo







From owner-ips@ece.cmu.edu  Sun Aug 26 10:27:14 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13025
	for <ips-archive@odin.ietf.org>; Sun, 26 Aug 2001 10:27:14 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7QD88n18575
	for ips-outgoing; Sun, 26 Aug 2001 09:08:08 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7QD86P18567
	for <ips@ece.cmu.edu>; Sun, 26 Aug 2001 09:08:06 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id PAA11972
	for <ips@ece.cmu.edu>; Sun, 26 Aug 2001 15:07:59 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7QD7xv44872
	for <ips@ece.cmu.edu>; Sun, 26 Aug 2001 15:07:59 +0200
Importance: Normal
Subject: iSCSI - open issues - no discussion - recovery levels
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFDF3A9B6A.C2DD471F-ONC2256AB4.004709FC@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Sun, 26 Aug 2001 16:07:24 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 26/08/2001 16:07:59
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Dear colleagues,

Considering that the next plugfest is getting close and we would like to
have
version 08 ready for it.

We have two open items that got little attention on the list up to now:

- taking out the markers and inserting a reference to an external framing
draft (what is mandatory, what is optional etc.)
- recovery the recovery levels proposal

The status  with both is as follows:

- on the framing there is consensus that it is a good idea; there is no
consensus on what is  MUST, SHOULD etc.
- on the recovery there is consesus that it is a good idea; there is no
consensus on how many layers to enforce (I think that 2 - all or nothing is
a good choice).

Regards,
Julo




From owner-ips@ece.cmu.edu  Mon Aug 27 08:45:32 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15146
	for <ips-archive@odin.ietf.org>; Mon, 27 Aug 2001 08:45:32 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7RBHG320900
	for ips-outgoing; Mon, 27 Aug 2001 07:17:16 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from sansrv1.san-rad.co.il ([212.199.104.226])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7RBHDP20893
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 07:17:14 -0400 (EDT)
content-class: urn:content-classes:message
Subject: ISCSI: A propos  MIB and specially iSCSI MIB
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Mon, 27 Aug 2001 10:22:26 +0200
Disposition-Notification-To: "Michele Hallak - Stamler" <michele@SANRAD.COM>
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
Message-ID: <838D8D2617300146B7F47E4D9AE7FF101149E5@SANSRV1.SAN-RAD.CO.IL>
Thread-Topic: ISCSI: A propos  MIB and specially iSCSI MIB
Thread-Index: AcEu0V2U+BdDa5q/EdWQUgACsy5SCw==
From: "Michele Hallak - Stamler" <michele@sanrad.com>
To: <ips@ece.cmu.edu>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f7RBHFP20896
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit

Since you are meeting at interim meetings on MIBs:

The following mail summarizes my suggestions concerning the improvement
of iSCSI MIB:

1. New Textual Convention:
 AuthenticationMethodTC  ::= TEXTUAL-CONVENTION
    STATUS current
    DESCRIPTION
        "List of possible authentication methods."
    SYNTAX INTEGER {
		none(1),
		crc32(2),
		crc64(3),
		md5(4),
		kerberosMd5(5),
		kerberosMd5des(6),
		kerberosMd5desHmark(7)
	}

2. Add RowStatus and Read-Write Access to the portals and to the
authorized list of initiators.

3. Add RowStatus to iscsiTargetAttributesTable in order to allow an
administrator to create target and 
set the access of the fields:     iscsiTgtName  and iscsiTgtAlias as
read-create   

I hope that you'll aggree to make the change,

	Michele


From owner-ips@ece.cmu.edu  Mon Aug 27 10:40:52 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20354
	for <ips-archive@odin.ietf.org>; Mon, 27 Aug 2001 10:40:52 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7RD5VQ25554
	for ips-outgoing; Mon, 27 Aug 2001 09:05:31 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from MAIL.NetOctave.com (netoctave-gw.customer.alter.net [65.195.230.86])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7RD5TP25549
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 09:05:29 -0400 (EDT)
Received: by MAIL.NetOctave.com with Internet Mail Service (5.5.2650.21)
	id <RRNMY4X7>; Mon, 27 Aug 2001 09:06:19 -0400
Message-ID: <49B96FCC784BC54F9675A6B558C3464E5D0C08@MAIL.NetOctave.com>
From: Mark Winstead <Mark.Winstead@NetOctave.com>
To: "'Black_David@emc.com'" <Black_David@emc.com>,
        sandeepj@research.bell-labs.com, ips@ece.cmu.edu
Subject: RE: FW: I-D ACTION:draft-aboba-ips-iscsi-security-00.txt
Date: Mon, 27 Aug 2001 09:06:18 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Last Friday, NIST held a modes of operation workshop (for the protection and
privacy of sensitive but unclassified data, NIST authorizes suitable
algorithms and techniques for use by federal government departments and
agencies).

OCB is one of three modes considered that achieve both privacy and
authentication, as well as the potential to scale well for speed. All three
either have patents or have been submitted for patents. IMHO w/o coding
them, only two of the three, OCB and Integrity Aware Parallelizable Mode
(IAPM) will scale well to support 10 Gbs and more. IAPM's patent is held by
IBM, OCB by Phil Rogaway.

The patent issue came up during the discussion time -- no one present knew
of a provably secure mode with the properties of OCB that was unpatented.
One could find an unpatented mode for privacy, say counter mode, and then
add a MAC that provides authentication, but that is an extra step (plus I
think you might run into the patent problem again in finding a MAC that will
permit 10 Gbs speed).

Mark Winstead

-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Tuesday, August 21, 2001 8:17 PM
To: sandeepj@research.bell-labs.com; ips@ece.cmu.edu
Subject: RE: FW: I-D ACTION:draft-aboba-ips-iscsi-security-00.txt


Sandeep,

There is a patent on it, and a license is required to ship product.
The license should be available under fair, reasonable, and non-
discriminatory terms, but will not be free.  A reasonable guess
would be that iSCSI licensing terms would be similar to the 802.11
terms, and that a suitable IETF intellectual property rights notice
will be forthcoming.

OTOH, this does seem to run counter to the usual IETF preference
for unpatented technology over patented technology provided that
the unpatented technology is a functionally suitable replacement
for the patented technology.  Whether there are functionally suitable
unpatented replacements for OCB is an issue for further discussion,
ditto the requirements and preferences that lead to the recommendation
of OCB.  A draft on OCB would need to go through the ipsec WG if we
were to use OCB, and my impression is that at least some portion of
that community has a very strong preference for unpatented technology.

I hope this is what you were looking for in the way of comments.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


> -----Original Message-----
> From: sandeepj@research.bell-labs.com
> [mailto:sandeepj@research.bell-labs.com]
> Sent: Tuesday, August 21, 2001 7:49 PM
> To: ips@ece.cmu.edu
> Subject: Re: FW: I-D ACTION:draft-aboba-ips-iscsi-security-00.txt
> 
> 
> David,
> 
> Could you comment on the intellectual rights issues 
> here, particularly on AES-OCB, which will be mandatory 
> according to this draft (Sec 2.1)
> 
> http://www.cs.ucdavis.edu/~rogaway/ocb/ocb-back.htm
> mentions the licensing terms for 802.11 products.
> 
> Secondly, appendix tables A.5 and A.6 seem to indicate
> that AES-CTR+UMAC performance is better than AES-OCB.
> Has AES-OCB been chosen since it requires lesser keying
> material and memory ?
> 
> thanks
> -Sandeep
> 
> > FYI - this is about use of IKE and IPsec algorithm selection
> > considerations.  --David
> > 
> > -----Original Message-----
> > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> > Sent: Tuesday, August 21, 2001 7:25 AM
> > Subject: I-D ACTION:draft-aboba-ips-iscsi-security-00.txt
> > 
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > 
> > Title           : Securing iSCSI using IPsec
> > Author(s)       : B. Aboba et al.
> > Filename        : draft-aboba-ips-iscsi-security-00.txt
> > Pages           : 35
> > Date            : 20-Aug-01
> > 
> > This document discusses how iSCSI may utilize IPsec to provide
> > authentication, integrity, confidentiality and replay protection.
> > 
> > A URL for this Internet-Draft is:
> > 
http://www.ietf.org/internet-drafts/draft-aboba-ips-iscsi-security-00.txt
> 
> Internet-Drafts are also available by anonymous FTP. Login with the
username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-aboba-ips-iscsi-security-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> mailserv@ietf.org.
> In the body type:
> "FILE /internet-drafts/draft-aboba-ips-iscsi-security-00.txt".
> 
> NOTE:   The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility.  To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader.  Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
> 
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
> ---------------------------------------------------------
> + Date: Tue, 21 Aug 2001 09:29:53 -0400
> + Content-Type:
> multipart/mixed;boundary="----_=_NextPart_002_01C12A44.418236C0"
> 
> ATT36560
> 
> <ftp://internet-drafts/>
> Transfer-mode: ftp.ietf.org
> ---------------------------------------------------------
> 


From owner-ips@ece.cmu.edu  Mon Aug 27 10:49:24 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20578
	for <ips-archive@odin.ietf.org>; Mon, 27 Aug 2001 10:49:24 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7RDsMM28342
	for ips-outgoing; Mon, 27 Aug 2001 09:54:22 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7RDsLP28338
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 09:54:21 -0400 (EDT)
Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA23224; Mon, 27 Aug 2001 09:54:13 -0400 (EDT)
Message-ID: <3B8A4F5B.D1485DFE@cisco.com>
Date: Mon, 27 Aug 2001 08:47:07 -0500
From: Mark Bakke <mbakke@cisco.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686)
X-Accept-Language: en, de
MIME-Version: 1.0
To: Michele Hallak - Stamler <michele@sanrad.com>
CC: ips@ece.cmu.edu
Subject: Re: ISCSI: A propos  MIB and specially iSCSI MIB
References: <838D8D2617300146B7F47E4D9AE7FF101149E5@SANSRV1.SAN-RAD.CO.IL>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Michele-

Thanks for the comments.  My comments are below.

--
Mark

Michele Hallak - Stamler wrote:
> 
> Since you are meeting at interim meetings on MIBs:
> 
> The following mail summarizes my suggestions concerning the improvement
> of iSCSI MIB:
> 
> 1. New Textual Convention:
>  AuthenticationMethodTC  ::= TEXTUAL-CONVENTION
>     STATUS current
>     DESCRIPTION
>         "List of possible authentication methods."
>     SYNTAX INTEGER {
>                 none(1),
>                 crc32(2),
>                 crc64(3),
>                 md5(4),
>                 kerberosMd5(5),
>                 kerberosMd5des(6),
>                 kerberosMd5desHmark(7)
>         }

This is a text field in the current MIB; it will change to
an OID field in the next version, which acts a little like
your enumerated types, but is extensible without modifying
the MIB.  BTW, this is a set of two attributes called DataDigest
and HeaderDigest; AuthMethod is something completely different.
All of the digest methods will be removed from draft-08 with
the exception of "none" and "crc-32c".  With the new OID scheme;
values for these can be added to your enterprise MIB if you
choose to implement them.

> 
> 2. Add RowStatus and Read-Write Access to the portals and to the
> authorized list of initiators.

Which attributes to write and which rows to delete are currently
under consideration.  We are looking for detailed input on this.

Please send the list of attributes you wish to write, and why
you wish to write them.

> 3. Add RowStatus to iscsiTargetAttributesTable in order to allow an
> administrator to create target and
> set the access of the fields:     iscsiTgtName  and iscsiTgtAlias as
> read-create

It's not possible to create an iSCSI target without first creating
a SCSI target.  I don't think we will be ready to explore this until
we have made progress on a SCSI MIB.  If you have some ideas on how
a management station would make use of this (with both MIBs) to create
new targets, please send them.


> I hope that you'll aggree to make the change,
> 
>         Michele

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054


From owner-ips@ece.cmu.edu  Mon Aug 27 10:50:52 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20713
	for <ips-archive@odin.ietf.org>; Mon, 27 Aug 2001 10:50:47 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7RDgYe27494
	for ips-outgoing; Mon, 27 Aug 2001 09:42:34 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7RDgWP27488
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 09:42:32 -0400 (EDT)
Received: from london ([192.168.195.163])
	by mail.wrs.com (8.9.3/8.9.1) with SMTP id GAA24961;
	Mon, 27 Aug 2001 06:42:12 -0700 (PDT)
From: "Rod Harrison" <rod.harrison@windriver.com>
To: "Julian Satran" <Julian_Satran@il.ibm.com>, <ips@ece.cmu.edu>
Subject: RE: iSCSI - open issues - no discussion - recovery levels
Date: Mon, 27 Aug 2001 14:43:56 +0100
Message-ID: <NEBBKMMOEMCINPLCHKGMCEPECMAA.rod.harrison@windriver.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <OFDF3A9B6A.C2DD471F-ONC2256AB4.004709FC@telaviv.ibm.com>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


	With respect to framing I would be firmly against replacing
markers with something that would require changes to the
network stack. I think it is clear that there will almost
certainly be software iSCSI implementations at workstations,
and that those workstations will need to provide framing /
markers for hardware at the server that require them. Having
come this far I think it would be a change for the worse
were we to prevent software implementations that allow a
hardware implementation to perform at its best. I favour
MUST provide markers, and have no objection to a reference
to an external framing draft as an option.

	With respect to recovery I agree that the all or nothing
approach (2 layers) is a good choice..

	- Rod

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On
Behalf Of
Julian Satran
Sent: Sunday, August 26, 2001 2:07 PM
To: ips@ece.cmu.edu
Subject: iSCSI - open issues - no discussion - recovery
levels


Dear colleagues,

Considering that the next plugfest is getting close and we
would like to
have
version 08 ready for it.

We have two open items that got little attention on the list
up to now:

- taking out the markers and inserting a reference to an
external framing
draft (what is mandatory, what is optional etc.)
- recovery the recovery levels proposal

The status  with both is as follows:

- on the framing there is consensus that it is a good idea;
there is no
consensus on what is  MUST, SHOULD etc.
- on the recovery there is consesus that it is a good idea;
there is no
consensus on how many layers to enforce (I think that 2 -
all or nothing is
a good choice).

Regards,
Julo




From owner-ips@ece.cmu.edu  Mon Aug 27 11:30:34 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21835
	for <ips-archive@odin.ietf.org>; Mon, 27 Aug 2001 11:30:33 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7REGee29732
	for ips-outgoing; Mon, 27 Aug 2001 10:16:40 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7REGcP29727
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 10:16:38 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA35850
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 10:14:26 -0400
Received: from d03nmx42.almaden.ibm.com (d03nmx42.almaden.ibm.com [9.1.24.146])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7REGac203732
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 08:16:36 -0600
Importance: Normal
Subject: RE: iSCSI: reusing ISID for recovery
To: ips@ece.cmu.edu
From: "Jim Hafner" <hafner@almaden.ibm.com>
Date: Mon, 27 Aug 2001 07:16:33 -0700
Message-ID: <OF8EBF608E.40E5243E-ON88256AB5.004E4B12@almaden.ibm.com>
X-MIMETrack: Serialize by Router on D03NMX42/03/M/IBM(Build M9_05202001 Beta 2|May 20, 2001) at
 08/27/2001 07:16:35 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Julo,
You wrote:
  And I would like to remind you all that we where on this exact thread
more
  tan 3 months ago (other players).
  I just restated the rationale for an (apparent) newcomer.

On the other hand, I don't recall this issue ever being called for
concensus.  Opinions were posted and nothing followed up.

I happen to agree with Marjorie.

Jim Hafner


Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 08/25/2001 12:22:33 AM

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery




It may be another OS running on the same machine or CPU complex or it could
be an attack.
In any case if the initiator is up and fine he can as well do logout.
It is a rare enough event for us not to try to optimize.

The reboot is the only case in which the initiator can't logout and about
which we care.

And I would like to remind you all that we where on this exact thread more
tan 3 months ago (other players).
I just restated the rationale for an (apparent) newcomer.

Julo

"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>@ece.cmu.edu
on 25-08-2001 03:51:43

Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"
      <marjorie_krueger@hp.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery



I don't see how Option A is prone to "wild closing of sessions".  The
target
is only looking for sessions with this particular initiator and closing
them
if the ISID matches.

If an initiator doesn't have a valid TSID (login w/TSID=0), it means it has
lost state entirely (reboot) or knows it wants to immediately reset a
session (NIC failure).  How could there possibly be a case where the
initiator has an active valid session with the same ISID, but just doesn't
know about it??  Rejecting the login seems pointless, since obviously the
initiator either has a bug or intends to quickly reset the session.

The behavior chosen (Option C) will cause the initiator's recovery to be
delayed while the target NOPs all the connections and waits for them to
time
out - this will only delay the initiators recovery unnecessarily.  I can't
help but think this will cause long term problems for the protocol.

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: marjorie_krueger@hp.com

> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Thursday, August 23, 2001 9:39 PM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI: reusing ISID for recovery (Was: RE: iSCSI
> - Change -
> Login/Text...)
>
>
>
> Mallikarjun,
>
> On  your point 1 that is what is stated today in the draft.
>
> On your point 2 option C is the one we took in the draft, after some
> debate.
>
> Option A is prone to "wild closing of sessions" and option B is also
> relaying to much on the good behaviour of the
> client. It also introduces a "feature" that complicates login/logout.
>
> Our postion on this is  that the initiator should logout the session
> explicitly if it can (and in this case it can as the target
> has ascertained
> that the session is alive).
>
> I agree that you may want to update the stayte diagram to
> reflect this.
>
> Julo
>
>
> "Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on 24-08-2001 01:46:40
>
> Please respond to cbm@rose.hp.com
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   ips@ece.cmu.edu
> cc:
> Subject:  iSCSI: reusing ISID for recovery (Was: RE: iSCSI - Change -
>       Login/Text...)
>
>
>
> Julian and all:
>
> This thread mirrors another discussion some of us are
> having in a different forum.  Following (two bullets 1
> & 2 below) is what I proposed there, attempting to address
> two issues -
>      a) how to recover sessions when target and the initiator
>            have conflicting views of the same TCP connection(s)?
>            (Initiator NIC fails, but there's no I/O activity,
>            and the target doesn't see any connection failure.)
>      b) More specifically, how to address the above problem
>            when the initiator *does not want* to re-instate failed
>            connections since it only implements the mandatory
>            session recovery?
>
> This could add clarity or muddle things up here, though hopefully
> the former...
>
> 1 If login is sent with the same ISID, same TSID, same CID and X-bit,
>   then it means a failed connection is being re-instated (whether
>   or not there are multiple connections in the session).  This login
>   attempt must be done before the connection timeout (transition M1),
>   or if this is the only connection in the session, also before the
>   session timeout (transition N6) - to be counted as a connection
>   reinstatement effort.
>            o CmdSN counters (CmdSN, ExpCmdSN) are continued.
> Initiator
>              must do command plugging when there's a mismatch
>              between its CmdSN and ExpCmdSN in the login response.
>            o Since this is an implicit connection logout, all
> the active
>              tasks on the connection are either internally terminated,
>              or made non-allegiant (based on ErrorRecoveryLevel=x/y,
>              TBD) for recovery.
>
> 2 If login is sent with the same ISID and TSID=0, the session (if it
>   exists on the target) is being cleared and any active connections
>   that the target sees must be immediately (at the end of the login
>   process including any initiator authentication) transport reset.
>   Initiator may attempt this only after it ascertains a
> session failure
>   on its end (ie. all connections entered RECOVERY_START).
>            o CmdSN counters get reset.  Initiator has to perform the
>              currently defined session recovery actions.
>            o All active tasks of the session are internally
> terminated.
>
>
> Essentially, I was proposing extending the same notion of "implicit
> logout" of a connection to the session level.  The options that I
> see are -
>
>        A) Should iSCSI let it happen by default as stated above (ie.
>           same ISID, TSID=0 always wipes out the pre-existing session
>           on target, since we are mandating it to be used only when
>           initiator sees a session failure)?
>        B) Should iSCSI mandate making this intended cleanup explicit
>           by setting a bit (Say C-bit, for Clear) in the Login Command
>           PDU to prevent an accidental session cleanup with a buggy
>           initiator code?
>        C) Should iSCSI merely state that targets must ascertain
>           the connection state(s) whenever a new session creation
>           attempt is made with a known ISID and TSID=0?  (sort of
>           defeats the intention of the initiator wanting quicker
>           session recovery since the Login command PDU would have
>           to idle till target ascertains the connection state(s)).
>
> I prefer A, or B.
>
> Going with A or B means that the description of transition N3
> in the session state diagram would have to change to:
>      Last LOGGED_IN connection had ceased to be LOGGED_IN,
>         or a Login Command requesting clearing the session (also
>         with C-bit set, if option B) was received by the target.
>
> The transition N7's description would have to be augmented as
> well to:
>         Session recovery attempt with an implicit logout,
>         or connection reinstatement/new CID addition.
>
> Comments?
> --
> Mallikarjun
>
>
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> MS 5668   Hewlett-Packard, Roseville.
> cbm@rose.hp.com
>
>
> >Stephen,
> >
> >That can happen as the target may set-up completely new TCP
> connections
> >(the old sockets are still there and look OK).
> >Untill the login is  progessing he assumes that this is just another
> >open-session attempt. Then he checks the old session and the
> session is
> >dead (initiator has closed the connections).
> >
> >The target has to distinguish only between a session that is
> alive (and
> >reject the new one) and one that its dead in which case it
> can clean-up.
> >
> >Julo
> >
> >"Wheat, Stephen R" <stephen.r.wheat@intel.com> on 23-08-2001 22:50:56
> >
> >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> >
> >To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> >cc:
> >Subject:  RE: iSCSI - Change - Login/Text commands with the
> binary stage
> co
> >          de
> >
> >
> >
> >Julian,
> >
> >I don't understand your answer.  For the scenario given, I
> would presume
> >then that the target would reject the new session attempt,
> as it sees the
> >previous session still "alive".  What is there to tell the
> target that
> this
> >is any different from when the Initiator is erroneously using the
> >repetitive
> >session id?
> >
> >Thanks,
> >Stephen
> >
> >-----Original Message-----
> >From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> >Sent: Thursday, August 23, 2001 11:15 AM
> >To: ips@ece.cmu.edu
> >Subject: Re: iSCSI - Change - Login/Text commands with the
> binary stage
> >co de
> >
> >
> >Stephen,
> >
> >1.If the initiator goes away for a while and reboots and there was no
> >activity on the connections
> >the target may see a session alive (I am not sure that it
> has to appear on
> >the state diagram but maybe).
> >
> >2.Again - I am not sure that the curent state diagram
> includes death of
> the
> >initiator
> >
> >Julo
> >
> >"Wheat, Stephen R" <stephen.r.wheat@intel.com>@ece.cmu.edu
> on 23-08-2001
> >19:58:34
> >
> >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> >
> >Sent by:  owner-ips@ece.cmu.edu
> >
> >
> >To:   ips@ece.cmu.edu
> >cc:
> >Subject:  Re: iSCSI - Change - Login/Text commands with the
> binary stage
> co
> >      de
> >
> >
> >
> >Julian,
> >
> >1.3.6 ISID states that the target should check to see if the
> old session
> is
> >still active when a duplicate session is detected.
> >
> >I have two questions, the second only if you answer in the
> affirmative on
> >the first ;^)
> >
> >1. Is there a properly executed sequence of events (i.e., no
> coding error
> >on
> >the target side) where the session is not active, but the
> target hadn't
> >taken notice of it?  It appears this as a protocol-specified
> means to work
> >around a flaw in a target's implementation.  I interpret the
> state diagram
> >transitions as being atomic wrt other commands.  I.e., the
> last logout
> >would
> >result in the various transitions of the connection/session
> prior to the
> >initiator starting the session up again.  And the target would have
> >completed the transitions prior to handling a new session request.
> >
> >2. If you answered (1) in the affirmative, then the word
> "Active" is not
> >consistent with the 6.3 Session State Diagram.  Does this
> mean the target
> >got lost, due to transport failures of any sort, in its
> transition from
> >Q3-to-Q2-to-Q1?  It sounds like the intent is to close the
> old session if
> >the session was in Q2 or Q4, presuming if it were in Q1,  it
> would not
> have
> >been found as a duplicate.
> >
> >Stephen
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
>








From owner-ips@ece.cmu.edu  Mon Aug 27 11:34:55 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21935
	for <ips-archive@odin.ietf.org>; Mon, 27 Aug 2001 11:34:55 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7RElkl01803
	for ips-outgoing; Mon, 27 Aug 2001 10:47:46 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7REljP01799
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 10:47:45 -0400 (EDT)
Received: from SMTP (fmsmsxvs05-1.fm.intel.com [132.233.42.205])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id OAA25154
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 14:47:43 GMT
Received: from fmsmsx28.fm.intel.com ([132.233.48.28]) by 132.233.48.205
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Mon, 27 Aug 2001 14:47:43 0000 (GMT)
Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <RR4GLPZ4>; Mon, 27 Aug 2001 07:47:42 -0700
Message-ID: <638EC1B28663D211AC3E00A0C96B78A8086ABB5F@orsmsx40.jf.intel.com>
From: "Wheat, Stephen R" <stephen.r.wheat@intel.com>
To: ips@ece.cmu.edu
Subject: RE: iSCSI - Change - Login/Text commands with the binary stage co
		de
Date: Mon, 27 Aug 2001 07:47:40 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Julian,

So the Target ignores C-replay CmdSN, mistaking C-replay to be a post-D
prompt.  How can that be?

Stephen the Terse (still looking for bookmark rationale)

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, August 23, 2001 10:05 PM
To: ips@ece.cmu.edu
Subject: RE: iSCSI - Change - Login/Text commands with the binary stage
co de


Stephen,

I wonder if 123 words (your note) are really needed to say that bookmarks
have no role at all.

For an exchange going well  and on a single connection bookmarks are not
doing more that their paper counterpart. It is when things go wrong that
you need them.

Assume that you have the following sequence:

a)I->T text B=0
b)T->I text B=1 Bkmk1
c)I->T text B=1 Bkmk1
d)T->I text B=1 Bkmk2
e)I ->T...

Assume now that D got lost (digest) and the initiator reissues C.  Without
a Bookmark
the target will think that he got a prompt after D when in fact he got a
replay of C

In summary the bit acts like the paper bookmark and the bookmark field is
more like the word-processor bookmarks - it hold information relevant to
the party that built it.

Julo


"Wheat, Stephen R" <stephen.r.wheat@intel.com> on 24-08-2001 01:21:04

Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:
Subject:  RE: iSCSI - Change - Login/Text commands with the binary stage co
      de



OK; that makes more sense.

But now, why do we have it?  This whole discussion could have been avoided
if it wasn't there in the first place.  How many that follow me in reading
this will have the same questions?  Why should the spec provide something
that has no value in the execution of the spec?  It seems to me that this
is
superfluous, and as such doesn't belong in the spec.  I.e., this seems more
clearly a unnecessary item ever-more-so than alias.

Would you mind doing a query of the group as to who has objection to
removing the bookmark field?

I really hope my relatively new exposure to all of this has value to you
and
the other authors on the readability/clarity of the spec.

Thanks,
Stephen

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, August 23, 2001 11:10 AM
To: Wheat, Stephen R
Subject: RE: iSCSI - Change - Login/Text commands with the binary stage
co de


Stephen,

Bookmark is an opaque thing.  The initiator copies it dutifully from the
target.
The target may choose to put some information there or leave it 0 etc.

Regards,
Julo

"Wheat, Stephen R" <stephen.r.wheat@intel.com> on 23-08-2001 18:03:45

Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:
Subject:  RE: iSCSI - Change - Login/Text commands with the binary stage co
          de



Julian,

Thanks for your response.

OK, then if you follow your temptation, then the bookmark field goes away
and the B-bit does it all, yes?  Otherwise, I'm still missing the sequence
of events where the bookmark fields contributes to syncronization or
segregation or both.

Stephen

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, August 22, 2001 11:10 PM
To: Wheat, Stephen R
Subject: RE: iSCSI - Change - Login/Text commands with the binary stage
co de


Stephen,

I've fixed the 2 offending occurrences of Initiator Text Tag (It was a typo
- thanks).

The bookmark  was introduced to:

   relieve the target from the need to maintain state for a number of
   pending sequences - you can have only one bookmark (with some state in
   it) I am tempted to make it one bookmark/initiator
   allow to certify to the target that the initiator is still there and
   willing to get more information (when you clear the bookmark you can
   delete whatever state you maintained).


Regards,
Julo



"Wheat, Stephen R" <stephen.r.wheat@intel.com> on 22-08-2001 20:48:25

Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:
Subject:  RE: iSCSI - Change - Login/Text commands with the binary stage co
      de



Julian, just to you.

In a couple of places, this refers to "Initiator Text Tag".  What is that?
Is it a typo?

Also, I've been pondering the bookmark field.  Why does this field exist
beyond the B bit, if the bookmark's validity is invalidated by having
received a command with a different ITT?  There must be a scenario where
the
following doesn't work.  Please advise.


      I->T Text SendTargets=all (F=1,B=0)
      T->I Text <part 1> (F=0,B=1)
      I->T Text <empty> (F=1,B=1)
      T->I Text <part 2> (F=0,B=1)
      I->T Text <empty> (F=1,B=1)
      ...
      T->I Text <part n> (F=1,B=0)

Thanks,
Stephen

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, August 22, 2001 1:30 AM
To: ips@ece.cmu.edu
Subject: iSCSI - Change - Login/Text commands with the binary stage code


1.1.5     Bookmark

   An opaque handle copied from a previous text response.  It is supposed
   to allow a target to transfer a large amount of textual data over a
   sequence of text-command/text-response exchanges.  The target associates
   the bookmark it issues with the Initiator Task Tag and a received
   Bookmark is considered valid by the Target only if received with the
   same Initiator Task Tag and if the target did not receive on the same
   connection a text command with a different Initiator Text Tag since it
*************                                           ^^^^ ????
   issued the Bookmark.













From owner-ips@ece.cmu.edu  Mon Aug 27 11:36:06 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21960
	for <ips-archive@odin.ietf.org>; Mon, 27 Aug 2001 11:36:06 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7REXxQ00829
	for ips-outgoing; Mon, 27 Aug 2001 10:33:59 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7REXvP00823
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 10:33:57 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id QAA62700
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 16:33:41 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7REVqD247384
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 16:31:54 +0200
Importance: Normal
Subject: RE: iSCSI - open issues - no discussion - recovery levels
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF11E73524.CCB43984-ONC2256AB5.004EFFB3@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Mon, 27 Aug 2001 17:31:19 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 27/08/2001 17:32:02
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Rod,

You are on the right track. The external draft includes markers and the
intent is to make them mandatory
whenever there is no other option.  The long debate is more on how to
phrase this.

Julo

"Rod Harrison" <rod.harrison@windriver.com> on 27-08-2001 16:43:56

Please respond to "Rod Harrison" <rod.harrison@windriver.com>

To:   Julian Satran/Haifa/IBM@IBMIL, <ips@ece.cmu.edu>
cc:
Subject:  RE: iSCSI - open issues - no discussion - recovery levels




     With respect to framing I would be firmly against replacing
markers with something that would require changes to the
network stack. I think it is clear that there will almost
certainly be software iSCSI implementations at workstations,
and that those workstations will need to provide framing /
markers for hardware at the server that require them. Having
come this far I think it would be a change for the worse
were we to prevent software implementations that allow a
hardware implementation to perform at its best. I favour
MUST provide markers, and have no objection to a reference
to an external framing draft as an option.

     With respect to recovery I agree that the all or nothing
approach (2 layers) is a good choice..

     - Rod

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On
Behalf Of
Julian Satran
Sent: Sunday, August 26, 2001 2:07 PM
To: ips@ece.cmu.edu
Subject: iSCSI - open issues - no discussion - recovery
levels


Dear colleagues,

Considering that the next plugfest is getting close and we
would like to
have
version 08 ready for it.

We have two open items that got little attention on the list
up to now:

- taking out the markers and inserting a reference to an
external framing
draft (what is mandatory, what is optional etc.)
- recovery the recovery levels proposal

The status  with both is as follows:

- on the framing there is consensus that it is a good idea;
there is no
consensus on what is  MUST, SHOULD etc.
- on the recovery there is consesus that it is a good idea;
there is no
consensus on how many layers to enforce (I think that 2 -
all or nothing is
a good choice).

Regards,
Julo







From owner-ips@ece.cmu.edu  Mon Aug 27 11:44:52 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22323
	for <ips-archive@odin.ietf.org>; Mon, 27 Aug 2001 11:44:52 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7REp3e02018
	for ips-outgoing; Mon, 27 Aug 2001 10:51:03 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7REp0P02013
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 10:51:00 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id QAA123356
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 16:50:50 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7REoje134650
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 16:50:45 +0200
Importance: Normal
Subject: RE: iSCSI: reusing ISID for recovery
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFA922338A.8425A36D-ONC2256AB5.00513E0D@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Mon, 27 Aug 2001 17:50:09 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 27/08/2001 17:50:46
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Jim,

It would be interesting to hear your arguments. The functions is clearly
there - only that an initiator has to perform two steps
Why is it important (except for boot) that a living initiator do it in one
step.

Regards,
Julo

Jim Hafner/Almaden/IBM@IBMUS@ece.cmu.edu on 27-08-2001 17:16:33

Please respond to Jim Hafner/Almaden/IBM@IBMUS

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery




Julo,
You wrote:
  And I would like to remind you all that we where on this exact thread
more
  tan 3 months ago (other players).
  I just restated the rationale for an (apparent) newcomer.

On the other hand, I don't recall this issue ever being called for
concensus.  Opinions were posted and nothing followed up.

I happen to agree with Marjorie.

Jim Hafner


Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 08/25/2001 12:22:33 AM

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery




It may be another OS running on the same machine or CPU complex or it could
be an attack.
In any case if the initiator is up and fine he can as well do logout.
It is a rare enough event for us not to try to optimize.

The reboot is the only case in which the initiator can't logout and about
which we care.

And I would like to remind you all that we where on this exact thread more
tan 3 months ago (other players).
I just restated the rationale for an (apparent) newcomer.

Julo

"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>@ece.cmu.edu
on 25-08-2001 03:51:43

Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"
      <marjorie_krueger@hp.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery



I don't see how Option A is prone to "wild closing of sessions".  The
target
is only looking for sessions with this particular initiator and closing
them
if the ISID matches.

If an initiator doesn't have a valid TSID (login w/TSID=0), it means it has
lost state entirely (reboot) or knows it wants to immediately reset a
session (NIC failure).  How could there possibly be a case where the
initiator has an active valid session with the same ISID, but just doesn't
know about it??  Rejecting the login seems pointless, since obviously the
initiator either has a bug or intends to quickly reset the session.

The behavior chosen (Option C) will cause the initiator's recovery to be
delayed while the target NOPs all the connections and waits for them to
time
out - this will only delay the initiators recovery unnecessarily.  I can't
help but think this will cause long term problems for the protocol.

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: marjorie_krueger@hp.com

> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Thursday, August 23, 2001 9:39 PM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI: reusing ISID for recovery (Was: RE: iSCSI
> - Change -
> Login/Text...)
>
>
>
> Mallikarjun,
>
> On  your point 1 that is what is stated today in the draft.
>
> On your point 2 option C is the one we took in the draft, after some
> debate.
>
> Option A is prone to "wild closing of sessions" and option B is also
> relaying to much on the good behaviour of the
> client. It also introduces a "feature" that complicates login/logout.
>
> Our postion on this is  that the initiator should logout the session
> explicitly if it can (and in this case it can as the target
> has ascertained
> that the session is alive).
>
> I agree that you may want to update the stayte diagram to
> reflect this.
>
> Julo
>
>
> "Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on 24-08-2001 01:46:40
>
> Please respond to cbm@rose.hp.com
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   ips@ece.cmu.edu
> cc:
> Subject:  iSCSI: reusing ISID for recovery (Was: RE: iSCSI - Change -
>       Login/Text...)
>
>
>
> Julian and all:
>
> This thread mirrors another discussion some of us are
> having in a different forum.  Following (two bullets 1
> & 2 below) is what I proposed there, attempting to address
> two issues -
>      a) how to recover sessions when target and the initiator
>            have conflicting views of the same TCP connection(s)?
>            (Initiator NIC fails, but there's no I/O activity,
>            and the target doesn't see any connection failure.)
>      b) More specifically, how to address the above problem
>            when the initiator *does not want* to re-instate failed
>            connections since it only implements the mandatory
>            session recovery?
>
> This could add clarity or muddle things up here, though hopefully
> the former...
>
> 1 If login is sent with the same ISID, same TSID, same CID and X-bit,
>   then it means a failed connection is being re-instated (whether
>   or not there are multiple connections in the session).  This login
>   attempt must be done before the connection timeout (transition M1),
>   or if this is the only connection in the session, also before the
>   session timeout (transition N6) - to be counted as a connection
>   reinstatement effort.
>            o CmdSN counters (CmdSN, ExpCmdSN) are continued.
> Initiator
>              must do command plugging when there's a mismatch
>              between its CmdSN and ExpCmdSN in the login response.
>            o Since this is an implicit connection logout, all
> the active
>              tasks on the connection are either internally terminated,
>              or made non-allegiant (based on ErrorRecoveryLevel=x/y,
>              TBD) for recovery.
>
> 2 If login is sent with the same ISID and TSID=0, the session (if it
>   exists on the target) is being cleared and any active connections
>   that the target sees must be immediately (at the end of the login
>   process including any initiator authentication) transport reset.
>   Initiator may attempt this only after it ascertains a
> session failure
>   on its end (ie. all connections entered RECOVERY_START).
>            o CmdSN counters get reset.  Initiator has to perform the
>              currently defined session recovery actions.
>            o All active tasks of the session are internally
> terminated.
>
>
> Essentially, I was proposing extending the same notion of "implicit
> logout" of a connection to the session level.  The options that I
> see are -
>
>        A) Should iSCSI let it happen by default as stated above (ie.
>           same ISID, TSID=0 always wipes out the pre-existing session
>           on target, since we are mandating it to be used only when
>           initiator sees a session failure)?
>        B) Should iSCSI mandate making this intended cleanup explicit
>           by setting a bit (Say C-bit, for Clear) in the Login Command
>           PDU to prevent an accidental session cleanup with a buggy
>           initiator code?
>        C) Should iSCSI merely state that targets must ascertain
>           the connection state(s) whenever a new session creation
>           attempt is made with a known ISID and TSID=0?  (sort of
>           defeats the intention of the initiator wanting quicker
>           session recovery since the Login command PDU would have
>           to idle till target ascertains the connection state(s)).
>
> I prefer A, or B.
>
> Going with A or B means that the description of transition N3
> in the session state diagram would have to change to:
>      Last LOGGED_IN connection had ceased to be LOGGED_IN,
>         or a Login Command requesting clearing the session (also
>         with C-bit set, if option B) was received by the target.
>
> The transition N7's description would have to be augmented as
> well to:
>         Session recovery attempt with an implicit logout,
>         or connection reinstatement/new CID addition.
>
> Comments?
> --
> Mallikarjun
>
>
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> MS 5668   Hewlett-Packard, Roseville.
> cbm@rose.hp.com
>
>
> >Stephen,
> >
> >That can happen as the target may set-up completely new TCP
> connections
> >(the old sockets are still there and look OK).
> >Untill the login is  progessing he assumes that this is just another
> >open-session attempt. Then he checks the old session and the
> session is
> >dead (initiator has closed the connections).
> >
> >The target has to distinguish only between a session that is
> alive (and
> >reject the new one) and one that its dead in which case it
> can clean-up.
> >
> >Julo
> >
> >"Wheat, Stephen R" <stephen.r.wheat@intel.com> on 23-08-2001 22:50:56
> >
> >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> >
> >To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> >cc:
> >Subject:  RE: iSCSI - Change - Login/Text commands with the
> binary stage
> co
> >          de
> >
> >
> >
> >Julian,
> >
> >I don't understand your answer.  For the scenario given, I
> would presume
> >then that the target would reject the new session attempt,
> as it sees the
> >previous session still "alive".  What is there to tell the
> target that
> this
> >is any different from when the Initiator is erroneously using the
> >repetitive
> >session id?
> >
> >Thanks,
> >Stephen
> >
> >-----Original Message-----
> >From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> >Sent: Thursday, August 23, 2001 11:15 AM
> >To: ips@ece.cmu.edu
> >Subject: Re: iSCSI - Change - Login/Text commands with the
> binary stage
> >co de
> >
> >
> >Stephen,
> >
> >1.If the initiator goes away for a while and reboots and there was no
> >activity on the connections
> >the target may see a session alive (I am not sure that it
> has to appear on
> >the state diagram but maybe).
> >
> >2.Again - I am not sure that the curent state diagram
> includes death of
> the
> >initiator
> >
> >Julo
> >
> >"Wheat, Stephen R" <stephen.r.wheat@intel.com>@ece.cmu.edu
> on 23-08-2001
> >19:58:34
> >
> >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> >
> >Sent by:  owner-ips@ece.cmu.edu
> >
> >
> >To:   ips@ece.cmu.edu
> >cc:
> >Subject:  Re: iSCSI - Change - Login/Text commands with the
> binary stage
> co
> >      de
> >
> >
> >
> >Julian,
> >
> >1.3.6 ISID states that the target should check to see if the
> old session
> is
> >still active when a duplicate session is detected.
> >
> >I have two questions, the second only if you answer in the
> affirmative on
> >the first ;^)
> >
> >1. Is there a properly executed sequence of events (i.e., no
> coding error
> >on
> >the target side) where the session is not active, but the
> target hadn't
> >taken notice of it?  It appears this as a protocol-specified
> means to work
> >around a flaw in a target's implementation.  I interpret the
> state diagram
> >transitions as being atomic wrt other commands.  I.e., the
> last logout
> >would
> >result in the various transitions of the connection/session
> prior to the
> >initiator starting the session up again.  And the target would have
> >completed the transitions prior to handling a new session request.
> >
> >2. If you answered (1) in the affirmative, then the word
> "Active" is not
> >consistent with the 6.3 Session State Diagram.  Does this
> mean the target
> >got lost, due to transport failures of any sort, in its
> transition from
> >Q3-to-Q2-to-Q1?  It sounds like the intent is to close the
> old session if
> >the session was in Q2 or Q4, presuming if it were in Q1,  it
> would not
> have
> >been found as a duplicate.
> >
> >Stephen
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
>











From owner-ips@ece.cmu.edu  Mon Aug 27 12:03:41 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22918
	for <ips-archive@odin.ietf.org>; Mon, 27 Aug 2001 12:03:40 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7RF98s03101
	for ips-outgoing; Mon, 27 Aug 2001 11:09:08 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from hebe.or.intel.com (jffdns02.or.intel.com [134.134.248.4])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7RF95P03092
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 11:09:05 -0400 (EDT)
Received: from SMTP (orsmsxvs01-1.jf.intel.com [192.168.65.200])
	by hebe.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id PAA18424
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 15:08:59 GMT
Received: from orsmsx29.jf.intel.com ([192.168.70.29]) by 192.168.70.200
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Mon, 27 Aug 2001 15:08:58 0000 (GMT)
Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2653.19)
	id <RR4JFCZP>; Mon, 27 Aug 2001 08:08:55 -0700
Message-ID: <638EC1B28663D211AC3E00A0C96B78A8086ABB60@orsmsx40.jf.intel.com>
From: "Wheat, Stephen R" <stephen.r.wheat@intel.com>
To: "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
Subject: RE: iSCSI - Change - Login/Text commands with the binary stage co
		de
Date: Mon, 27 Aug 2001 08:07:32 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Argh, in my attempt to be concise, I forgot to ask about why the target
would ignore the X-bit and consider this as a new command/prompt.  Shouldn't
that suffice to see that it is a replay of a text command, instead of a new
one?  I realize that with I-bit set, CmdSN may not be trackable, yes?

Stephen

-----Original Message-----
From: Wheat, Stephen R 
Sent: Monday, August 27, 2001 7:48 AM
To: ips@ece.cmu.edu
Subject: RE: iSCSI - Change - Login/Text commands with the binary stage
co de


Julian,

So the Target ignores C-replay CmdSN, mistaking C-replay to be a post-D
prompt.  How can that be?

Stephen the Terse (still looking for bookmark rationale)

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, August 23, 2001 10:05 PM
To: ips@ece.cmu.edu
Subject: RE: iSCSI - Change - Login/Text commands with the binary stage
co de


Stephen,

I wonder if 123 words (your note) are really needed to say that bookmarks
have no role at all.

For an exchange going well  and on a single connection bookmarks are not
doing more that their paper counterpart. It is when things go wrong that
you need them.

Assume that you have the following sequence:

a)I->T text B=0
b)T->I text B=1 Bkmk1
c)I->T text B=1 Bkmk1
d)T->I text B=1 Bkmk2
e)I ->T...

Assume now that D got lost (digest) and the initiator reissues C.  Without
a Bookmark
the target will think that he got a prompt after D when in fact he got a
replay of C

In summary the bit acts like the paper bookmark and the bookmark field is
more like the word-processor bookmarks - it hold information relevant to
the party that built it.

Julo


"Wheat, Stephen R" <stephen.r.wheat@intel.com> on 24-08-2001 01:21:04

Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:
Subject:  RE: iSCSI - Change - Login/Text commands with the binary stage co
      de



OK; that makes more sense.

But now, why do we have it?  This whole discussion could have been avoided
if it wasn't there in the first place.  How many that follow me in reading
this will have the same questions?  Why should the spec provide something
that has no value in the execution of the spec?  It seems to me that this
is
superfluous, and as such doesn't belong in the spec.  I.e., this seems more
clearly a unnecessary item ever-more-so than alias.

Would you mind doing a query of the group as to who has objection to
removing the bookmark field?

I really hope my relatively new exposure to all of this has value to you
and
the other authors on the readability/clarity of the spec.

Thanks,
Stephen

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, August 23, 2001 11:10 AM
To: Wheat, Stephen R
Subject: RE: iSCSI - Change - Login/Text commands with the binary stage
co de


Stephen,

Bookmark is an opaque thing.  The initiator copies it dutifully from the
target.
The target may choose to put some information there or leave it 0 etc.

Regards,
Julo

"Wheat, Stephen R" <stephen.r.wheat@intel.com> on 23-08-2001 18:03:45

Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:
Subject:  RE: iSCSI - Change - Login/Text commands with the binary stage co
          de



Julian,

Thanks for your response.

OK, then if you follow your temptation, then the bookmark field goes away
and the B-bit does it all, yes?  Otherwise, I'm still missing the sequence
of events where the bookmark fields contributes to syncronization or
segregation or both.

Stephen

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, August 22, 2001 11:10 PM
To: Wheat, Stephen R
Subject: RE: iSCSI - Change - Login/Text commands with the binary stage
co de


Stephen,

I've fixed the 2 offending occurrences of Initiator Text Tag (It was a typo
- thanks).

The bookmark  was introduced to:

   relieve the target from the need to maintain state for a number of
   pending sequences - you can have only one bookmark (with some state in
   it) I am tempted to make it one bookmark/initiator
   allow to certify to the target that the initiator is still there and
   willing to get more information (when you clear the bookmark you can
   delete whatever state you maintained).


Regards,
Julo



"Wheat, Stephen R" <stephen.r.wheat@intel.com> on 22-08-2001 20:48:25

Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:
Subject:  RE: iSCSI - Change - Login/Text commands with the binary stage co
      de



Julian, just to you.

In a couple of places, this refers to "Initiator Text Tag".  What is that?
Is it a typo?

Also, I've been pondering the bookmark field.  Why does this field exist
beyond the B bit, if the bookmark's validity is invalidated by having
received a command with a different ITT?  There must be a scenario where
the
following doesn't work.  Please advise.


      I->T Text SendTargets=all (F=1,B=0)
      T->I Text <part 1> (F=0,B=1)
      I->T Text <empty> (F=1,B=1)
      T->I Text <part 2> (F=0,B=1)
      I->T Text <empty> (F=1,B=1)
      ...
      T->I Text <part n> (F=1,B=0)

Thanks,
Stephen

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, August 22, 2001 1:30 AM
To: ips@ece.cmu.edu
Subject: iSCSI - Change - Login/Text commands with the binary stage code


1.1.5     Bookmark

   An opaque handle copied from a previous text response.  It is supposed
   to allow a target to transfer a large amount of textual data over a
   sequence of text-command/text-response exchanges.  The target associates
   the bookmark it issues with the Initiator Task Tag and a received
   Bookmark is considered valid by the Target only if received with the
   same Initiator Task Tag and if the target did not receive on the same
   connection a text command with a different Initiator Text Tag since it
*************                                           ^^^^ ????
   issued the Bookmark.













From owner-ips@ece.cmu.edu  Mon Aug 27 12:04:32 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22958
	for <ips-archive@odin.ietf.org>; Mon, 27 Aug 2001 12:04:27 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7RF7pS03010
	for ips-outgoing; Mon, 27 Aug 2001 11:07:51 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f7RF7nP03003
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 11:07:49 -0400 (EDT)
Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Mon Aug 27 11:07:26 EDT 2001
Received: from aura.research.bell-labs.com ([135.104.46.10]) by grubby; Mon Aug 27 11:07:45 EDT 2001
Received: from research.bell-labs.com (IDENT:sandeepj@sandeepj-pcmh.research.bell-labs.com [135.104.47.90])
	by aura.research.bell-labs.com (8.9.1/8.9.1) with ESMTP id LAA28537;
	Mon, 27 Aug 2001 11:07:10 -0400 (EDT)
Message-ID: <3B8A621E.C50BF07A@research.bell-labs.com>
Date: Mon, 27 Aug 2001 11:07:10 -0400
From: Sandeep Joshi <sandeepj@research.bell-labs.com>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-3 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Julian Satran <Julian_Satran@il.ibm.com>
CC: ips@ece.cmu.edu
Subject: Re: iSCSI: draft 7: remove S bit and Status field from the Data-i
References: <OF6D417708.84792326-ONC2256AB4.0016197F@telaviv.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


Julian,

I am probably missing something here..especially 
now that you refer to multiplexing.

The rule would be per-connection - why it is difficult
for the initiator to send the unsolicited data _right_
after the command ?  The data is already available from
the ULP.

If this new rule is not added, the target needs 
to route unsolicited PDUs based on ITT (..a foreign tag)
Its not a checking burden but a performance gain.

The only other cases which requires ITT routing at the
target are abort-task, D-SNACK and command-retry, all 
of which we can assume to be infrequent and not in the 
performance path.

-Sandeep

P.S. Let me throw in some casuistry...this is also why 
dog owners are made to follow dogs, so one doesnt need 
to look at dog tags :-)


Julian Satran wrote:
> 
> I am sure we don't want to enter this. The sequencing rules are there to
> asure:
> 
>    that there is no deadlock (order of data must follow the order of
>    commands)
>    that the target command buffer does not overflow (MaxCmdSN) - this will
>    eliminate an "unlimited number of immediate"
> 
> Any additional rules will interfere with performance, multiplexing policy
> etc. and I see no great
> value in enforcing them (and enforcing means checking and that means
> expense).
> 
> Julo
> 
> Sandeep Joshi <sandeepj@research.bell-labs.com>@ece.cmu.edu on 26-08-2001
> 00:11:39
> 
> Please respond to Sandeep Joshi <sandeepj@research.bell-labs.com>
> 
> Sent by:  owner-ips@ece.cmu.edu
> 
> To:   Dave Sheehy <dbs@acropora.rose.agilent.com>
> cc:   IETF IP SAN Reflector <ips@ece.cmu.edu>
> Subject:  Re: iSCSI: draft 7: remove S bit and Status field from the Data-i
> 
> Julian,
> 
> I wonder if Dave's last paragraph in this email has been considered.
> Here it is again..
> 
> > This does help some. It eliminates the situation where a target can
> receive
> > an essentially unlimited number of immediate data commands prior to
> receiving
> > *any* data PDUs.
> 
> in reference to Section 1.2.5
> > Unsolicited data MUST be sent on
> > every connection in the same order in which commands were sent.
> 
> The draft currently allows
>    c-1,c-2,c-3, (SEP-1-1),(SEP-1-2),(SEP-2-1,SEP-2-2),..
> where c-N = command {N}
> and   SEP-N-M = unsolicited (non-immediate) PDU number {M} for command
> {N}
> 
> It would be simplify target login (ITT lookup) if we only permitted
> this sequence.
>    c-1, SEP-1-1, SEP-1-2, c-2, SEP-2-1, SEP-2-2,..
> 
> -Sandeep
> 
> Dave Sheehy wrote:
> >
> > David,
> >
> > > I think you've taken a wrong turn.
> >
> > I think John hit the nail on the head.
> >
> > > > Second, thoughts of removing the immediate data seem not to be
> > > > simplification, since all the information to tie the data to the
> command
> > > is
> > > > right there with the command.  That has got to be easier than
> matching up
> > > > separate PDUs of data with the appropriate commands.
> > >
> > > Actually, that was the point, since the logic for "matching up separate
> > > PDUs of data with the appropriate commands" has to exist for inbound
> > > Data PDUs already.
> >
> > Except that there is a target context present in the solicited case to
> route
> > the data. That doesn't exist in the unsolicited case.
> >
> > > The slide I presented in London was about replacing
> > > immediate data with an unsolicited data PDU immediately following the
> > > command, thus removing the immediate data case in favor of reusing the
> > > logic for dealing with separate Data PDUs.  Remember that this was
> presented
> > > as a simplification possibility.
> >
> > This does help some. It eliminates the situation where a target can
> receive
> > an essentially unlimited number of immediate data commands prior to
> receiving
> > *any* data PDUs.
> >
> > But, do you mean to say that *one* unsolicited data PDU would follow the
> > command? Wouldn't that be unnecessarily restrictive if the PDU size is
> small?
> > Simply guaranteeing that the data PDUs will immediately follow the
> command
> > seems like an adequate improvement.
> >
> > Dave Sheehy


From owner-ips@ece.cmu.edu  Mon Aug 27 13:07:21 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24829
	for <ips-archive@odin.ietf.org>; Mon, 27 Aug 2001 13:07:20 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7RFK9m03893
	for ips-outgoing; Mon, 27 Aug 2001 11:20:09 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7RFK6P03887
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 11:20:07 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id RAA129916
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 17:19:56 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7RFJrk64374
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 17:19:53 +0200
Importance: Normal
Subject: RE: iSCSI - Change - Login/Text commands with the binary stage co		de
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF0F0E5AB4.E453E056-ONC2256AB5.0053F1E1@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Mon, 27 Aug 2001 18:19:18 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 27/08/2001 18:19:52
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Stephen,

Yes with one bookmark per initiator my scenario is wrong and the a bit is
enough for correct operation.

Regards,
Julo


"Wheat, Stephen R" <stephen.r.wheat@intel.com>@ece.cmu.edu on 27-08-2001
17:47:40

Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI - Change - Login/Text commands with the binary stage co
          de



Julian,

So the Target ignores C-replay CmdSN, mistaking C-replay to be a post-D
prompt.  How can that be?

Stephen the Terse (still looking for bookmark rationale)

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, August 23, 2001 10:05 PM
To: ips@ece.cmu.edu
Subject: RE: iSCSI - Change - Login/Text commands with the binary stage
co de


Stephen,

I wonder if 123 words (your note) are really needed to say that bookmarks
have no role at all.

For an exchange going well  and on a single connection bookmarks are not
doing more that their paper counterpart. It is when things go wrong that
you need them.

Assume that you have the following sequence:

a)I->T text B=0
b)T->I text B=1 Bkmk1
c)I->T text B=1 Bkmk1
d)T->I text B=1 Bkmk2
e)I ->T...

Assume now that D got lost (digest) and the initiator reissues C.  Without
a Bookmark
the target will think that he got a prompt after D when in fact he got a
replay of C

In summary the bit acts like the paper bookmark and the bookmark field is
more like the word-processor bookmarks - it hold information relevant to
the party that built it.

Julo


"Wheat, Stephen R" <stephen.r.wheat@intel.com> on 24-08-2001 01:21:04

Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:
Subject:  RE: iSCSI - Change - Login/Text commands with the binary stage co
      de



OK; that makes more sense.

But now, why do we have it?  This whole discussion could have been avoided
if it wasn't there in the first place.  How many that follow me in reading
this will have the same questions?  Why should the spec provide something
that has no value in the execution of the spec?  It seems to me that this
is
superfluous, and as such doesn't belong in the spec.  I.e., this seems more
clearly a unnecessary item ever-more-so than alias.

Would you mind doing a query of the group as to who has objection to
removing the bookmark field?

I really hope my relatively new exposure to all of this has value to you
and
the other authors on the readability/clarity of the spec.

Thanks,
Stephen

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, August 23, 2001 11:10 AM
To: Wheat, Stephen R
Subject: RE: iSCSI - Change - Login/Text commands with the binary stage
co de


Stephen,

Bookmark is an opaque thing.  The initiator copies it dutifully from the
target.
The target may choose to put some information there or leave it 0 etc.

Regards,
Julo

"Wheat, Stephen R" <stephen.r.wheat@intel.com> on 23-08-2001 18:03:45

Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:
Subject:  RE: iSCSI - Change - Login/Text commands with the binary stage co
          de



Julian,

Thanks for your response.

OK, then if you follow your temptation, then the bookmark field goes away
and the B-bit does it all, yes?  Otherwise, I'm still missing the sequence
of events where the bookmark fields contributes to syncronization or
segregation or both.

Stephen

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, August 22, 2001 11:10 PM
To: Wheat, Stephen R
Subject: RE: iSCSI - Change - Login/Text commands with the binary stage
co de


Stephen,

I've fixed the 2 offending occurrences of Initiator Text Tag (It was a typo
- thanks).

The bookmark  was introduced to:

   relieve the target from the need to maintain state for a number of
   pending sequences - you can have only one bookmark (with some state in
   it) I am tempted to make it one bookmark/initiator
   allow to certify to the target that the initiator is still there and
   willing to get more information (when you clear the bookmark you can
   delete whatever state you maintained).


Regards,
Julo



"Wheat, Stephen R" <stephen.r.wheat@intel.com> on 22-08-2001 20:48:25

Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:
Subject:  RE: iSCSI - Change - Login/Text commands with the binary stage co
      de



Julian, just to you.

In a couple of places, this refers to "Initiator Text Tag".  What is that?
Is it a typo?

Also, I've been pondering the bookmark field.  Why does this field exist
beyond the B bit, if the bookmark's validity is invalidated by having
received a command with a different ITT?  There must be a scenario where
the
following doesn't work.  Please advise.


      I->T Text SendTargets=all (F=1,B=0)
      T->I Text <part 1> (F=0,B=1)
      I->T Text <empty> (F=1,B=1)
      T->I Text <part 2> (F=0,B=1)
      I->T Text <empty> (F=1,B=1)
      ...
      T->I Text <part n> (F=1,B=0)

Thanks,
Stephen

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, August 22, 2001 1:30 AM
To: ips@ece.cmu.edu
Subject: iSCSI - Change - Login/Text commands with the binary stage code


1.1.5     Bookmark

   An opaque handle copied from a previous text response.  It is supposed
   to allow a target to transfer a large amount of textual data over a
   sequence of text-command/text-response exchanges.  The target associates
   the bookmark it issues with the Initiator Task Tag and a received
   Bookmark is considered valid by the Target only if received with the
   same Initiator Task Tag and if the target did not receive on the same
   connection a text command with a different Initiator Text Tag since it
*************                                           ^^^^ ????
   issued the Bookmark.
















From owner-ips@ece.cmu.edu  Mon Aug 27 14:06:54 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26177
	for <ips-archive@odin.ietf.org>; Mon, 27 Aug 2001 14:06:42 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7RGoqE09889
	for ips-outgoing; Mon, 27 Aug 2001 12:50:52 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7RGomP09880
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 12:50:48 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id SAA77806
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 18:50:38 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7RGoaI64774
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 18:50:36 +0200
Importance: Normal
Subject: RE: iSCSI: reusing ISID for recovery
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF652C3B95.3AA23FD0-ONC2256AB5.005C0648@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Mon, 27 Aug 2001 19:50:00 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 27/08/2001 19:50:35
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Jim,

Option A is clearly unacceptable as an initiator may do harm.
Recovery is not done by the target neither in B nor in C.

In B an initiator has to add a bit (he may be tempted to put it in as "my
code is safe" while in C
it requires the initiator to logout first before he can reinitiate the
session.

B is an optimization over C - and quite dangerous.

Julo


Jim Hafner/Almaden/IBM@IBMUS@ece.cmu.edu on 27-08-2001 19:22:12

Please respond to Jim Hafner/Almaden/IBM@IBMUS

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery




Julo,

Here's the way I look at it.  I think this is an "error detection/recovery"
issue.

With a rule that the ISID doesn't get reused by an initiator to a given
target portal group,  it's the obligation of the initiator not to do it.
If  the initiator does it anyway, then it is acting in protocol error and
it is the job of the target to enforce that rule.   If the initiator still
does it anyway, it's probably because it has "lost its way", then it is in
error state (but how does it know this?).  I prefer option B. The target
enforces the protocol rule only.  An unexpected reject is the "error
detection" mechanism for the intiator.  The "forced" login is part of the
error recovery, as driven by the initiator which is doing the error
recovery.

I see option A as a simpler mechanim that makes the "explicit" error
recovery request by the initiator an "implicit" request with no direct
detection mechanism on the initiator side.   I'd go with this choice if it
is decided that the only time we'd expect an initiator to make this request
is after a reboot or other massive reset, where it wouldn't have clue about
it's previous state.  If there are cases where we think it won't "do the
right thing" when it could, then I would say that option B as a safer
mechanism.

In short, it gets the target out of doing error recovery on behalf of the
initiator without explicit (option B) or implicit (Option A) direction.
It's not in the business of "guessing" if the initiator needs recovery.

Jim Hafner


Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 08/27/2001 07:50:09 am

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery




Jim,

It would be interesting to hear your arguments. The functions is clearly
there - only that an initiator has to perform two steps
Why is it important (except for boot) that a living initiator do it in one
step.

Regards,
Julo

Jim Hafner/Almaden/IBM@IBMUS@ece.cmu.edu on 27-08-2001 17:16:33

Please respond to Jim Hafner/Almaden/IBM@IBMUS

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery




Julo,
You wrote:
  And I would like to remind you all that we where on this exact thread
more
  tan 3 months ago (other players).
  I just restated the rationale for an (apparent) newcomer.

On the other hand, I don't recall this issue ever being called for
concensus.  Opinions were posted and nothing followed up.

I happen to agree with Marjorie.

Jim Hafner


Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 08/25/2001 12:22:33 AM

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery




It may be another OS running on the same machine or CPU complex or it could
be an attack.
In any case if the initiator is up and fine he can as well do logout.
It is a rare enough event for us not to try to optimize.

The reboot is the only case in which the initiator can't logout and about
which we care.

And I would like to remind you all that we where on this exact thread more
tan 3 months ago (other players).
I just restated the rationale for an (apparent) newcomer.

Julo

"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>@ece.cmu.edu
on 25-08-2001 03:51:43

Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"
      <marjorie_krueger@hp.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery



I don't see how Option A is prone to "wild closing of sessions".  The
target
is only looking for sessions with this particular initiator and closing
them
if the ISID matches.

If an initiator doesn't have a valid TSID (login w/TSID=0), it means it has
lost state entirely (reboot) or knows it wants to immediately reset a
session (NIC failure).  How could there possibly be a case where the
initiator has an active valid session with the same ISID, but just doesn't
know about it??  Rejecting the login seems pointless, since obviously the
initiator either has a bug or intends to quickly reset the session.

The behavior chosen (Option C) will cause the initiator's recovery to be
delayed while the target NOPs all the connections and waits for them to
time
out - this will only delay the initiators recovery unnecessarily.  I can't
help but think this will cause long term problems for the protocol.

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: marjorie_krueger@hp.com

> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Thursday, August 23, 2001 9:39 PM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI: reusing ISID for recovery (Was: RE: iSCSI
> - Change -
> Login/Text...)
>
>
>
> Mallikarjun,
>
> On  your point 1 that is what is stated today in the draft.
>
> On your point 2 option C is the one we took in the draft, after some
> debate.
>
> Option A is prone to "wild closing of sessions" and option B is also
> relaying to much on the good behaviour of the
> client. It also introduces a "feature" that complicates login/logout.
>
> Our postion on this is  that the initiator should logout the session
> explicitly if it can (and in this case it can as the target
> has ascertained
> that the session is alive).
>
> I agree that you may want to update the stayte diagram to
> reflect this.
>
> Julo
>
>
> "Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on 24-08-2001 01:46:40
>
> Please respond to cbm@rose.hp.com
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   ips@ece.cmu.edu
> cc:
> Subject:  iSCSI: reusing ISID for recovery (Was: RE: iSCSI - Change -
>       Login/Text...)
>
>
>
> Julian and all:
>
> This thread mirrors another discussion some of us are
> having in a different forum.  Following (two bullets 1
> & 2 below) is what I proposed there, attempting to address
> two issues -
>      a) how to recover sessions when target and the initiator
>            have conflicting views of the same TCP connection(s)?
>            (Initiator NIC fails, but there's no I/O activity,
>            and the target doesn't see any connection failure.)
>      b) More specifically, how to address the above problem
>            when the initiator *does not want* to re-instate failed
>            connections since it only implements the mandatory
>            session recovery?
>
> This could add clarity or muddle things up here, though hopefully
> the former...
>
> 1 If login is sent with the same ISID, same TSID, same CID and X-bit,
>   then it means a failed connection is being re-instated (whether
>   or not there are multiple connections in the session).  This login
>   attempt must be done before the connection timeout (transition M1),
>   or if this is the only connection in the session, also before the
>   session timeout (transition N6) - to be counted as a connection
>   reinstatement effort.
>            o CmdSN counters (CmdSN, ExpCmdSN) are continued.
> Initiator
>              must do command plugging when there's a mismatch
>              between its CmdSN and ExpCmdSN in the login response.
>            o Since this is an implicit connection logout, all
> the active
>              tasks on the connection are either internally terminated,
>              or made non-allegiant (based on ErrorRecoveryLevel=x/y,
>              TBD) for recovery.
>
> 2 If login is sent with the same ISID and TSID=0, the session (if it
>   exists on the target) is being cleared and any active connections
>   that the target sees must be immediately (at the end of the login
>   process including any initiator authentication) transport reset.
>   Initiator may attempt this only after it ascertains a
> session failure
>   on its end (ie. all connections entered RECOVERY_START).
>            o CmdSN counters get reset.  Initiator has to perform the
>              currently defined session recovery actions.
>            o All active tasks of the session are internally
> terminated.
>
>
> Essentially, I was proposing extending the same notion of "implicit
> logout" of a connection to the session level.  The options that I
> see are -
>
>        A) Should iSCSI let it happen by default as stated above (ie.
>           same ISID, TSID=0 always wipes out the pre-existing session
>           on target, since we are mandating it to be used only when
>           initiator sees a session failure)?
>        B) Should iSCSI mandate making this intended cleanup explicit
>           by setting a bit (Say C-bit, for Clear) in the Login Command
>           PDU to prevent an accidental session cleanup with a buggy
>           initiator code?
>        C) Should iSCSI merely state that targets must ascertain
>           the connection state(s) whenever a new session creation
>           attempt is made with a known ISID and TSID=0?  (sort of
>           defeats the intention of the initiator wanting quicker
>           session recovery since the Login command PDU would have
>           to idle till target ascertains the connection state(s)).
>
> I prefer A, or B.
>
> Going with A or B means that the description of transition N3
> in the session state diagram would have to change to:
>      Last LOGGED_IN connection had ceased to be LOGGED_IN,
>         or a Login Command requesting clearing the session (also
>         with C-bit set, if option B) was received by the target.
>
> The transition N7's description would have to be augmented as
> well to:
>         Session recovery attempt with an implicit logout,
>         or connection reinstatement/new CID addition.
>
> Comments?
> --
> Mallikarjun
>
>
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> MS 5668   Hewlett-Packard, Roseville.
> cbm@rose.hp.com
>
>
> >Stephen,
> >
> >That can happen as the target may set-up completely new TCP
> connections
> >(the old sockets are still there and look OK).
> >Untill the login is  progessing he assumes that this is just another
> >open-session attempt. Then he checks the old session and the
> session is
> >dead (initiator has closed the connections).
> >
> >The target has to distinguish only between a session that is
> alive (and
> >reject the new one) and one that its dead in which case it
> can clean-up.
> >
> >Julo
> >
> >"Wheat, Stephen R" <stephen.r.wheat@intel.com> on 23-08-2001 22:50:56
> >
> >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> >
> >To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> >cc:
> >Subject:  RE: iSCSI - Change - Login/Text commands with the
> binary stage
> co
> >          de
> >
> >
> >
> >Julian,
> >
> >I don't understand your answer.  For the scenario given, I
> would presume
> >then that the target would reject the new session attempt,
> as it sees the
> >previous session still "alive".  What is there to tell the
> target that
> this
> >is any different from when the Initiator is erroneously using the
> >repetitive
> >session id?
> >
> >Thanks,
> >Stephen
> >
> >-----Original Message-----
> >From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> >Sent: Thursday, August 23, 2001 11:15 AM
> >To: ips@ece.cmu.edu
> >Subject: Re: iSCSI - Change - Login/Text commands with the
> binary stage
> >co de
> >
> >
> >Stephen,
> >
> >1.If the initiator goes away for a while and reboots and there was no
> >activity on the connections
> >the target may see a session alive (I am not sure that it
> has to appear on
> >the state diagram but maybe).
> >
> >2.Again - I am not sure that the curent state diagram
> includes death of
> the
> >initiator
> >
> >Julo
> >
> >"Wheat, Stephen R" <stephen.r.wheat@intel.com>@ece.cmu.edu
> on 23-08-2001
> >19:58:34
> >
> >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> >
> >Sent by:  owner-ips@ece.cmu.edu
> >
> >
> >To:   ips@ece.cmu.edu
> >cc:
> >Subject:  Re: iSCSI - Change - Login/Text commands with the
> binary stage
> co
> >      de
> >
> >
> >
> >Julian,
> >
> >1.3.6 ISID states that the target should check to see if the
> old session
> is
> >still active when a duplicate session is detected.
> >
> >I have two questions, the second only if you answer in the
> affirmative on
> >the first ;^)
> >
> >1. Is there a properly executed sequence of events (i.e., no
> coding error
> >on
> >the target side) where the session is not active, but the
> target hadn't
> >taken notice of it?  It appears this as a protocol-specified
> means to work
> >around a flaw in a target's implementation.  I interpret the
> state diagram
> >transitions as being atomic wrt other commands.  I.e., the
> last logout
> >would
> >result in the various transitions of the connection/session
> prior to the
> >initiator starting the session up again.  And the target would have
> >completed the transitions prior to handling a new session request.
> >
> >2. If you answered (1) in the affirmative, then the word
> "Active" is not
> >consistent with the 6.3 Session State Diagram.  Does this
> mean the target
> >got lost, due to transport failures of any sort, in its
> transition from
> >Q3-to-Q2-to-Q1?  It sounds like the intent is to close the
> old session if
> >the session was in Q2 or Q4, presuming if it were in Q1,  it
> would not
> have
> >been found as a duplicate.
> >
> >Stephen
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
>

















From owner-ips@ece.cmu.edu  Mon Aug 27 14:11:47 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26321
	for <ips-archive@odin.ietf.org>; Mon, 27 Aug 2001 14:11:45 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7RGMWX08164
	for ips-outgoing; Mon, 27 Aug 2001 12:22:32 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7RGMNP08154
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 12:22:23 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA44646
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 12:20:05 -0400
Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7RGMCc198940
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 10:22:12 -0600
Importance: Normal
Subject: RE: iSCSI: reusing ISID for recovery
To: ips@ece.cmu.edu
From: "Jim Hafner" <hafner@almaden.ibm.com>
Date: Mon, 27 Aug 2001 09:22:09 -0700
Message-ID: <OF75DCCA86.8458ED2C-ON88256AB5.0059D5F1@boulder.ibm.com>
X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at
 08/27/2001 09:22:12 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Julo,

Here's the way I look at it.  I think this is an "error detection/recovery"
issue.

With a rule that the ISID doesn't get reused by an initiator to a given
target portal group,  it's the obligation of the initiator not to do it.
If  the initiator does it anyway, then it is acting in protocol error and
it is the job of the target to enforce that rule.   If the initiator still
does it anyway, it's probably because it has "lost its way", then it is in
error state (but how does it know this?).  I prefer option B. The target
enforces the protocol rule only.  An unexpected reject is the "error
detection" mechanism for the intiator.  The "forced" login is part of the
error recovery, as driven by the initiator which is doing the error
recovery.

I see option A as a simpler mechanim that makes the "explicit" error
recovery request by the initiator an "implicit" request with no direct
detection mechanism on the initiator side.   I'd go with this choice if it
is decided that the only time we'd expect an initiator to make this request
is after a reboot or other massive reset, where it wouldn't have clue about
it's previous state.  If there are cases where we think it won't "do the
right thing" when it could, then I would say that option B as a safer
mechanism.

In short, it gets the target out of doing error recovery on behalf of the
initiator without explicit (option B) or implicit (Option A) direction.
It's not in the business of "guessing" if the initiator needs recovery.

Jim Hafner


Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 08/27/2001 07:50:09 am

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery




Jim,

It would be interesting to hear your arguments. The functions is clearly
there - only that an initiator has to perform two steps
Why is it important (except for boot) that a living initiator do it in one
step.

Regards,
Julo

Jim Hafner/Almaden/IBM@IBMUS@ece.cmu.edu on 27-08-2001 17:16:33

Please respond to Jim Hafner/Almaden/IBM@IBMUS

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery




Julo,
You wrote:
  And I would like to remind you all that we where on this exact thread
more
  tan 3 months ago (other players).
  I just restated the rationale for an (apparent) newcomer.

On the other hand, I don't recall this issue ever being called for
concensus.  Opinions were posted and nothing followed up.

I happen to agree with Marjorie.

Jim Hafner


Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 08/25/2001 12:22:33 AM

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery




It may be another OS running on the same machine or CPU complex or it could
be an attack.
In any case if the initiator is up and fine he can as well do logout.
It is a rare enough event for us not to try to optimize.

The reboot is the only case in which the initiator can't logout and about
which we care.

And I would like to remind you all that we where on this exact thread more
tan 3 months ago (other players).
I just restated the rationale for an (apparent) newcomer.

Julo

"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>@ece.cmu.edu
on 25-08-2001 03:51:43

Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"
      <marjorie_krueger@hp.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery



I don't see how Option A is prone to "wild closing of sessions".  The
target
is only looking for sessions with this particular initiator and closing
them
if the ISID matches.

If an initiator doesn't have a valid TSID (login w/TSID=0), it means it has
lost state entirely (reboot) or knows it wants to immediately reset a
session (NIC failure).  How could there possibly be a case where the
initiator has an active valid session with the same ISID, but just doesn't
know about it??  Rejecting the login seems pointless, since obviously the
initiator either has a bug or intends to quickly reset the session.

The behavior chosen (Option C) will cause the initiator's recovery to be
delayed while the target NOPs all the connections and waits for them to
time
out - this will only delay the initiators recovery unnecessarily.  I can't
help but think this will cause long term problems for the protocol.

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: marjorie_krueger@hp.com

> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Thursday, August 23, 2001 9:39 PM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI: reusing ISID for recovery (Was: RE: iSCSI
> - Change -
> Login/Text...)
>
>
>
> Mallikarjun,
>
> On  your point 1 that is what is stated today in the draft.
>
> On your point 2 option C is the one we took in the draft, after some
> debate.
>
> Option A is prone to "wild closing of sessions" and option B is also
> relaying to much on the good behaviour of the
> client. It also introduces a "feature" that complicates login/logout.
>
> Our postion on this is  that the initiator should logout the session
> explicitly if it can (and in this case it can as the target
> has ascertained
> that the session is alive).
>
> I agree that you may want to update the stayte diagram to
> reflect this.
>
> Julo
>
>
> "Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on 24-08-2001 01:46:40
>
> Please respond to cbm@rose.hp.com
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   ips@ece.cmu.edu
> cc:
> Subject:  iSCSI: reusing ISID for recovery (Was: RE: iSCSI - Change -
>       Login/Text...)
>
>
>
> Julian and all:
>
> This thread mirrors another discussion some of us are
> having in a different forum.  Following (two bullets 1
> & 2 below) is what I proposed there, attempting to address
> two issues -
>      a) how to recover sessions when target and the initiator
>            have conflicting views of the same TCP connection(s)?
>            (Initiator NIC fails, but there's no I/O activity,
>            and the target doesn't see any connection failure.)
>      b) More specifically, how to address the above problem
>            when the initiator *does not want* to re-instate failed
>            connections since it only implements the mandatory
>            session recovery?
>
> This could add clarity or muddle things up here, though hopefully
> the former...
>
> 1 If login is sent with the same ISID, same TSID, same CID and X-bit,
>   then it means a failed connection is being re-instated (whether
>   or not there are multiple connections in the session).  This login
>   attempt must be done before the connection timeout (transition M1),
>   or if this is the only connection in the session, also before the
>   session timeout (transition N6) - to be counted as a connection
>   reinstatement effort.
>            o CmdSN counters (CmdSN, ExpCmdSN) are continued.
> Initiator
>              must do command plugging when there's a mismatch
>              between its CmdSN and ExpCmdSN in the login response.
>            o Since this is an implicit connection logout, all
> the active
>              tasks on the connection are either internally terminated,
>              or made non-allegiant (based on ErrorRecoveryLevel=x/y,
>              TBD) for recovery.
>
> 2 If login is sent with the same ISID and TSID=0, the session (if it
>   exists on the target) is being cleared and any active connections
>   that the target sees must be immediately (at the end of the login
>   process including any initiator authentication) transport reset.
>   Initiator may attempt this only after it ascertains a
> session failure
>   on its end (ie. all connections entered RECOVERY_START).
>            o CmdSN counters get reset.  Initiator has to perform the
>              currently defined session recovery actions.
>            o All active tasks of the session are internally
> terminated.
>
>
> Essentially, I was proposing extending the same notion of "implicit
> logout" of a connection to the session level.  The options that I
> see are -
>
>        A) Should iSCSI let it happen by default as stated above (ie.
>           same ISID, TSID=0 always wipes out the pre-existing session
>           on target, since we are mandating it to be used only when
>           initiator sees a session failure)?
>        B) Should iSCSI mandate making this intended cleanup explicit
>           by setting a bit (Say C-bit, for Clear) in the Login Command
>           PDU to prevent an accidental session cleanup with a buggy
>           initiator code?
>        C) Should iSCSI merely state that targets must ascertain
>           the connection state(s) whenever a new session creation
>           attempt is made with a known ISID and TSID=0?  (sort of
>           defeats the intention of the initiator wanting quicker
>           session recovery since the Login command PDU would have
>           to idle till target ascertains the connection state(s)).
>
> I prefer A, or B.
>
> Going with A or B means that the description of transition N3
> in the session state diagram would have to change to:
>      Last LOGGED_IN connection had ceased to be LOGGED_IN,
>         or a Login Command requesting clearing the session (also
>         with C-bit set, if option B) was received by the target.
>
> The transition N7's description would have to be augmented as
> well to:
>         Session recovery attempt with an implicit logout,
>         or connection reinstatement/new CID addition.
>
> Comments?
> --
> Mallikarjun
>
>
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> MS 5668   Hewlett-Packard, Roseville.
> cbm@rose.hp.com
>
>
> >Stephen,
> >
> >That can happen as the target may set-up completely new TCP
> connections
> >(the old sockets are still there and look OK).
> >Untill the login is  progessing he assumes that this is just another
> >open-session attempt. Then he checks the old session and the
> session is
> >dead (initiator has closed the connections).
> >
> >The target has to distinguish only between a session that is
> alive (and
> >reject the new one) and one that its dead in which case it
> can clean-up.
> >
> >Julo
> >
> >"Wheat, Stephen R" <stephen.r.wheat@intel.com> on 23-08-2001 22:50:56
> >
> >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> >
> >To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> >cc:
> >Subject:  RE: iSCSI - Change - Login/Text commands with the
> binary stage
> co
> >          de
> >
> >
> >
> >Julian,
> >
> >I don't understand your answer.  For the scenario given, I
> would presume
> >then that the target would reject the new session attempt,
> as it sees the
> >previous session still "alive".  What is there to tell the
> target that
> this
> >is any different from when the Initiator is erroneously using the
> >repetitive
> >session id?
> >
> >Thanks,
> >Stephen
> >
> >-----Original Message-----
> >From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> >Sent: Thursday, August 23, 2001 11:15 AM
> >To: ips@ece.cmu.edu
> >Subject: Re: iSCSI - Change - Login/Text commands with the
> binary stage
> >co de
> >
> >
> >Stephen,
> >
> >1.If the initiator goes away for a while and reboots and there was no
> >activity on the connections
> >the target may see a session alive (I am not sure that it
> has to appear on
> >the state diagram but maybe).
> >
> >2.Again - I am not sure that the curent state diagram
> includes death of
> the
> >initiator
> >
> >Julo
> >
> >"Wheat, Stephen R" <stephen.r.wheat@intel.com>@ece.cmu.edu
> on 23-08-2001
> >19:58:34
> >
> >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> >
> >Sent by:  owner-ips@ece.cmu.edu
> >
> >
> >To:   ips@ece.cmu.edu
> >cc:
> >Subject:  Re: iSCSI - Change - Login/Text commands with the
> binary stage
> co
> >      de
> >
> >
> >
> >Julian,
> >
> >1.3.6 ISID states that the target should check to see if the
> old session
> is
> >still active when a duplicate session is detected.
> >
> >I have two questions, the second only if you answer in the
> affirmative on
> >the first ;^)
> >
> >1. Is there a properly executed sequence of events (i.e., no
> coding error
> >on
> >the target side) where the session is not active, but the
> target hadn't
> >taken notice of it?  It appears this as a protocol-specified
> means to work
> >around a flaw in a target's implementation.  I interpret the
> state diagram
> >transitions as being atomic wrt other commands.  I.e., the
> last logout
> >would
> >result in the various transitions of the connection/session
> prior to the
> >initiator starting the session up again.  And the target would have
> >completed the transitions prior to handling a new session request.
> >
> >2. If you answered (1) in the affirmative, then the word
> "Active" is not
> >consistent with the 6.3 Session State Diagram.  Does this
> mean the target
> >got lost, due to transport failures of any sort, in its
> transition from
> >Q3-to-Q2-to-Q1?  It sounds like the intent is to close the
> old session if
> >the session was in Q2 or Q4, presuming if it were in Q1,  it
> would not
> have
> >been found as a duplicate.
> >
> >Stephen
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
>














From owner-ips@ece.cmu.edu  Mon Aug 27 14:14:30 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26389
	for <ips-archive@odin.ietf.org>; Mon, 27 Aug 2001 14:14:28 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7RGMNX08153
	for ips-outgoing; Mon, 27 Aug 2001 12:22:23 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7RGMLP08147
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 12:22:21 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA11658
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 12:20:09 -0400
Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7RGMFc79794
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 10:22:15 -0600
Importance: Normal
Subject: RE: iSCSI: reusing ISID for recovery
To: ips@ece.cmu.edu
From: "Jim Hafner" <hafner@almaden.ibm.com>
Date: Mon, 27 Aug 2001 09:22:12 -0700
Message-ID: <OFF1073691.92E6F52B-ON88256AB5.0059ECD3@boulder.ibm.com>
X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at
 08/27/2001 09:22:14 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Julo,

Here's the way I look at it.  I think this is an "error detection/recovery"
issue.

With a rule that the ISID doesn't get reused by an initiator to a given
target portal group,  it's the obligation of the initiator not to do it.
If  the initiator does it anyway, then it is acting in protocol error and
it is the job of the target to enforce that rule.   If the initiator still
does it anyway, it's probably because it has "lost its way", then it is in
error state (but how does it know this?).  I prefer option B. The target
enforces the protocol rule only.  An unexpected reject is the "error
detection" mechanism for the intiator.  The "forced" login is part of the
error recovery, as driven by the initiator which is doing the error
recovery.

I see option A as a simpler mechanim that makes the "explicit" error
recovery request by the initiator an "implicit" request with no direct
detection mechanism on the initiator side.   I'd go with this choice if it
is decided that the only time we'd expect an initiator to make this request
is after a reboot or other massive reset, where it wouldn't have clue about
it's previous state.  If there are cases where we think it won't "do the
right thing" when it could, then I would say that option B as a safer
mechanism.

In short, it gets the target out of doing error recovery on behalf of the
initiator without explicit (option B) or implicit (Option A) direction.
It's not in the business of "guessing" if the initiator needs recovery.

Jim Hafner


Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 08/27/2001 07:50:09 am

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery




Jim,

It would be interesting to hear your arguments. The functions is clearly
there - only that an initiator has to perform two steps
Why is it important (except for boot) that a living initiator do it in one
step.

Regards,
Julo

Jim Hafner/Almaden/IBM@IBMUS@ece.cmu.edu on 27-08-2001 17:16:33

Please respond to Jim Hafner/Almaden/IBM@IBMUS

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery




Julo,
You wrote:
  And I would like to remind you all that we where on this exact thread
more
  tan 3 months ago (other players).
  I just restated the rationale for an (apparent) newcomer.

On the other hand, I don't recall this issue ever being called for
concensus.  Opinions were posted and nothing followed up.

I happen to agree with Marjorie.

Jim Hafner


Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 08/25/2001 12:22:33 AM

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery




It may be another OS running on the same machine or CPU complex or it could
be an attack.
In any case if the initiator is up and fine he can as well do logout.
It is a rare enough event for us not to try to optimize.

The reboot is the only case in which the initiator can't logout and about
which we care.

And I would like to remind you all that we where on this exact thread more
tan 3 months ago (other players).
I just restated the rationale for an (apparent) newcomer.

Julo

"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>@ece.cmu.edu
on 25-08-2001 03:51:43

Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"
      <marjorie_krueger@hp.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery



I don't see how Option A is prone to "wild closing of sessions".  The
target
is only looking for sessions with this particular initiator and closing
them
if the ISID matches.

If an initiator doesn't have a valid TSID (login w/TSID=0), it means it has
lost state entirely (reboot) or knows it wants to immediately reset a
session (NIC failure).  How could there possibly be a case where the
initiator has an active valid session with the same ISID, but just doesn't
know about it??  Rejecting the login seems pointless, since obviously the
initiator either has a bug or intends to quickly reset the session.

The behavior chosen (Option C) will cause the initiator's recovery to be
delayed while the target NOPs all the connections and waits for them to
time
out - this will only delay the initiators recovery unnecessarily.  I can't
help but think this will cause long term problems for the protocol.

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: marjorie_krueger@hp.com

> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Thursday, August 23, 2001 9:39 PM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI: reusing ISID for recovery (Was: RE: iSCSI
> - Change -
> Login/Text...)
>
>
>
> Mallikarjun,
>
> On  your point 1 that is what is stated today in the draft.
>
> On your point 2 option C is the one we took in the draft, after some
> debate.
>
> Option A is prone to "wild closing of sessions" and option B is also
> relaying to much on the good behaviour of the
> client. It also introduces a "feature" that complicates login/logout.
>
> Our postion on this is  that the initiator should logout the session
> explicitly if it can (and in this case it can as the target
> has ascertained
> that the session is alive).
>
> I agree that you may want to update the stayte diagram to
> reflect this.
>
> Julo
>
>
> "Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on 24-08-2001 01:46:40
>
> Please respond to cbm@rose.hp.com
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   ips@ece.cmu.edu
> cc:
> Subject:  iSCSI: reusing ISID for recovery (Was: RE: iSCSI - Change -
>       Login/Text...)
>
>
>
> Julian and all:
>
> This thread mirrors another discussion some of us are
> having in a different forum.  Following (two bullets 1
> & 2 below) is what I proposed there, attempting to address
> two issues -
>      a) how to recover sessions when target and the initiator
>            have conflicting views of the same TCP connection(s)?
>            (Initiator NIC fails, but there's no I/O activity,
>            and the target doesn't see any connection failure.)
>      b) More specifically, how to address the above problem
>            when the initiator *does not want* to re-instate failed
>            connections since it only implements the mandatory
>            session recovery?
>
> This could add clarity or muddle things up here, though hopefully
> the former...
>
> 1 If login is sent with the same ISID, same TSID, same CID and X-bit,
>   then it means a failed connection is being re-instated (whether
>   or not there are multiple connections in the session).  This login
>   attempt must be done before the connection timeout (transition M1),
>   or if this is the only connection in the session, also before the
>   session timeout (transition N6) - to be counted as a connection
>   reinstatement effort.
>            o CmdSN counters (CmdSN, ExpCmdSN) are continued.
> Initiator
>              must do command plugging when there's a mismatch
>              between its CmdSN and ExpCmdSN in the login response.
>            o Since this is an implicit connection logout, all
> the active
>              tasks on the connection are either internally terminated,
>              or made non-allegiant (based on ErrorRecoveryLevel=x/y,
>              TBD) for recovery.
>
> 2 If login is sent with the same ISID and TSID=0, the session (if it
>   exists on the target) is being cleared and any active connections
>   that the target sees must be immediately (at the end of the login
>   process including any initiator authentication) transport reset.
>   Initiator may attempt this only after it ascertains a
> session failure
>   on its end (ie. all connections entered RECOVERY_START).
>            o CmdSN counters get reset.  Initiator has to perform the
>              currently defined session recovery actions.
>            o All active tasks of the session are internally
> terminated.
>
>
> Essentially, I was proposing extending the same notion of "implicit
> logout" of a connection to the session level.  The options that I
> see are -
>
>        A) Should iSCSI let it happen by default as stated above (ie.
>           same ISID, TSID=0 always wipes out the pre-existing session
>           on target, since we are mandating it to be used only when
>           initiator sees a session failure)?
>        B) Should iSCSI mandate making this intended cleanup explicit
>           by setting a bit (Say C-bit, for Clear) in the Login Command
>           PDU to prevent an accidental session cleanup with a buggy
>           initiator code?
>        C) Should iSCSI merely state that targets must ascertain
>           the connection state(s) whenever a new session creation
>           attempt is made with a known ISID and TSID=0?  (sort of
>           defeats the intention of the initiator wanting quicker
>           session recovery since the Login command PDU would have
>           to idle till target ascertains the connection state(s)).
>
> I prefer A, or B.
>
> Going with A or B means that the description of transition N3
> in the session state diagram would have to change to:
>      Last LOGGED_IN connection had ceased to be LOGGED_IN,
>         or a Login Command requesting clearing the session (also
>         with C-bit set, if option B) was received by the target.
>
> The transition N7's description would have to be augmented as
> well to:
>         Session recovery attempt with an implicit logout,
>         or connection reinstatement/new CID addition.
>
> Comments?
> --
> Mallikarjun
>
>
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> MS 5668   Hewlett-Packard, Roseville.
> cbm@rose.hp.com
>
>
> >Stephen,
> >
> >That can happen as the target may set-up completely new TCP
> connections
> >(the old sockets are still there and look OK).
> >Untill the login is  progessing he assumes that this is just another
> >open-session attempt. Then he checks the old session and the
> session is
> >dead (initiator has closed the connections).
> >
> >The target has to distinguish only between a session that is
> alive (and
> >reject the new one) and one that its dead in which case it
> can clean-up.
> >
> >Julo
> >
> >"Wheat, Stephen R" <stephen.r.wheat@intel.com> on 23-08-2001 22:50:56
> >
> >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> >
> >To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> >cc:
> >Subject:  RE: iSCSI - Change - Login/Text commands with the
> binary stage
> co
> >          de
> >
> >
> >
> >Julian,
> >
> >I don't understand your answer.  For the scenario given, I
> would presume
> >then that the target would reject the new session attempt,
> as it sees the
> >previous session still "alive".  What is there to tell the
> target that
> this
> >is any different from when the Initiator is erroneously using the
> >repetitive
> >session id?
> >
> >Thanks,
> >Stephen
> >
> >-----Original Message-----
> >From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> >Sent: Thursday, August 23, 2001 11:15 AM
> >To: ips@ece.cmu.edu
> >Subject: Re: iSCSI - Change - Login/Text commands with the
> binary stage
> >co de
> >
> >
> >Stephen,
> >
> >1.If the initiator goes away for a while and reboots and there was no
> >activity on the connections
> >the target may see a session alive (I am not sure that it
> has to appear on
> >the state diagram but maybe).
> >
> >2.Again - I am not sure that the curent state diagram
> includes death of
> the
> >initiator
> >
> >Julo
> >
> >"Wheat, Stephen R" <stephen.r.wheat@intel.com>@ece.cmu.edu
> on 23-08-2001
> >19:58:34
> >
> >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> >
> >Sent by:  owner-ips@ece.cmu.edu
> >
> >
> >To:   ips@ece.cmu.edu
> >cc:
> >Subject:  Re: iSCSI - Change - Login/Text commands with the
> binary stage
> co
> >      de
> >
> >
> >
> >Julian,
> >
> >1.3.6 ISID states that the target should check to see if the
> old session
> is
> >still active when a duplicate session is detected.
> >
> >I have two questions, the second only if you answer in the
> affirmative on
> >the first ;^)
> >
> >1. Is there a properly executed sequence of events (i.e., no
> coding error
> >on
> >the target side) where the session is not active, but the
> target hadn't
> >taken notice of it?  It appears this as a protocol-specified
> means to work
> >around a flaw in a target's implementation.  I interpret the
> state diagram
> >transitions as being atomic wrt other commands.  I.e., the
> last logout
> >would
> >result in the various transitions of the connection/session
> prior to the
> >initiator starting the session up again.  And the target would have
> >completed the transitions prior to handling a new session request.
> >
> >2. If you answered (1) in the affirmative, then the word
> "Active" is not
> >consistent with the 6.3 Session State Diagram.  Does this
> mean the target
> >got lost, due to transport failures of any sort, in its
> transition from
> >Q3-to-Q2-to-Q1?  It sounds like the intent is to close the
> old session if
> >the session was in Q2 or Q4, presuming if it were in Q1,  it
> would not
> have
> >been found as a duplicate.
> >
> >Stephen
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
>














From owner-ips@ece.cmu.edu  Mon Aug 27 14:16:05 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26448
	for <ips-archive@odin.ietf.org>; Mon, 27 Aug 2001 14:16:04 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7RGa9U09025
	for ips-outgoing; Mon, 27 Aug 2001 12:36:09 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mms2.broadcom.com (mms2.broadcom.com [63.70.210.59])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f7RGa1P09018
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 12:36:03 -0400 (EDT)
Received: from 63.70.210.1 by mms2.broadcom.com with ESMTP (Broadcom
 MMS-2 SMTP Relay (MMS v4.7)); Mon, 27 Aug 2001 09:35:33 -0700
X-Server-Uuid: 2a12fa22-b688-11d4-a6a1-00508bfc9626
Received: from mail-sj1-1.sj.broadcom.com (mail-sj1-1.sj.broadcom.com
 [10.16.128.231]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP
 id JAA19057; Mon, 27 Aug 2001 09:35:56 -0700 (PDT)
Received: from ltjtardo (dhcpe2-sj1-173 [10.16.75.173]) by
 mail-sj1-1.sj.broadcom.com (8.8.8/8.8.8/MS01) with SMTP id JAA14636;
 Mon, 27 Aug 2001 09:35:56 -0700 (PDT)
From: "Joseph Tardo" <jtardo@broadcom.com>
To: "Mark Winstead" <Mark.Winstead@NetOctave.com>, Black_David@emc.com,
        sandeepj@research.bell-labs.com, ips@ece.cmu.edu
Subject: RE: FW: I-D ACTION:draft-aboba-ips-iscsi-security-00.txt
Date: Mon, 27 Aug 2001 09:35:53 -0700
Message-ID: <NDBBJJDNOJJEFGHAECHIAELGDDAA.jtardo@broadcom.com>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Importance: Normal
In-Reply-To: <49B96FCC784BC54F9675A6B558C3464E5D0C08@MAIL.NetOctave.com>
X-WSS-ID: 1794A95F215948-01-01
Content-Type: text/plain; 
 charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Some additional issues raised at that workshop:

1. Typical security protocols, in particular the IPsec transforms, require
authentication to extend beyond the ciphertext to some additional cleartext
(e.g., the SPI and replay counter for ESP). Such use needs to be carefully
designed, and there are no current standardized proposals with proven
security.

2. To support ESP NULL, any such mode needs to be defined so as to support
authentication without confidentiality.

--Joe

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Mark Winstead
Sent: Monday, August 27, 2001 6:06 AM
To: 'Black_David@emc.com'; sandeepj@research.bell-labs.com;
ips@ece.cmu.edu
Subject: RE: FW: I-D ACTION:draft-aboba-ips-iscsi-security-00.txt


Last Friday, NIST held a modes of operation workshop (for the protection and
privacy of sensitive but unclassified data, NIST authorizes suitable
algorithms and techniques for use by federal government departments and
agencies).

OCB is one of three modes considered that achieve both privacy and
authentication, as well as the potential to scale well for speed. All three
either have patents or have been submitted for patents. IMHO w/o coding
them, only two of the three, OCB and Integrity Aware Parallelizable Mode
(IAPM) will scale well to support 10 Gbs and more. IAPM's patent is held by
IBM, OCB by Phil Rogaway.

The patent issue came up during the discussion time -- no one present knew
of a provably secure mode with the properties of OCB that was unpatented.
One could find an unpatented mode for privacy, say counter mode, and then
add a MAC that provides authentication, but that is an extra step (plus I
think you might run into the patent problem again in finding a MAC that will
permit 10 Gbs speed).

Mark Winstead

-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Tuesday, August 21, 2001 8:17 PM
To: sandeepj@research.bell-labs.com; ips@ece.cmu.edu
Subject: RE: FW: I-D ACTION:draft-aboba-ips-iscsi-security-00.txt


Sandeep,

There is a patent on it, and a license is required to ship product.
The license should be available under fair, reasonable, and non-
discriminatory terms, but will not be free.  A reasonable guess
would be that iSCSI licensing terms would be similar to the 802.11
terms, and that a suitable IETF intellectual property rights notice
will be forthcoming.

OTOH, this does seem to run counter to the usual IETF preference
for unpatented technology over patented technology provided that
the unpatented technology is a functionally suitable replacement
for the patented technology.  Whether there are functionally suitable
unpatented replacements for OCB is an issue for further discussion,
ditto the requirements and preferences that lead to the recommendation
of OCB.  A draft on OCB would need to go through the ipsec WG if we
were to use OCB, and my impression is that at least some portion of
that community has a very strong preference for unpatented technology.

I hope this is what you were looking for in the way of comments.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


> -----Original Message-----
> From: sandeepj@research.bell-labs.com
> [mailto:sandeepj@research.bell-labs.com]
> Sent: Tuesday, August 21, 2001 7:49 PM
> To: ips@ece.cmu.edu
> Subject: Re: FW: I-D ACTION:draft-aboba-ips-iscsi-security-00.txt
>
>
> David,
>
> Could you comment on the intellectual rights issues
> here, particularly on AES-OCB, which will be mandatory
> according to this draft (Sec 2.1)
>
> http://www.cs.ucdavis.edu/~rogaway/ocb/ocb-back.htm
> mentions the licensing terms for 802.11 products.
>
> Secondly, appendix tables A.5 and A.6 seem to indicate
> that AES-CTR+UMAC performance is better than AES-OCB.
> Has AES-OCB been chosen since it requires lesser keying
> material and memory ?
>
> thanks
> -Sandeep
>
> > FYI - this is about use of IKE and IPsec algorithm selection
> > considerations.  --David
> >
> > -----Original Message-----
> > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> > Sent: Tuesday, August 21, 2001 7:25 AM
> > Subject: I-D ACTION:draft-aboba-ips-iscsi-security-00.txt
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> >
> > Title           : Securing iSCSI using IPsec
> > Author(s)       : B. Aboba et al.
> > Filename        : draft-aboba-ips-iscsi-security-00.txt
> > Pages           : 35
> > Date            : 20-Aug-01
> >
> > This document discusses how iSCSI may utilize IPsec to provide
> > authentication, integrity, confidentiality and replay protection.
> >
> > A URL for this Internet-Draft is:
> >
http://www.ietf.org/internet-drafts/draft-aboba-ips-iscsi-security-00.txt
>
> Internet-Drafts are also available by anonymous FTP. Login with the
username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-aboba-ips-iscsi-security-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> mailserv@ietf.org.
> In the body type:
> "FILE /internet-drafts/draft-aboba-ips-iscsi-security-00.txt".
>
> NOTE:   The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility.  To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader.  Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
> ---------------------------------------------------------
> + Date: Tue, 21 Aug 2001 09:29:53 -0400
> + Content-Type:
> multipart/mixed;boundary="----_=_NextPart_002_01C12A44.418236C0"
>
> ATT36560
>
> <ftp://internet-drafts/>
> Transfer-mode: ftp.ietf.org
> ---------------------------------------------------------
>





From owner-ips@ece.cmu.edu  Mon Aug 27 15:09:06 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26390
	for <ips-archive@odin.ietf.org>; Mon, 27 Aug 2001 14:14:30 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7RH5ve10958
	for ips-outgoing; Mon, 27 Aug 2001 13:05:57 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7RH5tP10953
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 13:05:55 -0400 (EDT)
Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100])
	by palrel2.hp.com (Postfix) with ESMTP id 8D6FC88B
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 10:05:50 -0700 (PDT)
Received: (from cbm@localhost) by core.rose.hp.com (8.8.6 (PHNE_14041)/8.8.6 SMKit7.02) id KAA10640 for ips@ece.cmu.edu; Mon, 27 Aug 2001 10:07:08 -0700 (PDT)
Message-Id: <200108271707.KAA10640@core.rose.hp.com>
Subject: RE: iSCSI: reusing ISID for recovery
To: ips@ece.cmu.edu
Date: Mon, 27 Aug 2001 10:07:08 PDT
Reply-To: cbm@rose.hp.com
From: "Mallikarjun C." <cbm@rose.hp.com>
X-Mailer: Elm [revision: 212.4]
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Julian,

>It may be another OS running on the same machine or CPU complex

I know that the rules for iSCSI-Names aren't final yet, but I
would think that the second O/S copy in the case you mention will
have a different iSCSI-Name.

>or it could
>be an attack.

That's the reason in my description I had the following phrase
"at the end of the login process including any initiator authentication".
I assume that's adequate guarantee.

>In any case if the initiator is up and fine he can as well do logout.

I am not sure I understand this - are you suggesting a connection
reinstatement (within-session recovery), or second connection addition?
If I hadn't made it clear, I was searching for a decent solution for
single-connection, session-recovery-only case.  This implicit session
logout is the only one I came up with.  Please comment if I missed 
something (keep in mind that old TSID could very well be lost if
it's a NIC failure and the session manager is hosted by the NIC itself).

For these reasons, Option A is my preferred.  I also suggested that 
"Initiator may attempt this only after it ascertains a session failure
on its end." - so this is only to take care of the asymmetric session 
views on either end.

As I stated, I can live with option B which I suspect is the case of
protocol making allowances for incorrect implementations.

Option C, IMHO, would be needlessly slowing down recovery (and could
have an impact on boot times, depending on initiator boot probe
algorithm).

Regards.
--
Mallikarjun 


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


>It may be another OS running on the same machine or CPU complex or it could
>be an attack.
>In any case if the initiator is up and fine he can as well do logout.
>It is a rare enough event for us not to try to optimize.
>
>The reboot is the only case in which the initiator can't logout and about
>which we care.
>
>And I would like to remind you all that we where on this exact thread more
>tan 3 months ago (other players).
>I just restated the rationale for an (apparent) newcomer.
>
>Julo
>
>"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>@ece.cmu.edu
>on 25-08-2001 03:51:43
>
>Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"
>      <marjorie_krueger@hp.com>
>
>Sent by:  owner-ips@ece.cmu.edu
>
>
>To:   ips@ece.cmu.edu
>cc:
>Subject:  RE: iSCSI: reusing ISID for recovery
>
>
>
>I don't see how Option A is prone to "wild closing of sessions".  The
>target
>is only looking for sessions with this particular initiator and closing
>them
>if the ISID matches.
>
>If an initiator doesn't have a valid TSID (login w/TSID=0), it means it has
>lost state entirely (reboot) or knows it wants to immediately reset a
>session (NIC failure).  How could there possibly be a case where the
>initiator has an active valid session with the same ISID, but just doesn't
>know about it??  Rejecting the login seems pointless, since obviously the
>initiator either has a bug or intends to quickly reset the session.
>
>The behavior chosen (Option C) will cause the initiator's recovery to be
>delayed while the target NOPs all the connections and waits for them to
>time
>out - this will only delay the initiators recovery unnecessarily.  I can't
>help but think this will cause long term problems for the protocol.
>
>Marjorie Krueger
>Networked Storage Architecture
>Networked Storage Solutions Org.
>Hewlett-Packard
>tel: +1 916 785 2656
>fax: +1 916 785 0391
>email: marjorie_krueger@hp.com
>
>> -----Original Message-----
>> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
>> Sent: Thursday, August 23, 2001 9:39 PM
>> To: ips@ece.cmu.edu
>> Subject: Re: iSCSI: reusing ISID for recovery (Was: RE: iSCSI
>> - Change -
>> Login/Text...)
>>
>>
>>
>> Mallikarjun,
>>
>> On  your point 1 that is what is stated today in the draft.
>>
>> On your point 2 option C is the one we took in the draft, after some
>> debate.
>>
>> Option A is prone to "wild closing of sessions" and option B is also
>> relaying to much on the good behaviour of the
>> client. It also introduces a "feature" that complicates login/logout.
>>
>> Our postion on this is  that the initiator should logout the session
>> explicitly if it can (and in this case it can as the target
>> has ascertained
>> that the session is alive).
>>
>> I agree that you may want to update the stayte diagram to
>> reflect this.
>>
>> Julo
>>
>>
>> "Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on 24-08-2001 01:46:40
>>
>> Please respond to cbm@rose.hp.com
>>
>> Sent by:  owner-ips@ece.cmu.edu
>>
>>
>> To:   ips@ece.cmu.edu
>> cc:
>> Subject:  iSCSI: reusing ISID for recovery (Was: RE: iSCSI - Change -
>>       Login/Text...)
>>
>>
>>
>> Julian and all:
>>
>> This thread mirrors another discussion some of us are
>> having in a different forum.  Following (two bullets 1
>> & 2 below) is what I proposed there, attempting to address
>> two issues -
>>      a) how to recover sessions when target and the initiator
>>            have conflicting views of the same TCP connection(s)?
>>            (Initiator NIC fails, but there's no I/O activity,
>>            and the target doesn't see any connection failure.)
>>      b) More specifically, how to address the above problem
>>            when the initiator *does not want* to re-instate failed
>>            connections since it only implements the mandatory
>>            session recovery?
>>
>> This could add clarity or muddle things up here, though hopefully
>> the former...
>>
>> 1 If login is sent with the same ISID, same TSID, same CID and X-bit,
>>   then it means a failed connection is being re-instated (whether
>>   or not there are multiple connections in the session).  This login
>>   attempt must be done before the connection timeout (transition M1),
>>   or if this is the only connection in the session, also before the
>>   session timeout (transition N6) - to be counted as a connection
>>   reinstatement effort.
>>            o CmdSN counters (CmdSN, ExpCmdSN) are continued.
>> Initiator
>>              must do command plugging when there's a mismatch
>>              between its CmdSN and ExpCmdSN in the login response.
>>            o Since this is an implicit connection logout, all
>> the active
>>              tasks on the connection are either internally terminated,
>>              or made non-allegiant (based on ErrorRecoveryLevel=x/y,
>>              TBD) for recovery.
>>
>> 2 If login is sent with the same ISID and TSID=0, the session (if it
>>   exists on the target) is being cleared and any active connections
>>   that the target sees must be immediately (at the end of the login
>>   process including any initiator authentication) transport reset.
>>   Initiator may attempt this only after it ascertains a
>> session failure
>>   on its end (ie. all connections entered RECOVERY_START).
>>            o CmdSN counters get reset.  Initiator has to perform the
>>              currently defined session recovery actions.
>>            o All active tasks of the session are internally
>> terminated.
>>
>>
>> Essentially, I was proposing extending the same notion of "implicit
>> logout" of a connection to the session level.  The options that I
>> see are -
>>
>>        A) Should iSCSI let it happen by default as stated above (ie.
>>           same ISID, TSID=0 always wipes out the pre-existing session
>>           on target, since we are mandating it to be used only when
>>           initiator sees a session failure)?
>>        B) Should iSCSI mandate making this intended cleanup explicit
>>           by setting a bit (Say C-bit, for Clear) in the Login Command
>>           PDU to prevent an accidental session cleanup with a buggy
>>           initiator code?
>>        C) Should iSCSI merely state that targets must ascertain
>>           the connection state(s) whenever a new session creation
>>           attempt is made with a known ISID and TSID=0?  (sort of
>>           defeats the intention of the initiator wanting quicker
>>           session recovery since the Login command PDU would have
>>           to idle till target ascertains the connection state(s)).
>>
>> I prefer A, or B.
>>
>> Going with A or B means that the description of transition N3
>> in the session state diagram would have to change to:
>>      Last LOGGED_IN connection had ceased to be LOGGED_IN,
>>         or a Login Command requesting clearing the session (also
>>         with C-bit set, if option B) was received by the target.
>>
>> The transition N7's description would have to be augmented as
>> well to:
>>         Session recovery attempt with an implicit logout,
>>         or connection reinstatement/new CID addition.
>>
>> Comments?
>> --
>> Mallikarjun
>>
>>
>> Mallikarjun Chadalapaka
>> Networked Storage Architecture
>> Network Storage Solutions Organization
>> MS 5668   Hewlett-Packard, Roseville.
>> cbm@rose.hp.com
>>
>>
>> >Stephen,
>> >
>> >That can happen as the target may set-up completely new TCP
>> connections
>> >(the old sockets are still there and look OK).
>> >Untill the login is  progessing he assumes that this is just another
>> >open-session attempt. Then he checks the old session and the
>> session is
>> >dead (initiator has closed the connections).
>> >
>> >The target has to distinguish only between a session that is
>> alive (and
>> >reject the new one) and one that its dead in which case it
>> can clean-up.
>> >
>> >Julo
>> >
>> >"Wheat, Stephen R" <stephen.r.wheat@intel.com> on 23-08-2001 22:50:56
>> >
>> >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
>> >
>> >To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
>> >cc:
>> >Subject:  RE: iSCSI - Change - Login/Text commands with the
>> binary stage
>> co
>> >          de
>> >
>> >
>> >
>> >Julian,
>> >
>> >I don't understand your answer.  For the scenario given, I
>> would presume
>> >then that the target would reject the new session attempt,
>> as it sees the
>> >previous session still "alive".  What is there to tell the
>> target that
>> this
>> >is any different from when the Initiator is erroneously using the
>> >repetitive
>> >session id?
>> >
>> >Thanks,
>> >Stephen
>> >
>> >-----Original Message-----
>> >From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
>> >Sent: Thursday, August 23, 2001 11:15 AM
>> >To: ips@ece.cmu.edu
>> >Subject: Re: iSCSI - Change - Login/Text commands with the
>> binary stage
>> >co de
>> >
>> >
>> >Stephen,
>> >
>> >1.If the initiator goes away for a while and reboots and there was no
>> >activity on the connections
>> >the target may see a session alive (I am not sure that it
>> has to appear on
>> >the state diagram but maybe).
>> >
>> >2.Again - I am not sure that the curent state diagram
>> includes death of
>> the
>> >initiator
>> >
>> >Julo
>> >
>> >"Wheat, Stephen R" <stephen.r.wheat@intel.com>@ece.cmu.edu
>> on 23-08-2001
>> >19:58:34
>> >
>> >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
>> >
>> >Sent by:  owner-ips@ece.cmu.edu
>> >
>> >
>> >To:   ips@ece.cmu.edu
>> >cc:
>> >Subject:  Re: iSCSI - Change - Login/Text commands with the
>> binary stage
>> co
>> >      de
>> >
>> >
>> >
>> >Julian,
>> >
>> >1.3.6 ISID states that the target should check to see if the
>> old session
>> is
>> >still active when a duplicate session is detected.
>> >
>> >I have two questions, the second only if you answer in the
>> affirmative on
>> >the first ;^)
>> >
>> >1. Is there a properly executed sequence of events (i.e., no
>> coding error
>> >on
>> >the target side) where the session is not active, but the
>> target hadn't
>> >taken notice of it?  It appears this as a protocol-specified
>> means to work
>> >around a flaw in a target's implementation.  I interpret the
>> state diagram
>> >transitions as being atomic wrt other commands.  I.e., the
>> last logout
>> >would
>> >result in the various transitions of the connection/session
>> prior to the
>> >initiator starting the session up again.  And the target would have
>> >completed the transitions prior to handling a new session request.
>> >
>> >2. If you answered (1) in the affirmative, then the word
>> "Active" is not
>> >consistent with the 6.3 Session State Diagram.  Does this
>> mean the target
>> >got lost, due to transport failures of any sort, in its
>> transition from
>> >Q3-to-Q2-to-Q1?  It sounds like the intent is to close the
>> old session if
>> >the session was in Q2 or Q4, presuming if it were in Q1,  it
>> would not
>> have
>> >been found as a duplicate.
>> >
>> >Stephen
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>>
>>
>>
>>
>>
>
>
>
>




From owner-ips@ece.cmu.edu  Mon Aug 27 16:02:53 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28666
	for <ips-archive@odin.ietf.org>; Mon, 27 Aug 2001 16:02:52 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7RHOG012106
	for ips-outgoing; Mon, 27 Aug 2001 13:24:16 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7RHO2P12092
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 13:24:02 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA54046
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 13:21:40 -0400
Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7RHNpc186116
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 11:23:51 -0600
Importance: Normal
Subject: RE: iSCSI: reusing ISID for recovery
To: ips@ece.cmu.edu
From: "Jim Hafner" <hafner@almaden.ibm.com>
Date: Mon, 27 Aug 2001 10:23:47 -0700
Message-ID: <OF61D5E0D9.FB40B8B5-ON88256AB5.005D54F7@boulder.ibm.com>
X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at
 08/27/2001 10:23:50 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Julo,

 Comments in line of your last response.

Jim Hafner


Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 08/27/2001 09:50:00 am

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery



Jim,

Option A is clearly unacceptable as an initiator may do harm.
<JLH>
How can it do harm? It should only do this when it's "lost it's way" and so
doesn't have any state to harm.  If it can't tell that it has a session
with that ISID live, then having that session killed at the target end
isn't going to cause any problems.   If it can tell and still blows the
protocol, then all bets are off anyway.  [As an aside, I believe this is
the behavior of FC, though admittedly, it's at a lower and less
sophisticated layer then we are talking about.]  There's a further summary
of these issues below.
</JLH>

Recovery is not done by the target neither in B nor in C.
<JLH>
Certainly, recovery is done by the target! Perhaps your definition of
"recovery" is different than mine.  I include "cleanup" in "recovery".
It's not trying to get back the previous state, so much as get out from
under the bad state it's in.  So, in both cases, it's supposed to cleanup
dead session/connections.  In C, it's not even clear to the initiator that
this is going to happen!  In B, it knows it's explicitly asking for this
cleanup (with the bit set).
</JLH>

In B an initiator has to add a bit (he may be tempted to put it in as "my
code is safe" while in C
it requires the initiator to logout first before he can reinitiate the
session.

B is an optimization over C - and quite dangerous.
<JLH>
If B uses the bit indiscriminantly, then it's its own fault and tough
cookies.  So, I don't see how this is "quite dangerous".

I personally think that C is more dangerous, because the behavior is less
predictable to the initiator.  How can the initiator judge what the target
thinks of the state of the connections/sessions?  Maybe the target sees the
connections as dead, even though the initiator doesn't (yet?).
</JLH>

<JLH>
Ask the question why the initiator is taking this action and what state is
he in.  I see three cases:

1) If the initiator knows he has (or thinks he has) a session that he wants
to restart, then he can logout and login and this ISID rule enforcement is
*never* triggered. This is true whether he sees the session as live or
dead.

2) If the initiator knows he has a session and still proposes to break the
rule, then tough.  Either he has to work harder (option B) or he gets what
he gets (option A) in predictable fashion.  He knows what state he's in and
he knows the consequences of his actions.

3) The only time he should break his side of the protocol (reuse the ISID)
is if he has lost knowledge of the previous session.  In that case,
everyone might as well kill that session since context is lost on the
initiator side anyway.  That means that option A is just fine. Option B
carries the extra benefit of assisting him in error detection (that he's
lost his way).   He may not know enough a priori to know he's lost his way
(which is why I have a weak preference for B, though all of this discussion
is leaning me more towards A).
</JLH>


Julo


Jim Hafner/Almaden/IBM@IBMUS@ece.cmu.edu on 27-08-2001 19:22:12

Please respond to Jim Hafner/Almaden/IBM@IBMUS

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery




Julo,

Here's the way I look at it.  I think this is an "error detection/recovery"
issue.

With a rule that the ISID doesn't get reused by an initiator to a given
target portal group,  it's the obligation of the initiator not to do it.
If  the initiator does it anyway, then it is acting in protocol error and
it is the job of the target to enforce that rule.   If the initiator still
does it anyway, it's probably because it has "lost its way", then it is in
error state (but how does it know this?).  I prefer option B. The target
enforces the protocol rule only.  An unexpected reject is the "error
detection" mechanism for the intiator.  The "forced" login is part of the
error recovery, as driven by the initiator which is doing the error
recovery.

I see option A as a simpler mechanim that makes the "explicit" error
recovery request by the initiator an "implicit" request with no direct
detection mechanism on the initiator side.   I'd go with this choice if it
is decided that the only time we'd expect an initiator to make this request
is after a reboot or other massive reset, where it wouldn't have clue about
it's previous state.  If there are cases where we think it won't "do the
right thing" when it could, then I would say that option B as a safer
mechanism.

In short, it gets the target out of doing error recovery on behalf of the
initiator without explicit (option B) or implicit (Option A) direction.
It's not in the business of "guessing" if the initiator needs recovery.

Jim Hafner


Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 08/27/2001 07:50:09 am

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery




Jim,

It would be interesting to hear your arguments. The functions is clearly
there - only that an initiator has to perform two steps
Why is it important (except for boot) that a living initiator do it in one
step.

Regards,
Julo

Jim Hafner/Almaden/IBM@IBMUS@ece.cmu.edu on 27-08-2001 17:16:33

Please respond to Jim Hafner/Almaden/IBM@IBMUS

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery




Julo,
You wrote:
  And I would like to remind you all that we where on this exact thread
more
  tan 3 months ago (other players).
  I just restated the rationale for an (apparent) newcomer.

On the other hand, I don't recall this issue ever being called for
concensus.  Opinions were posted and nothing followed up.

I happen to agree with Marjorie.

Jim Hafner


Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 08/25/2001 12:22:33 AM

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery




It may be another OS running on the same machine or CPU complex or it could
be an attack.
In any case if the initiator is up and fine he can as well do logout.
It is a rare enough event for us not to try to optimize.

The reboot is the only case in which the initiator can't logout and about
which we care.

And I would like to remind you all that we where on this exact thread more
tan 3 months ago (other players).
I just restated the rationale for an (apparent) newcomer.

Julo

"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>@ece.cmu.edu
on 25-08-2001 03:51:43

Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"
      <marjorie_krueger@hp.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery



I don't see how Option A is prone to "wild closing of sessions".  The
target
is only looking for sessions with this particular initiator and closing
them
if the ISID matches.

If an initiator doesn't have a valid TSID (login w/TSID=0), it means it has
lost state entirely (reboot) or knows it wants to immediately reset a
session (NIC failure).  How could there possibly be a case where the
initiator has an active valid session with the same ISID, but just doesn't
know about it??  Rejecting the login seems pointless, since obviously the
initiator either has a bug or intends to quickly reset the session.

The behavior chosen (Option C) will cause the initiator's recovery to be
delayed while the target NOPs all the connections and waits for them to
time
out - this will only delay the initiators recovery unnecessarily.  I can't
help but think this will cause long term problems for the protocol.

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: marjorie_krueger@hp.com

> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Thursday, August 23, 2001 9:39 PM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI: reusing ISID for recovery (Was: RE: iSCSI
> - Change -
> Login/Text...)
>
>
>
> Mallikarjun,
>
> On  your point 1 that is what is stated today in the draft.
>
> On your point 2 option C is the one we took in the draft, after some
> debate.
>
> Option A is prone to "wild closing of sessions" and option B is also
> relaying to much on the good behaviour of the
> client. It also introduces a "feature" that complicates login/logout.
>
> Our postion on this is  that the initiator should logout the session
> explicitly if it can (and in this case it can as the target
> has ascertained
> that the session is alive).
>
> I agree that you may want to update the stayte diagram to
> reflect this.
>
> Julo
>
>
> "Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on 24-08-2001 01:46:40
>
> Please respond to cbm@rose.hp.com
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   ips@ece.cmu.edu
> cc:
> Subject:  iSCSI: reusing ISID for recovery (Was: RE: iSCSI - Change -
>       Login/Text...)
>
>
>
> Julian and all:
>
> This thread mirrors another discussion some of us are
> having in a different forum.  Following (two bullets 1
> & 2 below) is what I proposed there, attempting to address
> two issues -
>      a) how to recover sessions when target and the initiator
>            have conflicting views of the same TCP connection(s)?
>            (Initiator NIC fails, but there's no I/O activity,
>            and the target doesn't see any connection failure.)
>      b) More specifically, how to address the above problem
>            when the initiator *does not want* to re-instate failed
>            connections since it only implements the mandatory
>            session recovery?
>
> This could add clarity or muddle things up here, though hopefully
> the former...
>
> 1 If login is sent with the same ISID, same TSID, same CID and X-bit,
>   then it means a failed connection is being re-instated (whether
>   or not there are multiple connections in the session).  This login
>   attempt must be done before the connection timeout (transition M1),
>   or if this is the only connection in the session, also before the
>   session timeout (transition N6) - to be counted as a connection
>   reinstatement effort.
>            o CmdSN counters (CmdSN, ExpCmdSN) are continued.
> Initiator
>              must do command plugging when there's a mismatch
>              between its CmdSN and ExpCmdSN in the login response.
>            o Since this is an implicit connection logout, all
> the active
>              tasks on the connection are either internally terminated,
>              or made non-allegiant (based on ErrorRecoveryLevel=x/y,
>              TBD) for recovery.
>
> 2 If login is sent with the same ISID and TSID=0, the session (if it
>   exists on the target) is being cleared and any active connections
>   that the target sees must be immediately (at the end of the login
>   process including any initiator authentication) transport reset.
>   Initiator may attempt this only after it ascertains a
> session failure
>   on its end (ie. all connections entered RECOVERY_START).
>            o CmdSN counters get reset.  Initiator has to perform the
>              currently defined session recovery actions.
>            o All active tasks of the session are internally
> terminated.
>
>
> Essentially, I was proposing extending the same notion of "implicit
> logout" of a connection to the session level.  The options that I
> see are -
>
>        A) Should iSCSI let it happen by default as stated above (ie.
>           same ISID, TSID=0 always wipes out the pre-existing session
>           on target, since we are mandating it to be used only when
>           initiator sees a session failure)?
>        B) Should iSCSI mandate making this intended cleanup explicit
>           by setting a bit (Say C-bit, for Clear) in the Login Command
>           PDU to prevent an accidental session cleanup with a buggy
>           initiator code?
>        C) Should iSCSI merely state that targets must ascertain
>           the connection state(s) whenever a new session creation
>           attempt is made with a known ISID and TSID=0?  (sort of
>           defeats the intention of the initiator wanting quicker
>           session recovery since the Login command PDU would have
>           to idle till target ascertains the connection state(s)).
>
> I prefer A, or B.
>
> Going with A or B means that the description of transition N3
> in the session state diagram would have to change to:
>      Last LOGGED_IN connection had ceased to be LOGGED_IN,
>         or a Login Command requesting clearing the session (also
>         with C-bit set, if option B) was received by the target.
>
> The transition N7's description would have to be augmented as
> well to:
>         Session recovery attempt with an implicit logout,
>         or connection reinstatement/new CID addition.
>
> Comments?
> --
> Mallikarjun
>
>
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> MS 5668   Hewlett-Packard, Roseville.
> cbm@rose.hp.com
>
>
> >Stephen,
> >
> >That can happen as the target may set-up completely new TCP
> connections
> >(the old sockets are still there and look OK).
> >Untill the login is  progessing he assumes that this is just another
> >open-session attempt. Then he checks the old session and the
> session is
> >dead (initiator has closed the connections).
> >
> >The target has to distinguish only between a session that is
> alive (and
> >reject the new one) and one that its dead in which case it
> can clean-up.
> >
> >Julo
> >
> >"Wheat, Stephen R" <stephen.r.wheat@intel.com> on 23-08-2001 22:50:56
> >
> >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> >
> >To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> >cc:
> >Subject:  RE: iSCSI - Change - Login/Text commands with the
> binary stage
> co
> >          de
> >
> >
> >
> >Julian,
> >
> >I don't understand your answer.  For the scenario given, I
> would presume
> >then that the target would reject the new session attempt,
> as it sees the
> >previous session still "alive".  What is there to tell the
> target that
> this
> >is any different from when the Initiator is erroneously using the
> >repetitive
> >session id?
> >
> >Thanks,
> >Stephen
> >
> >-----Original Message-----
> >From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> >Sent: Thursday, August 23, 2001 11:15 AM
> >To: ips@ece.cmu.edu
> >Subject: Re: iSCSI - Change - Login/Text commands with the
> binary stage
> >co de
> >
> >
> >Stephen,
> >
> >1.If the initiator goes away for a while and reboots and there was no
> >activity on the connections
> >the target may see a session alive (I am not sure that it
> has to appear on
> >the state diagram but maybe).
> >
> >2.Again - I am not sure that the curent state diagram
> includes death of
> the
> >initiator
> >
> >Julo
> >
> >"Wheat, Stephen R" <stephen.r.wheat@intel.com>@ece.cmu.edu
> on 23-08-2001
> >19:58:34
> >
> >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> >
> >Sent by:  owner-ips@ece.cmu.edu
> >
> >
> >To:   ips@ece.cmu.edu
> >cc:
> >Subject:  Re: iSCSI - Change - Login/Text commands with the
> binary stage
> co
> >      de
> >
> >
> >
> >Julian,
> >
> >1.3.6 ISID states that the target should check to see if the
> old session
> is
> >still active when a duplicate session is detected.
> >
> >I have two questions, the second only if you answer in the
> affirmative on
> >the first ;^)
> >
> >1. Is there a properly executed sequence of events (i.e., no
> coding error
> >on
> >the target side) where the session is not active, but the
> target hadn't
> >taken notice of it?  It appears this as a protocol-specified
> means to work
> >around a flaw in a target's implementation.  I interpret the
> state diagram
> >transitions as being atomic wrt other commands.  I.e., the
> last logout
> >would
> >result in the various transitions of the connection/session
> prior to the
> >initiator starting the session up again.  And the target would have
> >completed the transitions prior to handling a new session request.
> >
> >2. If you answered (1) in the affirmative, then the word
> "Active" is not
> >consistent with the 6.3 Session State Diagram.  Does this
> mean the target
> >got lost, due to transport failures of any sort, in its
> transition from
> >Q3-to-Q2-to-Q1?  It sounds like the intent is to close the
> old session if
> >the session was in Q2 or Q4, presuming if it were in Q1,  it
> would not
> have
> >been found as a duplicate.
> >
> >Stephen
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
>




















From owner-ips@ece.cmu.edu  Mon Aug 27 18:03:17 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01997
	for <ips-archive@odin.ietf.org>; Mon, 27 Aug 2001 18:03:17 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7RKf7g25079
	for ips-outgoing; Mon, 27 Aug 2001 16:41:07 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7RKf4P25068
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 16:41:04 -0400 (EDT)
Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190])
	by atlrel2.hp.com (Postfix) with ESMTP id 58D78D5B
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 16:41:03 -0400 (EDT)
Received: from xatlbh3.atl.hp.com (xatlbh3.atl.hp.com [15.45.89.188])
	by xatlrelay1.atl.hp.com (Postfix) with ESMTP id BDCAB1F50C
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 16:41:02 -0400 (EDT)
Received: by xatlbh3.atl.hp.com with Internet Mail Service (5.5.2653.19)
	id <RTRVZ4Q6>; Mon, 27 Aug 2001 16:40:47 -0400
Message-ID: <6BD67FFB937FD411A04F00D0B74FE87802A0927F@xrose06.rose.hp.com>
From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
To: ips@ece.cmu.edu
Subject: RE: iSCSI: reusing ISID for recovery
Date: Mon, 27 Aug 2001 16:39:52 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

If it is another OS, it should be a different iSCSI initiator, and hence
will have a different initiator name, so this case shouldn't be a factor.
It's not the ISID along which identifies the initiator, it's the initiator
name  + ISID.

I believe the case in which this behavior (option C) will become an issue is
in the case of initiator reboot, which will be the norm, not the exception.
IOTW, most of the cases where the target will be faced with an initiator
login w/an "in use" ISID, TSID=0 will be in the case of an initiator reboot.
That is the case we should optimize for.  I could live with Option B, but
Option A seems sufficient.

It seems the primary value of option C is to guard against malfunctioning
initiators.  As has been said many times, we cannot design a protocol to
guard against coding errors. 

Marj

> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Saturday, August 25, 2001 12:23 AM
> To: ips@ece.cmu.edu
> Subject: RE: iSCSI: reusing ISID for recovery
> 
> 
> 
> It may be another OS running on the same machine or CPU 
> complex or it could
> be an attack.
> In any case if the initiator is up and fine he can as well do logout.
> It is a rare enough event for us not to try to optimize.
> 
> The reboot is the only case in which the initiator can't 
> logout and about
> which we care.
> 
> And I would like to remind you all that we where on this 
> exact thread more
> tan 3 months ago (other players).
> I just restated the rationale for an (apparent) newcomer.
> 
> Julo
> 
> "KRUEGER,MARJORIE (HP-Roseville,ex1)" 
> <marjorie_krueger@hp.com>@ece.cmu.edu
> on 25-08-2001 03:51:43
> 
> Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"
>       <marjorie_krueger@hp.com>
> 
> Sent by:  owner-ips@ece.cmu.edu
> 
> 
> To:   ips@ece.cmu.edu
> cc:
> Subject:  RE: iSCSI: reusing ISID for recovery
> 
> 
> 
> I don't see how Option A is prone to "wild closing of sessions".  The
> target
> is only looking for sessions with this particular initiator 
> and closing
> them
> if the ISID matches.
> 
> If an initiator doesn't have a valid TSID (login w/TSID=0), 
> it means it has
> lost state entirely (reboot) or knows it wants to immediately reset a
> session (NIC failure).  How could there possibly be a case where the
> initiator has an active valid session with the same ISID, but 
> just doesn't
> know about it??  Rejecting the login seems pointless, since 
> obviously the
> initiator either has a bug or intends to quickly reset the session.
> 
> The behavior chosen (Option C) will cause the initiator's 
> recovery to be
> delayed while the target NOPs all the connections and waits 
> for them to
> time
> out - this will only delay the initiators recovery 
> unnecessarily.  I can't
> help but think this will cause long term problems for the protocol.
> 
> Marjorie Krueger
> Networked Storage Architecture
> Networked Storage Solutions Org.
> Hewlett-Packard
> tel: +1 916 785 2656
> fax: +1 916 785 0391
> email: marjorie_krueger@hp.com
> 
> > -----Original Message-----
> > From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > Sent: Thursday, August 23, 2001 9:39 PM
> > To: ips@ece.cmu.edu
> > Subject: Re: iSCSI: reusing ISID for recovery (Was: RE: iSCSI
> > - Change -
> > Login/Text...)
> >
> >
> >
> > Mallikarjun,
> >
> > On  your point 1 that is what is stated today in the draft.
> >
> > On your point 2 option C is the one we took in the draft, after some
> > debate.
> >
> > Option A is prone to "wild closing of sessions" and option B is also
> > relaying to much on the good behaviour of the
> > client. It also introduces a "feature" that complicates 
> login/logout.
> >
> > Our postion on this is  that the initiator should logout the session
> > explicitly if it can (and in this case it can as the target
> > has ascertained
> > that the session is alive).
> >
> > I agree that you may want to update the stayte diagram to
> > reflect this.
> >
> > Julo
> >
> >
> > "Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on 
> 24-08-2001 01:46:40
> >
> > Please respond to cbm@rose.hp.com
> >
> > Sent by:  owner-ips@ece.cmu.edu
> >
> >
> > To:   ips@ece.cmu.edu
> > cc:
> > Subject:  iSCSI: reusing ISID for recovery (Was: RE: iSCSI 
> - Change -
> >       Login/Text...)
> >
> >
> >
> > Julian and all:
> >
> > This thread mirrors another discussion some of us are
> > having in a different forum.  Following (two bullets 1
> > & 2 below) is what I proposed there, attempting to address
> > two issues -
> >      a) how to recover sessions when target and the initiator
> >            have conflicting views of the same TCP connection(s)?
> >            (Initiator NIC fails, but there's no I/O activity,
> >            and the target doesn't see any connection failure.)
> >      b) More specifically, how to address the above problem
> >            when the initiator *does not want* to re-instate failed
> >            connections since it only implements the mandatory
> >            session recovery?
> >
> > This could add clarity or muddle things up here, though hopefully
> > the former...
> >
> > 1 If login is sent with the same ISID, same TSID, same CID 
> and X-bit,
> >   then it means a failed connection is being re-instated (whether
> >   or not there are multiple connections in the session).  This login
> >   attempt must be done before the connection timeout 
> (transition M1),
> >   or if this is the only connection in the session, also before the
> >   session timeout (transition N6) - to be counted as a connection
> >   reinstatement effort.
> >            o CmdSN counters (CmdSN, ExpCmdSN) are continued.
> > Initiator
> >              must do command plugging when there's a mismatch
> >              between its CmdSN and ExpCmdSN in the login response.
> >            o Since this is an implicit connection logout, all
> > the active
> >              tasks on the connection are either internally 
> terminated,
> >              or made non-allegiant (based on ErrorRecoveryLevel=x/y,
> >              TBD) for recovery.
> >
> > 2 If login is sent with the same ISID and TSID=0, the session (if it
> >   exists on the target) is being cleared and any active connections
> >   that the target sees must be immediately (at the end of the login
> >   process including any initiator authentication) transport reset.
> >   Initiator may attempt this only after it ascertains a
> > session failure
> >   on its end (ie. all connections entered RECOVERY_START).
> >            o CmdSN counters get reset.  Initiator has to perform the
> >              currently defined session recovery actions.
> >            o All active tasks of the session are internally
> > terminated.
> >
> >
> > Essentially, I was proposing extending the same notion of "implicit
> > logout" of a connection to the session level.  The options that I
> > see are -
> >
> >        A) Should iSCSI let it happen by default as stated above (ie.
> >           same ISID, TSID=0 always wipes out the 
> pre-existing session
> >           on target, since we are mandating it to be used only when
> >           initiator sees a session failure)?
> >        B) Should iSCSI mandate making this intended cleanup explicit
> >           by setting a bit (Say C-bit, for Clear) in the 
> Login Command
> >           PDU to prevent an accidental session cleanup with a buggy
> >           initiator code?
> >        C) Should iSCSI merely state that targets must ascertain
> >           the connection state(s) whenever a new session creation
> >           attempt is made with a known ISID and TSID=0?  (sort of
> >           defeats the intention of the initiator wanting quicker
> >           session recovery since the Login command PDU would have
> >           to idle till target ascertains the connection state(s)).
> >
> > I prefer A, or B.
> >
> > Going with A or B means that the description of transition N3
> > in the session state diagram would have to change to:
> >      Last LOGGED_IN connection had ceased to be LOGGED_IN,
> >         or a Login Command requesting clearing the session (also
> >         with C-bit set, if option B) was received by the target.
> >
> > The transition N7's description would have to be augmented as
> > well to:
> >         Session recovery attempt with an implicit logout,
> >         or connection reinstatement/new CID addition.
> >
> > Comments?
> > --
> > Mallikarjun
> >
> >
> > Mallikarjun Chadalapaka
> > Networked Storage Architecture
> > Network Storage Solutions Organization
> > MS 5668   Hewlett-Packard, Roseville.
> > cbm@rose.hp.com
> >
> >
> > >Stephen,
> > >
> > >That can happen as the target may set-up completely new TCP
> > connections
> > >(the old sockets are still there and look OK).
> > >Untill the login is  progessing he assumes that this is 
> just another
> > >open-session attempt. Then he checks the old session and the
> > session is
> > >dead (initiator has closed the connections).
> > >
> > >The target has to distinguish only between a session that is
> > alive (and
> > >reject the new one) and one that its dead in which case it
> > can clean-up.
> > >
> > >Julo
> > >
> > >"Wheat, Stephen R" <stephen.r.wheat@intel.com> on 
> 23-08-2001 22:50:56
> > >
> > >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> > >
> > >To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> > >cc:
> > >Subject:  RE: iSCSI - Change - Login/Text commands with the
> > binary stage
> > co
> > >          de
> > >
> > >
> > >
> > >Julian,
> > >
> > >I don't understand your answer.  For the scenario given, I
> > would presume
> > >then that the target would reject the new session attempt,
> > as it sees the
> > >previous session still "alive".  What is there to tell the
> > target that
> > this
> > >is any different from when the Initiator is erroneously using the
> > >repetitive
> > >session id?
> > >
> > >Thanks,
> > >Stephen
> > >
> > >-----Original Message-----
> > >From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > >Sent: Thursday, August 23, 2001 11:15 AM
> > >To: ips@ece.cmu.edu
> > >Subject: Re: iSCSI - Change - Login/Text commands with the
> > binary stage
> > >co de
> > >
> > >
> > >Stephen,
> > >
> > >1.If the initiator goes away for a while and reboots and 
> there was no
> > >activity on the connections
> > >the target may see a session alive (I am not sure that it
> > has to appear on
> > >the state diagram but maybe).
> > >
> > >2.Again - I am not sure that the curent state diagram
> > includes death of
> > the
> > >initiator
> > >
> > >Julo
> > >
> > >"Wheat, Stephen R" <stephen.r.wheat@intel.com>@ece.cmu.edu
> > on 23-08-2001
> > >19:58:34
> > >
> > >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> > >
> > >Sent by:  owner-ips@ece.cmu.edu
> > >
> > >
> > >To:   ips@ece.cmu.edu
> > >cc:
> > >Subject:  Re: iSCSI - Change - Login/Text commands with the
> > binary stage
> > co
> > >      de
> > >
> > >
> > >
> > >Julian,
> > >
> > >1.3.6 ISID states that the target should check to see if the
> > old session
> > is
> > >still active when a duplicate session is detected.
> > >
> > >I have two questions, the second only if you answer in the
> > affirmative on
> > >the first ;^)
> > >
> > >1. Is there a properly executed sequence of events (i.e., no
> > coding error
> > >on
> > >the target side) where the session is not active, but the
> > target hadn't
> > >taken notice of it?  It appears this as a protocol-specified
> > means to work
> > >around a flaw in a target's implementation.  I interpret the
> > state diagram
> > >transitions as being atomic wrt other commands.  I.e., the
> > last logout
> > >would
> > >result in the various transitions of the connection/session
> > prior to the
> > >initiator starting the session up again.  And the target would have
> > >completed the transitions prior to handling a new session request.
> > >
> > >2. If you answered (1) in the affirmative, then the word
> > "Active" is not
> > >consistent with the 6.3 Session State Diagram.  Does this
> > mean the target
> > >got lost, due to transport failures of any sort, in its
> > transition from
> > >Q3-to-Q2-to-Q1?  It sounds like the intent is to close the
> > old session if
> > >the session was in Q2 or Q4, presuming if it were in Q1,  it
> > would not
> > have
> > >been found as a duplicate.
> > >
> > >Stephen
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
> 
> 
> 


From owner-ips@ece.cmu.edu  Mon Aug 27 18:03:45 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02009
	for <ips-archive@odin.ietf.org>; Mon, 27 Aug 2001 18:03:45 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7RKRK024379
	for ips-outgoing; Mon, 27 Aug 2001 16:27:20 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from femail33.sdc1.sfba.home.com (femail33.sdc1.sfba.home.com [24.254.60.23])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7RKRIP24371
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 16:27:18 -0400 (EDT)
Received: from cc911880a ([65.14.127.68]) by femail33.sdc1.sfba.home.com
          (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP
          id <20010827202710.KPHD4276.femail33.sdc1.sfba.home.com@cc911880a>
          for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 13:27:10 -0700
Message-ID: <000c01c12f4f$7b060b00$447f0e41@rome1.ga.home.com>
Reply-To: "Adrian Raab" <araab1@earthlink.net>
From: "Adrian Raab" <araab1@earthlink.net>
To: <ips@ece.cmu.edu>
Subject: remove
Date: Mon, 27 Aug 2001 16:24:54 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0009_01C12F14.CE5346A0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0009_01C12F14.CE5346A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

remove from list

------=_NextPart_000_0009_01C12F14.CE5346A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4616.200" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>remove from =
list</FONT></DIV></BODY></HTML>

------=_NextPart_000_0009_01C12F14.CE5346A0--



From owner-ips@ece.cmu.edu  Mon Aug 27 18:07:54 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02155
	for <ips-archive@odin.ietf.org>; Mon, 27 Aug 2001 18:07:54 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7RJni522072
	for ips-outgoing; Mon, 27 Aug 2001 15:49:44 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f7RJnbP22054
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 15:49:37 -0400 (EDT)
Received: from scummy.research.bell-labs.com ([135.104.2.10]) by crufty; Mon Aug 27 15:44:22 EDT 2001
Received: from aura.research.bell-labs.com (aura.research.bell-labs.com [135.104.46.10])
	by scummy.research.bell-labs.com (8.11.4/8.11.4) with ESMTP id f7RJlrl40016
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 15:47:53 -0400 (EDT)
Received: from research.bell-labs.com (IDENT:sandeepj@sandeepj-pcmh.research.bell-labs.com [135.104.47.90])
	by aura.research.bell-labs.com (8.9.1/8.9.1) with ESMTP id PAA17661
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 15:47:52 -0400 (EDT)
Message-ID: <3B8AA3E7.41BBC33D@research.bell-labs.com>
Date: Mon, 27 Aug 2001 15:47:51 -0400
From: Sandeep Joshi <sandeepj@research.bell-labs.com>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-3 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: ips@ece.cmu.edu
Subject: Re: iSCSI: draft 7: remove S bit and Status field from the Data-i
References: <OFBB95214B.BF29E7CC-ONC2256AB5.0054554F@telaviv.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


Julian,

Wouldn't mechanical setup could go in parallel with network data 
reception anyways?  A target which has advertised a certain command 
window must also have reserved memory for the corresponding 
unsolicited bursts.  

So I guess I am still unconvinced..but can workaround if there 
aren't other supporters for the new ordering.

Btw, this "mechanical setup" rationale as well as the LUN tags in 
NOP-in (stated purpose: can be used to route NOP-ins to LUNs) 
seem to assume some model of an iSCSI storage target (JBOD/RAID), 
which is  perhaps external to what's in SAM-2.  
Just guessing, not sure. If there is some model, do share it with 
us since it may help see the design rationales.

Regards,
-Sandeep

Julian Satran wrote:
> 
> Sandeep,
> 
> It is not difficult but can be counterproductive.
> Lets assume that you have in the pipe 7 commands for 7 LUs (that can
> effectively execute in parallel) and all of them require
> some mechanical setup before they can effectively handle data.
> The rules in force today will allow the initiator to send out the commands
> (and let the mechanical setup start) and send the data afterwards (in the
> same order the commands where set).
> 
> The alternative will force order (without necessarily buying us anything)
> and disable the above optimization.
> 
> In the spec we set rules so that deadlocks will not occur (keep the same
> order as commands) but left room for optimization.
> 
> Julo
> 
> Sandeep Joshi <sandeepj@research.bell-labs.com>@research.bell-labs.com on
> 27-08-2001 18:07:10
> 
> Please respond to Sandeep Joshi <sandeepj@research.bell-labs.com>
> 
> Sent by:  sandeepj@research.bell-labs.com
> 
> To:   Julian Satran/Haifa/IBM@IBMIL
> cc:   ips@ece.cmu.edu
> Subject:  Re: iSCSI: draft 7: remove S bit and Status field from the Data-i
> 
> Julian,
> 
> I am probably missing something here..especially
> now that you refer to multiplexing.
> 
> The rule would be per-connection - why it is difficult
> for the initiator to send the unsolicited data _right_
> after the command ?  The data is already available from
> the ULP.
> 
> If this new rule is not added, the target needs
> to route unsolicited PDUs based on ITT (..a foreign tag)
> Its not a checking burden but a performance gain.
> 
> The only other cases which requires ITT routing at the
> target are abort-task, D-SNACK and command-retry, all
> of which we can assume to be infrequent and not in the
> performance path.
> 
> -Sandeep
> 
> P.S. Let me throw in some casuistry...this is also why
> dog owners are made to follow dogs, so one doesnt need
> to look at dog tags :-)
> 
> Julian Satran wrote:
> >
> > I am sure we don't want to enter this. The sequencing rules are there to
> > asure:
> >
> >    that there is no deadlock (order of data must follow the order of
> >    commands)
> >    that the target command buffer does not overflow (MaxCmdSN) - this
> will
> >    eliminate an "unlimited number of immediate"
> >
> > Any additional rules will interfere with performance, multiplexing policy
> > etc. and I see no great
> > value in enforcing them (and enforcing means checking and that means
> > expense).
> >
> > Julo
> >
> > Sandeep Joshi <sandeepj@research.bell-labs.com>@ece.cmu.edu on 26-08-2001
> > 00:11:39
> >
> > Please respond to Sandeep Joshi <sandeepj@research.bell-labs.com>
> >
> > Sent by:  owner-ips@ece.cmu.edu
> >
> > To:   Dave Sheehy <dbs@acropora.rose.agilent.com>
> > cc:   IETF IP SAN Reflector <ips@ece.cmu.edu>
> > Subject:  Re: iSCSI: draft 7: remove S bit and Status field from the
> Data-i
> >
> > Julian,
> >
> > I wonder if Dave's last paragraph in this email has been considered.
> > Here it is again..
> >
> > > This does help some. It eliminates the situation where a target can
> > receive
> > > an essentially unlimited number of immediate data commands prior to
> > receiving
> > > *any* data PDUs.
> >
> > in reference to Section 1.2.5
> > > Unsolicited data MUST be sent on
> > > every connection in the same order in which commands were sent.
> >
> > The draft currently allows
> >    c-1,c-2,c-3, (SEP-1-1),(SEP-1-2),(SEP-2-1,SEP-2-2),..
> > where c-N = command {N}
> > and   SEP-N-M = unsolicited (non-immediate) PDU number {M} for command
> > {N}
> >
> > It would be simplify target login (ITT lookup) if we only permitted
> > this sequence.
> >    c-1, SEP-1-1, SEP-1-2, c-2, SEP-2-1, SEP-2-2,..
> >
> > -Sandeep
> >
> > Dave Sheehy wrote:
> > >
> > > David,
> > >
> > > > I think you've taken a wrong turn.
> > >
> > > I think John hit the nail on the head.
> > >
> > > > > Second, thoughts of removing the immediate data seem not to be
> > > > > simplification, since all the information to tie the data to the
> > command
> > > > is
> > > > > right there with the command.  That has got to be easier than
> > matching up
> > > > > separate PDUs of data with the appropriate commands.
> > > >
> > > > Actually, that was the point, since the logic for "matching up
> separate
> > > > PDUs of data with the appropriate commands" has to exist for inbound
> > > > Data PDUs already.
> > >
> > > Except that there is a target context present in the solicited case to
> > route
> > > the data. That doesn't exist in the unsolicited case.
> > >
> > > > The slide I presented in London was about replacing
> > > > immediate data with an unsolicited data PDU immediately following the
> > > > command, thus removing the immediate data case in favor of reusing
> the
> > > > logic for dealing with separate Data PDUs.  Remember that this was
> > presented
> > > > as a simplification possibility.
> > >
> > > This does help some. It eliminates the situation where a target can
> > receive
> > > an essentially unlimited number of immediate data commands prior to
> > receiving
> > > *any* data PDUs.
> > >
> > > But, do you mean to say that *one* unsolicited data PDU would follow
> the
> > > command? Wouldn't that be unnecessarily restrictive if the PDU size is
> > small?
> > > Simply guaranteeing that the data PDUs will immediately follow the
> > command
> > > seems like an adequate improvement.
> > >
> > > Dave Sheehy


From owner-ips@ece.cmu.edu  Mon Aug 27 18:11:42 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02390
	for <ips-archive@odin.ietf.org>; Mon, 27 Aug 2001 18:11:42 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7RKWYI24668
	for ips-outgoing; Mon, 27 Aug 2001 16:32:34 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from sentinel.sanera.net (ns1.sanera.net [208.253.254.10])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7RKWVP24653
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 16:32:31 -0400 (EDT)
Received: from newton.sanera.net (newton [192.168.254.11])
	by sentinel.sanera.net (8.11.2/8.11.2) with ESMTP id f7RKWF213520
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 13:32:15 -0700
Received: from strahmw2k (dhcp-pc-100-165.sanera.net [192.168.100.165])
	by newton.sanera.net (8.11.4/8.11.4) with SMTP id f7RKW8U28137
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 13:32:08 -0700 (PDT)
From: "Bill Strahm" <bill@sanera.net>
To: <ips@ece.cmu.edu>
Subject: RE: FW: I-D ACTION:draft-aboba-ips-iscsi-security-00.txt
Date: Mon, 27 Aug 2001 13:31:44 -0700
Message-ID: <HDECJFNIFJBIAINDCFOMAEJDCAAA.bill@sanera.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4807.1700
In-Reply-To: <NDBBJJDNOJJEFGHAECHIAELGDDAA.jtardo@broadcom.com>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Just to step in...

I am concerned that we are going to standardize on some new toys that have
1) Unknown properties, possibly not to my liking
2) Unknown licensing requirements - Definitely not to my liking

I have to ask this question
What is wrong with requiring as a minimum, the required IPsec transforms,
and not go beyond that for a MUST implement.  Many people are going to argue
that DES is not good enough, well I hate to say it, but DES is better than
clear text - which almost by definition IS good enough.  I am also concerned
with the time needed to get these transforms into implementations that are
purchasable to be integrated with solutions.

When AES and its various modes are vetted over the next few years, I expect
IPsec to start requiring these things... Then we get it for free (i.e. IPsec
requires them, we require IPsec), if we do it now as the only REQUIRED
implementation and the mode we choose is found to be fundamentally weak -
our whole security story collapses on itself

Bill
Sanera Systems Inc.

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Joseph Tardo
Sent: Monday, August 27, 2001 9:36 AM
To: Mark Winstead; Black_David@emc.com; sandeepj@research.bell-labs.com;
ips@ece.cmu.edu
Subject: RE: FW: I-D ACTION:draft-aboba-ips-iscsi-security-00.txt


Some additional issues raised at that workshop:

1. Typical security protocols, in particular the IPsec transforms, require
authentication to extend beyond the ciphertext to some additional cleartext
(e.g., the SPI and replay counter for ESP). Such use needs to be carefully
designed, and there are no current standardized proposals with proven
security.

2. To support ESP NULL, any such mode needs to be defined so as to support
authentication without confidentiality.

--Joe

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Mark Winstead
Sent: Monday, August 27, 2001 6:06 AM
To: 'Black_David@emc.com'; sandeepj@research.bell-labs.com;
ips@ece.cmu.edu
Subject: RE: FW: I-D ACTION:draft-aboba-ips-iscsi-security-00.txt


Last Friday, NIST held a modes of operation workshop (for the protection and
privacy of sensitive but unclassified data, NIST authorizes suitable
algorithms and techniques for use by federal government departments and
agencies).

OCB is one of three modes considered that achieve both privacy and
authentication, as well as the potential to scale well for speed. All three
either have patents or have been submitted for patents. IMHO w/o coding
them, only two of the three, OCB and Integrity Aware Parallelizable Mode
(IAPM) will scale well to support 10 Gbs and more. IAPM's patent is held by
IBM, OCB by Phil Rogaway.

The patent issue came up during the discussion time -- no one present knew
of a provably secure mode with the properties of OCB that was unpatented.
One could find an unpatented mode for privacy, say counter mode, and then
add a MAC that provides authentication, but that is an extra step (plus I
think you might run into the patent problem again in finding a MAC that will
permit 10 Gbs speed).

Mark Winstead

-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Tuesday, August 21, 2001 8:17 PM
To: sandeepj@research.bell-labs.com; ips@ece.cmu.edu
Subject: RE: FW: I-D ACTION:draft-aboba-ips-iscsi-security-00.txt


Sandeep,

There is a patent on it, and a license is required to ship product.
The license should be available under fair, reasonable, and non-
discriminatory terms, but will not be free.  A reasonable guess
would be that iSCSI licensing terms would be similar to the 802.11
terms, and that a suitable IETF intellectual property rights notice
will be forthcoming.

OTOH, this does seem to run counter to the usual IETF preference
for unpatented technology over patented technology provided that
the unpatented technology is a functionally suitable replacement
for the patented technology.  Whether there are functionally suitable
unpatented replacements for OCB is an issue for further discussion,
ditto the requirements and preferences that lead to the recommendation
of OCB.  A draft on OCB would need to go through the ipsec WG if we
were to use OCB, and my impression is that at least some portion of
that community has a very strong preference for unpatented technology.

I hope this is what you were looking for in the way of comments.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


> -----Original Message-----
> From: sandeepj@research.bell-labs.com
> [mailto:sandeepj@research.bell-labs.com]
> Sent: Tuesday, August 21, 2001 7:49 PM
> To: ips@ece.cmu.edu
> Subject: Re: FW: I-D ACTION:draft-aboba-ips-iscsi-security-00.txt
>
>
> David,
>
> Could you comment on the intellectual rights issues
> here, particularly on AES-OCB, which will be mandatory
> according to this draft (Sec 2.1)
>
> http://www.cs.ucdavis.edu/~rogaway/ocb/ocb-back.htm
> mentions the licensing terms for 802.11 products.
>
> Secondly, appendix tables A.5 and A.6 seem to indicate
> that AES-CTR+UMAC performance is better than AES-OCB.
> Has AES-OCB been chosen since it requires lesser keying
> material and memory ?
>
> thanks
> -Sandeep
>
> > FYI - this is about use of IKE and IPsec algorithm selection
> > considerations.  --David
> >
> > -----Original Message-----
> > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> > Sent: Tuesday, August 21, 2001 7:25 AM
> > Subject: I-D ACTION:draft-aboba-ips-iscsi-security-00.txt
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> >
> > Title           : Securing iSCSI using IPsec
> > Author(s)       : B. Aboba et al.
> > Filename        : draft-aboba-ips-iscsi-security-00.txt
> > Pages           : 35
> > Date            : 20-Aug-01
> >
> > This document discusses how iSCSI may utilize IPsec to provide
> > authentication, integrity, confidentiality and replay protection.
> >
> > A URL for this Internet-Draft is:
> >
http://www.ietf.org/internet-drafts/draft-aboba-ips-iscsi-security-00.txt
>
> Internet-Drafts are also available by anonymous FTP. Login with the
username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-aboba-ips-iscsi-security-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> mailserv@ietf.org.
> In the body type:
> "FILE /internet-drafts/draft-aboba-ips-iscsi-security-00.txt".
>
> NOTE:   The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility.  To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader.  Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
> ---------------------------------------------------------
> + Date: Tue, 21 Aug 2001 09:29:53 -0400
> + Content-Type:
> multipart/mixed;boundary="----_=_NextPart_002_01C12A44.418236C0"
>
> ATT36560
>
> <ftp://internet-drafts/>
> Transfer-mode: ftp.ietf.org
> ---------------------------------------------------------
>






From owner-ips@ece.cmu.edu  Mon Aug 27 19:14:25 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03974
	for <ips-archive@odin.ietf.org>; Mon, 27 Aug 2001 19:14:25 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7RLJAE27451
	for ips-outgoing; Mon, 27 Aug 2001 17:19:10 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7RLJ5P27445
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 17:19:05 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA93876
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 17:16:32 -0400
Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7RLIWc166016
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 15:18:32 -0600
Importance: Normal
Subject: RE: iSCSI: reusing ISID for recovery
To: ips@ece.cmu.edu
From: "Jim Hafner" <hafner@almaden.ibm.com>
Date: Mon, 27 Aug 2001 14:18:31 -0700
Message-ID: <OF4B7BAFBB.55FA6C5A-ON88256AB5.00746845@boulder.ibm.com>
X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at
 08/27/2001 02:18:32 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Marj,

I agree (that is, I don't like option C).  I'm waffling between A and B.  A
is simpler and B is "more polite".

But I have a twist on option B that may make it a bit more palettable.

The problem with option B is that requires extra protocol to have the
additional bit to force the logout of the "dead" session, mostly because
the initiator doesn't have the context left for the old session.  Suppose
we have the target reject but in the response it puts what it is using for
TSID in the usual place.  In effect, this is saying to the initiator "I
already have a session in place with this ISID/TSID value".

I think this gives the initiator the handle it needs to expressly do a
logout of the old session (with a valid ISID/TSID pair) or at least enough
information for the initiator to figure out what's gone wrong.  That is, it
can do session recovery or whatever else is needed.  In this way, we don't
need anything like a "force" bit in the login.  He has more steps to do,
but they would be the same steps he would do if he just wanted to cleanup a
old session he did know about.

Jim Hafner


"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>@ece.cmu.edu
on 08/27/2001 01:39:52 pm

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery



If it is another OS, it should be a different iSCSI initiator, and hence
will have a different initiator name, so this case shouldn't be a factor.
It's not the ISID along which identifies the initiator, it's the initiator
name  + ISID.

I believe the case in which this behavior (option C) will become an issue
is
in the case of initiator reboot, which will be the norm, not the exception.
IOTW, most of the cases where the target will be faced with an initiator
login w/an "in use" ISID, TSID=0 will be in the case of an initiator
reboot.
That is the case we should optimize for.  I could live with Option B, but
Option A seems sufficient.

It seems the primary value of option C is to guard against malfunctioning
initiators.  As has been said many times, we cannot design a protocol to
guard against coding errors.

Marj

> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Saturday, August 25, 2001 12:23 AM
> To: ips@ece.cmu.edu
> Subject: RE: iSCSI: reusing ISID for recovery
>
>
>
> It may be another OS running on the same machine or CPU
> complex or it could
> be an attack.
> In any case if the initiator is up and fine he can as well do logout.
> It is a rare enough event for us not to try to optimize.
>
> The reboot is the only case in which the initiator can't
> logout and about
> which we care.
>
> And I would like to remind you all that we where on this
> exact thread more
> tan 3 months ago (other players).
> I just restated the rationale for an (apparent) newcomer.
>
> Julo
>
> "KRUEGER,MARJORIE (HP-Roseville,ex1)"
> <marjorie_krueger@hp.com>@ece.cmu.edu
> on 25-08-2001 03:51:43
>
> Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"
>       <marjorie_krueger@hp.com>
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   ips@ece.cmu.edu
> cc:
> Subject:  RE: iSCSI: reusing ISID for recovery
>
>
>
> I don't see how Option A is prone to "wild closing of sessions".  The
> target
> is only looking for sessions with this particular initiator
> and closing
> them
> if the ISID matches.
>
> If an initiator doesn't have a valid TSID (login w/TSID=0),
> it means it has
> lost state entirely (reboot) or knows it wants to immediately reset a
> session (NIC failure).  How could there possibly be a case where the
> initiator has an active valid session with the same ISID, but
> just doesn't
> know about it??  Rejecting the login seems pointless, since
> obviously the
> initiator either has a bug or intends to quickly reset the session.
>
> The behavior chosen (Option C) will cause the initiator's
> recovery to be
> delayed while the target NOPs all the connections and waits
> for them to
> time
> out - this will only delay the initiators recovery
> unnecessarily.  I can't
> help but think this will cause long term problems for the protocol.
>
> Marjorie Krueger
> Networked Storage Architecture
> Networked Storage Solutions Org.
> Hewlett-Packard
> tel: +1 916 785 2656
> fax: +1 916 785 0391
> email: marjorie_krueger@hp.com
>
> > -----Original Message-----
> > From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > Sent: Thursday, August 23, 2001 9:39 PM
> > To: ips@ece.cmu.edu
> > Subject: Re: iSCSI: reusing ISID for recovery (Was: RE: iSCSI
> > - Change -
> > Login/Text...)
> >
> >
> >
> > Mallikarjun,
> >
> > On  your point 1 that is what is stated today in the draft.
> >
> > On your point 2 option C is the one we took in the draft, after some
> > debate.
> >
> > Option A is prone to "wild closing of sessions" and option B is also
> > relaying to much on the good behaviour of the
> > client. It also introduces a "feature" that complicates
> login/logout.
> >
> > Our postion on this is  that the initiator should logout the session
> > explicitly if it can (and in this case it can as the target
> > has ascertained
> > that the session is alive).
> >
> > I agree that you may want to update the stayte diagram to
> > reflect this.
> >
> > Julo
> >
> >
> > "Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on
> 24-08-2001 01:46:40
> >
> > Please respond to cbm@rose.hp.com
> >
> > Sent by:  owner-ips@ece.cmu.edu
> >
> >
> > To:   ips@ece.cmu.edu
> > cc:
> > Subject:  iSCSI: reusing ISID for recovery (Was: RE: iSCSI
> - Change -
> >       Login/Text...)
> >
> >
> >
> > Julian and all:
> >
> > This thread mirrors another discussion some of us are
> > having in a different forum.  Following (two bullets 1
> > & 2 below) is what I proposed there, attempting to address
> > two issues -
> >      a) how to recover sessions when target and the initiator
> >            have conflicting views of the same TCP connection(s)?
> >            (Initiator NIC fails, but there's no I/O activity,
> >            and the target doesn't see any connection failure.)
> >      b) More specifically, how to address the above problem
> >            when the initiator *does not want* to re-instate failed
> >            connections since it only implements the mandatory
> >            session recovery?
> >
> > This could add clarity or muddle things up here, though hopefully
> > the former...
> >
> > 1 If login is sent with the same ISID, same TSID, same CID
> and X-bit,
> >   then it means a failed connection is being re-instated (whether
> >   or not there are multiple connections in the session).  This login
> >   attempt must be done before the connection timeout
> (transition M1),
> >   or if this is the only connection in the session, also before the
> >   session timeout (transition N6) - to be counted as a connection
> >   reinstatement effort.
> >            o CmdSN counters (CmdSN, ExpCmdSN) are continued.
> > Initiator
> >              must do command plugging when there's a mismatch
> >              between its CmdSN and ExpCmdSN in the login response.
> >            o Since this is an implicit connection logout, all
> > the active
> >              tasks on the connection are either internally
> terminated,
> >              or made non-allegiant (based on ErrorRecoveryLevel=x/y,
> >              TBD) for recovery.
> >
> > 2 If login is sent with the same ISID and TSID=0, the session (if it
> >   exists on the target) is being cleared and any active connections
> >   that the target sees must be immediately (at the end of the login
> >   process including any initiator authentication) transport reset.
> >   Initiator may attempt this only after it ascertains a
> > session failure
> >   on its end (ie. all connections entered RECOVERY_START).
> >            o CmdSN counters get reset.  Initiator has to perform the
> >              currently defined session recovery actions.
> >            o All active tasks of the session are internally
> > terminated.
> >
> >
> > Essentially, I was proposing extending the same notion of "implicit
> > logout" of a connection to the session level.  The options that I
> > see are -
> >
> >        A) Should iSCSI let it happen by default as stated above (ie.
> >           same ISID, TSID=0 always wipes out the
> pre-existing session
> >           on target, since we are mandating it to be used only when
> >           initiator sees a session failure)?
> >        B) Should iSCSI mandate making this intended cleanup explicit
> >           by setting a bit (Say C-bit, for Clear) in the
> Login Command
> >           PDU to prevent an accidental session cleanup with a buggy
> >           initiator code?
> >        C) Should iSCSI merely state that targets must ascertain
> >           the connection state(s) whenever a new session creation
> >           attempt is made with a known ISID and TSID=0?  (sort of
> >           defeats the intention of the initiator wanting quicker
> >           session recovery since the Login command PDU would have
> >           to idle till target ascertains the connection state(s)).
> >
> > I prefer A, or B.
> >
> > Going with A or B means that the description of transition N3
> > in the session state diagram would have to change to:
> >      Last LOGGED_IN connection had ceased to be LOGGED_IN,
> >         or a Login Command requesting clearing the session (also
> >         with C-bit set, if option B) was received by the target.
> >
> > The transition N7's description would have to be augmented as
> > well to:
> >         Session recovery attempt with an implicit logout,
> >         or connection reinstatement/new CID addition.
> >
> > Comments?
> > --
> > Mallikarjun
> >
> >
> > Mallikarjun Chadalapaka
> > Networked Storage Architecture
> > Network Storage Solutions Organization
> > MS 5668   Hewlett-Packard, Roseville.
> > cbm@rose.hp.com
> >
> >
> > >Stephen,
> > >
> > >That can happen as the target may set-up completely new TCP
> > connections
> > >(the old sockets are still there and look OK).
> > >Untill the login is  progessing he assumes that this is
> just another
> > >open-session attempt. Then he checks the old session and the
> > session is
> > >dead (initiator has closed the connections).
> > >
> > >The target has to distinguish only between a session that is
> > alive (and
> > >reject the new one) and one that its dead in which case it
> > can clean-up.
> > >
> > >Julo
> > >
> > >"Wheat, Stephen R" <stephen.r.wheat@intel.com> on
> 23-08-2001 22:50:56
> > >
> > >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> > >
> > >To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> > >cc:
> > >Subject:  RE: iSCSI - Change - Login/Text commands with the
> > binary stage
> > co
> > >          de
> > >
> > >
> > >
> > >Julian,
> > >
> > >I don't understand your answer.  For the scenario given, I
> > would presume
> > >then that the target would reject the new session attempt,
> > as it sees the
> > >previous session still "alive".  What is there to tell the
> > target that
> > this
> > >is any different from when the Initiator is erroneously using the
> > >repetitive
> > >session id?
> > >
> > >Thanks,
> > >Stephen
> > >
> > >-----Original Message-----
> > >From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > >Sent: Thursday, August 23, 2001 11:15 AM
> > >To: ips@ece.cmu.edu
> > >Subject: Re: iSCSI - Change - Login/Text commands with the
> > binary stage
> > >co de
> > >
> > >
> > >Stephen,
> > >
> > >1.If the initiator goes away for a while and reboots and
> there was no
> > >activity on the connections
> > >the target may see a session alive (I am not sure that it
> > has to appear on
> > >the state diagram but maybe).
> > >
> > >2.Again - I am not sure that the curent state diagram
> > includes death of
> > the
> > >initiator
> > >
> > >Julo
> > >
> > >"Wheat, Stephen R" <stephen.r.wheat@intel.com>@ece.cmu.edu
> > on 23-08-2001
> > >19:58:34
> > >
> > >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> > >
> > >Sent by:  owner-ips@ece.cmu.edu
> > >
> > >
> > >To:   ips@ece.cmu.edu
> > >cc:
> > >Subject:  Re: iSCSI - Change - Login/Text commands with the
> > binary stage
> > co
> > >      de
> > >
> > >
> > >
> > >Julian,
> > >
> > >1.3.6 ISID states that the target should check to see if the
> > old session
> > is
> > >still active when a duplicate session is detected.
> > >
> > >I have two questions, the second only if you answer in the
> > affirmative on
> > >the first ;^)
> > >
> > >1. Is there a properly executed sequence of events (i.e., no
> > coding error
> > >on
> > >the target side) where the session is not active, but the
> > target hadn't
> > >taken notice of it?  It appears this as a protocol-specified
> > means to work
> > >around a flaw in a target's implementation.  I interpret the
> > state diagram
> > >transitions as being atomic wrt other commands.  I.e., the
> > last logout
> > >would
> > >result in the various transitions of the connection/session
> > prior to the
> > >initiator starting the session up again.  And the target would have
> > >completed the transitions prior to handling a new session request.
> > >
> > >2. If you answered (1) in the affirmative, then the word
> > "Active" is not
> > >consistent with the 6.3 Session State Diagram.  Does this
> > mean the target
> > >got lost, due to transport failures of any sort, in its
> > transition from
> > >Q3-to-Q2-to-Q1?  It sounds like the intent is to close the
> > old session if
> > >the session was in Q2 or Q4, presuming if it were in Q1,  it
> > would not
> > have
> > >been found as a duplicate.
> > >
> > >Stephen
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
>
>
>





From owner-ips@ece.cmu.edu  Mon Aug 27 19:16:48 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04012
	for <ips-archive@odin.ietf.org>; Mon, 27 Aug 2001 19:16:48 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7RLPKI28192
	for ips-outgoing; Mon, 27 Aug 2001 17:25:20 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dominoe.integrix.com ([207.171.9.89])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7RLPHP28184
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 17:25:17 -0400 (EDT)
Received: from integrix.com (mdelmar [192.9.200.209])
	by dominoe.integrix.com (8.9.1b+Sun/8.9.1) with ESMTP id OAA13306
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 14:23:15 -0700 (PDT)
Message-ID: <3B8ABA30.71E257FC@integrix.com>
Date: Mon, 27 Aug 2001 14:22:57 -0700
From: Marcos Delmar <mdelmar@integrix.com>
X-Mailer: Mozilla 4.78 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ips@ece.cmu.edu
Subject: remove
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

remove from list



From owner-ips@ece.cmu.edu  Mon Aug 27 20:02:34 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04631
	for <ips-archive@odin.ietf.org>; Mon, 27 Aug 2001 20:02:33 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7RMdfd02643
	for ips-outgoing; Mon, 27 Aug 2001 18:39:41 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from clyde.stargateip.com ([209.237.5.66])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7RMdcP02638
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 18:39:38 -0400 (EDT)
Received: from bluestar (dhcp-101.stargateip.com [10.10.5.101])
	by clyde.stargateip.com (8.9.1/8.9.1) with SMTP id PAA11572;
	Mon, 27 Aug 2001 15:33:20 -0700 (PDT)
Reply-To: <deva@stargateip.com>
From: "Dev" <deva@stargateip.com>
To: "KRUEGER,MARJORIE \(HP-Roseville,ex1\)" <marjorie_krueger@hp.com>,
        <ips@ece.cmu.edu>
Subject: RE: iSCSI: reusing ISID for recovery
Date: Mon, 27 Aug 2001 15:44:15 -0700
Message-ID: <NFBBKBDFJCDMGCBKJLCJEEGHFDAA.deva@stargateip.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <6BD67FFB937FD411A04F00D0B74FE87802A0927F@xrose06.rose.hp.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

All,

When a session is already running authenticated, a login request with the
same
ISID + initiator fails authentication. Will the session continue to run?  Or
if the target fails during parameter negotiation?

I guess, yes. i.e. target will not act on the existing session, until
the login completes successfully. Or are there exception to these?

Thanks

Deva
Platys Communications





> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Saturday, August 25, 2001 12:23 AM
> To: ips@ece.cmu.edu
> Subject: RE: iSCSI: reusing ISID for recovery
>
>
>
> It may be another OS running on the same machine or CPU
> complex or it could
> be an attack.
> In any case if the initiator is up and fine he can as well do logout.
> It is a rare enough event for us not to try to optimize.
>
> The reboot is the only case in which the initiator can't
> logout and about
> which we care.
>
> And I would like to remind you all that we where on this
> exact thread more
> tan 3 months ago (other players).
> I just restated the rationale for an (apparent) newcomer.
>
> Julo
>
> "KRUEGER,MARJORIE (HP-Roseville,ex1)"
> <marjorie_krueger@hp.com>@ece.cmu.edu
> on 25-08-2001 03:51:43
>
> Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"
>       <marjorie_krueger@hp.com>
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   ips@ece.cmu.edu
> cc:
> Subject:  RE: iSCSI: reusing ISID for recovery
>
>
>
> I don't see how Option A is prone to "wild closing of sessions".  The
> target
> is only looking for sessions with this particular initiator
> and closing
> them
> if the ISID matches.
>
> If an initiator doesn't have a valid TSID (login w/TSID=0),
> it means it has
> lost state entirely (reboot) or knows it wants to immediately reset a
> session (NIC failure).  How could there possibly be a case where the
> initiator has an active valid session with the same ISID, but
> just doesn't
> know about it??  Rejecting the login seems pointless, since
> obviously the
> initiator either has a bug or intends to quickly reset the session.
>
> The behavior chosen (Option C) will cause the initiator's
> recovery to be
> delayed while the target NOPs all the connections and waits
> for them to
> time
> out - this will only delay the initiators recovery
> unnecessarily.  I can't
> help but think this will cause long term problems for the protocol.
>
> Marjorie Krueger
> Networked Storage Architecture
> Networked Storage Solutions Org.
> Hewlett-Packard
> tel: +1 916 785 2656
> fax: +1 916 785 0391
> email: marjorie_krueger@hp.com
>
> > -----Original Message-----
> > From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > Sent: Thursday, August 23, 2001 9:39 PM
> > To: ips@ece.cmu.edu
> > Subject: Re: iSCSI: reusing ISID for recovery (Was: RE: iSCSI
> > - Change -
> > Login/Text...)
> >
> >
> >
> > Mallikarjun,
> >
> > On  your point 1 that is what is stated today in the draft.
> >
> > On your point 2 option C is the one we took in the draft, after some
> > debate.
> >
> > Option A is prone to "wild closing of sessions" and option B is also
> > relaying to much on the good behaviour of the
> > client. It also introduces a "feature" that complicates
> login/logout.
> >
> > Our postion on this is  that the initiator should logout the session
> > explicitly if it can (and in this case it can as the target
> > has ascertained
> > that the session is alive).
> >
> > I agree that you may want to update the stayte diagram to
> > reflect this.
> >
> > Julo
> >
> >
> > "Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on
> 24-08-2001 01:46:40
> >
> > Please respond to cbm@rose.hp.com
> >
> > Sent by:  owner-ips@ece.cmu.edu
> >
> >
> > To:   ips@ece.cmu.edu
> > cc:
> > Subject:  iSCSI: reusing ISID for recovery (Was: RE: iSCSI
> - Change -
> >       Login/Text...)
> >
> >
> >
> > Julian and all:
> >
> > This thread mirrors another discussion some of us are
> > having in a different forum.  Following (two bullets 1
> > & 2 below) is what I proposed there, attempting to address
> > two issues -
> >      a) how to recover sessions when target and the initiator
> >            have conflicting views of the same TCP connection(s)?
> >            (Initiator NIC fails, but there's no I/O activity,
> >            and the target doesn't see any connection failure.)
> >      b) More specifically, how to address the above problem
> >            when the initiator *does not want* to re-instate failed
> >            connections since it only implements the mandatory
> >            session recovery?
> >
> > This could add clarity or muddle things up here, though hopefully
> > the former...
> >
> > 1 If login is sent with the same ISID, same TSID, same CID
> and X-bit,
> >   then it means a failed connection is being re-instated (whether
> >   or not there are multiple connections in the session).  This login
> >   attempt must be done before the connection timeout
> (transition M1),
> >   or if this is the only connection in the session, also before the
> >   session timeout (transition N6) - to be counted as a connection
> >   reinstatement effort.
> >            o CmdSN counters (CmdSN, ExpCmdSN) are continued.
> > Initiator
> >              must do command plugging when there's a mismatch
> >              between its CmdSN and ExpCmdSN in the login response.
> >            o Since this is an implicit connection logout, all
> > the active
> >              tasks on the connection are either internally
> terminated,
> >              or made non-allegiant (based on ErrorRecoveryLevel=x/y,
> >              TBD) for recovery.
> >
> > 2 If login is sent with the same ISID and TSID=0, the session (if it
> >   exists on the target) is being cleared and any active connections
> >   that the target sees must be immediately (at the end of the login
> >   process including any initiator authentication) transport reset.
> >   Initiator may attempt this only after it ascertains a
> > session failure
> >   on its end (ie. all connections entered RECOVERY_START).
> >            o CmdSN counters get reset.  Initiator has to perform the
> >              currently defined session recovery actions.
> >            o All active tasks of the session are internally
> > terminated.
> >
> >
> > Essentially, I was proposing extending the same notion of "implicit
> > logout" of a connection to the session level.  The options that I
> > see are -
> >
> >        A) Should iSCSI let it happen by default as stated above (ie.
> >           same ISID, TSID=0 always wipes out the
> pre-existing session
> >           on target, since we are mandating it to be used only when
> >           initiator sees a session failure)?
> >        B) Should iSCSI mandate making this intended cleanup explicit
> >           by setting a bit (Say C-bit, for Clear) in the
> Login Command
> >           PDU to prevent an accidental session cleanup with a buggy
> >           initiator code?
> >        C) Should iSCSI merely state that targets must ascertain
> >           the connection state(s) whenever a new session creation
> >           attempt is made with a known ISID and TSID=0?  (sort of
> >           defeats the intention of the initiator wanting quicker
> >           session recovery since the Login command PDU would have
> >           to idle till target ascertains the connection state(s)).
> >
> > I prefer A, or B.
> >
> > Going with A or B means that the description of transition N3
> > in the session state diagram would have to change to:
> >      Last LOGGED_IN connection had ceased to be LOGGED_IN,
> >         or a Login Command requesting clearing the session (also
> >         with C-bit set, if option B) was received by the target.
> >
> > The transition N7's description would have to be augmented as
> > well to:
> >         Session recovery attempt with an implicit logout,
> >         or connection reinstatement/new CID addition.
> >
> > Comments?
> > --
> > Mallikarjun
> >
> >
> > Mallikarjun Chadalapaka
> > Networked Storage Architecture
> > Network Storage Solutions Organization
> > MS 5668   Hewlett-Packard, Roseville.
> > cbm@rose.hp.com
> >
> >
> > >Stephen,
> > >
> > >That can happen as the target may set-up completely new TCP
> > connections
> > >(the old sockets are still there and look OK).
> > >Untill the login is  progessing he assumes that this is
> just another
> > >open-session attempt. Then he checks the old session and the
> > session is
> > >dead (initiator has closed the connections).
> > >
> > >The target has to distinguish only between a session that is
> > alive (and
> > >reject the new one) and one that its dead in which case it
> > can clean-up.
> > >
> > >Julo
> > >
> > >"Wheat, Stephen R" <stephen.r.wheat@intel.com> on
> 23-08-2001 22:50:56
> > >
> > >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> > >
> > >To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> > >cc:
> > >Subject:  RE: iSCSI - Change - Login/Text commands with the
> > binary stage
> > co
> > >          de
> > >
> > >
> > >
> > >Julian,
> > >
> > >I don't understand your answer.  For the scenario given, I
> > would presume
> > >then that the target would reject the new session attempt,
> > as it sees the
> > >previous session still "alive".  What is there to tell the
> > target that
> > this
> > >is any different from when the Initiator is erroneously using the
> > >repetitive
> > >session id?
> > >
> > >Thanks,
> > >Stephen
> > >
> > >-----Original Message-----
> > >From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > >Sent: Thursday, August 23, 2001 11:15 AM
> > >To: ips@ece.cmu.edu
> > >Subject: Re: iSCSI - Change - Login/Text commands with the
> > binary stage
> > >co de
> > >
> > >
> > >Stephen,
> > >
> > >1.If the initiator goes away for a while and reboots and
> there was no
> > >activity on the connections
> > >the target may see a session alive (I am not sure that it
> > has to appear on
> > >the state diagram but maybe).
> > >
> > >2.Again - I am not sure that the curent state diagram
> > includes death of
> > the
> > >initiator
> > >
> > >Julo
> > >
> > >"Wheat, Stephen R" <stephen.r.wheat@intel.com>@ece.cmu.edu
> > on 23-08-2001
> > >19:58:34
> > >
> > >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> > >
> > >Sent by:  owner-ips@ece.cmu.edu
> > >
> > >
> > >To:   ips@ece.cmu.edu
> > >cc:
> > >Subject:  Re: iSCSI - Change - Login/Text commands with the
> > binary stage
> > co
> > >      de
> > >
> > >
> > >
> > >Julian,
> > >
> > >1.3.6 ISID states that the target should check to see if the
> > old session
> > is
> > >still active when a duplicate session is detected.
> > >
> > >I have two questions, the second only if you answer in the
> > affirmative on
> > >the first ;^)
> > >
> > >1. Is there a properly executed sequence of events (i.e., no
> > coding error
> > >on
> > >the target side) where the session is not active, but the
> > target hadn't
> > >taken notice of it?  It appears this as a protocol-specified
> > means to work
> > >around a flaw in a target's implementation.  I interpret the
> > state diagram
> > >transitions as being atomic wrt other commands.  I.e., the
> > last logout
> > >would
> > >result in the various transitions of the connection/session
> > prior to the
> > >initiator starting the session up again.  And the target would have
> > >completed the transitions prior to handling a new session request.
> > >
> > >2. If you answered (1) in the affirmative, then the word
> > "Active" is not
> > >consistent with the 6.3 Session State Diagram.  Does this
> > mean the target
> > >got lost, due to transport failures of any sort, in its
> > transition from
> > >Q3-to-Q2-to-Q1?  It sounds like the intent is to close the
> > old session if
> > >the session was in Q2 or Q4, presuming if it were in Q1,  it
> > would not
> > have
> > >been found as a duplicate.
> > >
> > >Stephen
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
>
>
>



From owner-ips@ece.cmu.edu  Mon Aug 27 20:02:44 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04642
	for <ips-archive@odin.ietf.org>; Mon, 27 Aug 2001 20:02:44 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7RNCWi07773
	for ips-outgoing; Mon, 27 Aug 2001 19:12:32 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7RNCVP07769
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 19:12:31 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id TAA20256
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 19:10:19 -0400
Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7RNCTc23882
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 17:12:29 -0600
Importance: Normal
Subject: RE: iSCSI: reusing ISID for recovery
To: ips@ece.cmu.edu
From: "Jim Hafner" <hafner@almaden.ibm.com>
Date: Mon, 27 Aug 2001 16:12:28 -0700
Message-ID: <OFDFC82124.54A2B752-ON88256AB5.007EFD41@boulder.ibm.com>
X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at
 08/27/2001 04:12:29 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Marj,

All of your questions point out the lack of completeness in my thinking
(which is why I said "I think this gives...").

I guess I was thinking that the initiator could act like it wants to join a
new connection to the existing session, so that it can logout that session.
You're right that this is a problem for 1-connection-per-session targets,
but don't we have that problem anyway (if there is one connection and the
host looses it, what does it do now for recovery?)

As I said, I'm starting to lean a bit more toward A.  It's the cleanest and
simplest.

Jim Hafner


"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>@ece.cmu.edu
on 08/27/2001 03:46:23 pm

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery



How would the initiator log out the "dead" session?  Even if it knows a
TSID, it doesn't have any state, or any connections (assuming reboot).  Are
you suggesting the initiator perform some new sort of recovery where it
rebuilds a partial session state and "acts" like it wants to join the dead
session, for the purpose of logging it out?   Presumeably, this wouldn't
work with target implementations that only allow one connection? (see
Mallikarjun's last email) In my mind, any sort of recovery only makes sense
when there is surviving state information on both parties (I & T).  Is your
thinking different?

IMO, if option B were provided, initiator implementations would always just
turn on the "logout" bit, "just to be safe" and therefore, it would
effectively be no different than option A (just more protocol bits).

Marj

> -----Original Message-----
> From: Jim Hafner [mailto:hafner@almaden.ibm.com]
> Sent: Monday, August 27, 2001 2:19 PM
> To: ips@ece.cmu.edu
> Subject: RE: iSCSI: reusing ISID for recovery
>
>
>
> Marj,
>
> I agree (that is, I don't like option C).  I'm waffling
> between A and B.  A
> is simpler and B is "more polite".
>
> But I have a twist on option B that may make it a bit more palettable.
>
> The problem with option B is that requires extra protocol to have the
> additional bit to force the logout of the "dead" session,
> mostly because
> the initiator doesn't have the context left for the old
> session.  Suppose
> we have the target reject but in the response it puts what it
> is using for
> TSID in the usual place.  In effect, this is saying to the
> initiator "I
> already have a session in place with this ISID/TSID value".
>
> I think this gives the initiator the handle it needs to expressly do a
> logout of the old session (with a valid ISID/TSID pair) or at
> least enough
> information for the initiator to figure out what's gone
> wrong.  That is, it
> can do session recovery or whatever else is needed.  In this
> way, we don't
> need anything like a "force" bit in the login.  He has more
> steps to do,
> but they would be the same steps he would do if he just
> wanted to cleanup a
> old session he did know about.
>
> Jim Hafner
>
>






From owner-ips@ece.cmu.edu  Mon Aug 27 20:02:55 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04653
	for <ips-archive@odin.ietf.org>; Mon, 27 Aug 2001 20:02:55 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7RMlI203133
	for ips-outgoing; Mon, 27 Aug 2001 18:47:18 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7RMlGP03128
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 18:47:17 -0400 (EDT)
Received: from xparelay2.corp.hp.com (unknown [15.58.137.112])
	by palrel2.hp.com (Postfix) with ESMTP id DC4CF1B95
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 15:47:15 -0700 (PDT)
Received: from xpabh2.corp.hp.com (xpabh2.corp.hp.com [15.58.136.192])
	by xparelay2.corp.hp.com (Postfix) with ESMTP id BAAA31F547
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 15:47:15 -0700 (PDT)
Received: by xpabh2.corp.hp.com with Internet Mail Service (5.5.2653.19)
	id <RHJ5GQTR>; Mon, 27 Aug 2001 15:46:25 -0700
Message-ID: <6BD67FFB937FD411A04F00D0B74FE87802A09285@xrose06.rose.hp.com>
From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
To: ips@ece.cmu.edu
Subject: RE: iSCSI: reusing ISID for recovery
Date: Mon, 27 Aug 2001 15:46:23 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

How would the initiator log out the "dead" session?  Even if it knows a
TSID, it doesn't have any state, or any connections (assuming reboot).  Are
you suggesting the initiator perform some new sort of recovery where it
rebuilds a partial session state and "acts" like it wants to join the dead
session, for the purpose of logging it out?   Presumeably, this wouldn't
work with target implementations that only allow one connection? (see
Mallikarjun's last email) In my mind, any sort of recovery only makes sense
when there is surviving state information on both parties (I & T).  Is your
thinking different?

IMO, if option B were provided, initiator implementations would always just
turn on the "logout" bit, "just to be safe" and therefore, it would
effectively be no different than option A (just more protocol bits). 

Marj 

> -----Original Message-----
> From: Jim Hafner [mailto:hafner@almaden.ibm.com]
> Sent: Monday, August 27, 2001 2:19 PM
> To: ips@ece.cmu.edu
> Subject: RE: iSCSI: reusing ISID for recovery
> 
> 
> 
> Marj,
> 
> I agree (that is, I don't like option C).  I'm waffling 
> between A and B.  A
> is simpler and B is "more polite".
> 
> But I have a twist on option B that may make it a bit more palettable.
> 
> The problem with option B is that requires extra protocol to have the
> additional bit to force the logout of the "dead" session, 
> mostly because
> the initiator doesn't have the context left for the old 
> session.  Suppose
> we have the target reject but in the response it puts what it 
> is using for
> TSID in the usual place.  In effect, this is saying to the 
> initiator "I
> already have a session in place with this ISID/TSID value".
> 
> I think this gives the initiator the handle it needs to expressly do a
> logout of the old session (with a valid ISID/TSID pair) or at 
> least enough
> information for the initiator to figure out what's gone 
> wrong.  That is, it
> can do session recovery or whatever else is needed.  In this 
> way, we don't
> need anything like a "force" bit in the login.  He has more 
> steps to do,
> but they would be the same steps he would do if he just 
> wanted to cleanup a
> old session he did know about.
> 
> Jim Hafner
> 
> 
 


From owner-ips@ece.cmu.edu  Mon Aug 27 20:04:04 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04678
	for <ips-archive@odin.ietf.org>; Mon, 27 Aug 2001 20:03:58 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7RN5Ne07375
	for ips-outgoing; Mon, 27 Aug 2001 19:05:23 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7RN5KP07370
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 19:05:21 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id TAA49222
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 19:03:08 -0400
Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7RN5Jc199146
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 17:05:19 -0600
Importance: Normal
Subject: RE: iSCSI: reusing ISID for recovery
To: ips@ece.cmu.edu
From: "Jim Hafner" <hafner@almaden.ibm.com>
Date: Mon, 27 Aug 2001 16:05:18 -0700
Message-ID: <OFF04BCA42.67F3F877-ON88256AB5.007CD213@boulder.ibm.com>
X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at
 08/27/2001 04:05:19 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Deva,

I don't know what an initiator is going to do! If I could, I'd be a stock
broker instead :-{)!

It if doesn't want to mess around, it might just set the bit.
If it wants to perhaps find out something about its state prior to going
down (presumably because of a crash or else it would have logged out
anyway), then it won't set the bit and will get nice "oops" messages from
the target.  Then it can do what it thinks is best.

On the other hand, if the only time we expect to get into this condition
(where the initiator is doing the wrong thing because it doesn't know any
better), then option A is the better choice.  It removes the initiator from
having to make a choice of what it should do (to set or not to set?) and
forces the target to cleanup it's garbage connections (they have to be
garbage cause the initiator doesn't know about them).

But see also my other posting about an alternative to the "bit" (if that
idea actually would work).

Jim Hafner


"Dev - Platys" <deva@platys.com> on 08/27/2001 03:44:11 pm

To:   Jim Hafner/Almaden/IBM@IBMUS, <ips@ece.cmu.edu>
cc:
Subject:  RE: iSCSI: reusing ISID for recovery



Jim,
I have a question. Will the initiator during reboot would always open  a
session with this bit set. (The initiator may not even know that it has
restarted
after an earlier session abort.). Or am I missing something?

You wrote:
I see option A as a simpler mechanim that makes the "explicit" error
recovery request by the initiator an "implicit" request with no direct
detection mechanism on the initiator side.   I'd go with this choice if it
is decided that the only time we'd expect an initiator to make this request
is after a reboot or other massive reset, where it wouldn't have clue about
it's previous state.  If there are cases where we think it won't "do the
right thing" when it could, then I would say that option B as a safer
mechanism.

In short, it gets the target out of doing error recovery on behalf of the
initiator without explicit (option B) or implicit (Option A) direction.
It's not in the business of "guessing" if the initiator needs recovery.

Thanks

Deva
Platys Communications

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Jim Hafner
Sent: Monday, August 27, 2001 9:22 AM
To: ips@ece.cmu.edu
Subject: RE: iSCSI: reusing ISID for recovery



Julo,

Here's the way I look at it.  I think this is an "error detection/recovery"
issue.

With a rule that the ISID doesn't get reused by an initiator to a given
target portal group,  it's the obligation of the initiator not to do it.
If  the initiator does it anyway, then it is acting in protocol error and
it is the job of the target to enforce that rule.   If the initiator still
does it anyway, it's probably because it has "lost its way", then it is in
error state (but how does it know this?).  I prefer option B. The target
enforces the protocol rule only.  An unexpected reject is the "error
detection" mechanism for the intiator.  The "forced" login is part of the
error recovery, as driven by the initiator which is doing the error
recovery.

I see option A as a simpler mechanim that makes the "explicit" error
recovery request by the initiator an "implicit" request with no direct
detection mechanism on the initiator side.   I'd go with this choice if it
is decided that the only time we'd expect an initiator to make this request
is after a reboot or other massive reset, where it wouldn't have clue about
it's previous state.  If there are cases where we think it won't "do the
right thing" when it could, then I would say that option B as a safer
mechanism.

In short, it gets the target out of doing error recovery on behalf of the
initiator without explicit (option B) or implicit (Option A) direction.
It's not in the business of "guessing" if the initiator needs recovery.

Jim Hafner


Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 08/27/2001 07:50:09 am

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery




Jim,

It would be interesting to hear your arguments. The functions is clearly
there - only that an initiator has to perform two steps
Why is it important (except for boot) that a living initiator do it in one
step.

Regards,
Julo

Jim Hafner/Almaden/IBM@IBMUS@ece.cmu.edu on 27-08-2001 17:16:33

Please respond to Jim Hafner/Almaden/IBM@IBMUS

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery




Julo,
You wrote:
  And I would like to remind you all that we where on this exact thread
more
  tan 3 months ago (other players).
  I just restated the rationale for an (apparent) newcomer.

On the other hand, I don't recall this issue ever being called for
concensus.  Opinions were posted and nothing followed up.

I happen to agree with Marjorie.

Jim Hafner


Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 08/25/2001 12:22:33 AM

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery




It may be another OS running on the same machine or CPU complex or it could
be an attack.
In any case if the initiator is up and fine he can as well do logout.
It is a rare enough event for us not to try to optimize.

The reboot is the only case in which the initiator can't logout and about
which we care.

And I would like to remind you all that we where on this exact thread more
tan 3 months ago (other players).
I just restated the rationale for an (apparent) newcomer.

Julo

"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>@ece.cmu.edu
on 25-08-2001 03:51:43

Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"
      <marjorie_krueger@hp.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery



I don't see how Option A is prone to "wild closing of sessions".  The
target
is only looking for sessions with this particular initiator and closing
them
if the ISID matches.

If an initiator doesn't have a valid TSID (login w/TSID=0), it means it has
lost state entirely (reboot) or knows it wants to immediately reset a
session (NIC failure).  How could there possibly be a case where the
initiator has an active valid session with the same ISID, but just doesn't
know about it??  Rejecting the login seems pointless, since obviously the
initiator either has a bug or intends to quickly reset the session.

The behavior chosen (Option C) will cause the initiator's recovery to be
delayed while the target NOPs all the connections and waits for them to
time
out - this will only delay the initiators recovery unnecessarily.  I can't
help but think this will cause long term problems for the protocol.

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: marjorie_krueger@hp.com

> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Thursday, August 23, 2001 9:39 PM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI: reusing ISID for recovery (Was: RE: iSCSI
> - Change -
> Login/Text...)
>
>
>
> Mallikarjun,
>
> On  your point 1 that is what is stated today in the draft.
>
> On your point 2 option C is the one we took in the draft, after some
> debate.
>
> Option A is prone to "wild closing of sessions" and option B is also
> relaying to much on the good behaviour of the
> client. It also introduces a "feature" that complicates login/logout.
>
> Our postion on this is  that the initiator should logout the session
> explicitly if it can (and in this case it can as the target
> has ascertained
> that the session is alive).
>
> I agree that you may want to update the stayte diagram to
> reflect this.
>
> Julo
>
>
> "Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on 24-08-2001 01:46:40
>
> Please respond to cbm@rose.hp.com
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   ips@ece.cmu.edu
> cc:
> Subject:  iSCSI: reusing ISID for recovery (Was: RE: iSCSI - Change -
>       Login/Text...)
>
>
>
> Julian and all:
>
> This thread mirrors another discussion some of us are
> having in a different forum.  Following (two bullets 1
> & 2 below) is what I proposed there, attempting to address
> two issues -
>      a) how to recover sessions when target and the initiator
>            have conflicting views of the same TCP connection(s)?
>            (Initiator NIC fails, but there's no I/O activity,
>            and the target doesn't see any connection failure.)
>      b) More specifically, how to address the above problem
>            when the initiator *does not want* to re-instate failed
>            connections since it only implements the mandatory
>            session recovery?
>
> This could add clarity or muddle things up here, though hopefully
> the former...
>
> 1 If login is sent with the same ISID, same TSID, same CID and X-bit,
>   then it means a failed connection is being re-instated (whether
>   or not there are multiple connections in the session).  This login
>   attempt must be done before the connection timeout (transition M1),
>   or if this is the only connection in the session, also before the
>   session timeout (transition N6) - to be counted as a connection
>   reinstatement effort.
>            o CmdSN counters (CmdSN, ExpCmdSN) are continued.
> Initiator
>              must do command plugging when there's a mismatch
>              between its CmdSN and ExpCmdSN in the login response.
>            o Since this is an implicit connection logout, all
> the active
>              tasks on the connection are either internally terminated,
>              or made non-allegiant (based on ErrorRecoveryLevel=x/y,
>              TBD) for recovery.
>
> 2 If login is sent with the same ISID and TSID=0, the session (if it
>   exists on the target) is being cleared and any active connections
>   that the target sees must be immediately (at the end of the login
>   process including any initiator authentication) transport reset.
>   Initiator may attempt this only after it ascertains a
> session failure
>   on its end (ie. all connections entered RECOVERY_START).
>            o CmdSN counters get reset.  Initiator has to perform the
>              currently defined session recovery actions.
>            o All active tasks of the session are internally
> terminated.
>
>
> Essentially, I was proposing extending the same notion of "implicit
> logout" of a connection to the session level.  The options that I
> see are -
>
>        A) Should iSCSI let it happen by default as stated above (ie.
>           same ISID, TSID=0 always wipes out the pre-existing session
>           on target, since we are mandating it to be used only when
>           initiator sees a session failure)?
>        B) Should iSCSI mandate making this intended cleanup explicit
>           by setting a bit (Say C-bit, for Clear) in the Login Command
>           PDU to prevent an accidental session cleanup with a buggy
>           initiator code?
>        C) Should iSCSI merely state that targets must ascertain
>           the connection state(s) whenever a new session creation
>           attempt is made with a known ISID and TSID=0?  (sort of
>           defeats the intention of the initiator wanting quicker
>           session recovery since the Login command PDU would have
>           to idle till target ascertains the connection state(s)).
>
> I prefer A, or B.
>
> Going with A or B means that the description of transition N3
> in the session state diagram would have to change to:
>      Last LOGGED_IN connection had ceased to be LOGGED_IN,
>         or a Login Command requesting clearing the session (also
>         with C-bit set, if option B) was received by the target.
>
> The transition N7's description would have to be augmented as
> well to:
>         Session recovery attempt with an implicit logout,
>         or connection reinstatement/new CID addition.
>
> Comments?
> --
> Mallikarjun
>
>
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> MS 5668   Hewlett-Packard, Roseville.
> cbm@rose.hp.com
>
>
> >Stephen,
> >
> >That can happen as the target may set-up completely new TCP
> connections
> >(the old sockets are still there and look OK).
> >Untill the login is  progessing he assumes that this is just another
> >open-session attempt. Then he checks the old session and the
> session is
> >dead (initiator has closed the connections).
> >
> >The target has to distinguish only between a session that is
> alive (and
> >reject the new one) and one that its dead in which case it
> can clean-up.
> >
> >Julo
> >
> >"Wheat, Stephen R" <stephen.r.wheat@intel.com> on 23-08-2001 22:50:56
> >
> >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> >
> >To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> >cc:
> >Subject:  RE: iSCSI - Change - Login/Text commands with the
> binary stage
> co
> >          de
> >
> >
> >
> >Julian,
> >
> >I don't understand your answer.  For the scenario given, I
> would presume
> >then that the target would reject the new session attempt,
> as it sees the
> >previous session still "alive".  What is there to tell the
> target that
> this
> >is any different from when the Initiator is erroneously using the
> >repetitive
> >session id?
> >
> >Thanks,
> >Stephen
> >
> >-----Original Message-----
> >From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> >Sent: Thursday, August 23, 2001 11:15 AM
> >To: ips@ece.cmu.edu
> >Subject: Re: iSCSI - Change - Login/Text commands with the
> binary stage
> >co de
> >
> >
> >Stephen,
> >
> >1.If the initiator goes away for a while and reboots and there was no
> >activity on the connections
> >the target may see a session alive (I am not sure that it
> has to appear on
> >the state diagram but maybe).
> >
> >2.Again - I am not sure that the curent state diagram
> includes death of
> the
> >initiator
> >
> >Julo
> >
> >"Wheat, Stephen R" <stephen.r.wheat@intel.com>@ece.cmu.edu
> on 23-08-2001
> >19:58:34
> >
> >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> >
> >Sent by:  owner-ips@ece.cmu.edu
> >
> >
> >To:   ips@ece.cmu.edu
> >cc:
> >Subject:  Re: iSCSI - Change - Login/Text commands with the
> binary stage
> co
> >      de
> >
> >
> >
> >Julian,
> >
> >1.3.6 ISID states that the target should check to see if the
> old session
> is
> >still active when a duplicate session is detected.
> >
> >I have two questions, the second only if you answer in the
> affirmative on
> >the first ;^)
> >
> >1. Is there a properly executed sequence of events (i.e., no
> coding error
> >on
> >the target side) where the session is not active, but the
> target hadn't
> >taken notice of it?  It appears this as a protocol-specified
> means to work
> >around a flaw in a target's implementation.  I interpret the
> state diagram
> >transitions as being atomic wrt other commands.  I.e., the
> last logout
> >would
> >result in the various transitions of the connection/session
> prior to the
> >initiator starting the session up again.  And the target would have
> >completed the transitions prior to handling a new session request.
> >
> >2. If you answered (1) in the affirmative, then the word
> "Active" is not
> >consistent with the 6.3 Session State Diagram.  Does this
> mean the target
> >got lost, due to transport failures of any sort, in its
> transition from
> >Q3-to-Q2-to-Q1?  It sounds like the intent is to close the
> old session if
> >the session was in Q2 or Q4, presuming if it were in Q1,  it
> would not
> have
> >been found as a duplicate.
> >
> >Stephen
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
>

















From owner-ips@ece.cmu.edu  Mon Aug 27 20:04:07 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04690
	for <ips-archive@odin.ietf.org>; Mon, 27 Aug 2001 20:04:07 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7RMlXa03160
	for ips-outgoing; Mon, 27 Aug 2001 18:47:33 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from clyde.stargateip.com ([209.237.5.66])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7RMlUP03147
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 18:47:30 -0400 (EDT)
Received: from bluestar (dhcp-101.stargateip.com [10.10.5.101])
	by clyde.stargateip.com (8.9.1/8.9.1) with SMTP id PAA11688
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 15:41:42 -0700 (PDT)
Reply-To: <deva@stargateip.com>
From: "Dev" <deva@stargateip.com>
To: <ips@ece.cmu.edu>
Subject: iSCSI: CRN processing and task management
Date: Mon, 27 Aug 2001 15:52:36 -0700
Message-ID: <NFBBKBDFJCDMGCBKJLCJMEGHFDAA.deva@stargateip.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <6BD67FFB937FD411A04F00D0B74FE87802A0927F@xrose06.rose.hp.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

All,

I have a question handling CRNs. Let us say the target iSCSI device server
has commands with CRNs 8,9, 10 queued per LUN. The initiator now aborts a
command with CRN 9. Target will not be able to
execute 10, as it doesn't see the CRN 9. Is the initiator required to plug
in a command with CRN 9 or required to abort all commands and reissue the
commands with
new CRNs?

How is this scenario handled in FC?

Thanks

Deva
Platys Communications


-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
KRUEGER,MARJORIE (HP-Roseville,ex1)
Sent: Monday, August 27, 2001 1:40 PM
To: ips@ece.cmu.edu
Subject: RE: iSCSI: reusing ISID for recovery


If it is another OS, it should be a different iSCSI initiator, and hence
will have a different initiator name, so this case shouldn't be a factor.
It's not the ISID along which identifies the initiator, it's the initiator
name  + ISID.

I believe the case in which this behavior (option C) will become an issue is
in the case of initiator reboot, which will be the norm, not the exception.
IOTW, most of the cases where the target will be faced with an initiator
login w/an "in use" ISID, TSID=0 will be in the case of an initiator reboot.
That is the case we should optimize for.  I could live with Option B, but
Option A seems sufficient.

It seems the primary value of option C is to guard against malfunctioning
initiators.  As has been said many times, we cannot design a protocol to
guard against coding errors.

Marj

> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Saturday, August 25, 2001 12:23 AM
> To: ips@ece.cmu.edu
> Subject: RE: iSCSI: reusing ISID for recovery
>
>
>
> It may be another OS running on the same machine or CPU
> complex or it could
> be an attack.
> In any case if the initiator is up and fine he can as well do logout.
> It is a rare enough event for us not to try to optimize.
>
> The reboot is the only case in which the initiator can't
> logout and about
> which we care.
>
> And I would like to remind you all that we where on this
> exact thread more
> tan 3 months ago (other players).
> I just restated the rationale for an (apparent) newcomer.
>
> Julo
>
> "KRUEGER,MARJORIE (HP-Roseville,ex1)"
> <marjorie_krueger@hp.com>@ece.cmu.edu
> on 25-08-2001 03:51:43
>
> Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"
>       <marjorie_krueger@hp.com>
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   ips@ece.cmu.edu
> cc:
> Subject:  RE: iSCSI: reusing ISID for recovery
>
>
>
> I don't see how Option A is prone to "wild closing of sessions".  The
> target
> is only looking for sessions with this particular initiator
> and closing
> them
> if the ISID matches.
>
> If an initiator doesn't have a valid TSID (login w/TSID=0),
> it means it has
> lost state entirely (reboot) or knows it wants to immediately reset a
> session (NIC failure).  How could there possibly be a case where the
> initiator has an active valid session with the same ISID, but
> just doesn't
> know about it??  Rejecting the login seems pointless, since
> obviously the
> initiator either has a bug or intends to quickly reset the session.
>
> The behavior chosen (Option C) will cause the initiator's
> recovery to be
> delayed while the target NOPs all the connections and waits
> for them to
> time
> out - this will only delay the initiators recovery
> unnecessarily.  I can't
> help but think this will cause long term problems for the protocol.
>
> Marjorie Krueger
> Networked Storage Architecture
> Networked Storage Solutions Org.
> Hewlett-Packard
> tel: +1 916 785 2656
> fax: +1 916 785 0391
> email: marjorie_krueger@hp.com
>
> > -----Original Message-----
> > From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > Sent: Thursday, August 23, 2001 9:39 PM
> > To: ips@ece.cmu.edu
> > Subject: Re: iSCSI: reusing ISID for recovery (Was: RE: iSCSI
> > - Change -
> > Login/Text...)
> >
> >
> >
> > Mallikarjun,
> >
> > On  your point 1 that is what is stated today in the draft.
> >
> > On your point 2 option C is the one we took in the draft, after some
> > debate.
> >
> > Option A is prone to "wild closing of sessions" and option B is also
> > relaying to much on the good behaviour of the
> > client. It also introduces a "feature" that complicates
> login/logout.
> >
> > Our postion on this is  that the initiator should logout the session
> > explicitly if it can (and in this case it can as the target
> > has ascertained
> > that the session is alive).
> >
> > I agree that you may want to update the stayte diagram to
> > reflect this.
> >
> > Julo
> >
> >
> > "Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on
> 24-08-2001 01:46:40
> >
> > Please respond to cbm@rose.hp.com
> >
> > Sent by:  owner-ips@ece.cmu.edu
> >
> >
> > To:   ips@ece.cmu.edu
> > cc:
> > Subject:  iSCSI: reusing ISID for recovery (Was: RE: iSCSI
> - Change -
> >       Login/Text...)
> >
> >
> >
> > Julian and all:
> >
> > This thread mirrors another discussion some of us are
> > having in a different forum.  Following (two bullets 1
> > & 2 below) is what I proposed there, attempting to address
> > two issues -
> >      a) how to recover sessions when target and the initiator
> >            have conflicting views of the same TCP connection(s)?
> >            (Initiator NIC fails, but there's no I/O activity,
> >            and the target doesn't see any connection failure.)
> >      b) More specifically, how to address the above problem
> >            when the initiator *does not want* to re-instate failed
> >            connections since it only implements the mandatory
> >            session recovery?
> >
> > This could add clarity or muddle things up here, though hopefully
> > the former...
> >
> > 1 If login is sent with the same ISID, same TSID, same CID
> and X-bit,
> >   then it means a failed connection is being re-instated (whether
> >   or not there are multiple connections in the session).  This login
> >   attempt must be done before the connection timeout
> (transition M1),
> >   or if this is the only connection in the session, also before the
> >   session timeout (transition N6) - to be counted as a connection
> >   reinstatement effort.
> >            o CmdSN counters (CmdSN, ExpCmdSN) are continued.
> > Initiator
> >              must do command plugging when there's a mismatch
> >              between its CmdSN and ExpCmdSN in the login response.
> >            o Since this is an implicit connection logout, all
> > the active
> >              tasks on the connection are either internally
> terminated,
> >              or made non-allegiant (based on ErrorRecoveryLevel=x/y,
> >              TBD) for recovery.
> >
> > 2 If login is sent with the same ISID and TSID=0, the session (if it
> >   exists on the target) is being cleared and any active connections
> >   that the target sees must be immediately (at the end of the login
> >   process including any initiator authentication) transport reset.
> >   Initiator may attempt this only after it ascertains a
> > session failure
> >   on its end (ie. all connections entered RECOVERY_START).
> >            o CmdSN counters get reset.  Initiator has to perform the
> >              currently defined session recovery actions.
> >            o All active tasks of the session are internally
> > terminated.
> >
> >
> > Essentially, I was proposing extending the same notion of "implicit
> > logout" of a connection to the session level.  The options that I
> > see are -
> >
> >        A) Should iSCSI let it happen by default as stated above (ie.
> >           same ISID, TSID=0 always wipes out the
> pre-existing session
> >           on target, since we are mandating it to be used only when
> >           initiator sees a session failure)?
> >        B) Should iSCSI mandate making this intended cleanup explicit
> >           by setting a bit (Say C-bit, for Clear) in the
> Login Command
> >           PDU to prevent an accidental session cleanup with a buggy
> >           initiator code?
> >        C) Should iSCSI merely state that targets must ascertain
> >           the connection state(s) whenever a new session creation
> >           attempt is made with a known ISID and TSID=0?  (sort of
> >           defeats the intention of the initiator wanting quicker
> >           session recovery since the Login command PDU would have
> >           to idle till target ascertains the connection state(s)).
> >
> > I prefer A, or B.
> >
> > Going with A or B means that the description of transition N3
> > in the session state diagram would have to change to:
> >      Last LOGGED_IN connection had ceased to be LOGGED_IN,
> >         or a Login Command requesting clearing the session (also
> >         with C-bit set, if option B) was received by the target.
> >
> > The transition N7's description would have to be augmented as
> > well to:
> >         Session recovery attempt with an implicit logout,
> >         or connection reinstatement/new CID addition.
> >
> > Comments?
> > --
> > Mallikarjun
> >
> >
> > Mallikarjun Chadalapaka
> > Networked Storage Architecture
> > Network Storage Solutions Organization
> > MS 5668   Hewlett-Packard, Roseville.
> > cbm@rose.hp.com
> >
> >
> > >Stephen,
> > >
> > >That can happen as the target may set-up completely new TCP
> > connections
> > >(the old sockets are still there and look OK).
> > >Untill the login is  progessing he assumes that this is
> just another
> > >open-session attempt. Then he checks the old session and the
> > session is
> > >dead (initiator has closed the connections).
> > >
> > >The target has to distinguish only between a session that is
> > alive (and
> > >reject the new one) and one that its dead in which case it
> > can clean-up.
> > >
> > >Julo
> > >
> > >"Wheat, Stephen R" <stephen.r.wheat@intel.com> on
> 23-08-2001 22:50:56
> > >
> > >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> > >
> > >To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> > >cc:
> > >Subject:  RE: iSCSI - Change - Login/Text commands with the
> > binary stage
> > co
> > >          de
> > >
> > >
> > >
> > >Julian,
> > >
> > >I don't understand your answer.  For the scenario given, I
> > would presume
> > >then that the target would reject the new session attempt,
> > as it sees the
> > >previous session still "alive".  What is there to tell the
> > target that
> > this
> > >is any different from when the Initiator is erroneously using the
> > >repetitive
> > >session id?
> > >
> > >Thanks,
> > >Stephen
> > >
> > >-----Original Message-----
> > >From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > >Sent: Thursday, August 23, 2001 11:15 AM
> > >To: ips@ece.cmu.edu
> > >Subject: Re: iSCSI - Change - Login/Text commands with the
> > binary stage
> > >co de
> > >
> > >
> > >Stephen,
> > >
> > >1.If the initiator goes away for a while and reboots and
> there was no
> > >activity on the connections
> > >the target may see a session alive (I am not sure that it
> > has to appear on
> > >the state diagram but maybe).
> > >
> > >2.Again - I am not sure that the curent state diagram
> > includes death of
> > the
> > >initiator
> > >
> > >Julo
> > >
> > >"Wheat, Stephen R" <stephen.r.wheat@intel.com>@ece.cmu.edu
> > on 23-08-2001
> > >19:58:34
> > >
> > >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> > >
> > >Sent by:  owner-ips@ece.cmu.edu
> > >
> > >
> > >To:   ips@ece.cmu.edu
> > >cc:
> > >Subject:  Re: iSCSI - Change - Login/Text commands with the
> > binary stage
> > co
> > >      de
> > >
> > >
> > >
> > >Julian,
> > >
> > >1.3.6 ISID states that the target should check to see if the
> > old session
> > is
> > >still active when a duplicate session is detected.
> > >
> > >I have two questions, the second only if you answer in the
> > affirmative on
> > >the first ;^)
> > >
> > >1. Is there a properly executed sequence of events (i.e., no
> > coding error
> > >on
> > >the target side) where the session is not active, but the
> > target hadn't
> > >taken notice of it?  It appears this as a protocol-specified
> > means to work
> > >around a flaw in a target's implementation.  I interpret the
> > state diagram
> > >transitions as being atomic wrt other commands.  I.e., the
> > last logout
> > >would
> > >result in the various transitions of the connection/session
> > prior to the
> > >initiator starting the session up again.  And the target would have
> > >completed the transitions prior to handling a new session request.
> > >
> > >2. If you answered (1) in the affirmative, then the word
> > "Active" is not
> > >consistent with the 6.3 Session State Diagram.  Does this
> > mean the target
> > >got lost, due to transport failures of any sort, in its
> > transition from
> > >Q3-to-Q2-to-Q1?  It sounds like the intent is to close the
> > old session if
> > >the session was in Q2 or Q4, presuming if it were in Q1,  it
> > would not
> > have
> > >been found as a duplicate.
> > >
> > >Stephen
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
>
>
>



From owner-ips@ece.cmu.edu  Mon Aug 27 21:06:37 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05597
	for <ips-archive@odin.ietf.org>; Mon, 27 Aug 2001 21:06:34 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7RNLdP08355
	for ips-outgoing; Mon, 27 Aug 2001 19:21:39 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail07b.vwh1.net (mail07b.vwh1.net [209.238.9.59])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f7RMdJP02623
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 18:39:19 -0400 (EDT)
Received: from www.platys.com (208.55.89.7)
	by mail07b.vwh1.net (RS ver 1.0.60s) with SMTP id 02709393;
	Mon, 27 Aug 2001 18:39:02 -0400 (EDT)
From: "Dev - Platys" <deva@platys.com>
To: "Jim Hafner" <hafner@almaden.ibm.com>, <ips@ece.cmu.edu>
Subject: RE: iSCSI: reusing ISID for recovery
Date: Mon, 27 Aug 2001 15:44:11 -0700
Message-ID: <NFBBKBDFJCDMGCBKJLCJCEGHFDAA.deva@platys.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <OF75DCCA86.8458ED2C-ON88256AB5.0059D5F1@boulder.ibm.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
X-Loop-Detect: 1
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Jim,
I have a question. Will the initiator during reboot would always open  a
session with this bit set. (The initiator may not even know that it has
restarted
after an earlier session abort.). Or am I missing something?

You wrote:
I see option A as a simpler mechanim that makes the "explicit" error
recovery request by the initiator an "implicit" request with no direct
detection mechanism on the initiator side.   I'd go with this choice if it
is decided that the only time we'd expect an initiator to make this request
is after a reboot or other massive reset, where it wouldn't have clue about
it's previous state.  If there are cases where we think it won't "do the
right thing" when it could, then I would say that option B as a safer
mechanism.

In short, it gets the target out of doing error recovery on behalf of the
initiator without explicit (option B) or implicit (Option A) direction.
It's not in the business of "guessing" if the initiator needs recovery.

Thanks

Deva
Platys Communications

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Jim Hafner
Sent: Monday, August 27, 2001 9:22 AM
To: ips@ece.cmu.edu
Subject: RE: iSCSI: reusing ISID for recovery



Julo,

Here's the way I look at it.  I think this is an "error detection/recovery"
issue.

With a rule that the ISID doesn't get reused by an initiator to a given
target portal group,  it's the obligation of the initiator not to do it.
If  the initiator does it anyway, then it is acting in protocol error and
it is the job of the target to enforce that rule.   If the initiator still
does it anyway, it's probably because it has "lost its way", then it is in
error state (but how does it know this?).  I prefer option B. The target
enforces the protocol rule only.  An unexpected reject is the "error
detection" mechanism for the intiator.  The "forced" login is part of the
error recovery, as driven by the initiator which is doing the error
recovery.

I see option A as a simpler mechanim that makes the "explicit" error
recovery request by the initiator an "implicit" request with no direct
detection mechanism on the initiator side.   I'd go with this choice if it
is decided that the only time we'd expect an initiator to make this request
is after a reboot or other massive reset, where it wouldn't have clue about
it's previous state.  If there are cases where we think it won't "do the
right thing" when it could, then I would say that option B as a safer
mechanism.

In short, it gets the target out of doing error recovery on behalf of the
initiator without explicit (option B) or implicit (Option A) direction.
It's not in the business of "guessing" if the initiator needs recovery.

Jim Hafner


Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 08/27/2001 07:50:09 am

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery




Jim,

It would be interesting to hear your arguments. The functions is clearly
there - only that an initiator has to perform two steps
Why is it important (except for boot) that a living initiator do it in one
step.

Regards,
Julo

Jim Hafner/Almaden/IBM@IBMUS@ece.cmu.edu on 27-08-2001 17:16:33

Please respond to Jim Hafner/Almaden/IBM@IBMUS

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery




Julo,
You wrote:
  And I would like to remind you all that we where on this exact thread
more
  tan 3 months ago (other players).
  I just restated the rationale for an (apparent) newcomer.

On the other hand, I don't recall this issue ever being called for
concensus.  Opinions were posted and nothing followed up.

I happen to agree with Marjorie.

Jim Hafner


Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 08/25/2001 12:22:33 AM

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery




It may be another OS running on the same machine or CPU complex or it could
be an attack.
In any case if the initiator is up and fine he can as well do logout.
It is a rare enough event for us not to try to optimize.

The reboot is the only case in which the initiator can't logout and about
which we care.

And I would like to remind you all that we where on this exact thread more
tan 3 months ago (other players).
I just restated the rationale for an (apparent) newcomer.

Julo

"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>@ece.cmu.edu
on 25-08-2001 03:51:43

Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"
      <marjorie_krueger@hp.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery



I don't see how Option A is prone to "wild closing of sessions".  The
target
is only looking for sessions with this particular initiator and closing
them
if the ISID matches.

If an initiator doesn't have a valid TSID (login w/TSID=0), it means it has
lost state entirely (reboot) or knows it wants to immediately reset a
session (NIC failure).  How could there possibly be a case where the
initiator has an active valid session with the same ISID, but just doesn't
know about it??  Rejecting the login seems pointless, since obviously the
initiator either has a bug or intends to quickly reset the session.

The behavior chosen (Option C) will cause the initiator's recovery to be
delayed while the target NOPs all the connections and waits for them to
time
out - this will only delay the initiators recovery unnecessarily.  I can't
help but think this will cause long term problems for the protocol.

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: marjorie_krueger@hp.com

> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Thursday, August 23, 2001 9:39 PM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI: reusing ISID for recovery (Was: RE: iSCSI
> - Change -
> Login/Text...)
>
>
>
> Mallikarjun,
>
> On  your point 1 that is what is stated today in the draft.
>
> On your point 2 option C is the one we took in the draft, after some
> debate.
>
> Option A is prone to "wild closing of sessions" and option B is also
> relaying to much on the good behaviour of the
> client. It also introduces a "feature" that complicates login/logout.
>
> Our postion on this is  that the initiator should logout the session
> explicitly if it can (and in this case it can as the target
> has ascertained
> that the session is alive).
>
> I agree that you may want to update the stayte diagram to
> reflect this.
>
> Julo
>
>
> "Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on 24-08-2001 01:46:40
>
> Please respond to cbm@rose.hp.com
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   ips@ece.cmu.edu
> cc:
> Subject:  iSCSI: reusing ISID for recovery (Was: RE: iSCSI - Change -
>       Login/Text...)
>
>
>
> Julian and all:
>
> This thread mirrors another discussion some of us are
> having in a different forum.  Following (two bullets 1
> & 2 below) is what I proposed there, attempting to address
> two issues -
>      a) how to recover sessions when target and the initiator
>            have conflicting views of the same TCP connection(s)?
>            (Initiator NIC fails, but there's no I/O activity,
>            and the target doesn't see any connection failure.)
>      b) More specifically, how to address the above problem
>            when the initiator *does not want* to re-instate failed
>            connections since it only implements the mandatory
>            session recovery?
>
> This could add clarity or muddle things up here, though hopefully
> the former...
>
> 1 If login is sent with the same ISID, same TSID, same CID and X-bit,
>   then it means a failed connection is being re-instated (whether
>   or not there are multiple connections in the session).  This login
>   attempt must be done before the connection timeout (transition M1),
>   or if this is the only connection in the session, also before the
>   session timeout (transition N6) - to be counted as a connection
>   reinstatement effort.
>            o CmdSN counters (CmdSN, ExpCmdSN) are continued.
> Initiator
>              must do command plugging when there's a mismatch
>              between its CmdSN and ExpCmdSN in the login response.
>            o Since this is an implicit connection logout, all
> the active
>              tasks on the connection are either internally terminated,
>              or made non-allegiant (based on ErrorRecoveryLevel=x/y,
>              TBD) for recovery.
>
> 2 If login is sent with the same ISID and TSID=0, the session (if it
>   exists on the target) is being cleared and any active connections
>   that the target sees must be immediately (at the end of the login
>   process including any initiator authentication) transport reset.
>   Initiator may attempt this only after it ascertains a
> session failure
>   on its end (ie. all connections entered RECOVERY_START).
>            o CmdSN counters get reset.  Initiator has to perform the
>              currently defined session recovery actions.
>            o All active tasks of the session are internally
> terminated.
>
>
> Essentially, I was proposing extending the same notion of "implicit
> logout" of a connection to the session level.  The options that I
> see are -
>
>        A) Should iSCSI let it happen by default as stated above (ie.
>           same ISID, TSID=0 always wipes out the pre-existing session
>           on target, since we are mandating it to be used only when
>           initiator sees a session failure)?
>        B) Should iSCSI mandate making this intended cleanup explicit
>           by setting a bit (Say C-bit, for Clear) in the Login Command
>           PDU to prevent an accidental session cleanup with a buggy
>           initiator code?
>        C) Should iSCSI merely state that targets must ascertain
>           the connection state(s) whenever a new session creation
>           attempt is made with a known ISID and TSID=0?  (sort of
>           defeats the intention of the initiator wanting quicker
>           session recovery since the Login command PDU would have
>           to idle till target ascertains the connection state(s)).
>
> I prefer A, or B.
>
> Going with A or B means that the description of transition N3
> in the session state diagram would have to change to:
>      Last LOGGED_IN connection had ceased to be LOGGED_IN,
>         or a Login Command requesting clearing the session (also
>         with C-bit set, if option B) was received by the target.
>
> The transition N7's description would have to be augmented as
> well to:
>         Session recovery attempt with an implicit logout,
>         or connection reinstatement/new CID addition.
>
> Comments?
> --
> Mallikarjun
>
>
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> MS 5668   Hewlett-Packard, Roseville.
> cbm@rose.hp.com
>
>
> >Stephen,
> >
> >That can happen as the target may set-up completely new TCP
> connections
> >(the old sockets are still there and look OK).
> >Untill the login is  progessing he assumes that this is just another
> >open-session attempt. Then he checks the old session and the
> session is
> >dead (initiator has closed the connections).
> >
> >The target has to distinguish only between a session that is
> alive (and
> >reject the new one) and one that its dead in which case it
> can clean-up.
> >
> >Julo
> >
> >"Wheat, Stephen R" <stephen.r.wheat@intel.com> on 23-08-2001 22:50:56
> >
> >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> >
> >To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> >cc:
> >Subject:  RE: iSCSI - Change - Login/Text commands with the
> binary stage
> co
> >          de
> >
> >
> >
> >Julian,
> >
> >I don't understand your answer.  For the scenario given, I
> would presume
> >then that the target would reject the new session attempt,
> as it sees the
> >previous session still "alive".  What is there to tell the
> target that
> this
> >is any different from when the Initiator is erroneously using the
> >repetitive
> >session id?
> >
> >Thanks,
> >Stephen
> >
> >-----Original Message-----
> >From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> >Sent: Thursday, August 23, 2001 11:15 AM
> >To: ips@ece.cmu.edu
> >Subject: Re: iSCSI - Change - Login/Text commands with the
> binary stage
> >co de
> >
> >
> >Stephen,
> >
> >1.If the initiator goes away for a while and reboots and there was no
> >activity on the connections
> >the target may see a session alive (I am not sure that it
> has to appear on
> >the state diagram but maybe).
> >
> >2.Again - I am not sure that the curent state diagram
> includes death of
> the
> >initiator
> >
> >Julo
> >
> >"Wheat, Stephen R" <stephen.r.wheat@intel.com>@ece.cmu.edu
> on 23-08-2001
> >19:58:34
> >
> >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> >
> >Sent by:  owner-ips@ece.cmu.edu
> >
> >
> >To:   ips@ece.cmu.edu
> >cc:
> >Subject:  Re: iSCSI - Change - Login/Text commands with the
> binary stage
> co
> >      de
> >
> >
> >
> >Julian,
> >
> >1.3.6 ISID states that the target should check to see if the
> old session
> is
> >still active when a duplicate session is detected.
> >
> >I have two questions, the second only if you answer in the
> affirmative on
> >the first ;^)
> >
> >1. Is there a properly executed sequence of events (i.e., no
> coding error
> >on
> >the target side) where the session is not active, but the
> target hadn't
> >taken notice of it?  It appears this as a protocol-specified
> means to work
> >around a flaw in a target's implementation.  I interpret the
> state diagram
> >transitions as being atomic wrt other commands.  I.e., the
> last logout
> >would
> >result in the various transitions of the connection/session
> prior to the
> >initiator starting the session up again.  And the target would have
> >completed the transitions prior to handling a new session request.
> >
> >2. If you answered (1) in the affirmative, then the word
> "Active" is not
> >consistent with the 6.3 Session State Diagram.  Does this
> mean the target
> >got lost, due to transport failures of any sort, in its
> transition from
> >Q3-to-Q2-to-Q1?  It sounds like the intent is to close the
> old session if
> >the session was in Q2 or Q4, presuming if it were in Q1,  it
> would not
> have
> >been found as a duplicate.
> >
> >Stephen
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
>













From owner-ips@ece.cmu.edu  Mon Aug 27 22:15:46 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07534
	for <ips-archive@odin.ietf.org>; Mon, 27 Aug 2001 22:15:45 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7S0e9712230
	for ips-outgoing; Mon, 27 Aug 2001 20:40:09 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from clyde.stargateip.com ([209.237.5.66])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7S0e6P12225
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 20:40:07 -0400 (EDT)
Received: from bluestar (dhcp-101.stargateip.com [10.10.5.101])
	by clyde.stargateip.com (8.9.1/8.9.1) with SMTP id RAA12942;
	Mon, 27 Aug 2001 17:34:18 -0700 (PDT)
Reply-To: <deva@stargateip.com>
From: "Dev" <deva@stargateip.com>
To: "KRUEGER,MARJORIE \(HP-Roseville,ex1\)" <marjorie_krueger@hp.com>,
        <ips@ece.cmu.edu>
Subject: RE: iSCSI: reusing ISID for recovery
Date: Mon, 27 Aug 2001 17:45:12 -0700
Message-ID: <NFBBKBDFJCDMGCBKJLCJCEGMFDAA.deva@stargateip.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <6BD67FFB937FD411A04F00D0B74FE87802A09285@xrose06.rose.hp.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Marj,

You wrote:
IMO, if option B were provided, initiator implementations would always just
turn on the "logout" bit, "just to be safe" and therefore, it would
effectively be no different than option A (just more protocol bits). 

I concur with this.


Thanks

Deva
Platys Communications



> -----Original Message-----
> From: Jim Hafner [mailto:hafner@almaden.ibm.com]
> Sent: Monday, August 27, 2001 2:19 PM
> To: ips@ece.cmu.edu
> Subject: RE: iSCSI: reusing ISID for recovery
> 
> 
> 
> Marj,
> 
> I agree (that is, I don't like option C).  I'm waffling 
> between A and B.  A
> is simpler and B is "more polite".
> 
> But I have a twist on option B that may make it a bit more palettable.
> 
> The problem with option B is that requires extra protocol to have the
> additional bit to force the logout of the "dead" session, 
> mostly because
> the initiator doesn't have the context left for the old 
> session.  Suppose
> we have the target reject but in the response it puts what it 
> is using for
> TSID in the usual place.  In effect, this is saying to the 
> initiator "I
> already have a session in place with this ISID/TSID value".
> 
> I think this gives the initiator the handle it needs to expressly do a
> logout of the old session (with a valid ISID/TSID pair) or at 
> least enough
> information for the initiator to figure out what's gone 
> wrong.  That is, it
> can do session recovery or whatever else is needed.  In this 
> way, we don't
> need anything like a "force" bit in the login.  He has more 
> steps to do,
> but they would be the same steps he would do if he just 
> wanted to cleanup a
> old session he did know about.
> 
> Jim Hafner
> 
> 
 


From owner-ips@ece.cmu.edu  Mon Aug 27 22:47:24 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09127
	for <ips-archive@odin.ietf.org>; Mon, 27 Aug 2001 22:47:23 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7S0jhr12501
	for ips-outgoing; Mon, 27 Aug 2001 20:45:43 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from clyde.stargateip.com ([209.237.5.66])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7S0jeP12496
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 20:45:41 -0400 (EDT)
Received: from bluestar (dhcp-101.stargateip.com [10.10.5.101])
	by clyde.stargateip.com (8.9.1/8.9.1) with SMTP id RAA13017;
	Mon, 27 Aug 2001 17:39:48 -0700 (PDT)
Reply-To: <deva@stargateip.com>
From: "Dev" <deva@stargateip.com>
To: "Jim Hafner" <hafner@almaden.ibm.com>, <ips@ece.cmu.edu>
Subject: RE: iSCSI: reusing ISID for recovery
Date: Mon, 27 Aug 2001 17:50:42 -0700
Message-ID: <NFBBKBDFJCDMGCBKJLCJMEGMFDAA.deva@stargateip.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <OFF04BCA42.67F3F877-ON88256AB5.007CD213@boulder.ibm.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Jim,

Good to know that you are leaning towards Option-A to see from your other
posting. I agree with you that Option-A will be the cleanest and simplest.

The reason I mentioned that initiator by choosing a forced logout,
by setting a bit, will always end up using the bit when a new
session is created as it would have lost all state of a previous
session.

Thanks

Deva
Platys communications

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Jim Hafner
Sent: Monday, August 27, 2001 4:05 PM
To: ips@ece.cmu.edu
Subject: RE: iSCSI: reusing ISID for recovery



Deva,

I don't know what an initiator is going to do! If I could, I'd be a stock
broker instead :-{)!

It if doesn't want to mess around, it might just set the bit.
If it wants to perhaps find out something about its state prior to going
down (presumably because of a crash or else it would have logged out
anyway), then it won't set the bit and will get nice "oops" messages from
the target.  Then it can do what it thinks is best.

On the other hand, if the only time we expect to get into this condition
(where the initiator is doing the wrong thing because it doesn't know any
better), then option A is the better choice.  It removes the initiator from
having to make a choice of what it should do (to set or not to set?) and
forces the target to cleanup it's garbage connections (they have to be
garbage cause the initiator doesn't know about them).

But see also my other posting about an alternative to the "bit" (if that
idea actually would work).

Jim Hafner


"Dev - Platys" <deva@platys.com> on 08/27/2001 03:44:11 pm

To:   Jim Hafner/Almaden/IBM@IBMUS, <ips@ece.cmu.edu>
cc:
Subject:  RE: iSCSI: reusing ISID for recovery



Jim,
I have a question. Will the initiator during reboot would always open  a
session with this bit set. (The initiator may not even know that it has
restarted
after an earlier session abort.). Or am I missing something?

You wrote:
I see option A as a simpler mechanim that makes the "explicit" error
recovery request by the initiator an "implicit" request with no direct
detection mechanism on the initiator side.   I'd go with this choice if it
is decided that the only time we'd expect an initiator to make this request
is after a reboot or other massive reset, where it wouldn't have clue about
it's previous state.  If there are cases where we think it won't "do the
right thing" when it could, then I would say that option B as a safer
mechanism.

In short, it gets the target out of doing error recovery on behalf of the
initiator without explicit (option B) or implicit (Option A) direction.
It's not in the business of "guessing" if the initiator needs recovery.

Thanks

Deva
Platys Communications

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Jim Hafner
Sent: Monday, August 27, 2001 9:22 AM
To: ips@ece.cmu.edu
Subject: RE: iSCSI: reusing ISID for recovery



Julo,

Here's the way I look at it.  I think this is an "error detection/recovery"
issue.

With a rule that the ISID doesn't get reused by an initiator to a given
target portal group,  it's the obligation of the initiator not to do it.
If  the initiator does it anyway, then it is acting in protocol error and
it is the job of the target to enforce that rule.   If the initiator still
does it anyway, it's probably because it has "lost its way", then it is in
error state (but how does it know this?).  I prefer option B. The target
enforces the protocol rule only.  An unexpected reject is the "error
detection" mechanism for the intiator.  The "forced" login is part of the
error recovery, as driven by the initiator which is doing the error
recovery.

I see option A as a simpler mechanim that makes the "explicit" error
recovery request by the initiator an "implicit" request with no direct
detection mechanism on the initiator side.   I'd go with this choice if it
is decided that the only time we'd expect an initiator to make this request
is after a reboot or other massive reset, where it wouldn't have clue about
it's previous state.  If there are cases where we think it won't "do the
right thing" when it could, then I would say that option B as a safer
mechanism.

In short, it gets the target out of doing error recovery on behalf of the
initiator without explicit (option B) or implicit (Option A) direction.
It's not in the business of "guessing" if the initiator needs recovery.

Jim Hafner


Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 08/27/2001 07:50:09 am

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery




Jim,

It would be interesting to hear your arguments. The functions is clearly
there - only that an initiator has to perform two steps
Why is it important (except for boot) that a living initiator do it in one
step.

Regards,
Julo

Jim Hafner/Almaden/IBM@IBMUS@ece.cmu.edu on 27-08-2001 17:16:33

Please respond to Jim Hafner/Almaden/IBM@IBMUS

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery




Julo,
You wrote:
  And I would like to remind you all that we where on this exact thread
more
  tan 3 months ago (other players).
  I just restated the rationale for an (apparent) newcomer.

On the other hand, I don't recall this issue ever being called for
concensus.  Opinions were posted and nothing followed up.

I happen to agree with Marjorie.

Jim Hafner


Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 08/25/2001 12:22:33 AM

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery




It may be another OS running on the same machine or CPU complex or it could
be an attack.
In any case if the initiator is up and fine he can as well do logout.
It is a rare enough event for us not to try to optimize.

The reboot is the only case in which the initiator can't logout and about
which we care.

And I would like to remind you all that we where on this exact thread more
tan 3 months ago (other players).
I just restated the rationale for an (apparent) newcomer.

Julo

"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>@ece.cmu.edu
on 25-08-2001 03:51:43

Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"
      <marjorie_krueger@hp.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery



I don't see how Option A is prone to "wild closing of sessions".  The
target
is only looking for sessions with this particular initiator and closing
them
if the ISID matches.

If an initiator doesn't have a valid TSID (login w/TSID=0), it means it has
lost state entirely (reboot) or knows it wants to immediately reset a
session (NIC failure).  How could there possibly be a case where the
initiator has an active valid session with the same ISID, but just doesn't
know about it??  Rejecting the login seems pointless, since obviously the
initiator either has a bug or intends to quickly reset the session.

The behavior chosen (Option C) will cause the initiator's recovery to be
delayed while the target NOPs all the connections and waits for them to
time
out - this will only delay the initiators recovery unnecessarily.  I can't
help but think this will cause long term problems for the protocol.

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: marjorie_krueger@hp.com

> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Thursday, August 23, 2001 9:39 PM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI: reusing ISID for recovery (Was: RE: iSCSI
> - Change -
> Login/Text...)
>
>
>
> Mallikarjun,
>
> On  your point 1 that is what is stated today in the draft.
>
> On your point 2 option C is the one we took in the draft, after some
> debate.
>
> Option A is prone to "wild closing of sessions" and option B is also
> relaying to much on the good behaviour of the
> client. It also introduces a "feature" that complicates login/logout.
>
> Our postion on this is  that the initiator should logout the session
> explicitly if it can (and in this case it can as the target
> has ascertained
> that the session is alive).
>
> I agree that you may want to update the stayte diagram to
> reflect this.
>
> Julo
>
>
> "Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on 24-08-2001 01:46:40
>
> Please respond to cbm@rose.hp.com
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   ips@ece.cmu.edu
> cc:
> Subject:  iSCSI: reusing ISID for recovery (Was: RE: iSCSI - Change -
>       Login/Text...)
>
>
>
> Julian and all:
>
> This thread mirrors another discussion some of us are
> having in a different forum.  Following (two bullets 1
> & 2 below) is what I proposed there, attempting to address
> two issues -
>      a) how to recover sessions when target and the initiator
>            have conflicting views of the same TCP connection(s)?
>            (Initiator NIC fails, but there's no I/O activity,
>            and the target doesn't see any connection failure.)
>      b) More specifically, how to address the above problem
>            when the initiator *does not want* to re-instate failed
>            connections since it only implements the mandatory
>            session recovery?
>
> This could add clarity or muddle things up here, though hopefully
> the former...
>
> 1 If login is sent with the same ISID, same TSID, same CID and X-bit,
>   then it means a failed connection is being re-instated (whether
>   or not there are multiple connections in the session).  This login
>   attempt must be done before the connection timeout (transition M1),
>   or if this is the only connection in the session, also before the
>   session timeout (transition N6) - to be counted as a connection
>   reinstatement effort.
>            o CmdSN counters (CmdSN, ExpCmdSN) are continued.
> Initiator
>              must do command plugging when there's a mismatch
>              between its CmdSN and ExpCmdSN in the login response.
>            o Since this is an implicit connection logout, all
> the active
>              tasks on the connection are either internally terminated,
>              or made non-allegiant (based on ErrorRecoveryLevel=x/y,
>              TBD) for recovery.
>
> 2 If login is sent with the same ISID and TSID=0, the session (if it
>   exists on the target) is being cleared and any active connections
>   that the target sees must be immediately (at the end of the login
>   process including any initiator authentication) transport reset.
>   Initiator may attempt this only after it ascertains a
> session failure
>   on its end (ie. all connections entered RECOVERY_START).
>            o CmdSN counters get reset.  Initiator has to perform the
>              currently defined session recovery actions.
>            o All active tasks of the session are internally
> terminated.
>
>
> Essentially, I was proposing extending the same notion of "implicit
> logout" of a connection to the session level.  The options that I
> see are -
>
>        A) Should iSCSI let it happen by default as stated above (ie.
>           same ISID, TSID=0 always wipes out the pre-existing session
>           on target, since we are mandating it to be used only when
>           initiator sees a session failure)?
>        B) Should iSCSI mandate making this intended cleanup explicit
>           by setting a bit (Say C-bit, for Clear) in the Login Command
>           PDU to prevent an accidental session cleanup with a buggy
>           initiator code?
>        C) Should iSCSI merely state that targets must ascertain
>           the connection state(s) whenever a new session creation
>           attempt is made with a known ISID and TSID=0?  (sort of
>           defeats the intention of the initiator wanting quicker
>           session recovery since the Login command PDU would have
>           to idle till target ascertains the connection state(s)).
>
> I prefer A, or B.
>
> Going with A or B means that the description of transition N3
> in the session state diagram would have to change to:
>      Last LOGGED_IN connection had ceased to be LOGGED_IN,
>         or a Login Command requesting clearing the session (also
>         with C-bit set, if option B) was received by the target.
>
> The transition N7's description would have to be augmented as
> well to:
>         Session recovery attempt with an implicit logout,
>         or connection reinstatement/new CID addition.
>
> Comments?
> --
> Mallikarjun
>
>
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> MS 5668   Hewlett-Packard, Roseville.
> cbm@rose.hp.com
>
>
> >Stephen,
> >
> >That can happen as the target may set-up completely new TCP
> connections
> >(the old sockets are still there and look OK).
> >Untill the login is  progessing he assumes that this is just another
> >open-session attempt. Then he checks the old session and the
> session is
> >dead (initiator has closed the connections).
> >
> >The target has to distinguish only between a session that is
> alive (and
> >reject the new one) and one that its dead in which case it
> can clean-up.
> >
> >Julo
> >
> >"Wheat, Stephen R" <stephen.r.wheat@intel.com> on 23-08-2001 22:50:56
> >
> >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> >
> >To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> >cc:
> >Subject:  RE: iSCSI - Change - Login/Text commands with the
> binary stage
> co
> >          de
> >
> >
> >
> >Julian,
> >
> >I don't understand your answer.  For the scenario given, I
> would presume
> >then that the target would reject the new session attempt,
> as it sees the
> >previous session still "alive".  What is there to tell the
> target that
> this
> >is any different from when the Initiator is erroneously using the
> >repetitive
> >session id?
> >
> >Thanks,
> >Stephen
> >
> >-----Original Message-----
> >From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> >Sent: Thursday, August 23, 2001 11:15 AM
> >To: ips@ece.cmu.edu
> >Subject: Re: iSCSI - Change - Login/Text commands with the
> binary stage
> >co de
> >
> >
> >Stephen,
> >
> >1.If the initiator goes away for a while and reboots and there was no
> >activity on the connections
> >the target may see a session alive (I am not sure that it
> has to appear on
> >the state diagram but maybe).
> >
> >2.Again - I am not sure that the curent state diagram
> includes death of
> the
> >initiator
> >
> >Julo
> >
> >"Wheat, Stephen R" <stephen.r.wheat@intel.com>@ece.cmu.edu
> on 23-08-2001
> >19:58:34
> >
> >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> >
> >Sent by:  owner-ips@ece.cmu.edu
> >
> >
> >To:   ips@ece.cmu.edu
> >cc:
> >Subject:  Re: iSCSI - Change - Login/Text commands with the
> binary stage
> co
> >      de
> >
> >
> >
> >Julian,
> >
> >1.3.6 ISID states that the target should check to see if the
> old session
> is
> >still active when a duplicate session is detected.
> >
> >I have two questions, the second only if you answer in the
> affirmative on
> >the first ;^)
> >
> >1. Is there a properly executed sequence of events (i.e., no
> coding error
> >on
> >the target side) where the session is not active, but the
> target hadn't
> >taken notice of it?  It appears this as a protocol-specified
> means to work
> >around a flaw in a target's implementation.  I interpret the
> state diagram
> >transitions as being atomic wrt other commands.  I.e., the
> last logout
> >would
> >result in the various transitions of the connection/session
> prior to the
> >initiator starting the session up again.  And the target would have
> >completed the transitions prior to handling a new session request.
> >
> >2. If you answered (1) in the affirmative, then the word
> "Active" is not
> >consistent with the 6.3 Session State Diagram.  Does this
> mean the target
> >got lost, due to transport failures of any sort, in its
> transition from
> >Q3-to-Q2-to-Q1?  It sounds like the intent is to close the
> old session if
> >the session was in Q2 or Q4, presuming if it were in Q1,  it
> would not
> have
> >been found as a duplicate.
> >
> >Stephen
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
>

















From owner-ips@ece.cmu.edu  Mon Aug 27 23:32:15 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09962
	for <ips-archive@odin.ietf.org>; Mon, 27 Aug 2001 23:32:14 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7S1hrC15122
	for ips-outgoing; Mon, 27 Aug 2001 21:43:53 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7S1hqP15116
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 21:43:52 -0400 (EDT)
Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100])
	by palrel1.hp.com (Postfix) with ESMTP id 41A061AE7
	for <ips@ece.cmu.edu>; Mon, 27 Aug 2001 18:43:51 -0700 (PDT)
Received: (from cbm@localhost) by core.rose.hp.com (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id SAA12342 for ips@ece.cmu.edu; Mon, 27 Aug 2001 18:45:09 -0700 (PDT)
Message-Id: <200108280145.SAA12342@core.rose.hp.com>
Subject: RE: iSCSI: reusing ISID for recovery
To: ips@ece.cmu.edu
Date: Mon, 27 Aug 2001 18:45:08 PDT
Reply-To: cbm@rose.hp.com
From: "Mallikarjun C." <cbm@rose.hp.com>
X-Mailer: Elm [revision: 212.4]
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Jim,

I am glad you're leaning towards A.  I believe that's the only
option that makes most sense.

>if there is one connection and the
>host looses it, what does it do now for recovery?)

Here's an excerpt from my first email with this subject heading -

---->
   1 If login is sent with the same ISID, same TSID, same CID and X-bit,
     then it means a failed connection is being re-instated (whether
     or not there are multiple connections in the session).  This login
     attempt must be done before the connection timeout (transition M1),
     or if this is the only connection in the session, also before the
     session timeout (transition N6) - to be counted as a connection
     reinstatement effort.
<----

There are two sub-cases under one-connection-per-session targets -
   case-a: Target supports connection reinstatement for the same CID
           (ie. within-session recovery supported).
   case-b: Target doesn't support connection replacement, mandatory
           session recovery is the only supported form of recovery.

The above excerpt from my first email only addresses case-a (it is 
defined in the rev07 draft).

As I said in my last posting (can't quote a URL since the mail
archive appears broken), I was attempting to find a decent solution
for case-b (not to mention the rebooting-host-after-a-crash scenario), 
and I believe option A is the best for it (though option A can be 
used whenever one/all connections reach the RECOVERY_START state on 
the initiator, or initiator doesn't have an active session at all).

Regards.
--
Mallikarjun 


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


>Marj,
>
>All of your questions point out the lack of completeness in my thinking
>(which is why I said "I think this gives...").
>
>I guess I was thinking that the initiator could act like it wants to join a
>new connection to the existing session, so that it can logout that session.
>You're right that this is a problem for 1-connection-per-session targets,
>but don't we have that problem anyway (if there is one connection and the
>host looses it, what does it do now for recovery?)
>
>As I said, I'm starting to lean a bit more toward A.  It's the cleanest and
>simplest.
>
>Jim Hafner
>
>
>"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>@ece.cmu.edu
>on 08/27/2001 03:46:23 pm
>
>Sent by:  owner-ips@ece.cmu.edu
>
>
>To:   ips@ece.cmu.edu
>cc:
>Subject:  RE: iSCSI: reusing ISID for recovery
>
>
>
>How would the initiator log out the "dead" session?  Even if it knows a
>TSID, it doesn't have any state, or any connections (assuming reboot).  Are
>you suggesting the initiator perform some new sort of recovery where it
>rebuilds a partial session state and "acts" like it wants to join the dead
>session, for the purpose of logging it out?   Presumeably, this wouldn't
>work with target implementations that only allow one connection? (see
>Mallikarjun's last email) In my mind, any sort of recovery only makes sense
>when there is surviving state information on both parties (I & T).  Is your
>thinking different?
>
>IMO, if option B were provided, initiator implementations would always just
>turn on the "logout" bit, "just to be safe" and therefore, it would
>effectively be no different than option A (just more protocol bits).
>
>Marj
>
>> -----Original Message-----
>> From: Jim Hafner [mailto:hafner@almaden.ibm.com]
>> Sent: Monday, August 27, 2001 2:19 PM
>> To: ips@ece.cmu.edu
>> Subject: RE: iSCSI: reusing ISID for recovery
>>
>>
>>
>> Marj,
>>
>> I agree (that is, I don't like option C).  I'm waffling
>> between A and B.  A
>> is simpler and B is "more polite".
>>
>> But I have a twist on option B that may make it a bit more palettable.
>>
>> The problem with option B is that requires extra protocol to have the
>> additional bit to force the logout of the "dead" session,
>> mostly because
>> the initiator doesn't have the context left for the old
>> session.  Suppose
>> we have the target reject but in the response it puts what it
>> is using for
>> TSID in the usual place.  In effect, this is saying to the
>> initiator "I
>> already have a session in place with this ISID/TSID value".
>>
>> I think this gives the initiator the handle it needs to expressly do a
>> logout of the old session (with a valid ISID/TSID pair) or at
>> least enough
>> information for the initiator to figure out what's gone
>> wrong.  That is, it
>> can do session recovery or whatever else is needed.  In this
>> way, we don't
>> need anything like a "force" bit in the login.  He has more
>> steps to do,
>> but they would be the same steps he would do if he just
>> wanted to cleanup a
>> old session he did know about.
>>
>> Jim Hafner
>>
>>
>
>
>
>
>




From owner-ips@ece.cmu.edu  Tue Aug 28 02:07:53 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26675
	for <ips-archive@odin.ietf.org>; Tue, 28 Aug 2001 02:07:53 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7S4doJ25865
	for ips-outgoing; Tue, 28 Aug 2001 00:39:50 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7S4dlP25861
	for <ips@ece.cmu.edu>; Tue, 28 Aug 2001 00:39:48 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id GAA10074
	for <ips@ece.cmu.edu>; Tue, 28 Aug 2001 06:39:40 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7S4ddg166758
	for <ips@ece.cmu.edu>; Tue, 28 Aug 2001 06:39:39 +0200
Importance: Normal
Subject: RE: iSCSI: reusing ISID for recovery
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF1FE2860E.104C8D43-ONC2256AB6.001805FE@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Tue, 28 Aug 2001 07:39:03 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 28/08/2001 07:39:38
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Marjorie, Jim, Mallikarjun, Deva & all

Let's attemp to close that optimization that is so dear to your hearts.
If we go for the following scheme (very close to B):

The initiator knows "that he lost his way" (in the initiator jungle tough)
and issues a Login + ISID + TSID=0 + X bit on (meaning
" I think I have an old session - please clean it up for me" and open a new
one) then the target may do one of the following:

- before going to the effort of authenticating the new initiator check if a
session exist (if he has the initiator name) or go to authentication if it
does not
- If he has a session then clean it and create a new one
- If he does not have a session - we have 3 options:
a)- tell him hid did not have an old session and drop him
b)- tell him he did not have an old session but nevertheless create a new
one
c)- create a new session and do not tell him

With option a we are close to the old option c but the initiator does not
have to find the old session he can do now safely a new login
With b & c  we are back at the old b.

Which one would you give your kingdom for ( and my peace!).

Julo

"Dev" <deva@stargateip.com>@ece.cmu.edu on 28-08-2001 01:44:15

Please respond to <deva@stargateip.com>

Sent by:  owner-ips@ece.cmu.edu


To:   "KRUEGER,MARJORIE \(HP-Roseville,ex1\)" <marjorie_krueger@hp.com>,
      <ips@ece.cmu.edu>
cc:
Subject:  RE: iSCSI: reusing ISID for recovery



All,

When a session is already running authenticated, a login request with the
same
ISID + initiator fails authentication. Will the session continue to run?
Or
if the target fails during parameter negotiation?

I guess, yes. i.e. target will not act on the existing session, until
the login completes successfully. Or are there exception to these?

Thanks

Deva
Platys Communications





> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Saturday, August 25, 2001 12:23 AM
> To: ips@ece.cmu.edu
> Subject: RE: iSCSI: reusing ISID for recovery
>
>
>
> It may be another OS running on the same machine or CPU
> complex or it could
> be an attack.
> In any case if the initiator is up and fine he can as well do logout.
> It is a rare enough event for us not to try to optimize.
>
> The reboot is the only case in which the initiator can't
> logout and about
> which we care.
>
> And I would like to remind you all that we where on this
> exact thread more
> tan 3 months ago (other players).
> I just restated the rationale for an (apparent) newcomer.
>
> Julo
>
> "KRUEGER,MARJORIE (HP-Roseville,ex1)"
> <marjorie_krueger@hp.com>@ece.cmu.edu
> on 25-08-2001 03:51:43
>
> Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"
>       <marjorie_krueger@hp.com>
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   ips@ece.cmu.edu
> cc:
> Subject:  RE: iSCSI: reusing ISID for recovery
>
>
>
> I don't see how Option A is prone to "wild closing of sessions".  The
> target
> is only looking for sessions with this particular initiator
> and closing
> them
> if the ISID matches.
>
> If an initiator doesn't have a valid TSID (login w/TSID=0),
> it means it has
> lost state entirely (reboot) or knows it wants to immediately reset a
> session (NIC failure).  How could there possibly be a case where the
> initiator has an active valid session with the same ISID, but
> just doesn't
> know about it??  Rejecting the login seems pointless, since
> obviously the
> initiator either has a bug or intends to quickly reset the session.
>
> The behavior chosen (Option C) will cause the initiator's
> recovery to be
> delayed while the target NOPs all the connections and waits
> for them to
> time
> out - this will only delay the initiators recovery
> unnecessarily.  I can't
> help but think this will cause long term problems for the protocol.
>
> Marjorie Krueger
> Networked Storage Architecture
> Networked Storage Solutions Org.
> Hewlett-Packard
> tel: +1 916 785 2656
> fax: +1 916 785 0391
> email: marjorie_krueger@hp.com
>
> > -----Original Message-----
> > From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > Sent: Thursday, August 23, 2001 9:39 PM
> > To: ips@ece.cmu.edu
> > Subject: Re: iSCSI: reusing ISID for recovery (Was: RE: iSCSI
> > - Change -
> > Login/Text...)
> >
> >
> >
> > Mallikarjun,
> >
> > On  your point 1 that is what is stated today in the draft.
> >
> > On your point 2 option C is the one we took in the draft, after some
> > debate.
> >
> > Option A is prone to "wild closing of sessions" and option B is also
> > relaying to much on the good behaviour of the
> > client. It also introduces a "feature" that complicates
> login/logout.
> >
> > Our postion on this is  that the initiator should logout the session
> > explicitly if it can (and in this case it can as the target
> > has ascertained
> > that the session is alive).
> >
> > I agree that you may want to update the stayte diagram to
> > reflect this.
> >
> > Julo
> >
> >
> > "Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on
> 24-08-2001 01:46:40
> >
> > Please respond to cbm@rose.hp.com
> >
> > Sent by:  owner-ips@ece.cmu.edu
> >
> >
> > To:   ips@ece.cmu.edu
> > cc:
> > Subject:  iSCSI: reusing ISID for recovery (Was: RE: iSCSI
> - Change -
> >       Login/Text...)
> >
> >
> >
> > Julian and all:
> >
> > This thread mirrors another discussion some of us are
> > having in a different forum.  Following (two bullets 1
> > & 2 below) is what I proposed there, attempting to address
> > two issues -
> >      a) how to recover sessions when target and the initiator
> >            have conflicting views of the same TCP connection(s)?
> >            (Initiator NIC fails, but there's no I/O activity,
> >            and the target doesn't see any connection failure.)
> >      b) More specifically, how to address the above problem
> >            when the initiator *does not want* to re-instate failed
> >            connections since it only implements the mandatory
> >            session recovery?
> >
> > This could add clarity or muddle things up here, though hopefully
> > the former...
> >
> > 1 If login is sent with the same ISID, same TSID, same CID
> and X-bit,
> >   then it means a failed connection is being re-instated (whether
> >   or not there are multiple connections in the session).  This login
> >   attempt must be done before the connection timeout
> (transition M1),
> >   or if this is the only connection in the session, also before the
> >   session timeout (transition N6) - to be counted as a connection
> >   reinstatement effort.
> >            o CmdSN counters (CmdSN, ExpCmdSN) are continued.
> > Initiator
> >              must do command plugging when there's a mismatch
> >              between its CmdSN and ExpCmdSN in the login response.
> >            o Since this is an implicit connection logout, all
> > the active
> >              tasks on the connection are either internally
> terminated,
> >              or made non-allegiant (based on ErrorRecoveryLevel=x/y,
> >              TBD) for recovery.
> >
> > 2 If login is sent with the same ISID and TSID=0, the session (if it
> >   exists on the target) is being cleared and any active connections
> >   that the target sees must be immediately (at the end of the login
> >   process including any initiator authentication) transport reset.
> >   Initiator may attempt this only after it ascertains a
> > session failure
> >   on its end (ie. all connections entered RECOVERY_START).
> >            o CmdSN counters get reset.  Initiator has to perform the
> >              currently defined session recovery actions.
> >            o All active tasks of the session are internally
> > terminated.
> >
> >
> > Essentially, I was proposing extending the same notion of "implicit
> > logout" of a connection to the session level.  The options that I
> > see are -
> >
> >        A) Should iSCSI let it happen by default as stated above (ie.
> >           same ISID, TSID=0 always wipes out the
> pre-existing session
> >           on target, since we are mandating it to be used only when
> >           initiator sees a session failure)?
> >        B) Should iSCSI mandate making this intended cleanup explicit
> >           by setting a bit (Say C-bit, for Clear) in the
> Login Command
> >           PDU to prevent an accidental session cleanup with a buggy
> >           initiator code?
> >        C) Should iSCSI merely state that targets must ascertain
> >           the connection state(s) whenever a new session creation
> >           attempt is made with a known ISID and TSID=0?  (sort of
> >           defeats the intention of the initiator wanting quicker
> >           session recovery since the Login command PDU would have
> >           to idle till target ascertains the connection state(s)).
> >
> > I prefer A, or B.
> >
> > Going with A or B means that the description of transition N3
> > in the session state diagram would have to change to:
> >      Last LOGGED_IN connection had ceased to be LOGGED_IN,
> >         or a Login Command requesting clearing the session (also
> >         with C-bit set, if option B) was received by the target.
> >
> > The transition N7's description would have to be augmented as
> > well to:
> >         Session recovery attempt with an implicit logout,
> >         or connection reinstatement/new CID addition.
> >
> > Comments?
> > --
> > Mallikarjun
> >
> >
> > Mallikarjun Chadalapaka
> > Networked Storage Architecture
> > Network Storage Solutions Organization
> > MS 5668   Hewlett-Packard, Roseville.
> > cbm@rose.hp.com
> >
> >
> > >Stephen,
> > >
> > >That can happen as the target may set-up completely new TCP
> > connections
> > >(the old sockets are still there and look OK).
> > >Untill the login is  progessing he assumes that this is
> just another
> > >open-session attempt. Then he checks the old session and the
> > session is
> > >dead (initiator has closed the connections).
> > >
> > >The target has to distinguish only between a session that is
> > alive (and
> > >reject the new one) and one that its dead in which case it
> > can clean-up.
> > >
> > >Julo
> > >
> > >"Wheat, Stephen R" <stephen.r.wheat@intel.com> on
> 23-08-2001 22:50:56
> > >
> > >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> > >
> > >To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> > >cc:
> > >Subject:  RE: iSCSI - Change - Login/Text commands with the
> > binary stage
> > co
> > >          de
> > >
> > >
> > >
> > >Julian,
> > >
> > >I don't understand your answer.  For the scenario given, I
> > would presume
> > >then that the target would reject the new session attempt,
> > as it sees the
> > >previous session still "alive".  What is there to tell the
> > target that
> > this
> > >is any different from when the Initiator is erroneously using the
> > >repetitive
> > >session id?
> > >
> > >Thanks,
> > >Stephen
> > >
> > >-----Original Message-----
> > >From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > >Sent: Thursday, August 23, 2001 11:15 AM
> > >To: ips@ece.cmu.edu
> > >Subject: Re: iSCSI - Change - Login/Text commands with the
> > binary stage
> > >co de
> > >
> > >
> > >Stephen,
> > >
> > >1.If the initiator goes away for a while and reboots and
> there was no
> > >activity on the connections
> > >the target may see a session alive (I am not sure that it
> > has to appear on
> > >the state diagram but maybe).
> > >
> > >2.Again - I am not sure that the curent state diagram
> > includes death of
> > the
> > >initiator
> > >
> > >Julo
> > >
> > >"Wheat, Stephen R" <stephen.r.wheat@intel.com>@ece.cmu.edu
> > on 23-08-2001
> > >19:58:34
> > >
> > >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> > >
> > >Sent by:  owner-ips@ece.cmu.edu
> > >
> > >
> > >To:   ips@ece.cmu.edu
> > >cc:
> > >Subject:  Re: iSCSI - Change - Login/Text commands with the
> > binary stage
> > co
> > >      de
> > >
> > >
> > >
> > >Julian,
> > >
> > >1.3.6 ISID states that the target should check to see if the
> > old session
> > is
> > >still active when a duplicate session is detected.
> > >
> > >I have two questions, the second only if you answer in the
> > affirmative on
> > >the first ;^)
> > >
> > >1. Is there a properly executed sequence of events (i.e., no
> > coding error
> > >on
> > >the target side) where the session is not active, but the
> > target hadn't
> > >taken notice of it?  It appears this as a protocol-specified
> > means to work
> > >around a flaw in a target's implementation.  I interpret the
> > state diagram
> > >transitions as being atomic wrt other commands.  I.e., the
> > last logout
> > >would
> > >result in the various transitions of the connection/session
> > prior to the
> > >initiator starting the session up again.  And the target would have
> > >completed the transitions prior to handling a new session request.
> > >
> > >2. If you answered (1) in the affirmative, then the word
> > "Active" is not
> > >consistent with the 6.3 Session State Diagram.  Does this
> > mean the target
> > >got lost, due to transport failures of any sort, in its
> > transition from
> > >Q3-to-Q2-to-Q1?  It sounds like the intent is to close the
> > old session if
> > >the session was in Q2 or Q4, presuming if it were in Q1,  it
> > would not
> > have
> > >been found as a duplicate.
> > >
> > >Stephen
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
>
>
>






From owner-ips@ece.cmu.edu  Tue Aug 28 05:02:56 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00090
	for <ips-archive@odin.ietf.org>; Tue, 28 Aug 2001 05:02:55 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7S7oZk03078
	for ips-outgoing; Tue, 28 Aug 2001 03:50:35 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7S7oUP03073
	for <ips@ece.cmu.edu>; Tue, 28 Aug 2001 03:50:31 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id JAA31494
	for <ips@ece.cmu.edu>; Tue, 28 Aug 2001 09:50:20 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7S7n1d128078
	for <ips@ece.cmu.edu>; Tue, 28 Aug 2001 09:49:01 +0200
Importance: Normal
Subject: Re: iSCSI: draft 7: remove S bit and Status field from the Data-i
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF17C32591.4A8D3C0C-ONC2256AB6.002A3CA4@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Tue, 28 Aug 2001 10:48:25 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 28/08/2001 10:49:01
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Sandeep,

About the mechanical setup - I was perhaps unclear but the issue is that
getting the commands earlier helps.

If you send c1,c2,c3... data 1, data2 ...

c2 will get its command and start its mechanical setup earlier than in:

c1 data1, c2 data2...

I was not conerned about buffers but about letting command through as early
as possible when it makes sense.
My design rule of thumb was "don't impose scheduling restrictions if you
don't have to".

The TAGs for NOP-IN was mainly to enable tags to be generated independently
in independent units.
My assumption was that together with the LUNs they will give targets enough
room for "uniqueness".

Julo

Sandeep Joshi <sandeepj@research.bell-labs.com>@ece.cmu.edu on 27-08-2001
22:47:51

Please respond to Sandeep Joshi <sandeepj@research.bell-labs.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  Re: iSCSI: draft 7: remove S bit and Status field from the Data-i




Julian,

Wouldn't mechanical setup could go in parallel with network data
reception anyways?  A target which has advertised a certain command
window must also have reserved memory for the corresponding
unsolicited bursts.

So I guess I am still unconvinced..but can workaround if there
aren't other supporters for the new ordering.

Btw, this "mechanical setup" rationale as well as the LUN tags in
NOP-in (stated purpose: can be used to route NOP-ins to LUNs)
seem to assume some model of an iSCSI storage target (JBOD/RAID),
which is  perhaps external to what's in SAM-2.
Just guessing, not sure. If there is some model, do share it with
us since it may help see the design rationales.

Regards,
-Sandeep

Julian Satran wrote:
>
> Sandeep,
>
> It is not difficult but can be counterproductive.
> Lets assume that you have in the pipe 7 commands for 7 LUs (that can
> effectively execute in parallel) and all of them require
> some mechanical setup before they can effectively handle data.
> The rules in force today will allow the initiator to send out the
commands
> (and let the mechanical setup start) and send the data afterwards (in the
> same order the commands where set).
>
> The alternative will force order (without necessarily buying us anything)
> and disable the above optimization.
>
> In the spec we set rules so that deadlocks will not occur (keep the same
> order as commands) but left room for optimization.
>
> Julo
>
> Sandeep Joshi <sandeepj@research.bell-labs.com>@research.bell-labs.com on
> 27-08-2001 18:07:10
>
> Please respond to Sandeep Joshi <sandeepj@research.bell-labs.com>
>
> Sent by:  sandeepj@research.bell-labs.com
>
> To:   Julian Satran/Haifa/IBM@IBMIL
> cc:   ips@ece.cmu.edu
> Subject:  Re: iSCSI: draft 7: remove S bit and Status field from the
Data-i
>
> Julian,
>
> I am probably missing something here..especially
> now that you refer to multiplexing.
>
> The rule would be per-connection - why it is difficult
> for the initiator to send the unsolicited data _right_
> after the command ?  The data is already available from
> the ULP.
>
> If this new rule is not added, the target needs
> to route unsolicited PDUs based on ITT (..a foreign tag)
> Its not a checking burden but a performance gain.
>
> The only other cases which requires ITT routing at the
> target are abort-task, D-SNACK and command-retry, all
> of which we can assume to be infrequent and not in the
> performance path.
>
> -Sandeep
>
> P.S. Let me throw in some casuistry...this is also why
> dog owners are made to follow dogs, so one doesnt need
> to look at dog tags :-)
>
> Julian Satran wrote:
> >
> > I am sure we don't want to enter this. The sequencing rules are there
to
> > asure:
> >
> >    that there is no deadlock (order of data must follow the order of
> >    commands)
> >    that the target command buffer does not overflow (MaxCmdSN) - this
> will
> >    eliminate an "unlimited number of immediate"
> >
> > Any additional rules will interfere with performance, multiplexing
policy
> > etc. and I see no great
> > value in enforcing them (and enforcing means checking and that means
> > expense).
> >
> > Julo
> >
> > Sandeep Joshi <sandeepj@research.bell-labs.com>@ece.cmu.edu on
26-08-2001
> > 00:11:39
> >
> > Please respond to Sandeep Joshi <sandeepj@research.bell-labs.com>
> >
> > Sent by:  owner-ips@ece.cmu.edu
> >
> > To:   Dave Sheehy <dbs@acropora.rose.agilent.com>
> > cc:   IETF IP SAN Reflector <ips@ece.cmu.edu>
> > Subject:  Re: iSCSI: draft 7: remove S bit and Status field from the
> Data-i
> >
> > Julian,
> >
> > I wonder if Dave's last paragraph in this email has been considered.
> > Here it is again..
> >
> > > This does help some. It eliminates the situation where a target can
> > receive
> > > an essentially unlimited number of immediate data commands prior to
> > receiving
> > > *any* data PDUs.
> >
> > in reference to Section 1.2.5
> > > Unsolicited data MUST be sent on
> > > every connection in the same order in which commands were sent.
> >
> > The draft currently allows
> >    c-1,c-2,c-3, (SEP-1-1),(SEP-1-2),(SEP-2-1,SEP-2-2),..
> > where c-N = command {N}
> > and   SEP-N-M = unsolicited (non-immediate) PDU number {M} for command
> > {N}
> >
> > It would be simplify target login (ITT lookup) if we only permitted
> > this sequence.
> >    c-1, SEP-1-1, SEP-1-2, c-2, SEP-2-1, SEP-2-2,..
> >
> > -Sandeep
> >
> > Dave Sheehy wrote:
> > >
> > > David,
> > >
> > > > I think you've taken a wrong turn.
> > >
> > > I think John hit the nail on the head.
> > >
> > > > > Second, thoughts of removing the immediate data seem not to be
> > > > > simplification, since all the information to tie the data to the
> > command
> > > > is
> > > > > right there with the command.  That has got to be easier than
> > matching up
> > > > > separate PDUs of data with the appropriate commands.
> > > >
> > > > Actually, that was the point, since the logic for "matching up
> separate
> > > > PDUs of data with the appropriate commands" has to exist for
inbound
> > > > Data PDUs already.
> > >
> > > Except that there is a target context present in the solicited case
to
> > route
> > > the data. That doesn't exist in the unsolicited case.
> > >
> > > > The slide I presented in London was about replacing
> > > > immediate data with an unsolicited data PDU immediately following
the
> > > > command, thus removing the immediate data case in favor of reusing
> the
> > > > logic for dealing with separate Data PDUs.  Remember that this was
> > presented
> > > > as a simplification possibility.
> > >
> > > This does help some. It eliminates the situation where a target can
> > receive
> > > an essentially unlimited number of immediate data commands prior to
> > receiving
> > > *any* data PDUs.
> > >
> > > But, do you mean to say that *one* unsolicited data PDU would follow
> the
> > > command? Wouldn't that be unnecessarily restrictive if the PDU size
is
> > small?
> > > Simply guaranteeing that the data PDUs will immediately follow the
> > command
> > > seems like an adequate improvement.
> > >
> > > Dave Sheehy





From owner-ips@ece.cmu.edu  Tue Aug 28 12:54:23 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15756
	for <ips-archive@odin.ietf.org>; Tue, 28 Aug 2001 12:54:23 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7SFsix07199
	for ips-outgoing; Tue, 28 Aug 2001 11:54:44 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from clyde.stargateip.com ([209.237.5.66])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7SFsbP07191
	for <ips@ece.cmu.edu>; Tue, 28 Aug 2001 11:54:37 -0400 (EDT)
Received: from bluestar (dhcp-101.stargateip.com [10.10.5.101])
	by clyde.stargateip.com (8.9.1/8.9.1) with SMTP id IAA18846;
	Tue, 28 Aug 2001 08:45:06 -0700 (PDT)
Reply-To: <deva@stargateip.com>
From: "Dev" <deva@stargateip.com>
To: "Julian Satran" <Julian_Satran@il.ibm.com>, <ips@ece.cmu.edu>
Subject: RE: iSCSI: reusing ISID for recovery
Date: Tue, 28 Aug 2001 08:56:06 -0700
Message-ID: <NFBBKBDFJCDMGCBKJLCJAEGPFDAA.deva@stargateip.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
In-Reply-To: <OF1FE2860E.104C8D43-ONC2256AB6.001805FE@telaviv.ibm.com>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Julian,

>The initiator knows "that he lost his way" (in the initiator jungle tough)
>and issues a Login + ISID + TSID=0 + X bit on (meaning
>" I think I have an old session - please clean it up for me" and open a new
>one) then the target may do one of the following:

>- before going to the effort of authenticating the new initiator check if a
>session exist (if he has the initiator name) or go to authentication if it
>does not

Are you saying that authentication is not required when a login request
with ISID + TSID= 0 + X bit is set? Or will it result in a valid session
close when a forced access to the target is attempted by a hacker?
What exactly if some hacker issues to the target with retry bit set and
gains access?  I
thought authentication will protect the existing session from a 'me too'
hacking identifications? Am I missing something here?

>- If he does not have a session - we have 3 options:
>a)- tell him hid did not have an old session and drop him
>b)- tell him he did not have an old session but nevertheless create a new
>one
>c)- create a new session and do not tell him

Does your proposal (i.e. with 'X' bit set) take care of the case , when
the initiator reboots (probably after a crash) while a session is still
active in the session? How is that taken care of?


Thanks

Deva
Platys communications

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Julian Satran
Sent: Monday, August 27, 2001 9:39 PM
To: ips@ece.cmu.edu
Subject: RE: iSCSI: reusing ISID for recovery



Marjorie, Jim, Mallikarjun, Deva & all

Let's attemp to close that optimization that is so dear to your hearts.
If we go for the following scheme (very close to B):

The initiator knows "that he lost his way" (in the initiator jungle tough)
and issues a Login + ISID + TSID=0 + X bit on (meaning
" I think I have an old session - please clean it up for me" and open a new
one) then the target may do one of the following:

- before going to the effort of authenticating the new initiator check if a
session exist (if he has the initiator name) or go to authentication if it
does not
- If he has a session then clean it and create a new one
- If he does not have a session - we have 3 options:
a)- tell him hid did not have an old session and drop him
b)- tell him he did not have an old session but nevertheless create a new
one
c)- create a new session and do not tell him

With option a we are close to the old option c but the initiator does not
have to find the old session he can do now safely a new login
With b & c  we are back at the old b.

Which one would you give your kingdom for ( and my peace!).

Julo

"Dev" <deva@stargateip.com>@ece.cmu.edu on 28-08-2001 01:44:15

Please respond to <deva@stargateip.com>

Sent by:  owner-ips@ece.cmu.edu


To:   "KRUEGER,MARJORIE \(HP-Roseville,ex1\)" <marjorie_krueger@hp.com>,
      <ips@ece.cmu.edu>
cc:
Subject:  RE: iSCSI: reusing ISID for recovery



All,

When a session is already running authenticated, a login request with the
same
ISID + initiator fails authentication. Will the session continue to run?
Or
if the target fails during parameter negotiation?

I guess, yes. i.e. target will not act on the existing session, until
the login completes successfully. Or are there exception to these?

Thanks

Deva
Platys Communications





> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Saturday, August 25, 2001 12:23 AM
> To: ips@ece.cmu.edu
> Subject: RE: iSCSI: reusing ISID for recovery
>
>
>
> It may be another OS running on the same machine or CPU
> complex or it could
> be an attack.
> In any case if the initiator is up and fine he can as well do logout.
> It is a rare enough event for us not to try to optimize.
>
> The reboot is the only case in which the initiator can't
> logout and about
> which we care.
>
> And I would like to remind you all that we where on this
> exact thread more
> tan 3 months ago (other players).
> I just restated the rationale for an (apparent) newcomer.
>
> Julo
>
> "KRUEGER,MARJORIE (HP-Roseville,ex1)"
> <marjorie_krueger@hp.com>@ece.cmu.edu
> on 25-08-2001 03:51:43
>
> Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"
>       <marjorie_krueger@hp.com>
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   ips@ece.cmu.edu
> cc:
> Subject:  RE: iSCSI: reusing ISID for recovery
>
>
>
> I don't see how Option A is prone to "wild closing of sessions".  The
> target
> is only looking for sessions with this particular initiator
> and closing
> them
> if the ISID matches.
>
> If an initiator doesn't have a valid TSID (login w/TSID=0),
> it means it has
> lost state entirely (reboot) or knows it wants to immediately reset a
> session (NIC failure).  How could there possibly be a case where the
> initiator has an active valid session with the same ISID, but
> just doesn't
> know about it??  Rejecting the login seems pointless, since
> obviously the
> initiator either has a bug or intends to quickly reset the session.
>
> The behavior chosen (Option C) will cause the initiator's
> recovery to be
> delayed while the target NOPs all the connections and waits
> for them to
> time
> out - this will only delay the initiators recovery
> unnecessarily.  I can't
> help but think this will cause long term problems for the protocol.
>
> Marjorie Krueger
> Networked Storage Architecture
> Networked Storage Solutions Org.
> Hewlett-Packard
> tel: +1 916 785 2656
> fax: +1 916 785 0391
> email: marjorie_krueger@hp.com
>
> > -----Original Message-----
> > From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > Sent: Thursday, August 23, 2001 9:39 PM
> > To: ips@ece.cmu.edu
> > Subject: Re: iSCSI: reusing ISID for recovery (Was: RE: iSCSI
> > - Change -
> > Login/Text...)
> >
> >
> >
> > Mallikarjun,
> >
> > On  your point 1 that is what is stated today in the draft.
> >
> > On your point 2 option C is the one we took in the draft, after some
> > debate.
> >
> > Option A is prone to "wild closing of sessions" and option B is also
> > relaying to much on the good behaviour of the
> > client. It also introduces a "feature" that complicates
> login/logout.
> >
> > Our postion on this is  that the initiator should logout the session
> > explicitly if it can (and in this case it can as the target
> > has ascertained
> > that the session is alive).
> >
> > I agree that you may want to update the stayte diagram to
> > reflect this.
> >
> > Julo
> >
> >
> > "Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on
> 24-08-2001 01:46:40
> >
> > Please respond to cbm@rose.hp.com
> >
> > Sent by:  owner-ips@ece.cmu.edu
> >
> >
> > To:   ips@ece.cmu.edu
> > cc:
> > Subject:  iSCSI: reusing ISID for recovery (Was: RE: iSCSI
> - Change -
> >       Login/Text...)
> >
> >
> >
> > Julian and all:
> >
> > This thread mirrors another discussion some of us are
> > having in a different forum.  Following (two bullets 1
> > & 2 below) is what I proposed there, attempting to address
> > two issues -
> >      a) how to recover sessions when target and the initiator
> >            have conflicting views of the same TCP connection(s)?
> >            (Initiator NIC fails, but there's no I/O activity,
> >            and the target doesn't see any connection failure.)
> >      b) More specifically, how to address the above problem
> >            when the initiator *does not want* to re-instate failed
> >            connections since it only implements the mandatory
> >            session recovery?
> >
> > This could add clarity or muddle things up here, though hopefully
> > the former...
> >
> > 1 If login is sent with the same ISID, same TSID, same CID
> and X-bit,
> >   then it means a failed connection is being re-instated (whether
> >   or not there are multiple connections in the session).  This login
> >   attempt must be done before the connection timeout
> (transition M1),
> >   or if this is the only connection in the session, also before the
> >   session timeout (transition N6) - to be counted as a connection
> >   reinstatement effort.
> >            o CmdSN counters (CmdSN, ExpCmdSN) are continued.
> > Initiator
> >              must do command plugging when there's a mismatch
> >              between its CmdSN and ExpCmdSN in the login response.
> >            o Since this is an implicit connection logout, all
> > the active
> >              tasks on the connection are either internally
> terminated,
> >              or made non-allegiant (based on ErrorRecoveryLevel=x/y,
> >              TBD) for recovery.
> >
> > 2 If login is sent with the same ISID and TSID=0, the session (if it
> >   exists on the target) is being cleared and any active connections
> >   that the target sees must be immediately (at the end of the login
> >   process including any initiator authentication) transport reset.
> >   Initiator may attempt this only after it ascertains a
> > session failure
> >   on its end (ie. all connections entered RECOVERY_START).
> >            o CmdSN counters get reset.  Initiator has to perform the
> >              currently defined session recovery actions.
> >            o All active tasks of the session are internally
> > terminated.
> >
> >
> > Essentially, I was proposing extending the same notion of "implicit
> > logout" of a connection to the session level.  The options that I
> > see are -
> >
> >        A) Should iSCSI let it happen by default as stated above (ie.
> >           same ISID, TSID=0 always wipes out the
> pre-existing session
> >           on target, since we are mandating it to be used only when
> >           initiator sees a session failure)?
> >        B) Should iSCSI mandate making this intended cleanup explicit
> >           by setting a bit (Say C-bit, for Clear) in the
> Login Command
> >           PDU to prevent an accidental session cleanup with a buggy
> >           initiator code?
> >        C) Should iSCSI merely state that targets must ascertain
> >           the connection state(s) whenever a new session creation
> >           attempt is made with a known ISID and TSID=0?  (sort of
> >           defeats the intention of the initiator wanting quicker
> >           session recovery since the Login command PDU would have
> >           to idle till target ascertains the connection state(s)).
> >
> > I prefer A, or B.
> >
> > Going with A or B means that the description of transition N3
> > in the session state diagram would have to change to:
> >      Last LOGGED_IN connection had ceased to be LOGGED_IN,
> >         or a Login Command requesting clearing the session (also
> >         with C-bit set, if option B) was received by the target.
> >
> > The transition N7's description would have to be augmented as
> > well to:
> >         Session recovery attempt with an implicit logout,
> >         or connection reinstatement/new CID addition.
> >
> > Comments?
> > --
> > Mallikarjun
> >
> >
> > Mallikarjun Chadalapaka
> > Networked Storage Architecture
> > Network Storage Solutions Organization
> > MS 5668   Hewlett-Packard, Roseville.
> > cbm@rose.hp.com
> >
> >
> > >Stephen,
> > >
> > >That can happen as the target may set-up completely new TCP
> > connections
> > >(the old sockets are still there and look OK).
> > >Untill the login is  progessing he assumes that this is
> just another
> > >open-session attempt. Then he checks the old session and the
> > session is
> > >dead (initiator has closed the connections).
> > >
> > >The target has to distinguish only between a session that is
> > alive (and
> > >reject the new one) and one that its dead in which case it
> > can clean-up.
> > >
> > >Julo
> > >
> > >"Wheat, Stephen R" <stephen.r.wheat@intel.com> on
> 23-08-2001 22:50:56
> > >
> > >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> > >
> > >To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> > >cc:
> > >Subject:  RE: iSCSI - Change - Login/Text commands with the
> > binary stage
> > co
> > >          de
> > >
> > >
> > >
> > >Julian,
> > >
> > >I don't understand your answer.  For the scenario given, I
> > would presume
> > >then that the target would reject the new session attempt,
> > as it sees the
> > >previous session still "alive".  What is there to tell the
> > target that
> > this
> > >is any different from when the Initiator is erroneously using the
> > >repetitive
> > >session id?
> > >
> > >Thanks,
> > >Stephen
> > >
> > >-----Original Message-----
> > >From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > >Sent: Thursday, August 23, 2001 11:15 AM
> > >To: ips@ece.cmu.edu
> > >Subject: Re: iSCSI - Change - Login/Text commands with the
> > binary stage
> > >co de
> > >
> > >
> > >Stephen,
> > >
> > >1.If the initiator goes away for a while and reboots and
> there was no
> > >activity on the connections
> > >the target may see a session alive (I am not sure that it
> > has to appear on
> > >the state diagram but maybe).
> > >
> > >2.Again - I am not sure that the curent state diagram
> > includes death of
> > the
> > >initiator
> > >
> > >Julo
> > >
> > >"Wheat, Stephen R" <stephen.r.wheat@intel.com>@ece.cmu.edu
> > on 23-08-2001
> > >19:58:34
> > >
> > >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> > >
> > >Sent by:  owner-ips@ece.cmu.edu
> > >
> > >
> > >To:   ips@ece.cmu.edu
> > >cc:
> > >Subject:  Re: iSCSI - Change - Login/Text commands with the
> > binary stage
> > co
> > >      de
> > >
> > >
> > >
> > >Julian,
> > >
> > >1.3.6 ISID states that the target should check to see if the
> > old session
> > is
> > >still active when a duplicate session is detected.
> > >
> > >I have two questions, the second only if you answer in the
> > affirmative on
> > >the first ;^)
> > >
> > >1. Is there a properly executed sequence of events (i.e., no
> > coding error
> > >on
> > >the target side) where the session is not active, but the
> > target hadn't
> > >taken notice of it?  It appears this as a protocol-specified
> > means to work
> > >around a flaw in a target's implementation.  I interpret the
> > state diagram
> > >transitions as being atomic wrt other commands.  I.e., the
> > last logout
> > >would
> > >result in the various transitions of the connection/session
> > prior to the
> > >initiator starting the session up again.  And the target would have
> > >completed the transitions prior to handling a new session request.
> > >
> > >2. If you answered (1) in the affirmative, then the word
> > "Active" is not
> > >consistent with the 6.3 Session State Diagram.  Does this
> > mean the target
> > >got lost, due to transport failures of any sort, in its
> > transition from
> > >Q3-to-Q2-to-Q1?  It sounds like the intent is to close the
> > old session if
> > >the session was in Q2 or Q4, presuming if it were in Q1,  it
> > would not
> > have
> > >been found as a duplicate.
> > >
> > >Stephen
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
>
>
>






From owner-ips@ece.cmu.edu  Tue Aug 28 12:58:09 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15851
	for <ips-archive@odin.ietf.org>; Tue, 28 Aug 2001 12:58:07 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7SFJfL04859
	for ips-outgoing; Tue, 28 Aug 2001 11:19:41 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from sansrv1.san-rad.co.il ([212.199.104.226])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7SFJFP04841
	for <ips@ece.cmu.edu>; Tue, 28 Aug 2001 11:19:21 -0400 (EDT)
content-class: urn:content-classes:message
Subject: RE: ISCSI: A propos  MIB and specially iSCSI MIB
Date: Tue, 28 Aug 2001 18:20:19 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Message-ID: <838D8D2617300146B7F47E4D9AE7FF101149EB@SANSRV1.SAN-RAD.CO.IL>
Disposition-Notification-To: "Michele Hallak - Stamler" <michele@SANRAD.COM>
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
Thread-Topic: ISCSI: A propos  MIB and specially iSCSI MIB
Thread-Index: AcEvCFG8di1kGI4lR0egtnk/Y+zDpQACCSIAAAAPvZA=
From: "Michele Hallak - Stamler" <michele@sanrad.com>
To: <mbakke@cisco.com>
Cc: <ips@ece.cmu.edu>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f7SFJSP04846
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit

Mark,
Thanks a lot for your prompt answer...
My comments are prefixed by MHS.
Thanks again,
	Michele

> -----Original Message-----
> From: Mark Bakke [mailto:mbakke@cisco.com]
> Sent: Monday, August 27, 2001 3:47 PM
> To: Michele Hallak - Stamler
> Cc: ips@ece.cmu.edu
> Subject: Re: ISCSI: A propos MIB and specially iSCSI MIB
> 
> 
> Michele-
> 
> Thanks for the comments.  My comments are below.
> 
> --
> Mark
> 
> Michele Hallak - Stamler wrote:
> > 
> > Since you are meeting at interim meetings on MIBs:
> > 
> > The following mail summarizes my suggestions concerning the
> improvement
> > of iSCSI MIB:
> > 
> > 1. New Textual Convention:
> >  AuthenticationMethodTC  ::= TEXTUAL-CONVENTION
> >     STATUS current
> >     DESCRIPTION
> >         "List of possible authentication methods."
> >     SYNTAX INTEGER {
> >                 none(1),
> >                 crc32(2),
> >                 crc64(3),
> >                 md5(4),
> >                 kerberosMd5(5),
> >                 kerberosMd5des(6),
> >                 kerberosMd5desHmark(7)
> >         }
> 
> This is a text field in the current MIB; it will change to
> an OID field in the next version, which acts a little like
> your enumerated types, but is extensible without modifying
> the MIB.  BTW, this is a set of two attributes called DataDigest
> and HeaderDigest; AuthMethod is something completely different.
> All of the digest methods will be removed from draft-08 with
> the exception of "none" and "crc-32c".  With the new OID scheme;
> values for these can be added to your enterprise MIB if you
> choose to implement them.
> 
	[MHS]  If it will be OIDs, it's fine with me. I was
inconfortable with simple strings.
> > 
> > 2. Add RowStatus and Read-Write Access to the portals and to the
> > authorized list of initiators.
> 
> Which attributes to write and which rows to delete are currently
> under consideration.  We are looking for detailed input on this.
> 
> Please send the list of attributes you wish to write, and why
> you wish to write them.
	[MHS]  Mainly, we would like to add the type of access for each
initiator: read-only or read-write.

> > 3. Add RowStatus to iscsiTargetAttributesTable in order to allow an
> > administrator to create target and
> > set the access of the fields:     iscsiTgtName  and iscsiTgtAlias as
> > read-create
> 
> It's not possible to create an iSCSI target without first creating
> a SCSI target.  I don't think we will be ready to explore this until
> we have made progress on a SCSI MIB.  If you have some ideas on how
> a management station would make use of this (with both MIBs) to create
> new targets, please send them.
> 
	[MHS]  After having made some clarifications, I understand what
you mean now.
	What is the status of the SCSI MIB? Is there any work done on
the matter? 
	And at which organization?
	For our management we need the ability to create targets. What
is your suggestion?
	(Apart of private MIB)
	I think that anyway we can allow to create targets via iSCSI
MIB; it is MAX-ACCESS and it
	will be the responsibility of the implementation to update SCSI
modules about new targets.
	Your opinion?


> > I hope that you'll aggree to make the change,
> > 
> >         Michele
> 
> -- 
> Mark A. Bakke
> Cisco Systems
> mbakke@cisco.com
> 763.398.1054
	[MHS]  
	Again Thanks a lot,

	Michele Hallak-Stamler
	Sanrad Intelligent Storage
	michele@sanrad.com
	972-3-7674809


From owner-ips@ece.cmu.edu  Tue Aug 28 13:50:40 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17056
	for <ips-archive@odin.ietf.org>; Tue, 28 Aug 2001 13:50:38 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7SG4fb07822
	for ips-outgoing; Tue, 28 Aug 2001 12:04:41 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e33.bld.us.ibm.com (e33.co.us.ibm.com [32.97.110.131])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7SG4dP07813
	for <ips@ece.cmu.edu>; Tue, 28 Aug 2001 12:04:39 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e33.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA48150
	for <ips@ece.cmu.edu>; Tue, 28 Aug 2001 11:02:26 -0500
Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7SG4aH55498
	for <ips@ece.cmu.edu>; Tue, 28 Aug 2001 10:04:36 -0600
Importance: Normal
Subject: RE: iSCSI: reusing ISID for recovery
To: ips@ece.cmu.edu
From: "Jim Hafner" <hafner@almaden.ibm.com>
Date: Tue, 28 Aug 2001 09:04:34 -0700
Message-ID: <OF5AEADD45.E2507E16-ON88256AB6.005789EA@boulder.ibm.com>
X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at
 08/28/2001 09:04:35 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Julo,

I'm unclear why you think that option A isn't viable and why you think a
more complicated protocol is required here.

If the initiator 'lost his way' such that he thinks he has an existing
session, then he does the normal error recovery for that scenario (a la the
mechanisms Mallikarjun noted).  If he 'lost his way' so badly that he
doesn't even know he has an existing session, then option A is probably the
right thing to do.  In this case, he won't even know he's lost his way so
can't expect to set the X bit rationally.  He'd either not set it, and then
we need a rule for what the target does then OR he sets it knee-jerk in
which case there's no point in having it (as Marj, Deva, et al, have
argued).

In short, if he has knowledge of a lost session, he does session recovery.
If not, he just logs in and the target cleans up its end.

I'd like to close this issue as well, should there be a call for consensus?

Jim Hafner


Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 08/27/2001 09:39:03 pm

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery




Marjorie, Jim, Mallikarjun, Deva & all

Let's attemp to close that optimization that is so dear to your hearts.
If we go for the following scheme (very close to B):

The initiator knows "that he lost his way" (in the initiator jungle tough)
and issues a Login + ISID + TSID=0 + X bit on (meaning
" I think I have an old session - please clean it up for me" and open a new
one) then the target may do one of the following:

- before going to the effort of authenticating the new initiator check if a
session exist (if he has the initiator name) or go to authentication if it
does not
- If he has a session then clean it and create a new one
- If he does not have a session - we have 3 options:
a)- tell him hid did not have an old session and drop him
b)- tell him he did not have an old session but nevertheless create a new
one
c)- create a new session and do not tell him

With option a we are close to the old option c but the initiator does not
have to find the old session he can do now safely a new login
With b & c  we are back at the old b.

Which one would you give your kingdom for ( and my peace!).

Julo

"Dev" <deva@stargateip.com>@ece.cmu.edu on 28-08-2001 01:44:15

Please respond to <deva@stargateip.com>

Sent by:  owner-ips@ece.cmu.edu


To:   "KRUEGER,MARJORIE \(HP-Roseville,ex1\)" <marjorie_krueger@hp.com>,
      <ips@ece.cmu.edu>
cc:
Subject:  RE: iSCSI: reusing ISID for recovery



All,

When a session is already running authenticated, a login request with the
same
ISID + initiator fails authentication. Will the session continue to run?
Or
if the target fails during parameter negotiation?

I guess, yes. i.e. target will not act on the existing session, until
the login completes successfully. Or are there exception to these?

Thanks

Deva
Platys Communications





> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Saturday, August 25, 2001 12:23 AM
> To: ips@ece.cmu.edu
> Subject: RE: iSCSI: reusing ISID for recovery
>
>
>
> It may be another OS running on the same machine or CPU
> complex or it could
> be an attack.
> In any case if the initiator is up and fine he can as well do logout.
> It is a rare enough event for us not to try to optimize.
>
> The reboot is the only case in which the initiator can't
> logout and about
> which we care.
>
> And I would like to remind you all that we where on this
> exact thread more
> tan 3 months ago (other players).
> I just restated the rationale for an (apparent) newcomer.
>
> Julo
>
> "KRUEGER,MARJORIE (HP-Roseville,ex1)"
> <marjorie_krueger@hp.com>@ece.cmu.edu
> on 25-08-2001 03:51:43
>
> Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"
>       <marjorie_krueger@hp.com>
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   ips@ece.cmu.edu
> cc:
> Subject:  RE: iSCSI: reusing ISID for recovery
>
>
>
> I don't see how Option A is prone to "wild closing of sessions".  The
> target
> is only looking for sessions with this particular initiator
> and closing
> them
> if the ISID matches.
>
> If an initiator doesn't have a valid TSID (login w/TSID=0),
> it means it has
> lost state entirely (reboot) or knows it wants to immediately reset a
> session (NIC failure).  How could there possibly be a case where the
> initiator has an active valid session with the same ISID, but
> just doesn't
> know about it??  Rejecting the login seems pointless, since
> obviously the
> initiator either has a bug or intends to quickly reset the session.
>
> The behavior chosen (Option C) will cause the initiator's
> recovery to be
> delayed while the target NOPs all the connections and waits
> for them to
> time
> out - this will only delay the initiators recovery
> unnecessarily.  I can't
> help but think this will cause long term problems for the protocol.
>
> Marjorie Krueger
> Networked Storage Architecture
> Networked Storage Solutions Org.
> Hewlett-Packard
> tel: +1 916 785 2656
> fax: +1 916 785 0391
> email: marjorie_krueger@hp.com
>
> > -----Original Message-----
> > From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > Sent: Thursday, August 23, 2001 9:39 PM
> > To: ips@ece.cmu.edu
> > Subject: Re: iSCSI: reusing ISID for recovery (Was: RE: iSCSI
> > - Change -
> > Login/Text...)
> >
> >
> >
> > Mallikarjun,
> >
> > On  your point 1 that is what is stated today in the draft.
> >
> > On your point 2 option C is the one we took in the draft, after some
> > debate.
> >
> > Option A is prone to "wild closing of sessions" and option B is also
> > relaying to much on the good behaviour of the
> > client. It also introduces a "feature" that complicates
> login/logout.
> >
> > Our postion on this is  that the initiator should logout the session
> > explicitly if it can (and in this case it can as the target
> > has ascertained
> > that the session is alive).
> >
> > I agree that you may want to update the stayte diagram to
> > reflect this.
> >
> > Julo
> >
> >
> > "Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on
> 24-08-2001 01:46:40
> >
> > Please respond to cbm@rose.hp.com
> >
> > Sent by:  owner-ips@ece.cmu.edu
> >
> >
> > To:   ips@ece.cmu.edu
> > cc:
> > Subject:  iSCSI: reusing ISID for recovery (Was: RE: iSCSI
> - Change -
> >       Login/Text...)
> >
> >
> >
> > Julian and all:
> >
> > This thread mirrors another discussion some of us are
> > having in a different forum.  Following (two bullets 1
> > & 2 below) is what I proposed there, attempting to address
> > two issues -
> >      a) how to recover sessions when target and the initiator
> >            have conflicting views of the same TCP connection(s)?
> >            (Initiator NIC fails, but there's no I/O activity,
> >            and the target doesn't see any connection failure.)
> >      b) More specifically, how to address the above problem
> >            when the initiator *does not want* to re-instate failed
> >            connections since it only implements the mandatory
> >            session recovery?
> >
> > This could add clarity or muddle things up here, though hopefully
> > the former...
> >
> > 1 If login is sent with the same ISID, same TSID, same CID
> and X-bit,
> >   then it means a failed connection is being re-instated (whether
> >   or not there are multiple connections in the session).  This login
> >   attempt must be done before the connection timeout
> (transition M1),
> >   or if this is the only connection in the session, also before the
> >   session timeout (transition N6) - to be counted as a connection
> >   reinstatement effort.
> >            o CmdSN counters (CmdSN, ExpCmdSN) are continued.
> > Initiator
> >              must do command plugging when there's a mismatch
> >              between its CmdSN and ExpCmdSN in the login response.
> >            o Since this is an implicit connection logout, all
> > the active
> >              tasks on the connection are either internally
> terminated,
> >              or made non-allegiant (based on ErrorRecoveryLevel=x/y,
> >              TBD) for recovery.
> >
> > 2 If login is sent with the same ISID and TSID=0, the session (if it
> >   exists on the target) is being cleared and any active connections
> >   that the target sees must be immediately (at the end of the login
> >   process including any initiator authentication) transport reset.
> >   Initiator may attempt this only after it ascertains a
> > session failure
> >   on its end (ie. all connections entered RECOVERY_START).
> >            o CmdSN counters get reset.  Initiator has to perform the
> >              currently defined session recovery actions.
> >            o All active tasks of the session are internally
> > terminated.
> >
> >
> > Essentially, I was proposing extending the same notion of "implicit
> > logout" of a connection to the session level.  The options that I
> > see are -
> >
> >        A) Should iSCSI let it happen by default as stated above (ie.
> >           same ISID, TSID=0 always wipes out the
> pre-existing session
> >           on target, since we are mandating it to be used only when
> >           initiator sees a session failure)?
> >        B) Should iSCSI mandate making this intended cleanup explicit
> >           by setting a bit (Say C-bit, for Clear) in the
> Login Command
> >           PDU to prevent an accidental session cleanup with a buggy
> >           initiator code?
> >        C) Should iSCSI merely state that targets must ascertain
> >           the connection state(s) whenever a new session creation
> >           attempt is made with a known ISID and TSID=0?  (sort of
> >           defeats the intention of the initiator wanting quicker
> >           session recovery since the Login command PDU would have
> >           to idle till target ascertains the connection state(s)).
> >
> > I prefer A, or B.
> >
> > Going with A or B means that the description of transition N3
> > in the session state diagram would have to change to:
> >      Last LOGGED_IN connection had ceased to be LOGGED_IN,
> >         or a Login Command requesting clearing the session (also
> >         with C-bit set, if option B) was received by the target.
> >
> > The transition N7's description would have to be augmented as
> > well to:
> >         Session recovery attempt with an implicit logout,
> >         or connection reinstatement/new CID addition.
> >
> > Comments?
> > --
> > Mallikarjun
> >
> >
> > Mallikarjun Chadalapaka
> > Networked Storage Architecture
> > Network Storage Solutions Organization
> > MS 5668   Hewlett-Packard, Roseville.
> > cbm@rose.hp.com
> >
> >
> > >Stephen,
> > >
> > >That can happen as the target may set-up completely new TCP
> > connections
> > >(the old sockets are still there and look OK).
> > >Untill the login is  progessing he assumes that this is
> just another
> > >open-session attempt. Then he checks the old session and the
> > session is
> > >dead (initiator has closed the connections).
> > >
> > >The target has to distinguish only between a session that is
> > alive (and
> > >reject the new one) and one that its dead in which case it
> > can clean-up.
> > >
> > >Julo
> > >
> > >"Wheat, Stephen R" <stephen.r.wheat@intel.com> on
> 23-08-2001 22:50:56
> > >
> > >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> > >
> > >To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> > >cc:
> > >Subject:  RE: iSCSI - Change - Login/Text commands with the
> > binary stage
> > co
> > >          de
> > >
> > >
> > >
> > >Julian,
> > >
> > >I don't understand your answer.  For the scenario given, I
> > would presume
> > >then that the target would reject the new session attempt,
> > as it sees the
> > >previous session still "alive".  What is there to tell the
> > target that
> > this
> > >is any different from when the Initiator is erroneously using the
> > >repetitive
> > >session id?
> > >
> > >Thanks,
> > >Stephen
> > >
> > >-----Original Message-----
> > >From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > >Sent: Thursday, August 23, 2001 11:15 AM
> > >To: ips@ece.cmu.edu
> > >Subject: Re: iSCSI - Change - Login/Text commands with the
> > binary stage
> > >co de
> > >
> > >
> > >Stephen,
> > >
> > >1.If the initiator goes away for a while and reboots and
> there was no
> > >activity on the connections
> > >the target may see a session alive (I am not sure that it
> > has to appear on
> > >the state diagram but maybe).
> > >
> > >2.Again - I am not sure that the curent state diagram
> > includes death of
> > the
> > >initiator
> > >
> > >Julo
> > >
> > >"Wheat, Stephen R" <stephen.r.wheat@intel.com>@ece.cmu.edu
> > on 23-08-2001
> > >19:58:34
> > >
> > >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> > >
> > >Sent by:  owner-ips@ece.cmu.edu
> > >
> > >
> > >To:   ips@ece.cmu.edu
> > >cc:
> > >Subject:  Re: iSCSI - Change - Login/Text commands with the
> > binary stage
> > co
> > >      de
> > >
> > >
> > >
> > >Julian,
> > >
> > >1.3.6 ISID states that the target should check to see if the
> > old session
> > is
> > >still active when a duplicate session is detected.
> > >
> > >I have two questions, the second only if you answer in the
> > affirmative on
> > >the first ;^)
> > >
> > >1. Is there a properly executed sequence of events (i.e., no
> > coding error
> > >on
> > >the target side) where the session is not active, but the
> > target hadn't
> > >taken notice of it?  It appears this as a protocol-specified
> > means to work
> > >around a flaw in a target's implementation.  I interpret the
> > state diagram
> > >transitions as being atomic wrt other commands.  I.e., the
> > last logout
> > >would
> > >result in the various transitions of the connection/session
> > prior to the
> > >initiator starting the session up again.  And the target would have
> > >completed the transitions prior to handling a new session request.
> > >
> > >2. If you answered (1) in the affirmative, then the word
> > "Active" is not
> > >consistent with the 6.3 Session State Diagram.  Does this
> > mean the target
> > >got lost, due to transport failures of any sort, in its
> > transition from
> > >Q3-to-Q2-to-Q1?  It sounds like the intent is to close the
> > old session if
> > >the session was in Q2 or Q4, presuming if it were in Q1,  it
> > would not
> > have
> > >been found as a duplicate.
> > >
> > >Stephen
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
>
>
>









From owner-ips@ece.cmu.edu  Tue Aug 28 14:34:42 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18163
	for <ips-archive@odin.ietf.org>; Tue, 28 Aug 2001 14:34:42 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7SHZfG13734
	for ips-outgoing; Tue, 28 Aug 2001 13:35:41 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7SHZbP13726
	for <ips@ece.cmu.edu>; Tue, 28 Aug 2001 13:35:38 -0400 (EDT)
Received: from d06relay02.portsmouth.uk.ibm.com (d06relay02.portsmouth.uk.ibm.com [9.166.84.148])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id TAA58236
	for <ips@ece.cmu.edu>; Tue, 28 Aug 2001 19:35:29 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d06relay02.portsmouth.uk.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7SHZ7U281656
	for <ips@ece.cmu.edu>; Tue, 28 Aug 2001 18:35:07 +0100
Importance: Normal
Subject: RE: iSCSI: reusing ISID for recovery
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF01DF7D59.A05A6FF0-ONC2256AB6.005FC7A1@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Tue, 28 Aug 2001 20:28:36 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 28/08/2001 20:35:06
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Marjorie,

When I say without authetication I meant only on option A.
And it is option B with some details and using the X bit.

Julo



"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>@ece.cmu.edu
on 28-08-2001 20:15:29

Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"
      <marjorie_krueger@hp.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery



I am opposed to doing anything before authentication as this opens
opportunities for DOS attacks or some new form of hacking.  Also, this
would
be a "special case" behavior for login, and I'm sure I speak for all
implementors when I beg you not to create unnecessary special case
behavior.
We like a simple state machine for the login process.

I agree, w/Jim, this looks much like a more complicated option B, and the
value escapes me?

Marj

> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Monday, August 27, 2001 9:39 PM
> To: ips@ece.cmu.edu
> Subject: RE: iSCSI: reusing ISID for recovery
>
>
>
> Marjorie, Jim, Mallikarjun, Deva & all
>
> Let's attemp to close that optimization that is so dear to
> your hearts.
> If we go for the following scheme (very close to B):
>
> The initiator knows "that he lost his way" (in the initiator
> jungle tough)
> and issues a Login + ISID + TSID=0 + X bit on (meaning
> " I think I have an old session - please clean it up for me"
> and open a new
> one) then the target may do one of the following:
>
> - before going to the effort of authenticating the new
> initiator check if a
> session exist (if he has the initiator name) or go to
> authentication if it
> does not
> - If he has a session then clean it and create a new one
> - If he does not have a session - we have 3 options:
> a)- tell him hid did not have an old session and drop him
> b)- tell him he did not have an old session but nevertheless
> create a new
> one
> c)- create a new session and do not tell him
>
> With option a we are close to the old option c but the
> initiator does not
> have to find the old session he can do now safely a new login
> With b & c  we are back at the old b.
>
> Which one would you give your kingdom for ( and my peace!).
>
> Julo
>
>





From owner-ips@ece.cmu.edu  Tue Aug 28 14:44:28 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18377
	for <ips-archive@odin.ietf.org>; Tue, 28 Aug 2001 14:44:27 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7SHFbq12372
	for ips-outgoing; Tue, 28 Aug 2001 13:15:37 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7SHFZP12363
	for <ips@ece.cmu.edu>; Tue, 28 Aug 2001 13:15:35 -0400 (EDT)
Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190])
	by atlrel2.hp.com (Postfix) with ESMTP id 1F87FDF6
	for <ips@ece.cmu.edu>; Tue, 28 Aug 2001 13:15:35 -0400 (EDT)
Received: from xatlbh2.atl.hp.com (xatlbh2.atl.hp.com [15.45.89.187])
	by xatlrelay1.atl.hp.com (Postfix) with ESMTP id D78271F515
	for <ips@ece.cmu.edu>; Tue, 28 Aug 2001 13:15:34 -0400 (EDT)
Received: by xatlbh2.atl.hp.com with Internet Mail Service (5.5.2653.19)
	id <RHJYFZA2>; Tue, 28 Aug 2001 13:15:34 -0400
Message-ID: <6BD67FFB937FD411A04F00D0B74FE87802A09286@xrose06.rose.hp.com>
From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
To: ips@ece.cmu.edu
Subject: RE: iSCSI: reusing ISID for recovery
Date: Tue, 28 Aug 2001 13:15:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

I am opposed to doing anything before authentication as this opens
opportunities for DOS attacks or some new form of hacking.  Also, this would
be a "special case" behavior for login, and I'm sure I speak for all
implementors when I beg you not to create unnecessary special case behavior.
We like a simple state machine for the login process.

I agree, w/Jim, this looks much like a more complicated option B, and the
value escapes me?

Marj 

> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Monday, August 27, 2001 9:39 PM
> To: ips@ece.cmu.edu
> Subject: RE: iSCSI: reusing ISID for recovery
> 
> 
> 
> Marjorie, Jim, Mallikarjun, Deva & all
> 
> Let's attemp to close that optimization that is so dear to 
> your hearts.
> If we go for the following scheme (very close to B):
> 
> The initiator knows "that he lost his way" (in the initiator 
> jungle tough)
> and issues a Login + ISID + TSID=0 + X bit on (meaning
> " I think I have an old session - please clean it up for me" 
> and open a new
> one) then the target may do one of the following:
> 
> - before going to the effort of authenticating the new 
> initiator check if a
> session exist (if he has the initiator name) or go to 
> authentication if it
> does not
> - If he has a session then clean it and create a new one
> - If he does not have a session - we have 3 options:
> a)- tell him hid did not have an old session and drop him
> b)- tell him he did not have an old session but nevertheless 
> create a new
> one
> c)- create a new session and do not tell him
> 
> With option a we are close to the old option c but the 
> initiator does not
> have to find the old session he can do now safely a new login
> With b & c  we are back at the old b.
> 
> Which one would you give your kingdom for ( and my peace!).
> 
> Julo
> 
> 


From owner-ips@ece.cmu.edu  Tue Aug 28 16:54:24 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21262
	for <ips-archive@odin.ietf.org>; Tue, 28 Aug 2001 16:54:23 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7SJmKj22795
	for ips-outgoing; Tue, 28 Aug 2001 15:48:20 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7SJmIP22790
	for <ips@ece.cmu.edu>; Tue, 28 Aug 2001 15:48:18 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id VAA47366
	for <ips@ece.cmu.edu>; Tue, 28 Aug 2001 21:48:11 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7SJm8M292154
	for <ips@ece.cmu.edu>; Tue, 28 Aug 2001 21:48:09 +0200
Importance: Normal
Subject: Re: Silly Question - N.B. = ???
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF8C232781.F4CD75A8-ONC2256AB6.006BD8BB@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Tue, 28 Aug 2001 22:46:49 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 28/08/2001 22:48:08
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f7SJmJP22792
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit

Dear Greg A. (or KA5VBS ?),

N.B. is from Nota Bene (the same way as i.e. comes from "It Est") - it is
latin for "take good note"  (Webster's College dictionary translates it
almost literally to "note well").

Julo

KA5VBS@aol.com@ece.cmu.edu on 28-08-2001 22:15:20

Please respond to KA5VBS@aol.com

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  Silly Question - N.B. = ???



I have a "silly" question that should be easy to answer.

What does the "N.B." mean in the iSCSI document?  I don't see it "defined"
anywhere in iSCSI.

Thanks in advance,

Greg A.






From owner-ips@ece.cmu.edu  Tue Aug 28 16:57:51 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21342
	for <ips-archive@odin.ietf.org>; Tue, 28 Aug 2001 16:57:49 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7SJFRb20609
	for ips-outgoing; Tue, 28 Aug 2001 15:15:27 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from imo-r09.mx.aol.com (imo-r09.mx.aol.com [152.163.225.105])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7SJFPP20600
	for <ips@ece.cmu.edu>; Tue, 28 Aug 2001 15:15:25 -0400 (EDT)
Received: from KA5VBS@aol.com
	by imo-r09.mx.aol.com (mail_out_v31_r1.4.) id 3.12.119f612d (4332)
	 for <ips@ece.cmu.edu>; Tue, 28 Aug 2001 15:15:20 -0400 (EDT)
From: KA5VBS@aol.com
Message-ID: <12.119f612d.28bd47c8@aol.com>
Date: Tue, 28 Aug 2001 15:15:20 EDT
Subject: Silly Question - N.B. = ???
To: ips@ece.cmu.edu
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="part1_12.119f612d.28bd47c8_boundary"
X-Mailer: AOL 6.0 for Windows US sub 10536
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


--part1_12.119f612d.28bd47c8_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

I have a "silly" question that should be easy to answer.

What does the "N.B." mean in the iSCSI document?  I don't see it "defined" 
anywhere in iSCSI.

Thanks in advance,

Greg A.


--part1_12.119f612d.28bd47c8_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

<HTML><FONT FACE=arial,helvetica><FONT  SIZE=3>I have a "silly" question that should be easy to answer.
<BR>
<BR>What does the "N.B." mean in the iSCSI document? &nbsp;I don't see it "defined" 
<BR>anywhere in iSCSI.
<BR>
<BR>Thanks in advance,
<BR>
<BR>Greg A.
<BR></FONT></HTML>

--part1_12.119f612d.28bd47c8_boundary--


From owner-ips@ece.cmu.edu  Tue Aug 28 17:42:34 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22098
	for <ips-archive@odin.ietf.org>; Tue, 28 Aug 2001 17:42:34 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7SJxMe23486
	for ips-outgoing; Tue, 28 Aug 2001 15:59:22 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7SJxJP23481
	for <ips@ece.cmu.edu>; Tue, 28 Aug 2001 15:59:20 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA12320
	for <ips@ece.cmu.edu>; Tue, 28 Aug 2001 15:57:02 -0400
Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7SJxDH20716
	for <ips@ece.cmu.edu>; Tue, 28 Aug 2001 13:59:13 -0600
Importance: Normal
Subject: iSCSI: definition of TSID (2.11.4 of draft 07)
To: ips@ece.cmu.edu
From: "Jim Hafner" <hafner@almaden.ibm.com>
Date: Tue, 28 Aug 2001 12:59:11 -0700
Message-ID: <OFFF38B050.AF69B80D-ON88256AB6.006D4D42@boulder.ibm.com>
X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at
 08/28/2001 12:59:13 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Folks,

The following text defines TSID in referenced document (and with the
changes proposed by Mallikarjun):

"The TSID is a tag that identifies the SCSI initiator port.  TSID is set by
the target.  It MUST be valid only in the final response."

I'm trying to figure out what the TSID has to do with the SCSI initiator
port.  As I understand it, they are completely unrelated (at an
architecture level).  In implementation may choose to use the TSID as a
pointer to the session in a unique way across all sessions in the target or
in a unique way across all sessions with a given named iSCSI initiator or
it can do any number of other things.  It is, in my opinion, unrelated to
the SCSI initiator port.

I would propose the following alternative text:

"The TSID is a tag set by the target that, together with the ISID,
identifies a unique session with the initiator."

Comments?

Jim Hafner



From owner-ips@ece.cmu.edu  Tue Aug 28 19:02:24 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23166
	for <ips-archive@odin.ietf.org>; Tue, 28 Aug 2001 19:02:24 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7SMGuR01988
	for ips-outgoing; Tue, 28 Aug 2001 18:16:56 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e33.bld.us.ibm.com (e33.co.us.ibm.com [32.97.110.131])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7SMGsP01984
	for <ips@ece.cmu.edu>; Tue, 28 Aug 2001 18:16:54 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e33.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA117770
	for <ips@ece.cmu.edu>; Tue, 28 Aug 2001 17:14:42 -0500
Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7SMFbH216726
	for <ips@ece.cmu.edu>; Tue, 28 Aug 2001 16:15:37 -0600
Importance: Normal
Subject: RE: iSCSI: definition of TSID (2.11.4 of draft 07)
To: ips@ece.cmu.edu
From: "Jim Hafner" <hafner@almaden.ibm.com>
Date: Tue, 28 Aug 2001 15:15:35 -0700
Message-ID: <OF18127EBA.4C309208-ON88256AB6.0078C3CE@boulder.ibm.com>
X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at
 08/28/2001 03:15:36 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Marj,

Comments in line (as usual...).  But for the person of few words, I'd agree
with just this text (your first sentence only):

"The TSID is the target assigned tag for a session with a specific named
initiator
that, together with the ISID uniquely identifies a session with that
initiator."

(I moved the word "name" around because the session is with the initiator
not with the name.)

Jim Hafner


"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>@ece.cmu.edu
on 08/28/2001 02:46:45 pm

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: definition of TSID (2.11.4 of draft 07)



I'm curious why you've phrased it this way.  I think of it more like;

"The TSID is the target assigned tag for a session with a specific
initiator
name that, together with the ISID uniquely identifies a session with that
initiator.
<JLH>
I don't really see the subtle difference between this text and mine, so I
guess I don't have any problem with it.  At least it doesn't bind the
definition to anything SCSI'ish.
</JLH>

However, the target MUST enforce uniqueness of the SSID for a given I_T
combination (in order for login and recovery rules to make sense).
<JLH>
I think I see what you're getting at here, but I don't think the words
capture it (it looks like an incorrect use of "I_T nexus" (a SCSI thing).
Do you mean:

  "However, the target MUST enforce the uniqueness of the SSID [aside:
isn't this 'SID'?] for sessions with a given initiator."

If so, I can go with this text, but I think this is stated in other places
and need not be here.  But I won't argue if it is also here.
</JLH>

The TSID MAY be a unique tag for a session with a specific initiator name."
<JLH>
I don't think this belongs at all.  It is an implementation statement and
so outside the scope.  It's a true statement, but I don't think it should
be made explicit (especially in this part of the document -- I'd have less
problem with this in the "Notes to Implementers" but even then it is
suggesting a prefered(?) implementation).
</JLH>

I know the last "rule" is more for convenience than to follow the "modeling
rules" (but that's the most straight forward way to implement TSID
assignment?).  From the target viewpoint, it must first set the context of
the initiator name, secondly the ISID.
<JLH>
First, it's not necessarily the most straightforward way. It could generate
a unique TSID for every session regardless of initiator name.  That gives
it a twobyte pointer to the session context.  That's a lot more efficient
(perhaps) than having to also have an initiator name in that "pointer".
So, if you go with your implementation, you have to index on the name+TSID,
and that's too big, so you need an indirect pointer to the context and at
that point it doesn't really matter what the TSID is relative to other
TSIDs; you can use the name + joint SID=ISID||TSID as your index (it's only
2 bytes more out of a possible 258!).

So, I argue for no statement about implementation options, leave that to
the clever programmers!
</JLH>

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: marjorie_krueger@hp.com

> -----Original Message-----
> From: Jim Hafner [mailto:hafner@almaden.ibm.com]
> Sent: Tuesday, August 28, 2001 12:59 PM
> To: ips@ece.cmu.edu
> Subject: iSCSI: definition of TSID (2.11.4 of draft 07)
>
>
> Folks,
>
> The following text defines TSID in referenced document (and with the
> changes proposed by Mallikarjun):
>
> "The TSID is a tag that identifies the SCSI initiator port.
> TSID is set by
> the target.  It MUST be valid only in the final response."
>
> I'm trying to figure out what the TSID has to do with the
> SCSI initiator
> port.  As I understand it, they are completely unrelated (at an
> architecture level).  In implementation may choose to use the
> TSID as a
> pointer to the session in a unique way across all sessions in
> the target or
> in a unique way across all sessions with a given named iSCSI
> initiator or
> it can do any number of other things.  It is, in my opinion,
> unrelated to
> the SCSI initiator port.
>
> I would propose the following alternative text:
>
> "The TSID is a tag set by the target that, together with the ISID,
> identifies a unique session with the initiator."
>
> Comments?
>
> Jim Hafner
>





From owner-ips@ece.cmu.edu  Tue Aug 28 19:13:31 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23674
	for <ips-archive@odin.ietf.org>; Tue, 28 Aug 2001 19:13:31 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7SLkq400239
	for ips-outgoing; Tue, 28 Aug 2001 17:46:52 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7SLkpP00232
	for <ips@ece.cmu.edu>; Tue, 28 Aug 2001 17:46:51 -0400 (EDT)
Received: from xparelay2.corp.hp.com (unknown [15.58.137.112])
	by palrel1.hp.com (Postfix) with ESMTP id 5F765142E
	for <ips@ece.cmu.edu>; Tue, 28 Aug 2001 14:46:50 -0700 (PDT)
Received: from xpabh1.corp.hp.com (xpabh1.corp.hp.com [15.58.136.191])
	by xparelay2.corp.hp.com (Postfix) with ESMTP id E2A461F50A
	for <ips@ece.cmu.edu>; Tue, 28 Aug 2001 14:46:49 -0700 (PDT)
Received: by xpabh1.corp.hp.com with Internet Mail Service (5.5.2653.19)
	id <QVBA728T>; Tue, 28 Aug 2001 14:46:49 -0700
Message-ID: <6BD67FFB937FD411A04F00D0B74FE87802A09288@xrose06.rose.hp.com>
From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
To: ips@ece.cmu.edu
Subject: RE: iSCSI: definition of TSID (2.11.4 of draft 07)
Date: Tue, 28 Aug 2001 14:46:45 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

I'm curious why you've phrased it this way.  I think of it more like;

"The TSID is the target assigned tag for a session with a specific initiator
name that, together with the ISID uniquely identifies a session with that
initiator.

However, the target MUST enforce uniqueness of the SSID for a given I_T
combination (in order for login and recovery rules to make sense).

The TSID MAY be a unique tag for a session with a specific initiator name."

I know the last "rule" is more for convenience than to follow the "modeling
rules" (but that's the most straight forward way to implement TSID
assignment?).  From the target viewpoint, it must first set the context of
the initiator name, secondly the ISID.  

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: marjorie_krueger@hp.com 

> -----Original Message-----
> From: Jim Hafner [mailto:hafner@almaden.ibm.com]
> Sent: Tuesday, August 28, 2001 12:59 PM
> To: ips@ece.cmu.edu
> Subject: iSCSI: definition of TSID (2.11.4 of draft 07)
> 
> 
> Folks,
> 
> The following text defines TSID in referenced document (and with the
> changes proposed by Mallikarjun):
> 
> "The TSID is a tag that identifies the SCSI initiator port.  
> TSID is set by
> the target.  It MUST be valid only in the final response."
> 
> I'm trying to figure out what the TSID has to do with the 
> SCSI initiator
> port.  As I understand it, they are completely unrelated (at an
> architecture level).  In implementation may choose to use the 
> TSID as a
> pointer to the session in a unique way across all sessions in 
> the target or
> in a unique way across all sessions with a given named iSCSI 
> initiator or
> it can do any number of other things.  It is, in my opinion, 
> unrelated to
> the SCSI initiator port.
> 
> I would propose the following alternative text:
> 
> "The TSID is a tag set by the target that, together with the ISID,
> identifies a unique session with the initiator."
> 
> Comments?
> 
> Jim Hafner
> 


From owner-ips@ece.cmu.edu  Tue Aug 28 20:01:37 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24219
	for <ips-archive@odin.ietf.org>; Tue, 28 Aug 2001 20:01:32 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7SMgZC03356
	for ips-outgoing; Tue, 28 Aug 2001 18:42:35 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7SMgXP03352
	for <ips@ece.cmu.edu>; Tue, 28 Aug 2001 18:42:33 -0400 (EDT)
Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100])
	by atlrel2.hp.com (Postfix) with ESMTP id 26F7524C
	for <ips@ece.cmu.edu>; Tue, 28 Aug 2001 18:42:31 -0400 (EDT)
Received: (from cbm@localhost) by core.rose.hp.com (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id PAA29781 for ips@ece.cmu.edu; Tue, 28 Aug 2001 15:43:48 -0700 (PDT)
Message-Id: <200108282243.PAA29781@core.rose.hp.com>
Subject: RE: iSCSI: reusing ISID for recovery
To: ips@ece.cmu.edu
Date: Tue, 28 Aug 2001 15:43:48 PDT
Reply-To: cbm@rose.hp.com
From: "Mallikarjun C." <cbm@rose.hp.com>
X-Mailer: Elm [revision: 212.4]
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Julian,

I disagree that it is an optimization that most of us are
seeking, but more to the point...

I continue to prefer option A even after this proposal.  

Reasons?

o Attaching more semantics to X-bit is only more complexity.
  Only "plug command" and "reinstate connection" until now; 
  with this additionally, "lost my way" (if TSID = 0). 

o This is option B (overloading X-bit instead of a new C-bit), 
  which we all (I thought including you) agreed shouldn't be 
  adopted.

o I am unclear on the model you have in mind on authentication
  - going with any of these models.  I am further perplexed with
  this response you gave to Marjorie -

>When I say without authetication I meant only on option A.

  To quote my original email yet again, here is my phrasing:

  "at the end of the login process including any initiator authentication"

  I believe that's the only time a target must decide to invoke
  option A.

Regards.
--
Mallikarjun 


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


>Marjorie, Jim, Mallikarjun, Deva & all
>
>Let's attemp to close that optimization that is so dear to your hearts.
>If we go for the following scheme (very close to B):
>
>The initiator knows "that he lost his way" (in the initiator jungle tough)
>and issues a Login + ISID + TSID=0 + X bit on (meaning
>" I think I have an old session - please clean it up for me" and open a new
>one) then the target may do one of the following:
>
>- before going to the effort of authenticating the new initiator check if a
>session exist (if he has the initiator name) or go to authentication if it
>does not
>- If he has a session then clean it and create a new one
>- If he does not have a session - we have 3 options:
>a)- tell him hid did not have an old session and drop him
>b)- tell him he did not have an old session but nevertheless create a new
>one
>c)- create a new session and do not tell him
>
>With option a we are close to the old option c but the initiator does not
>have to find the old session he can do now safely a new login
>With b & c  we are back at the old b.
>
>Which one would you give your kingdom for ( and my peace!).
>
>Julo
>
>"Dev" <deva@stargateip.com>@ece.cmu.edu on 28-08-2001 01:44:15
>
>Please respond to <deva@stargateip.com>
>
>Sent by:  owner-ips@ece.cmu.edu
>
>
>To:   "KRUEGER,MARJORIE \(HP-Roseville,ex1\)" <marjorie_krueger@hp.com>,
>      <ips@ece.cmu.edu>
>cc:
>Subject:  RE: iSCSI: reusing ISID for recovery
>
>
>
>All,
>
>When a session is already running authenticated, a login request with the
>same
>ISID + initiator fails authentication. Will the session continue to run?
>Or
>if the target fails during parameter negotiation?
>
>I guess, yes. i.e. target will not act on the existing session, until
>the login completes successfully. Or are there exception to these?
>
>Thanks
>
>Deva
>Platys Communications
>
>
>
>
>
>> -----Original Message-----
>> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
>> Sent: Saturday, August 25, 2001 12:23 AM
>> To: ips@ece.cmu.edu
>> Subject: RE: iSCSI: reusing ISID for recovery
>>
>>
>>
>> It may be another OS running on the same machine or CPU
>> complex or it could
>> be an attack.
>> In any case if the initiator is up and fine he can as well do logout.
>> It is a rare enough event for us not to try to optimize.
>>
>> The reboot is the only case in which the initiator can't
>> logout and about
>> which we care.
>>
>> And I would like to remind you all that we where on this
>> exact thread more
>> tan 3 months ago (other players).
>> I just restated the rationale for an (apparent) newcomer.
>>
>> Julo
>>
>> "KRUEGER,MARJORIE (HP-Roseville,ex1)"
>> <marjorie_krueger@hp.com>@ece.cmu.edu
>> on 25-08-2001 03:51:43
>>
>> Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"
>>       <marjorie_krueger@hp.com>
>>
>> Sent by:  owner-ips@ece.cmu.edu
>>
>>
>> To:   ips@ece.cmu.edu
>> cc:
>> Subject:  RE: iSCSI: reusing ISID for recovery
>>
>>
>>
>> I don't see how Option A is prone to "wild closing of sessions".  The
>> target
>> is only looking for sessions with this particular initiator
>> and closing
>> them
>> if the ISID matches.
>>
>> If an initiator doesn't have a valid TSID (login w/TSID=0),
>> it means it has
>> lost state entirely (reboot) or knows it wants to immediately reset a
>> session (NIC failure).  How could there possibly be a case where the
>> initiator has an active valid session with the same ISID, but
>> just doesn't
>> know about it??  Rejecting the login seems pointless, since
>> obviously the
>> initiator either has a bug or intends to quickly reset the session.
>>
>> The behavior chosen (Option C) will cause the initiator's
>> recovery to be
>> delayed while the target NOPs all the connections and waits
>> for them to
>> time
>> out - this will only delay the initiators recovery
>> unnecessarily.  I can't
>> help but think this will cause long term problems for the protocol.
>>
>> Marjorie Krueger
>> Networked Storage Architecture
>> Networked Storage Solutions Org.
>> Hewlett-Packard
>> tel: +1 916 785 2656
>> fax: +1 916 785 0391
>> email: marjorie_krueger@hp.com
>>
>> > -----Original Message-----
>> > From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
>> > Sent: Thursday, August 23, 2001 9:39 PM
>> > To: ips@ece.cmu.edu
>> > Subject: Re: iSCSI: reusing ISID for recovery (Was: RE: iSCSI
>> > - Change -
>> > Login/Text...)
>> >
>> >
>> >
>> > Mallikarjun,
>> >
>> > On  your point 1 that is what is stated today in the draft.
>> >
>> > On your point 2 option C is the one we took in the draft, after some
>> > debate.
>> >
>> > Option A is prone to "wild closing of sessions" and option B is also
>> > relaying to much on the good behaviour of the
>> > client. It also introduces a "feature" that complicates
>> login/logout.
>> >
>> > Our postion on this is  that the initiator should logout the session
>> > explicitly if it can (and in this case it can as the target
>> > has ascertained
>> > that the session is alive).
>> >
>> > I agree that you may want to update the stayte diagram to
>> > reflect this.
>> >
>> > Julo
>> >
>> >
>> > "Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on
>> 24-08-2001 01:46:40
>> >
>> > Please respond to cbm@rose.hp.com
>> >
>> > Sent by:  owner-ips@ece.cmu.edu
>> >
>> >
>> > To:   ips@ece.cmu.edu
>> > cc:
>> > Subject:  iSCSI: reusing ISID for recovery (Was: RE: iSCSI
>> - Change -
>> >       Login/Text...)
>> >
>> >
>> >
>> > Julian and all:
>> >
>> > This thread mirrors another discussion some of us are
>> > having in a different forum.  Following (two bullets 1
>> > & 2 below) is what I proposed there, attempting to address
>> > two issues -
>> >      a) how to recover sessions when target and the initiator
>> >            have conflicting views of the same TCP connection(s)?
>> >            (Initiator NIC fails, but there's no I/O activity,
>> >            and the target doesn't see any connection failure.)
>> >      b) More specifically, how to address the above problem
>> >            when the initiator *does not want* to re-instate failed
>> >            connections since it only implements the mandatory
>> >            session recovery?
>> >
>> > This could add clarity or muddle things up here, though hopefully
>> > the former...
>> >
>> > 1 If login is sent with the same ISID, same TSID, same CID
>> and X-bit,
>> >   then it means a failed connection is being re-instated (whether
>> >   or not there are multiple connections in the session).  This login
>> >   attempt must be done before the connection timeout
>> (transition M1),
>> >   or if this is the only connection in the session, also before the
>> >   session timeout (transition N6) - to be counted as a connection
>> >   reinstatement effort.
>> >            o CmdSN counters (CmdSN, ExpCmdSN) are continued.
>> > Initiator
>> >              must do command plugging when there's a mismatch
>> >              between its CmdSN and ExpCmdSN in the login response.
>> >            o Since this is an implicit connection logout, all
>> > the active
>> >              tasks on the connection are either internally
>> terminated,
>> >              or made non-allegiant (based on ErrorRecoveryLevel=x/y,
>> >              TBD) for recovery.
>> >
>> > 2 If login is sent with the same ISID and TSID=0, the session (if it
>> >   exists on the target) is being cleared and any active connections
>> >   that the target sees must be immediately (at the end of the login
>> >   process including any initiator authentication) transport reset.
>> >   Initiator may attempt this only after it ascertains a
>> > session failure
>> >   on its end (ie. all connections entered RECOVERY_START).
>> >            o CmdSN counters get reset.  Initiator has to perform the
>> >              currently defined session recovery actions.
>> >            o All active tasks of the session are internally
>> > terminated.
>> >
>> >
>> > Essentially, I was proposing extending the same notion of "implicit
>> > logout" of a connection to the session level.  The options that I
>> > see are -
>> >
>> >        A) Should iSCSI let it happen by default as stated above (ie.
>> >           same ISID, TSID=0 always wipes out the
>> pre-existing session
>> >           on target, since we are mandating it to be used only when
>> >           initiator sees a session failure)?
>> >        B) Should iSCSI mandate making this intended cleanup explicit
>> >           by setting a bit (Say C-bit, for Clear) in the
>> Login Command
>> >           PDU to prevent an accidental session cleanup with a buggy
>> >           initiator code?
>> >        C) Should iSCSI merely state that targets must ascertain
>> >           the connection state(s) whenever a new session creation
>> >           attempt is made with a known ISID and TSID=0?  (sort of
>> >           defeats the intention of the initiator wanting quicker
>> >           session recovery since the Login command PDU would have
>> >           to idle till target ascertains the connection state(s)).
>> >
>> > I prefer A, or B.
>> >
>> > Going with A or B means that the description of transition N3
>> > in the session state diagram would have to change to:
>> >      Last LOGGED_IN connection had ceased to be LOGGED_IN,
>> >         or a Login Command requesting clearing the session (also
>> >         with C-bit set, if option B) was received by the target.
>> >
>> > The transition N7's description would have to be augmented as
>> > well to:
>> >         Session recovery attempt with an implicit logout,
>> >         or connection reinstatement/new CID addition.
>> >
>> > Comments?
>> > --
>> > Mallikarjun
>> >
>> >
>> > Mallikarjun Chadalapaka
>> > Networked Storage Architecture
>> > Network Storage Solutions Organization
>> > MS 5668   Hewlett-Packard, Roseville.
>> > cbm@rose.hp.com
>> >
>> >
>> > >Stephen,
>> > >
>> > >That can happen as the target may set-up completely new TCP
>> > connections
>> > >(the old sockets are still there and look OK).
>> > >Untill the login is  progessing he assumes that this is
>> just another
>> > >open-session attempt. Then he checks the old session and the
>> > session is
>> > >dead (initiator has closed the connections).
>> > >
>> > >The target has to distinguish only between a session that is
>> > alive (and
>> > >reject the new one) and one that its dead in which case it
>> > can clean-up.
>> > >
>> > >Julo
>> > >
>> > >"Wheat, Stephen R" <stephen.r.wheat@intel.com> on
>> 23-08-2001 22:50:56
>> > >
>> > >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
>> > >
>> > >To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
>> > >cc:
>> > >Subject:  RE: iSCSI - Change - Login/Text commands with the
>> > binary stage
>> > co
>> > >          de
>> > >
>> > >
>> > >
>> > >Julian,
>> > >
>> > >I don't understand your answer.  For the scenario given, I
>> > would presume
>> > >then that the target would reject the new session attempt,
>> > as it sees the
>> > >previous session still "alive".  What is there to tell the
>> > target that
>> > this
>> > >is any different from when the Initiator is erroneously using the
>> > >repetitive
>> > >session id?
>> > >
>> > >Thanks,
>> > >Stephen
>> > >
>> > >-----Original Message-----
>> > >From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
>> > >Sent: Thursday, August 23, 2001 11:15 AM
>> > >To: ips@ece.cmu.edu
>> > >Subject: Re: iSCSI - Change - Login/Text commands with the
>> > binary stage
>> > >co de
>> > >
>> > >
>> > >Stephen,
>> > >
>> > >1.If the initiator goes away for a while and reboots and
>> there was no
>> > >activity on the connections
>> > >the target may see a session alive (I am not sure that it
>> > has to appear on
>> > >the state diagram but maybe).
>> > >
>> > >2.Again - I am not sure that the curent state diagram
>> > includes death of
>> > the
>> > >initiator
>> > >
>> > >Julo
>> > >
>> > >"Wheat, Stephen R" <stephen.r.wheat@intel.com>@ece.cmu.edu
>> > on 23-08-2001
>> > >19:58:34
>> > >
>> > >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
>> > >
>> > >Sent by:  owner-ips@ece.cmu.edu
>> > >
>> > >
>> > >To:   ips@ece.cmu.edu
>> > >cc:
>> > >Subject:  Re: iSCSI - Change - Login/Text commands with the
>> > binary stage
>> > co
>> > >      de
>> > >
>> > >
>> > >
>> > >Julian,
>> > >
>> > >1.3.6 ISID states that the target should check to see if the
>> > old session
>> > is
>> > >still active when a duplicate session is detected.
>> > >
>> > >I have two questions, the second only if you answer in the
>> > affirmative on
>> > >the first ;^)
>> > >
>> > >1. Is there a properly executed sequence of events (i.e., no
>> > coding error
>> > >on
>> > >the target side) where the session is not active, but the
>> > target hadn't
>> > >taken notice of it?  It appears this as a protocol-specified
>> > means to work
>> > >around a flaw in a target's implementation.  I interpret the
>> > state diagram
>> > >transitions as being atomic wrt other commands.  I.e., the
>> > last logout
>> > >would
>> > >result in the various transitions of the connection/session
>> > prior to the
>> > >initiator starting the session up again.  And the target would have
>> > >completed the transitions prior to handling a new session request.
>> > >
>> > >2. If you answered (1) in the affirmative, then the word
>> > "Active" is not
>> > >consistent with the 6.3 Session State Diagram.  Does this
>> > mean the target
>> > >got lost, due to transport failures of any sort, in its
>> > transition from
>> > >Q3-to-Q2-to-Q1?  It sounds like the intent is to close the
>> > old session if
>> > >the session was in Q2 or Q4, presuming if it were in Q1,  it
>> > would not
>> > have
>> > >been found as a duplicate.
>> > >
>> > >Stephen
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> >
>> >
>> >
>> >
>> >
>>
>>
>>
>
>
>
>
>




From owner-ips@ece.cmu.edu  Tue Aug 28 20:06:49 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24281
	for <ips-archive@odin.ietf.org>; Tue, 28 Aug 2001 20:06:49 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7SN98i04628
	for ips-outgoing; Tue, 28 Aug 2001 19:09:09 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7SN97P04624
	for <ips@ece.cmu.edu>; Tue, 28 Aug 2001 19:09:07 -0400 (EDT)
Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100])
	by palrel2.hp.com (Postfix) with ESMTP
	id 6D3D91762; Tue, 28 Aug 2001 16:09:06 -0700 (PDT)
Received: (from cbm@localhost) by core.rose.hp.com (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id QAA03691; Tue, 28 Aug 2001 16:10:24 -0700 (PDT)
Message-Id: <200108282310.QAA03691@core.rose.hp.com>
Subject: RE: iSCSI: definition of TSID (2.11.4 of draft 07)
To: hafner@almaden.ibm.com
Date: Tue, 28 Aug 2001 16:10:24 PDT
Cc: ips@ece.cmu.edu
In-Reply-To: <OF18127EBA.4C309208-ON88256AB6.0078C3CE@boulder.ibm.com>; from "Jim Hafner" at Aug 28, 101 3:48 pm
Reply-To: cbm@rose.hp.com
From: "Mallikarjun C." <cbm@rose.hp.com>
X-Mailer: Elm [revision: 212.4]
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Jim,

I see your point about the current wording possibly suggesting
an implementation option.

Can I suggest the following text:

  The TSID is a target-assigned tag which together with the InitiatorName
  uniquely identifies the session within the target.

It appears to me that it's all that's required for uniqueness, I 
don't think we need to mention ISID here.  If there are multiple
sessions with an initiator, each would anyway be assigned a different
TSID.  What am I missing?
--
Mallikarjun 


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


>Marj,
>
>Comments in line (as usual...).  But for the person of few words, I'd agree
>with just this text (your first sentence only):
>
>"The TSID is the target assigned tag for a session with a specific named
>initiator
>that, together with the ISID uniquely identifies a session with that
>initiator."
>
>(I moved the word "name" around because the session is with the initiator
>not with the name.)
>
>Jim Hafner
>
>
>"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>@ece.cmu.edu
>on 08/28/2001 02:46:45 pm
>
>Sent by:  owner-ips@ece.cmu.edu
>
>
>To:   ips@ece.cmu.edu
>cc:
>Subject:  RE: iSCSI: definition of TSID (2.11.4 of draft 07)
>
>
>
>I'm curious why you've phrased it this way.  I think of it more like;
>
>"The TSID is the target assigned tag for a session with a specific
>initiator
>name that, together with the ISID uniquely identifies a session with that
>initiator.
><JLH>
>I don't really see the subtle difference between this text and mine, so I
>guess I don't have any problem with it.  At least it doesn't bind the
>definition to anything SCSI'ish.
></JLH>
>
>However, the target MUST enforce uniqueness of the SSID for a given I_T
>combination (in order for login and recovery rules to make sense).
><JLH>
>I think I see what you're getting at here, but I don't think the words
>capture it (it looks like an incorrect use of "I_T nexus" (a SCSI thing).
>Do you mean:
>
>  "However, the target MUST enforce the uniqueness of the SSID [aside:
>isn't this 'SID'?] for sessions with a given initiator."
>
>If so, I can go with this text, but I think this is stated in other places
>and need not be here.  But I won't argue if it is also here.
></JLH>
>
>The TSID MAY be a unique tag for a session with a specific initiator name."
><JLH>
>I don't think this belongs at all.  It is an implementation statement and
>so outside the scope.  It's a true statement, but I don't think it should
>be made explicit (especially in this part of the document -- I'd have less
>problem with this in the "Notes to Implementers" but even then it is
>suggesting a prefered(?) implementation).
></JLH>
>
>I know the last "rule" is more for convenience than to follow the "modeling
>rules" (but that's the most straight forward way to implement TSID
>assignment?).  From the target viewpoint, it must first set the context of
>the initiator name, secondly the ISID.
><JLH>
>First, it's not necessarily the most straightforward way. It could generate
>a unique TSID for every session regardless of initiator name.  That gives
>it a twobyte pointer to the session context.  That's a lot more efficient
>(perhaps) than having to also have an initiator name in that "pointer".
>So, if you go with your implementation, you have to index on the name+TSID,
>and that's too big, so you need an indirect pointer to the context and at
>that point it doesn't really matter what the TSID is relative to other
>TSIDs; you can use the name + joint SID=ISID||TSID as your index (it's only
>2 bytes more out of a possible 258!).
>
>So, I argue for no statement about implementation options, leave that to
>the clever programmers!
></JLH>
>
>Marjorie Krueger
>Networked Storage Architecture
>Networked Storage Solutions Org.
>Hewlett-Packard
>tel: +1 916 785 2656
>fax: +1 916 785 0391
>email: marjorie_krueger@hp.com
>
>> -----Original Message-----
>> From: Jim Hafner [mailto:hafner@almaden.ibm.com]
>> Sent: Tuesday, August 28, 2001 12:59 PM
>> To: ips@ece.cmu.edu
>> Subject: iSCSI: definition of TSID (2.11.4 of draft 07)
>>
>>
>> Folks,
>>
>> The following text defines TSID in referenced document (and with the
>> changes proposed by Mallikarjun):
>>
>> "The TSID is a tag that identifies the SCSI initiator port.
>> TSID is set by
>> the target.  It MUST be valid only in the final response."
>>
>> I'm trying to figure out what the TSID has to do with the
>> SCSI initiator
>> port.  As I understand it, they are completely unrelated (at an
>> architecture level).  In implementation may choose to use the
>> TSID as a
>> pointer to the session in a unique way across all sessions in
>> the target or
>> in a unique way across all sessions with a given named iSCSI
>> initiator or
>> it can do any number of other things.  It is, in my opinion,
>> unrelated to
>> the SCSI initiator port.
>>
>> I would propose the following alternative text:
>>
>> "The TSID is a tag set by the target that, together with the ISID,
>> identifies a unique session with the initiator."
>>
>> Comments?
>>
>> Jim Hafner
>>
>
>
>
>




From owner-ips@ece.cmu.edu  Tue Aug 28 21:05:16 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24900
	for <ips-archive@odin.ietf.org>; Tue, 28 Aug 2001 21:05:15 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7SNdeK06041
	for ips-outgoing; Tue, 28 Aug 2001 19:39:40 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e33.bld.us.ibm.com (e33.co.us.ibm.com [32.97.110.131])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7SNdbP06037
	for <ips@ece.cmu.edu>; Tue, 28 Aug 2001 19:39:38 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e33.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA44772
	for <ips@ece.cmu.edu>; Tue, 28 Aug 2001 18:37:24 -0500
Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7SNcJH170958
	for <ips@ece.cmu.edu>; Tue, 28 Aug 2001 17:38:19 -0600
Importance: Normal
Subject: RE: iSCSI: definition of TSID (2.11.4 of draft 07)
To: ips@ece.cmu.edu
From: "Jim Hafner" <hafner@almaden.ibm.com>
Date: Tue, 28 Aug 2001 16:38:18 -0700
Message-ID: <OF2D8ACD8F.84541DA4-ON88256AB6.007FD8F0@boulder.ibm.com>
X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at
 08/28/2001 04:38:18 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Mallikarjun,

What you suggest is *more* than is required for uniqueness!  Again, that's
an implementation choice that goes beyond the model.

The model says that the *combination of ISID || TSID* has to be unique
between a given initiator and a given target.
When you say " If there are multiple sessions with an initiator, each would
anyway be assigned a different TSID"  you are assuming that the TSID alone
provide the uniqueness (between a pair).   It can, but it's more than is
necessary.

In short, you're still selecting an implementation.   Here's two other
implementations.  Suppose I have exactly one Target Portal Group.  Then I
can meet the uniqueness requirements by (a) enforcing the ISID RULE and (b)
using TSID=1 *for every session*!  This one is "minimalist" with respect to
the model.  (Because there is only one portal group, I can leverage the
uniqueness of the ISID to meet the general uniqueness rule -- it's very
different if I have more portal groups (see note below)) The "maximalist"
implementation with respect to the model is (a) enforce the ISID RULE and
(b') use a unique TSID for each session I have regardless of initiator
name!

The spec should say what is required to implement the model.  In my mind,
that's the rule that says the combination of ISID and TSID (the SID) must
be unique between a pair (initiator and target).   And that's all I'm
asking for in the definition of TSID.

Jim Hafner

Note: If I had more than one portal group, I might legitimately see the
same ISID (from the same initiator) come in to each portal group.  In that
case, I need to use a different TSID for each such occurrence.  If I say,
for example, that each portal group always uses it's portal group tag as
it's TSID (not required, just a choice), then I get uniqueness of SID's
again.  This is again, a minimalist implementation with respect to the
model.   This also gives an example of why the TSID namespace "should" be
partitioned between the portal groups, so they can always be sure that they
won't accidentally create an SID that is the same as an existing one.  As
long as the "half" of the SID one portal group generates is different from
the half generated by another portal group, there will be no chance of
collision.  [This is delegation of naming authority!!!]  The same principle
holds on the initiator side in how it generates ISIDs.

Are we getting closer?

"Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on 08/28/2001 04:10:24 pm

Please respond to cbm@rose.hp.com

Sent by:  owner-ips@ece.cmu.edu


To:   Jim Hafner/Almaden/IBM@IBMUS
cc:   ips@ece.cmu.edu
Subject:  RE: iSCSI: definition of TSID (2.11.4 of draft 07)



Jim,

I see your point about the current wording possibly suggesting
an implementation option.

Can I suggest the following text:

  The TSID is a target-assigned tag which together with the InitiatorName
  uniquely identifies the session within the target.

It appears to me that it's all that's required for uniqueness, I
don't think we need to mention ISID here.  If there are multiple
sessions with an initiator, each would anyway be assigned a different
TSID.  What am I missing?
--
Mallikarjun


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


>Marj,
>
>Comments in line (as usual...).  But for the person of few words, I'd
agree
>with just this text (your first sentence only):
>
>"The TSID is the target assigned tag for a session with a specific named
>initiator
>that, together with the ISID uniquely identifies a session with that
>initiator."
>
>(I moved the word "name" around because the session is with the initiator
>not with the name.)
>
>Jim Hafner
>
>
>"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
@ece.cmu.edu
>on 08/28/2001 02:46:45 pm
>
>Sent by:  owner-ips@ece.cmu.edu
>
>
>To:   ips@ece.cmu.edu
>cc:
>Subject:  RE: iSCSI: definition of TSID (2.11.4 of draft 07)
>
>
>
>I'm curious why you've phrased it this way.  I think of it more like;
>
>"The TSID is the target assigned tag for a session with a specific
>initiator
>name that, together with the ISID uniquely identifies a session with that
>initiator.
><JLH>
>I don't really see the subtle difference between this text and mine, so I
>guess I don't have any problem with it.  At least it doesn't bind the
>definition to anything SCSI'ish.
></JLH>
>
>However, the target MUST enforce uniqueness of the SSID for a given I_T
>combination (in order for login and recovery rules to make sense).
><JLH>
>I think I see what you're getting at here, but I don't think the words
>capture it (it looks like an incorrect use of "I_T nexus" (a SCSI thing).
>Do you mean:
>
>  "However, the target MUST enforce the uniqueness of the SSID [aside:
>isn't this 'SID'?] for sessions with a given initiator."
>
>If so, I can go with this text, but I think this is stated in other places
>and need not be here.  But I won't argue if it is also here.
></JLH>
>
>The TSID MAY be a unique tag for a session with a specific initiator
name."
><JLH>
>I don't think this belongs at all.  It is an implementation statement and
>so outside the scope.  It's a true statement, but I don't think it should
>be made explicit (especially in this part of the document -- I'd have less
>problem with this in the "Notes to Implementers" but even then it is
>suggesting a prefered(?) implementation).
></JLH>
>
>I know the last "rule" is more for convenience than to follow the
"modeling
>rules" (but that's the most straight forward way to implement TSID
>assignment?).  From the target viewpoint, it must first set the context of
>the initiator name, secondly the ISID.
><JLH>
>First, it's not necessarily the most straightforward way. It could
generate
>a unique TSID for every session regardless of initiator name.  That gives
>it a twobyte pointer to the session context.  That's a lot more efficient
>(perhaps) than having to also have an initiator name in that "pointer".
>So, if you go with your implementation, you have to index on the
name+TSID,
>and that's too big, so you need an indirect pointer to the context and at
>that point it doesn't really matter what the TSID is relative to other
>TSIDs; you can use the name + joint SID=ISID||TSID as your index (it's
only
>2 bytes more out of a possible 258!).
>
>So, I argue for no statement about implementation options, leave that to
>the clever programmers!
></JLH>
>
>Marjorie Krueger
>Networked Storage Architecture
>Networked Storage Solutions Org.
>Hewlett-Packard
>tel: +1 916 785 2656
>fax: +1 916 785 0391
>email: marjorie_krueger@hp.com
>
>> -----Original Message-----
>> From: Jim Hafner [mailto:hafner@almaden.ibm.com]
>> Sent: Tuesday, August 28, 2001 12:59 PM
>> To: ips@ece.cmu.edu
>> Subject: iSCSI: definition of TSID (2.11.4 of draft 07)
>>
>>
>> Folks,
>>
>> The following text defines TSID in referenced document (and with the
>> changes proposed by Mallikarjun):
>>
>> "The TSID is a tag that identifies the SCSI initiator port.
>> TSID is set by
>> the target.  It MUST be valid only in the final response."
>>
>> I'm trying to figure out what the TSID has to do with the
>> SCSI initiator
>> port.  As I understand it, they are completely unrelated (at an
>> architecture level).  In implementation may choose to use the
>> TSID as a
>> pointer to the session in a unique way across all sessions in
>> the target or
>> in a unique way across all sessions with a given named iSCSI
>> initiator or
>> it can do any number of other things.  It is, in my opinion,
>> unrelated to
>> the SCSI initiator port.
>>
>> I would propose the following alternative text:
>>
>> "The TSID is a tag set by the target that, together with the ISID,
>> identifies a unique session with the initiator."
>>
>> Comments?
>>
>> Jim Hafner
>>
>
>
>
>







From owner-ips@ece.cmu.edu  Tue Aug 28 23:33:38 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28590
	for <ips-archive@odin.ietf.org>; Tue, 28 Aug 2001 23:33:38 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7T1J0c10549
	for ips-outgoing; Tue, 28 Aug 2001 21:19:00 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7T1IxP10545
	for <ips@ece.cmu.edu>; Tue, 28 Aug 2001 21:18:59 -0400 (EDT)
Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100])
	by palrel2.hp.com (Postfix) with ESMTP id 58C42C65
	for <ips@ece.cmu.edu>; Tue, 28 Aug 2001 18:18:58 -0700 (PDT)
Received: (from cbm@localhost) by core.rose.hp.com (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id SAA17397 for ips@ece.cmu.edu; Tue, 28 Aug 2001 18:20:16 -0700 (PDT)
Message-Id: <200108290120.SAA17397@core.rose.hp.com>
Subject: RE: iSCSI: definition of TSID (2.11.4 of draft 07)
To: ips@ece.cmu.edu
Date: Tue, 28 Aug 2001 18:20:16 PDT
Reply-To: cbm@rose.hp.com
From: "Mallikarjun C." <cbm@rose.hp.com>
X-Mailer: Elm [revision: 212.4]
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Jim,

Thanks for the explanation.

>The model says that the *combination of ISID || TSID* has to be unique
>between a given initiator and a given target.

Actually, I do not find this formulation stated anywhere
in rev07.

The closest about TSID assignment policy is this sentence 
in section 1.5.3: "The TSID name space of the iSCSI Initiator 
should be partitioned among the target portal groups."
My earlier comments were based on this quote.

More importantly, let me try to understand the reasoning 
behind this formulation.  The only reason that I could come
up with is to preclude a "parallel nexus".  In our previous
conversation, we identified two types of nexus ids for this
enforcement - a)InitiatorName-ISID-TargetName-TargetPortalGroupTag
b)SSID-InitiatorName-TargetName.  By choosing the stated 
formulation (in conjunction with the ISID RULE), are you 
attempting to ensure that a parallel nexus cannot be created 
if one goes with either definition?

Thanks.
--
Mallikarjun 


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


>Mallikarjun,
>
>What you suggest is *more* than is required for uniqueness!  Again, that's
>an implementation choice that goes beyond the model.
>
>The model says that the *combination of ISID || TSID* has to be unique
>between a given initiator and a given target.
>When you say " If there are multiple sessions with an initiator, each would
>anyway be assigned a different TSID"  you are assuming that the TSID alone
>provide the uniqueness (between a pair).   It can, but it's more than is
>necessary.
>
>In short, you're still selecting an implementation.   Here's two other
>implementations.  Suppose I have exactly one Target Portal Group.  Then I
>can meet the uniqueness requirements by (a) enforcing the ISID RULE and (b)
>using TSID=1 *for every session*!  This one is "minimalist" with respect to
>the model.  (Because there is only one portal group, I can leverage the
>uniqueness of the ISID to meet the general uniqueness rule -- it's very
>different if I have more portal groups (see note below)) The "maximalist"
>implementation with respect to the model is (a) enforce the ISID RULE and
>(b') use a unique TSID for each session I have regardless of initiator
>name!
>
>The spec should say what is required to implement the model.  In my mind,
>that's the rule that says the combination of ISID and TSID (the SID) must
>be unique between a pair (initiator and target).   And that's all I'm
>asking for in the definition of TSID.
>
>Jim Hafner
>
>Note: If I had more than one portal group, I might legitimately see the
>same ISID (from the same initiator) come in to each portal group.  In that
>case, I need to use a different TSID for each such occurrence.  If I say,
>for example, that each portal group always uses it's portal group tag as
>it's TSID (not required, just a choice), then I get uniqueness of SID's
>again.  This is again, a minimalist implementation with respect to the
>model.   This also gives an example of why the TSID namespace "should" be
>partitioned between the portal groups, so they can always be sure that they
>won't accidentally create an SID that is the same as an existing one.  As
>long as the "half" of the SID one portal group generates is different from
>the half generated by another portal group, there will be no chance of
>collision.  [This is delegation of naming authority!!!]  The same principle
>holds on the initiator side in how it generates ISIDs.
>
>Are we getting closer?
>
>"Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on 08/28/2001 04:10:24 pm
>
>Please respond to cbm@rose.hp.com
>
>Sent by:  owner-ips@ece.cmu.edu
>
>
>To:   Jim Hafner/Almaden/IBM@IBMUS
>cc:   ips@ece.cmu.edu
>Subject:  RE: iSCSI: definition of TSID (2.11.4 of draft 07)
>
>
>
>Jim,
>
>I see your point about the current wording possibly suggesting
>an implementation option.
>
>Can I suggest the following text:
>
>  The TSID is a target-assigned tag which together with the InitiatorName
>  uniquely identifies the session within the target.
>
>It appears to me that it's all that's required for uniqueness, I
>don't think we need to mention ISID here.  If there are multiple
>sessions with an initiator, each would anyway be assigned a different
>TSID.  What am I missing?
>--
>Mallikarjun
>
>
>Mallikarjun Chadalapaka
>Networked Storage Architecture
>Network Storage Solutions Organization
>MS 5668   Hewlett-Packard, Roseville.
>cbm@rose.hp.com
>
>
>>Marj,
>>
>>Comments in line (as usual...).  But for the person of few words, I'd
>agree
>>with just this text (your first sentence only):
>>
>>"The TSID is the target assigned tag for a session with a specific named
>>initiator
>>that, together with the ISID uniquely identifies a session with that
>>initiator."
>>
>>(I moved the word "name" around because the session is with the initiator
>>not with the name.)
>>
>>Jim Hafner
>>
>>
>>"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
>@ece.cmu.edu
>>on 08/28/2001 02:46:45 pm
>>
>>Sent by:  owner-ips@ece.cmu.edu
>>
>>
>>To:   ips@ece.cmu.edu
>>cc:
>>Subject:  RE: iSCSI: definition of TSID (2.11.4 of draft 07)
>>
>>
>>
>>I'm curious why you've phrased it this way.  I think of it more like;
>>
>>"The TSID is the target assigned tag for a session with a specific
>>initiator
>>name that, together with the ISID uniquely identifies a session with that
>>initiator.
>><JLH>
>>I don't really see the subtle difference between this text and mine, so I
>>guess I don't have any problem with it.  At least it doesn't bind the
>>definition to anything SCSI'ish.
>></JLH>
>>
>>However, the target MUST enforce uniqueness of the SSID for a given I_T
>>combination (in order for login and recovery rules to make sense).
>><JLH>
>>I think I see what you're getting at here, but I don't think the words
>>capture it (it looks like an incorrect use of "I_T nexus" (a SCSI thing).
>>Do you mean:
>>
>>  "However, the target MUST enforce the uniqueness of the SSID [aside:
>>isn't this 'SID'?] for sessions with a given initiator."
>>
>>If so, I can go with this text, but I think this is stated in other places
>>and need not be here.  But I won't argue if it is also here.
>></JLH>
>>
>>The TSID MAY be a unique tag for a session with a specific initiator
>name."
>><JLH>
>>I don't think this belongs at all.  It is an implementation statement and
>>so outside the scope.  It's a true statement, but I don't think it should
>>be made explicit (especially in this part of the document -- I'd have less
>>problem with this in the "Notes to Implementers" but even then it is
>>suggesting a prefered(?) implementation).
>></JLH>
>>
>>I know the last "rule" is more for convenience than to follow the
>"modeling
>>rules" (but that's the most straight forward way to implement TSID
>>assignment?).  From the target viewpoint, it must first set the context of
>>the initiator name, secondly the ISID.
>><JLH>
>>First, it's not necessarily the most straightforward way. It could
>generate
>>a unique TSID for every session regardless of initiator name.  That gives
>>it a twobyte pointer to the session context.  That's a lot more efficient
>>(perhaps) than having to also have an initiator name in that "pointer".
>>So, if you go with your implementation, you have to index on the
>name+TSID,
>>and that's too big, so you need an indirect pointer to the context and at
>>that point it doesn't really matter what the TSID is relative to other
>>TSIDs; you can use the name + joint SID=ISID||TSID as your index (it's
>only
>>2 bytes more out of a possible 258!).
>>
>>So, I argue for no statement about implementation options, leave that to
>>the clever programmers!
>></JLH>
>>
>>Marjorie Krueger
>>Networked Storage Architecture
>>Networked Storage Solutions Org.
>>Hewlett-Packard
>>tel: +1 916 785 2656
>>fax: +1 916 785 0391
>>email: marjorie_krueger@hp.com
>>
>>> -----Original Message-----
>>> From: Jim Hafner [mailto:hafner@almaden.ibm.com]
>>> Sent: Tuesday, August 28, 2001 12:59 PM
>>> To: ips@ece.cmu.edu
>>> Subject: iSCSI: definition of TSID (2.11.4 of draft 07)
>>>
>>>
>>> Folks,
>>>
>>> The following text defines TSID in referenced document (and with the
>>> changes proposed by Mallikarjun):
>>>
>>> "The TSID is a tag that identifies the SCSI initiator port.
>>> TSID is set by
>>> the target.  It MUST be valid only in the final response."
>>>
>>> I'm trying to figure out what the TSID has to do with the
>>> SCSI initiator
>>> port.  As I understand it, they are completely unrelated (at an
>>> architecture level).  In implementation may choose to use the
>>> TSID as a
>>> pointer to the session in a unique way across all sessions in
>>> the target or
>>> in a unique way across all sessions with a given named iSCSI
>>> initiator or
>>> it can do any number of other things.  It is, in my opinion,
>>> unrelated to
>>> the SCSI initiator port.
>>>
>>> I would propose the following alternative text:
>>>
>>> "The TSID is a tag set by the target that, together with the ISID,
>>> identifies a unique session with the initiator."
>>>
>>> Comments?
>>>
>>> Jim Hafner
>>>
>>
>>
>>
>>
>
>
>
>
>
>




From owner-ips@ece.cmu.edu  Wed Aug 29 04:16:03 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18198
	for <ips-archive@odin.ietf.org>; Wed, 29 Aug 2001 04:16:03 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7T71dl25362
	for ips-outgoing; Wed, 29 Aug 2001 03:01:39 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7T71aP25358
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 03:01:36 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id JAA31540
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 09:01:25 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7T71Ov282486
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 09:01:24 +0200
Importance: Normal
Subject: RE: iSCSI: reusing ISID for recovery
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF98EDA907.87D6DF4B-ONC2256AB7.00222B9A@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Wed, 29 Aug 2001 09:23:35 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 29/08/2001 10:01:24
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Jim,

I think that making a new session bring down an old one makes just too easy
for common mistakes.

The scheme I've proposed - like the original option B - avoids just that by
letting the target know that this
was intentional - by adding the X bit.   But - as this is bound to bring
many an initiator writer to set always
the bit to "just cover for the case" I propose that the command fails if
the X bit was on but there was no need for it to be on.

I hope that this will get us to have a scheme in which both the common
mistakes can't do harm and the initiator writers
will not get away by always having the X bit on.

The price is a login in 2 steps in case of recovery - and I think this is
acceptable.

Julo

Jim Hafner/Almaden/IBM@IBMUS@ece.cmu.edu on 28-08-2001 19:04:34

Please respond to Jim Hafner/Almaden/IBM@IBMUS

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery




Julo,

I'm unclear why you think that option A isn't viable and why you think a
more complicated protocol is required here.

If the initiator 'lost his way' such that he thinks he has an existing
session, then he does the normal error recovery for that scenario (a la the
mechanisms Mallikarjun noted).  If he 'lost his way' so badly that he
doesn't even know he has an existing session, then option A is probably the
right thing to do.  In this case, he won't even know he's lost his way so
can't expect to set the X bit rationally.  He'd either not set it, and then
we need a rule for what the target does then OR he sets it knee-jerk in
which case there's no point in having it (as Marj, Deva, et al, have
argued).

In short, if he has knowledge of a lost session, he does session recovery.
If not, he just logs in and the target cleans up its end.

I'd like to close this issue as well, should there be a call for consensus?

Jim Hafner


Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 08/27/2001 09:39:03 pm

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery




Marjorie, Jim, Mallikarjun, Deva & all

Let's attemp to close that optimization that is so dear to your hearts.
If we go for the following scheme (very close to B):

The initiator knows "that he lost his way" (in the initiator jungle tough)
and issues a Login + ISID + TSID=0 + X bit on (meaning
" I think I have an old session - please clean it up for me" and open a new
one) then the target may do one of the following:

- before going to the effort of authenticating the new initiator check if a
session exist (if he has the initiator name) or go to authentication if it
does not
- If he has a session then clean it and create a new one
- If he does not have a session - we have 3 options:
a)- tell him hid did not have an old session and drop him
b)- tell him he did not have an old session but nevertheless create a new
one
c)- create a new session and do not tell him

With option a we are close to the old option c but the initiator does not
have to find the old session he can do now safely a new login
With b & c  we are back at the old b.

Which one would you give your kingdom for ( and my peace!).

Julo

"Dev" <deva@stargateip.com>@ece.cmu.edu on 28-08-2001 01:44:15

Please respond to <deva@stargateip.com>

Sent by:  owner-ips@ece.cmu.edu


To:   "KRUEGER,MARJORIE \(HP-Roseville,ex1\)" <marjorie_krueger@hp.com>,
      <ips@ece.cmu.edu>
cc:
Subject:  RE: iSCSI: reusing ISID for recovery



All,

When a session is already running authenticated, a login request with the
same
ISID + initiator fails authentication. Will the session continue to run?
Or
if the target fails during parameter negotiation?

I guess, yes. i.e. target will not act on the existing session, until
the login completes successfully. Or are there exception to these?

Thanks

Deva
Platys Communications





> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Saturday, August 25, 2001 12:23 AM
> To: ips@ece.cmu.edu
> Subject: RE: iSCSI: reusing ISID for recovery
>
>
>
> It may be another OS running on the same machine or CPU
> complex or it could
> be an attack.
> In any case if the initiator is up and fine he can as well do logout.
> It is a rare enough event for us not to try to optimize.
>
> The reboot is the only case in which the initiator can't
> logout and about
> which we care.
>
> And I would like to remind you all that we where on this
> exact thread more
> tan 3 months ago (other players).
> I just restated the rationale for an (apparent) newcomer.
>
> Julo
>
> "KRUEGER,MARJORIE (HP-Roseville,ex1)"
> <marjorie_krueger@hp.com>@ece.cmu.edu
> on 25-08-2001 03:51:43
>
> Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"
>       <marjorie_krueger@hp.com>
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   ips@ece.cmu.edu
> cc:
> Subject:  RE: iSCSI: reusing ISID for recovery
>
>
>
> I don't see how Option A is prone to "wild closing of sessions".  The
> target
> is only looking for sessions with this particular initiator
> and closing
> them
> if the ISID matches.
>
> If an initiator doesn't have a valid TSID (login w/TSID=0),
> it means it has
> lost state entirely (reboot) or knows it wants to immediately reset a
> session (NIC failure).  How could there possibly be a case where the
> initiator has an active valid session with the same ISID, but
> just doesn't
> know about it??  Rejecting the login seems pointless, since
> obviously the
> initiator either has a bug or intends to quickly reset the session.
>
> The behavior chosen (Option C) will cause the initiator's
> recovery to be
> delayed while the target NOPs all the connections and waits
> for them to
> time
> out - this will only delay the initiators recovery
> unnecessarily.  I can't
> help but think this will cause long term problems for the protocol.
>
> Marjorie Krueger
> Networked Storage Architecture
> Networked Storage Solutions Org.
> Hewlett-Packard
> tel: +1 916 785 2656
> fax: +1 916 785 0391
> email: marjorie_krueger@hp.com
>
> > -----Original Message-----
> > From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > Sent: Thursday, August 23, 2001 9:39 PM
> > To: ips@ece.cmu.edu
> > Subject: Re: iSCSI: reusing ISID for recovery (Was: RE: iSCSI
> > - Change -
> > Login/Text...)
> >
> >
> >
> > Mallikarjun,
> >
> > On  your point 1 that is what is stated today in the draft.
> >
> > On your point 2 option C is the one we took in the draft, after some
> > debate.
> >
> > Option A is prone to "wild closing of sessions" and option B is also
> > relaying to much on the good behaviour of the
> > client. It also introduces a "feature" that complicates
> login/logout.
> >
> > Our postion on this is  that the initiator should logout the session
> > explicitly if it can (and in this case it can as the target
> > has ascertained
> > that the session is alive).
> >
> > I agree that you may want to update the stayte diagram to
> > reflect this.
> >
> > Julo
> >
> >
> > "Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on
> 24-08-2001 01:46:40
> >
> > Please respond to cbm@rose.hp.com
> >
> > Sent by:  owner-ips@ece.cmu.edu
> >
> >
> > To:   ips@ece.cmu.edu
> > cc:
> > Subject:  iSCSI: reusing ISID for recovery (Was: RE: iSCSI
> - Change -
> >       Login/Text...)
> >
> >
> >
> > Julian and all:
> >
> > This thread mirrors another discussion some of us are
> > having in a different forum.  Following (two bullets 1
> > & 2 below) is what I proposed there, attempting to address
> > two issues -
> >      a) how to recover sessions when target and the initiator
> >            have conflicting views of the same TCP connection(s)?
> >            (Initiator NIC fails, but there's no I/O activity,
> >            and the target doesn't see any connection failure.)
> >      b) More specifically, how to address the above problem
> >            when the initiator *does not want* to re-instate failed
> >            connections since it only implements the mandatory
> >            session recovery?
> >
> > This could add clarity or muddle things up here, though hopefully
> > the former...
> >
> > 1 If login is sent with the same ISID, same TSID, same CID
> and X-bit,
> >   then it means a failed connection is being re-instated (whether
> >   or not there are multiple connections in the session).  This login
> >   attempt must be done before the connection timeout
> (transition M1),
> >   or if this is the only connection in the session, also before the
> >   session timeout (transition N6) - to be counted as a connection
> >   reinstatement effort.
> >            o CmdSN counters (CmdSN, ExpCmdSN) are continued.
> > Initiator
> >              must do command plugging when there's a mismatch
> >              between its CmdSN and ExpCmdSN in the login response.
> >            o Since this is an implicit connection logout, all
> > the active
> >              tasks on the connection are either internally
> terminated,
> >              or made non-allegiant (based on ErrorRecoveryLevel=x/y,
> >              TBD) for recovery.
> >
> > 2 If login is sent with the same ISID and TSID=0, the session (if it
> >   exists on the target) is being cleared and any active connections
> >   that the target sees must be immediately (at the end of the login
> >   process including any initiator authentication) transport reset.
> >   Initiator may attempt this only after it ascertains a
> > session failure
> >   on its end (ie. all connections entered RECOVERY_START).
> >            o CmdSN counters get reset.  Initiator has to perform the
> >              currently defined session recovery actions.
> >            o All active tasks of the session are internally
> > terminated.
> >
> >
> > Essentially, I was proposing extending the same notion of "implicit
> > logout" of a connection to the session level.  The options that I
> > see are -
> >
> >        A) Should iSCSI let it happen by default as stated above (ie.
> >           same ISID, TSID=0 always wipes out the
> pre-existing session
> >           on target, since we are mandating it to be used only when
> >           initiator sees a session failure)?
> >        B) Should iSCSI mandate making this intended cleanup explicit
> >           by setting a bit (Say C-bit, for Clear) in the
> Login Command
> >           PDU to prevent an accidental session cleanup with a buggy
> >           initiator code?
> >        C) Should iSCSI merely state that targets must ascertain
> >           the connection state(s) whenever a new session creation
> >           attempt is made with a known ISID and TSID=0?  (sort of
> >           defeats the intention of the initiator wanting quicker
> >           session recovery since the Login command PDU would have
> >           to idle till target ascertains the connection state(s)).
> >
> > I prefer A, or B.
> >
> > Going with A or B means that the description of transition N3
> > in the session state diagram would have to change to:
> >      Last LOGGED_IN connection had ceased to be LOGGED_IN,
> >         or a Login Command requesting clearing the session (also
> >         with C-bit set, if option B) was received by the target.
> >
> > The transition N7's description would have to be augmented as
> > well to:
> >         Session recovery attempt with an implicit logout,
> >         or connection reinstatement/new CID addition.
> >
> > Comments?
> > --
> > Mallikarjun
> >
> >
> > Mallikarjun Chadalapaka
> > Networked Storage Architecture
> > Network Storage Solutions Organization
> > MS 5668   Hewlett-Packard, Roseville.
> > cbm@rose.hp.com
> >
> >
> > >Stephen,
> > >
> > >That can happen as the target may set-up completely new TCP
> > connections
> > >(the old sockets are still there and look OK).
> > >Untill the login is  progessing he assumes that this is
> just another
> > >open-session attempt. Then he checks the old session and the
> > session is
> > >dead (initiator has closed the connections).
> > >
> > >The target has to distinguish only between a session that is
> > alive (and
> > >reject the new one) and one that its dead in which case it
> > can clean-up.
> > >
> > >Julo
> > >
> > >"Wheat, Stephen R" <stephen.r.wheat@intel.com> on
> 23-08-2001 22:50:56
> > >
> > >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> > >
> > >To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> > >cc:
> > >Subject:  RE: iSCSI - Change - Login/Text commands with the
> > binary stage
> > co
> > >          de
> > >
> > >
> > >
> > >Julian,
> > >
> > >I don't understand your answer.  For the scenario given, I
> > would presume
> > >then that the target would reject the new session attempt,
> > as it sees the
> > >previous session still "alive".  What is there to tell the
> > target that
> > this
> > >is any different from when the Initiator is erroneously using the
> > >repetitive
> > >session id?
> > >
> > >Thanks,
> > >Stephen
> > >
> > >-----Original Message-----
> > >From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > >Sent: Thursday, August 23, 2001 11:15 AM
> > >To: ips@ece.cmu.edu
> > >Subject: Re: iSCSI - Change - Login/Text commands with the
> > binary stage
> > >co de
> > >
> > >
> > >Stephen,
> > >
> > >1.If the initiator goes away for a while and reboots and
> there was no
> > >activity on the connections
> > >the target may see a session alive (I am not sure that it
> > has to appear on
> > >the state diagram but maybe).
> > >
> > >2.Again - I am not sure that the curent state diagram
> > includes death of
> > the
> > >initiator
> > >
> > >Julo
> > >
> > >"Wheat, Stephen R" <stephen.r.wheat@intel.com>@ece.cmu.edu
> > on 23-08-2001
> > >19:58:34
> > >
> > >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> > >
> > >Sent by:  owner-ips@ece.cmu.edu
> > >
> > >
> > >To:   ips@ece.cmu.edu
> > >cc:
> > >Subject:  Re: iSCSI - Change - Login/Text commands with the
> > binary stage
> > co
> > >      de
> > >
> > >
> > >
> > >Julian,
> > >
> > >1.3.6 ISID states that the target should check to see if the
> > old session
> > is
> > >still active when a duplicate session is detected.
> > >
> > >I have two questions, the second only if you answer in the
> > affirmative on
> > >the first ;^)
> > >
> > >1. Is there a properly executed sequence of events (i.e., no
> > coding error
> > >on
> > >the target side) where the session is not active, but the
> > target hadn't
> > >taken notice of it?  It appears this as a protocol-specified
> > means to work
> > >around a flaw in a target's implementation.  I interpret the
> > state diagram
> > >transitions as being atomic wrt other commands.  I.e., the
> > last logout
> > >would
> > >result in the various transitions of the connection/session
> > prior to the
> > >initiator starting the session up again.  And the target would have
> > >completed the transitions prior to handling a new session request.
> > >
> > >2. If you answered (1) in the affirmative, then the word
> > "Active" is not
> > >consistent with the 6.3 Session State Diagram.  Does this
> > mean the target
> > >got lost, due to transport failures of any sort, in its
> > transition from
> > >Q3-to-Q2-to-Q1?  It sounds like the intent is to close the
> > old session if
> > >the session was in Q2 or Q4, presuming if it were in Q1,  it
> > would not
> > have
> > >been found as a duplicate.
> > >
> > >Stephen
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
>
>
>












From owner-ips@ece.cmu.edu  Wed Aug 29 04:18:02 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18242
	for <ips-archive@odin.ietf.org>; Wed, 29 Aug 2001 04:18:01 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7T71hF25369
	for ips-outgoing; Wed, 29 Aug 2001 03:01:43 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7T71ZP25356
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 03:01:35 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id JAA53082
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 09:01:27 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7T71Qv277040
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 09:01:26 +0200
Importance: Normal
Subject: RE: iSCSI: definition of TSID (2.11.4 of draft 07)
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF98149C31.770D4870-ONC2256AB7.00247D8E@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Wed, 29 Aug 2001 09:44:22 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 29/08/2001 10:01:26
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Jim,

I think that Mallikarjun is right. Along with all our clever model elements
that closely align whatever we have with SAM
we have lost a statement about  the session-ID being unique (although it is
implied by the rest - how else could you know to what session to add a new
connection).  We should say - in 1.2.1 something like:

"A session-ID uniquely identifies a session at the initiator and at the
target."

Julo

"Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on 29-08-2001 04:20:16

Please respond to cbm@rose.hp.com

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: definition of TSID (2.11.4 of draft 07)



Jim,

Thanks for the explanation.

>The model says that the *combination of ISID || TSID* has to be unique
>between a given initiator and a given target.

Actually, I do not find this formulation stated anywhere
in rev07.

The closest about TSID assignment policy is this sentence
in section 1.5.3: "The TSID name space of the iSCSI Initiator
should be partitioned among the target portal groups."
My earlier comments were based on this quote.

More importantly, let me try to understand the reasoning
behind this formulation.  The only reason that I could come
up with is to preclude a "parallel nexus".  In our previous
conversation, we identified two types of nexus ids for this
enforcement - a)InitiatorName-ISID-TargetName-TargetPortalGroupTag
b)SSID-InitiatorName-TargetName.  By choosing the stated
formulation (in conjunction with the ISID RULE), are you
attempting to ensure that a parallel nexus cannot be created
if one goes with either definition?

Thanks.
--
Mallikarjun


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


>Mallikarjun,
>
>What you suggest is *more* than is required for uniqueness!  Again, that's
>an implementation choice that goes beyond the model.
>
>The model says that the *combination of ISID || TSID* has to be unique
>between a given initiator and a given target.
>When you say " If there are multiple sessions with an initiator, each
would
>anyway be assigned a different TSID"  you are assuming that the TSID alone
>provide the uniqueness (between a pair).   It can, but it's more than is
>necessary.
>
>In short, you're still selecting an implementation.   Here's two other
>implementations.  Suppose I have exactly one Target Portal Group.  Then I
>can meet the uniqueness requirements by (a) enforcing the ISID RULE and
(b)
>using TSID=1 *for every session*!  This one is "minimalist" with respect
to
>the model.  (Because there is only one portal group, I can leverage the
>uniqueness of the ISID to meet the general uniqueness rule -- it's very
>different if I have more portal groups (see note below)) The "maximalist"
>implementation with respect to the model is (a) enforce the ISID RULE and
>(b') use a unique TSID for each session I have regardless of initiator
>name!
>
>The spec should say what is required to implement the model.  In my mind,
>that's the rule that says the combination of ISID and TSID (the SID) must
>be unique between a pair (initiator and target).   And that's all I'm
>asking for in the definition of TSID.
>
>Jim Hafner
>
>Note: If I had more than one portal group, I might legitimately see the
>same ISID (from the same initiator) come in to each portal group.  In that
>case, I need to use a different TSID for each such occurrence.  If I say,
>for example, that each portal group always uses it's portal group tag as
>it's TSID (not required, just a choice), then I get uniqueness of SID's
>again.  This is again, a minimalist implementation with respect to the
>model.   This also gives an example of why the TSID namespace "should" be
>partitioned between the portal groups, so they can always be sure that
they
>won't accidentally create an SID that is the same as an existing one.  As
>long as the "half" of the SID one portal group generates is different from
>the half generated by another portal group, there will be no chance of
>collision.  [This is delegation of naming authority!!!]  The same
principle
>holds on the initiator side in how it generates ISIDs.
>
>Are we getting closer?
>
>"Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on 08/28/2001 04:10:24 pm
>
>Please respond to cbm@rose.hp.com
>
>Sent by:  owner-ips@ece.cmu.edu
>
>
>To:   Jim Hafner/Almaden/IBM@IBMUS
>cc:   ips@ece.cmu.edu
>Subject:  RE: iSCSI: definition of TSID (2.11.4 of draft 07)
>
>
>
>Jim,
>
>I see your point about the current wording possibly suggesting
>an implementation option.
>
>Can I suggest the following text:
>
>  The TSID is a target-assigned tag which together with the InitiatorName
>  uniquely identifies the session within the target.
>
>It appears to me that it's all that's required for uniqueness, I
>don't think we need to mention ISID here.  If there are multiple
>sessions with an initiator, each would anyway be assigned a different
>TSID.  What am I missing?
>--
>Mallikarjun
>
>
>Mallikarjun Chadalapaka
>Networked Storage Architecture
>Network Storage Solutions Organization
>MS 5668   Hewlett-Packard, Roseville.
>cbm@rose.hp.com
>
>
>>Marj,
>>
>>Comments in line (as usual...).  But for the person of few words, I'd
>agree
>>with just this text (your first sentence only):
>>
>>"The TSID is the target assigned tag for a session with a specific named
>>initiator
>>that, together with the ISID uniquely identifies a session with that
>>initiator."
>>
>>(I moved the word "name" around because the session is with the initiator
>>not with the name.)
>>
>>Jim Hafner
>>
>>
>>"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
>@ece.cmu.edu
>>on 08/28/2001 02:46:45 pm
>>
>>Sent by:  owner-ips@ece.cmu.edu
>>
>>
>>To:   ips@ece.cmu.edu
>>cc:
>>Subject:  RE: iSCSI: definition of TSID (2.11.4 of draft 07)
>>
>>
>>
>>I'm curious why you've phrased it this way.  I think of it more like;
>>
>>"The TSID is the target assigned tag for a session with a specific
>>initiator
>>name that, together with the ISID uniquely identifies a session with that
>>initiator.
>><JLH>
>>I don't really see the subtle difference between this text and mine, so I
>>guess I don't have any problem with it.  At least it doesn't bind the
>>definition to anything SCSI'ish.
>></JLH>
>>
>>However, the target MUST enforce uniqueness of the SSID for a given I_T
>>combination (in order for login and recovery rules to make sense).
>><JLH>
>>I think I see what you're getting at here, but I don't think the words
>>capture it (it looks like an incorrect use of "I_T nexus" (a SCSI thing).
>>Do you mean:
>>
>>  "However, the target MUST enforce the uniqueness of the SSID [aside:
>>isn't this 'SID'?] for sessions with a given initiator."
>>
>>If so, I can go with this text, but I think this is stated in other
places
>>and need not be here.  But I won't argue if it is also here.
>></JLH>
>>
>>The TSID MAY be a unique tag for a session with a specific initiator
>name."
>><JLH>
>>I don't think this belongs at all.  It is an implementation statement and
>>so outside the scope.  It's a true statement, but I don't think it should
>>be made explicit (especially in this part of the document -- I'd have
less
>>problem with this in the "Notes to Implementers" but even then it is
>>suggesting a prefered(?) implementation).
>></JLH>
>>
>>I know the last "rule" is more for convenience than to follow the
>"modeling
>>rules" (but that's the most straight forward way to implement TSID
>>assignment?).  From the target viewpoint, it must first set the context
of
>>the initiator name, secondly the ISID.
>><JLH>
>>First, it's not necessarily the most straightforward way. It could
>generate
>>a unique TSID for every session regardless of initiator name.  That gives
>>it a twobyte pointer to the session context.  That's a lot more efficient
>>(perhaps) than having to also have an initiator name in that "pointer".
>>So, if you go with your implementation, you have to index on the
>name+TSID,
>>and that's too big, so you need an indirect pointer to the context and at
>>that point it doesn't really matter what the TSID is relative to other
>>TSIDs; you can use the name + joint SID=ISID||TSID as your index (it's
>only
>>2 bytes more out of a possible 258!).
>>
>>So, I argue for no statement about implementation options, leave that to
>>the clever programmers!
>></JLH>
>>
>>Marjorie Krueger
>>Networked Storage Architecture
>>Networked Storage Solutions Org.
>>Hewlett-Packard
>>tel: +1 916 785 2656
>>fax: +1 916 785 0391
>>email: marjorie_krueger@hp.com
>>
>>> -----Original Message-----
>>> From: Jim Hafner [mailto:hafner@almaden.ibm.com]
>>> Sent: Tuesday, August 28, 2001 12:59 PM
>>> To: ips@ece.cmu.edu
>>> Subject: iSCSI: definition of TSID (2.11.4 of draft 07)
>>>
>>>
>>> Folks,
>>>
>>> The following text defines TSID in referenced document (and with the
>>> changes proposed by Mallikarjun):
>>>
>>> "The TSID is a tag that identifies the SCSI initiator port.
>>> TSID is set by
>>> the target.  It MUST be valid only in the final response."
>>>
>>> I'm trying to figure out what the TSID has to do with the
>>> SCSI initiator
>>> port.  As I understand it, they are completely unrelated (at an
>>> architecture level).  In implementation may choose to use the
>>> TSID as a
>>> pointer to the session in a unique way across all sessions in
>>> the target or
>>> in a unique way across all sessions with a given named iSCSI
>>> initiator or
>>> it can do any number of other things.  It is, in my opinion,
>>> unrelated to
>>> the SCSI initiator port.
>>>
>>> I would propose the following alternative text:
>>>
>>> "The TSID is a tag set by the target that, together with the ISID,
>>> identifies a unique session with the initiator."
>>>
>>> Comments?
>>>
>>> Jim Hafner
>>>
>>
>>
>>
>>
>
>
>
>
>
>







From owner-ips@ece.cmu.edu  Wed Aug 29 10:23:16 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28749
	for <ips-archive@odin.ietf.org>; Wed, 29 Aug 2001 10:23:16 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7TCuji20254
	for ips-outgoing; Wed, 29 Aug 2001 08:56:45 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7TBKvP16231
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 07:20:57 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19919;
	Wed, 29 Aug 2001 07:19:37 -0400 (EDT)
Message-Id: <200108291119.HAA19919@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ips@ece.cmu.edu
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ips-iscsi-boot-03.txt
Date: Wed, 29 Aug 2001 07:19:36 -0400
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Storage Working Group of the IETF.

	Title		: Bootstrapping Clients using the iSCSI Protocol
	Author(s)	: P. Sarkar, D. Missimer, C. Sapuntzakis
	Filename	: draft-ietf-ips-iscsi-boot-03.txt
	Pages		: 8
	Date		: 28-Aug-01
	
The Small Computer Systems Interface (SCSI) is a popular family of
protocols for communicating with I/O devices, especially storage
devices.  iSCSI is a proposed transport protocol for SCSI that
operates on top of TCP[12].  This memo describes a standard mechanism
to enable clients to bootstrap themselves using the iSCSI protocol.
The goal of this standard is to enable iSCSI boot clients to obtain
the information to open an iSCSI session with the iSCSI boot server,
assuming this information is not available.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-boot-03.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ips-iscsi-boot-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ips-iscsi-boot-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010828120830.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ips-iscsi-boot-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ips-iscsi-boot-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010828120830.I-D@ietf.org>

--OtherAccess--

--NextPart--



From owner-ips@ece.cmu.edu  Wed Aug 29 13:17:51 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03510
	for <ips-archive@odin.ietf.org>; Wed, 29 Aug 2001 13:17:45 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7TFfO529683
	for ips-outgoing; Wed, 29 Aug 2001 11:41:24 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from sentinel.sanera.net (ns1.sanera.net [208.253.254.10])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7TFfMP29679
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 11:41:22 -0400 (EDT)
Received: from newton.sanera.net (newton [192.168.254.11])
	by sentinel.sanera.net (8.11.2/8.11.2) with ESMTP id f7TFfH220276
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 08:41:17 -0700
Received: from strahmw2k (dhcp-pc-100-165.sanera.net [192.168.100.165])
	by newton.sanera.net (8.11.4/8.11.4) with SMTP id f7TFfBU08074
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 08:41:11 -0700 (PDT)
From: "Bill Strahm" <bill@sanera.net>
To: "Ips@Ece. Cmu. Edu" <ips@ece.cmu.edu>
Subject: ISCSI: User authentication vs. Machine Authentication for iSCSI
Date: Wed, 29 Aug 2001 08:40:54 -0700
Message-ID: <HDECJFNIFJBIAINDCFOMKEJOCAAA.bill@sanera.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Importance: Normal
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

I have been fighting with this problem since I left LA.

I am not aware of any usage scenarios today where block devices are owned by
the user rather than the machine.  I will conceed that in many instances the
first thing the system does is assign the resource to a use (tape, scanner,
etc.) but the machine still owns the resource and can in fact remove it out
from under the user...

I am not to certain how I could build a trusted iSCSI environment where one
user would have no knowledge about what was happening with other users in a
malicious environment (especially where a system was participating in the
exposure of resourses).  Examples of this include things like co-located Web
hosting where a single user scans process memory looking for 1Kbit of random
data, and when finding it attempts to determine if that is the private key
of a user sharing the resource.

The reason I am bringing this up, is I am not sure trying to define security
above the machine level makes any sense for iSCSI.  Aren't most SCSI devices
owned by the Operating System not the User and partitioned out by the
Operating System to the users ?  If this is the case many of our
authentication methods simplify to simple IKE identities.

Bill



From owner-ips@ece.cmu.edu  Wed Aug 29 13:21:38 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03654
	for <ips-archive@odin.ietf.org>; Wed, 29 Aug 2001 13:21:38 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7TFYkh29283
	for ips-outgoing; Wed, 29 Aug 2001 11:34:46 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from sentinel.sanera.net (ns1.sanera.net [208.253.254.10])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7TFYiP29278
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 11:34:44 -0400 (EDT)
Received: from newton.sanera.net (newton [192.168.254.11])
	by sentinel.sanera.net (8.11.2/8.11.2) with ESMTP id f7TFYZ220236
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 08:34:35 -0700
Received: from strahmw2k (dhcp-pc-100-165.sanera.net [192.168.100.165])
	by newton.sanera.net (8.11.4/8.11.4) with SMTP id f7TFYTU07665
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 08:34:29 -0700 (PDT)
From: "Bill Strahm" <bill@sanera.net>
To: "Ips@Ece. Cmu. Edu" <ips@ece.cmu.edu>
Subject: ISCSI: Required Crytographic transforms for iSCSI
Date: Wed, 29 Aug 2001 08:34:11 -0700
Message-ID: <HDECJFNIFJBIAINDCFOMGEJOCAAA.bill@sanera.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Importance: Normal
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

When we were talking about required transforms yesterday in Los Angeles, I
believe that we forgot a VERY important transform that need to be a MUST
implement for ESP.  That is the NULL Encryption Algorithm (RFC2410).

I propose that this algorithm is a MUST implement for all iSCSI
implementations

Bill
Sanera Systems Inc.



From owner-ips@ece.cmu.edu  Wed Aug 29 13:24:14 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03816
	for <ips-archive@odin.ietf.org>; Wed, 29 Aug 2001 13:24:12 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7TFHhv28246
	for ips-outgoing; Wed, 29 Aug 2001 11:17:43 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e34.bld.us.ibm.com (e34.co.us.ibm.com [32.97.110.132])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7TFHeP28229
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 11:17:41 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e34.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA86472
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 11:15:27 -0400
Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7TFGM1127166
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 09:16:22 -0600
Importance: Normal
Subject: RE: iSCSI: definition of TSID (2.11.4 of draft 07)
To: ips@ece.cmu.edu
From: "Jim Hafner" <hafner@almaden.ibm.com>
Date: Wed, 29 Aug 2001 08:16:20 -0700
Message-ID: <OF1F698899.0CFFEBFA-ON88256AB7.005139BA@boulder.ibm.com>
X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at
 08/29/2001 08:16:22 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Mallikarjun,

There are two assumptions that go into the model and requirements (as I see
it).  One is currently implicit in draft-07 and is an iSCSI issue, the
other is a bit more explicit and is a SCSI issue with iSCSI implications.
These are

A) (Uniqueness of SIDs) Between a given iSCSI Initiator Node and iSCSI
Target Node there can be only one session with a given SID.  [This is
implied by the language that says that a login attempt that uses an
existing SID=ISID||TSID is an attempt to *add* a connection to the existing
session. (This is the response I got from Julian when I suggested making
this explicit.)

B) (No parallel I_T nexus) Between a given SCSI Initiator Port and SCSI
Target Port there can be only one nexus.  [With the definition of SCSI
Initiator Port as the endpoint of a session identified by iSCSI Initiator
Name + ISID, and with the definition of the SCSI Target Port as the target
portal group identified by the iSCSI Target Name + portal group tag, we get
the ISID RULE as stated (or intended) in the draft.]

The minimalist requirement is to meet the these two rules (assumptions).

There is a typo in the text you quote.  It should read "The TSID name space
of the iSCSI Target should be partitioned among the target portal groups".
But as we've discussed this really less of a requirement than it is a
desirable "note to implementers" (and I'm going to propose that this sort
of text move to that section).

In what you say below, the "no parallel nexus" (assumption B) is enforced
by the ISID RULE.  Assumption A (uniquely identified sessions) is enforced
if the target does the right thing when selecting a TSID *to pair with* an
ISID.  My text for the definition of TSID simply says that the target
should find a new TSID that enforces Assumption A (no more and no less).
All the stuff about partitioning name space belongs in "notes to
implementers".  So, between my proposed definition of TSID and the ISID
RULE, both assumptions are satisfied and the model works.  No finer
restrictions are required *by the model*.

Note that in all this description, we haven't had to provide a formal
definition of "nexus identifier".
The reason is two fold.  First, independent of what we might use to
identify them, the I_T nexus is defined as a relationship between a SCSI
Initiator Port and a SCSI Target Port.  Assumption B says we can't have two
such relationships active at one time.  As I've noted above, the ISID RULE
enforces that.  Second, the nexus identifier doesn't get used in SAM-2
explicitly anyway and in SAM-3 it will probably be "up to the transport to
define AND relative to the viewpoint of the initiator or target".  That
last part means that the nexus identifier may not need a globally unique
value, but may depend on whose end of the nexus you're looking from.  E.g.,
the target side need only track the "relative target port" and need not
care about the external address/name/identifier of that port when defining
its value for the nexus identifier.  In short, the nexus identifier issue
is tangential (and we can safely skip it formally).


Jim Hafner

[P.S. See also the proposed rewrite of the relevant draft sections in the
stuff I sent you off-line, as well, and see if that doesn't help clarify.]

"Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on 08/28/2001 06:20:16 pm

Please respond to cbm@rose.hp.com

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: definition of TSID (2.11.4 of draft 07)



Jim,

Thanks for the explanation.

>The model says that the *combination of ISID || TSID* has to be unique
>between a given initiator and a given target.

Actually, I do not find this formulation stated anywhere
in rev07.

The closest about TSID assignment policy is this sentence
in section 1.5.3: "The TSID name space of the iSCSI Initiator
should be partitioned among the target portal groups."
My earlier comments were based on this quote.

More importantly, let me try to understand the reasoning
behind this formulation.  The only reason that I could come
up with is to preclude a "parallel nexus".  In our previous
conversation, we identified two types of nexus ids for this
enforcement - a)InitiatorName-ISID-TargetName-TargetPortalGroupTag
b)SSID-InitiatorName-TargetName.  By choosing the stated
formulation (in conjunction with the ISID RULE), are you
attempting to ensure that a parallel nexus cannot be created
if one goes with either definition?

Thanks.
--
Mallikarjun


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


>Mallikarjun,
>
>What you suggest is *more* than is required for uniqueness!  Again, that's
>an implementation choice that goes beyond the model.
>
>The model says that the *combination of ISID || TSID* has to be unique
>between a given initiator and a given target.
>When you say " If there are multiple sessions with an initiator, each
would
>anyway be assigned a different TSID"  you are assuming that the TSID alone
>provide the uniqueness (between a pair).   It can, but it's more than is
>necessary.
>
>In short, you're still selecting an implementation.   Here's two other
>implementations.  Suppose I have exactly one Target Portal Group.  Then I
>can meet the uniqueness requirements by (a) enforcing the ISID RULE and
(b)
>using TSID=1 *for every session*!  This one is "minimalist" with respect
to
>the model.  (Because there is only one portal group, I can leverage the
>uniqueness of the ISID to meet the general uniqueness rule -- it's very
>different if I have more portal groups (see note below)) The "maximalist"
>implementation with respect to the model is (a) enforce the ISID RULE and
>(b') use a unique TSID for each session I have regardless of initiator
>name!
>
>The spec should say what is required to implement the model.  In my mind,
>that's the rule that says the combination of ISID and TSID (the SID) must
>be unique between a pair (initiator and target).   And that's all I'm
>asking for in the definition of TSID.
>
>Jim Hafner
>
>Note: If I had more than one portal group, I might legitimately see the
>same ISID (from the same initiator) come in to each portal group.  In that
>case, I need to use a different TSID for each such occurrence.  If I say,
>for example, that each portal group always uses it's portal group tag as
>it's TSID (not required, just a choice), then I get uniqueness of SID's
>again.  This is again, a minimalist implementation with respect to the
>model.   This also gives an example of why the TSID namespace "should" be
>partitioned between the portal groups, so they can always be sure that
they
>won't accidentally create an SID that is the same as an existing one.  As
>long as the "half" of the SID one portal group generates is different from
>the half generated by another portal group, there will be no chance of
>collision.  [This is delegation of naming authority!!!]  The same
principle
>holds on the initiator side in how it generates ISIDs.
>
>Are we getting closer?
>
>"Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on 08/28/2001 04:10:24 pm
>
>Please respond to cbm@rose.hp.com
>
>Sent by:  owner-ips@ece.cmu.edu
>
>
>To:   Jim Hafner/Almaden/IBM@IBMUS
>cc:   ips@ece.cmu.edu
>Subject:  RE: iSCSI: definition of TSID (2.11.4 of draft 07)
>
>
>
>Jim,
>
>I see your point about the current wording possibly suggesting
>an implementation option.
>
>Can I suggest the following text:
>
>  The TSID is a target-assigned tag which together with the InitiatorName
>  uniquely identifies the session within the target.
>
>It appears to me that it's all that's required for uniqueness, I
>don't think we need to mention ISID here.  If there are multiple
>sessions with an initiator, each would anyway be assigned a different
>TSID.  What am I missing?
>--
>Mallikarjun
>
>
>Mallikarjun Chadalapaka
>Networked Storage Architecture
>Network Storage Solutions Organization
>MS 5668   Hewlett-Packard, Roseville.
>cbm@rose.hp.com
>
>
>>Marj,
>>
>>Comments in line (as usual...).  But for the person of few words, I'd
>agree
>>with just this text (your first sentence only):
>>
>>"The TSID is the target assigned tag for a session with a specific named
>>initiator
>>that, together with the ISID uniquely identifies a session with that
>>initiator."
>>
>>(I moved the word "name" around because the session is with the initiator
>>not with the name.)
>>
>>Jim Hafner
>>
>>
>>"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
>@ece.cmu.edu
>>on 08/28/2001 02:46:45 pm
>>
>>Sent by:  owner-ips@ece.cmu.edu
>>
>>
>>To:   ips@ece.cmu.edu
>>cc:
>>Subject:  RE: iSCSI: definition of TSID (2.11.4 of draft 07)
>>
>>
>>
>>I'm curious why you've phrased it this way.  I think of it more like;
>>
>>"The TSID is the target assigned tag for a session with a specific
>>initiator
>>name that, together with the ISID uniquely identifies a session with that
>>initiator.
>><JLH>
>>I don't really see the subtle difference between this text and mine, so I
>>guess I don't have any problem with it.  At least it doesn't bind the
>>definition to anything SCSI'ish.
>></JLH>
>>
>>However, the target MUST enforce uniqueness of the SSID for a given I_T
>>combination (in order for login and recovery rules to make sense).
>><JLH>
>>I think I see what you're getting at here, but I don't think the words
>>capture it (it looks like an incorrect use of "I_T nexus" (a SCSI thing).
>>Do you mean:
>>
>>  "However, the target MUST enforce the uniqueness of the SSID [aside:
>>isn't this 'SID'?] for sessions with a given initiator."
>>
>>If so, I can go with this text, but I think this is stated in other
places
>>and need not be here.  But I won't argue if it is also here.
>></JLH>
>>
>>The TSID MAY be a unique tag for a session with a specific initiator
>name."
>><JLH>
>>I don't think this belongs at all.  It is an implementation statement and
>>so outside the scope.  It's a true statement, but I don't think it should
>>be made explicit (especially in this part of the document -- I'd have
less
>>problem with this in the "Notes to Implementers" but even then it is
>>suggesting a prefered(?) implementation).
>></JLH>
>>
>>I know the last "rule" is more for convenience than to follow the
>"modeling
>>rules" (but that's the most straight forward way to implement TSID
>>assignment?).  From the target viewpoint, it must first set the context
of
>>the initiator name, secondly the ISID.
>><JLH>
>>First, it's not necessarily the most straightforward way. It could
>generate
>>a unique TSID for every session regardless of initiator name.  That gives
>>it a twobyte pointer to the session context.  That's a lot more efficient
>>(perhaps) than having to also have an initiator name in that "pointer".
>>So, if you go with your implementation, you have to index on the
>name+TSID,
>>and that's too big, so you need an indirect pointer to the context and at
>>that point it doesn't really matter what the TSID is relative to other
>>TSIDs; you can use the name + joint SID=ISID||TSID as your index (it's
>only
>>2 bytes more out of a possible 258!).
>>
>>So, I argue for no statement about implementation options, leave that to
>>the clever programmers!
>></JLH>
>>
>>Marjorie Krueger
>>Networked Storage Architecture
>>Networked Storage Solutions Org.
>>Hewlett-Packard
>>tel: +1 916 785 2656
>>fax: +1 916 785 0391
>>email: marjorie_krueger@hp.com
>>
>>> -----Original Message-----
>>> From: Jim Hafner [mailto:hafner@almaden.ibm.com]
>>> Sent: Tuesday, August 28, 2001 12:59 PM
>>> To: ips@ece.cmu.edu
>>> Subject: iSCSI: definition of TSID (2.11.4 of draft 07)
>>>
>>>
>>> Folks,
>>>
>>> The following text defines TSID in referenced document (and with the
>>> changes proposed by Mallikarjun):
>>>
>>> "The TSID is a tag that identifies the SCSI initiator port.
>>> TSID is set by
>>> the target.  It MUST be valid only in the final response."
>>>
>>> I'm trying to figure out what the TSID has to do with the
>>> SCSI initiator
>>> port.  As I understand it, they are completely unrelated (at an
>>> architecture level).  In implementation may choose to use the
>>> TSID as a
>>> pointer to the session in a unique way across all sessions in
>>> the target or
>>> in a unique way across all sessions with a given named iSCSI
>>> initiator or
>>> it can do any number of other things.  It is, in my opinion,
>>> unrelated to
>>> the SCSI initiator port.
>>>
>>> I would propose the following alternative text:
>>>
>>> "The TSID is a tag set by the target that, together with the ISID,
>>> identifies a unique session with the initiator."
>>>
>>> Comments?
>>>
>>> Jim Hafner
>>>
>>
>>
>>
>>
>
>
>
>
>
>







From owner-ips@ece.cmu.edu  Wed Aug 29 13:26:13 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03864
	for <ips-archive@odin.ietf.org>; Wed, 29 Aug 2001 13:26:10 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7TFwnC00839
	for ips-outgoing; Wed, 29 Aug 2001 11:58:49 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from clyde.stargateip.com ([209.237.5.66])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7TFweP00820
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 11:58:40 -0400 (EDT)
Received: from bluestar (dhcp-101.stargateip.com [10.10.5.101])
	by clyde.stargateip.com (8.9.1/8.9.1) with SMTP id IAA29880;
	Wed, 29 Aug 2001 08:52:38 -0700 (PDT)
Reply-To: <deva@stargateip.com>
From: "Dev" <deva@stargateip.com>
To: "Julian Satran" <Julian_Satran@il.ibm.com>, <ips@ece.cmu.edu>
Subject: RE: iSCSI: reusing ISID for recovery
Date: Wed, 29 Aug 2001 09:03:40 -0700
Message-ID: <NFBBKBDFJCDMGCBKJLCJCEHJFDAA.deva@stargateip.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Importance: Normal
In-Reply-To: <OF98EDA907.87D6DF4B-ONC2256AB7.00222B9A@telaviv.ibm.com>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Julian,

>But - as this is bound to bring
>many an initiator writer to set always
>the bit to "just cover for the case" I propose that the command fails if
>the X bit was on but there was no need for it to be on.

The only need to set the X-bit (when ISID, TSID=0) could be to forcibly
close a pre-existing session, if any in the target right?

I agree with this proposal, as this forces the initiator to issue the
command
with an X-bit only when there is an error (a session already exists).
I also like that returning an error when there is no need to set an X-bit,
as it discourages the initiators to set the X-bit by default, for opening
a session.

Thanks

Deva
Platys Communications.




I think that making a new session bring down an old one makes just too easy
for common mistakes.

The scheme I've proposed - like the original option B - avoids just that by
letting the target know that this
was intentional - by adding the X bit.   But - as this is bound to bring
many an initiator writer to set always
the bit to "just cover for the case" I propose that the command fails if
the X bit was on but there was no need for it to be on.

I hope that this will get us to have a scheme in which both the common
mistakes can't do harm and the initiator writers
will not get away by always having the X bit on.

The price is a login in 2 steps in case of recovery - and I think this is
acceptable.

Julo

Jim Hafner/Almaden/IBM@IBMUS@ece.cmu.edu on 28-08-2001 19:04:34

Please respond to Jim Hafner/Almaden/IBM@IBMUS

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery




Julo,

I'm unclear why you think that option A isn't viable and why you think a
more complicated protocol is required here.

If the initiator 'lost his way' such that he thinks he has an existing
session, then he does the normal error recovery for that scenario (a la the
mechanisms Mallikarjun noted).  If he 'lost his way' so badly that he
doesn't even know he has an existing session, then option A is probably the
right thing to do.  In this case, he won't even know he's lost his way so
can't expect to set the X bit rationally.  He'd either not set it, and then
we need a rule for what the target does then OR he sets it knee-jerk in
which case there's no point in having it (as Marj, Deva, et al, have
argued).

In short, if he has knowledge of a lost session, he does session recovery.
If not, he just logs in and the target cleans up its end.

I'd like to close this issue as well, should there be a call for consensus?

Jim Hafner


Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 08/27/2001 09:39:03 pm

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery




Marjorie, Jim, Mallikarjun, Deva & all

Let's attemp to close that optimization that is so dear to your hearts.
If we go for the following scheme (very close to B):

The initiator knows "that he lost his way" (in the initiator jungle tough)
and issues a Login + ISID + TSID=0 + X bit on (meaning
" I think I have an old session - please clean it up for me" and open a new
one) then the target may do one of the following:

- before going to the effort of authenticating the new initiator check if a
session exist (if he has the initiator name) or go to authentication if it
does not
- If he has a session then clean it and create a new one
- If he does not have a session - we have 3 options:
a)- tell him hid did not have an old session and drop him
b)- tell him he did not have an old session but nevertheless create a new
one
c)- create a new session and do not tell him

With option a we are close to the old option c but the initiator does not
have to find the old session he can do now safely a new login
With b & c  we are back at the old b.

Which one would you give your kingdom for ( and my peace!).

Julo

"Dev" <deva@stargateip.com>@ece.cmu.edu on 28-08-2001 01:44:15

Please respond to <deva@stargateip.com>

Sent by:  owner-ips@ece.cmu.edu


To:   "KRUEGER,MARJORIE \(HP-Roseville,ex1\)" <marjorie_krueger@hp.com>,
      <ips@ece.cmu.edu>
cc:
Subject:  RE: iSCSI: reusing ISID for recovery



All,

When a session is already running authenticated, a login request with the
same
ISID + initiator fails authentication. Will the session continue to run?
Or
if the target fails during parameter negotiation?

I guess, yes. i.e. target will not act on the existing session, until
the login completes successfully. Or are there exception to these?

Thanks

Deva
Platys Communications





> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Saturday, August 25, 2001 12:23 AM
> To: ips@ece.cmu.edu
> Subject: RE: iSCSI: reusing ISID for recovery
>
>
>
> It may be another OS running on the same machine or CPU
> complex or it could
> be an attack.
> In any case if the initiator is up and fine he can as well do logout.
> It is a rare enough event for us not to try to optimize.
>
> The reboot is the only case in which the initiator can't
> logout and about
> which we care.
>
> And I would like to remind you all that we where on this
> exact thread more
> tan 3 months ago (other players).
> I just restated the rationale for an (apparent) newcomer.
>
> Julo
>
> "KRUEGER,MARJORIE (HP-Roseville,ex1)"
> <marjorie_krueger@hp.com>@ece.cmu.edu
> on 25-08-2001 03:51:43
>
> Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"
>       <marjorie_krueger@hp.com>
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   ips@ece.cmu.edu
> cc:
> Subject:  RE: iSCSI: reusing ISID for recovery
>
>
>
> I don't see how Option A is prone to "wild closing of sessions".  The
> target
> is only looking for sessions with this particular initiator
> and closing
> them
> if the ISID matches.
>
> If an initiator doesn't have a valid TSID (login w/TSID=0),
> it means it has
> lost state entirely (reboot) or knows it wants to immediately reset a
> session (NIC failure).  How could there possibly be a case where the
> initiator has an active valid session with the same ISID, but
> just doesn't
> know about it??  Rejecting the login seems pointless, since
> obviously the
> initiator either has a bug or intends to quickly reset the session.
>
> The behavior chosen (Option C) will cause the initiator's
> recovery to be
> delayed while the target NOPs all the connections and waits
> for them to
> time
> out - this will only delay the initiators recovery
> unnecessarily.  I can't
> help but think this will cause long term problems for the protocol.
>
> Marjorie Krueger
> Networked Storage Architecture
> Networked Storage Solutions Org.
> Hewlett-Packard
> tel: +1 916 785 2656
> fax: +1 916 785 0391
> email: marjorie_krueger@hp.com
>
> > -----Original Message-----
> > From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > Sent: Thursday, August 23, 2001 9:39 PM
> > To: ips@ece.cmu.edu
> > Subject: Re: iSCSI: reusing ISID for recovery (Was: RE: iSCSI
> > - Change -
> > Login/Text...)
> >
> >
> >
> > Mallikarjun,
> >
> > On  your point 1 that is what is stated today in the draft.
> >
> > On your point 2 option C is the one we took in the draft, after some
> > debate.
> >
> > Option A is prone to "wild closing of sessions" and option B is also
> > relaying to much on the good behaviour of the
> > client. It also introduces a "feature" that complicates
> login/logout.
> >
> > Our postion on this is  that the initiator should logout the session
> > explicitly if it can (and in this case it can as the target
> > has ascertained
> > that the session is alive).
> >
> > I agree that you may want to update the stayte diagram to
> > reflect this.
> >
> > Julo
> >
> >
> > "Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on
> 24-08-2001 01:46:40
> >
> > Please respond to cbm@rose.hp.com
> >
> > Sent by:  owner-ips@ece.cmu.edu
> >
> >
> > To:   ips@ece.cmu.edu
> > cc:
> > Subject:  iSCSI: reusing ISID for recovery (Was: RE: iSCSI
> - Change -
> >       Login/Text...)
> >
> >
> >
> > Julian and all:
> >
> > This thread mirrors another discussion some of us are
> > having in a different forum.  Following (two bullets 1
> > & 2 below) is what I proposed there, attempting to address
> > two issues -
> >      a) how to recover sessions when target and the initiator
> >            have conflicting views of the same TCP connection(s)?
> >            (Initiator NIC fails, but there's no I/O activity,
> >            and the target doesn't see any connection failure.)
> >      b) More specifically, how to address the above problem
> >            when the initiator *does not want* to re-instate failed
> >            connections since it only implements the mandatory
> >            session recovery?
> >
> > This could add clarity or muddle things up here, though hopefully
> > the former...
> >
> > 1 If login is sent with the same ISID, same TSID, same CID
> and X-bit,
> >   then it means a failed connection is being re-instated (whether
> >   or not there are multiple connections in the session).  This login
> >   attempt must be done before the connection timeout
> (transition M1),
> >   or if this is the only connection in the session, also before the
> >   session timeout (transition N6) - to be counted as a connection
> >   reinstatement effort.
> >            o CmdSN counters (CmdSN, ExpCmdSN) are continued.
> > Initiator
> >              must do command plugging when there's a mismatch
> >              between its CmdSN and ExpCmdSN in the login response.
> >            o Since this is an implicit connection logout, all
> > the active
> >              tasks on the connection are either internally
> terminated,
> >              or made non-allegiant (based on ErrorRecoveryLevel=x/y,
> >              TBD) for recovery.
> >
> > 2 If login is sent with the same ISID and TSID=0, the session (if it
> >   exists on the target) is being cleared and any active connections
> >   that the target sees must be immediately (at the end of the login
> >   process including any initiator authentication) transport reset.
> >   Initiator may attempt this only after it ascertains a
> > session failure
> >   on its end (ie. all connections entered RECOVERY_START).
> >            o CmdSN counters get reset.  Initiator has to perform the
> >              currently defined session recovery actions.
> >            o All active tasks of the session are internally
> > terminated.
> >
> >
> > Essentially, I was proposing extending the same notion of "implicit
> > logout" of a connection to the session level.  The options that I
> > see are -
> >
> >        A) Should iSCSI let it happen by default as stated above (ie.
> >           same ISID, TSID=0 always wipes out the
> pre-existing session
> >           on target, since we are mandating it to be used only when
> >           initiator sees a session failure)?
> >        B) Should iSCSI mandate making this intended cleanup explicit
> >           by setting a bit (Say C-bit, for Clear) in the
> Login Command
> >           PDU to prevent an accidental session cleanup with a buggy
> >           initiator code?
> >        C) Should iSCSI merely state that targets must ascertain
> >           the connection state(s) whenever a new session creation
> >           attempt is made with a known ISID and TSID=0?  (sort of
> >           defeats the intention of the initiator wanting quicker
> >           session recovery since the Login command PDU would have
> >           to idle till target ascertains the connection state(s)).
> >
> > I prefer A, or B.
> >
> > Going with A or B means that the description of transition N3
> > in the session state diagram would have to change to:
> >      Last LOGGED_IN connection had ceased to be LOGGED_IN,
> >         or a Login Command requesting clearing the session (also
> >         with C-bit set, if option B) was received by the target.
> >
> > The transition N7's description would have to be augmented as
> > well to:
> >         Session recovery attempt with an implicit logout,
> >         or connection reinstatement/new CID addition.
> >
> > Comments?
> > --
> > Mallikarjun
> >
> >
> > Mallikarjun Chadalapaka
> > Networked Storage Architecture
> > Network Storage Solutions Organization
> > MS 5668   Hewlett-Packard, Roseville.
> > cbm@rose.hp.com
> >
> >
> > >Stephen,
> > >
> > >That can happen as the target may set-up completely new TCP
> > connections
> > >(the old sockets are still there and look OK).
> > >Untill the login is  progessing he assumes that this is
> just another
> > >open-session attempt. Then he checks the old session and the
> > session is
> > >dead (initiator has closed the connections).
> > >
> > >The target has to distinguish only between a session that is
> > alive (and
> > >reject the new one) and one that its dead in which case it
> > can clean-up.
> > >
> > >Julo
> > >
> > >"Wheat, Stephen R" <stephen.r.wheat@intel.com> on
> 23-08-2001 22:50:56
> > >
> > >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> > >
> > >To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> > >cc:
> > >Subject:  RE: iSCSI - Change - Login/Text commands with the
> > binary stage
> > co
> > >          de
> > >
> > >
> > >
> > >Julian,
> > >
> > >I don't understand your answer.  For the scenario given, I
> > would presume
> > >then that the target would reject the new session attempt,
> > as it sees the
> > >previous session still "alive".  What is there to tell the
> > target that
> > this
> > >is any different from when the Initiator is erroneously using the
> > >repetitive
> > >session id?
> > >
> > >Thanks,
> > >Stephen
> > >
> > >-----Original Message-----
> > >From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > >Sent: Thursday, August 23, 2001 11:15 AM
> > >To: ips@ece.cmu.edu
> > >Subject: Re: iSCSI - Change - Login/Text commands with the
> > binary stage
> > >co de
> > >
> > >
> > >Stephen,
> > >
> > >1.If the initiator goes away for a while and reboots and
> there was no
> > >activity on the connections
> > >the target may see a session alive (I am not sure that it
> > has to appear on
> > >the state diagram but maybe).
> > >
> > >2.Again - I am not sure that the curent state diagram
> > includes death of
> > the
> > >initiator
> > >
> > >Julo
> > >
> > >"Wheat, Stephen R" <stephen.r.wheat@intel.com>@ece.cmu.edu
> > on 23-08-2001
> > >19:58:34
> > >
> > >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> > >
> > >Sent by:  owner-ips@ece.cmu.edu
> > >
> > >
> > >To:   ips@ece.cmu.edu
> > >cc:
> > >Subject:  Re: iSCSI - Change - Login/Text commands with the
> > binary stage
> > co
> > >      de
> > >
> > >
> > >
> > >Julian,
> > >
> > >1.3.6 ISID states that the target should check to see if the
> > old session
> > is
> > >still active when a duplicate session is detected.
> > >
> > >I have two questions, the second only if you answer in the
> > affirmative on
> > >the first ;^)
> > >
> > >1. Is there a properly executed sequence of events (i.e., no
> > coding error
> > >on
> > >the target side) where the session is not active, but the
> > target hadn't
> > >taken notice of it?  It appears this as a protocol-specified
> > means to work
> > >around a flaw in a target's implementation.  I interpret the
> > state diagram
> > >transitions as being atomic wrt other commands.  I.e., the
> > last logout
> > >would
> > >result in the various transitions of the connection/session
> > prior to the
> > >initiator starting the session up again.  And the target would have
> > >completed the transitions prior to handling a new session request.
> > >
> > >2. If you answered (1) in the affirmative, then the word
> > "Active" is not
> > >consistent with the 6.3 Session State Diagram.  Does this
> > mean the target
> > >got lost, due to transport failures of any sort, in its
> > transition from
> > >Q3-to-Q2-to-Q1?  It sounds like the intent is to close the
> > old session if
> > >the session was in Q2 or Q4, presuming if it were in Q1,  it
> > would not
> > have
> > >been found as a duplicate.
> > >
> > >Stephen
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
>
>
>












From owner-ips@ece.cmu.edu  Wed Aug 29 14:35:04 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05574
	for <ips-archive@odin.ietf.org>; Wed, 29 Aug 2001 14:35:04 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7TGa0T02962
	for ips-outgoing; Wed, 29 Aug 2001 12:36:00 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7TGZuP02956
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 12:35:57 -0400 (EDT)
Received: by ATLOPS with Internet Mail Service (5.5.2448.0)
	id <QMJCNG4N>; Wed, 29 Aug 2001 12:35:45 -0400
Message-ID: <25369470B6F0D41194820002B328BDD211625F@ATLOPS>
From: Sanjay Goyal <sanjay_goyal@ivivity.com>
To: ips@ece.cmu.edu
Cc: Sanjay Goyal <sanjay_goyal@ivivity.com>
Subject: iSCSI: Markers and CmdSN
Date: Wed, 29 Aug 2001 12:35:44 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Hi
 I have few Qs

1. When there are packet loss during transmission, you will also miss/loss
the CmdSN value with the command PDU. 
Does it mean you can not pass/present other higher CmdSN value command PDUs
to SCSI layer, as according to the draft specification the PDUs should be
transferred to SCSI layer in continuous increasing order of CmdSN value.

2. As per the new draft specification 
  draft-ietf-tsvwg-tcp-ulp-frame-00.txt

 The markers are 16-bit, whereas the Max PDU size and DataSegmentLength in
the iSCSI PDUs are 24-bit. 
 Is there any reason for having this difference?

3. As per iSCSI draft ver07
   FMarker, RFMarkInt, SFMarkInt are described as "LO" and the description
says they are connection specific. 
 Would somebody clarify what is correct?


Regards
Sanjay Goyal



From owner-ips@ece.cmu.edu  Wed Aug 29 15:33:47 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07051
	for <ips-archive@odin.ietf.org>; Wed, 29 Aug 2001 15:33:45 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7THpYH07535
	for ips-outgoing; Wed, 29 Aug 2001 13:51:34 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e34.bld.us.ibm.com (e34.co.us.ibm.com [32.97.110.132])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7THpWP07531
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 13:51:32 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e34.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA99052;
	Wed, 29 Aug 2001 13:49:19 -0400
Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7THoE1212908;
	Wed, 29 Aug 2001 11:50:14 -0600
X-Priority: 1 (High)
Importance: Normal
Subject: Re: ISCSI: Required Crytographic transforms for iSCSI
To: "Bill Strahm" <bill@sanera.net>
Cc: "Ips@Ece. Cmu. Edu" <ips@ece.cmu.edu>
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OF7D0D4148.D0ED97F2-ON88256AB7.0061784D@boulder.ibm.com>
From: "John Hufferd" <hufferd@us.ibm.com>
Date: Wed, 29 Aug 2001 10:49:14 -0700
X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at
 08/29/2001 11:50:14 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Bill,
you are correct, but I think it was implicitly there, since I think we
agreed to it in Nasuha.  That is why we did not specify it.  But for
precision, we need to ensure that David records "NULL Encryption Algorithm
" as being a MUST implement.

David Black what do you think?

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com


"Bill Strahm" <bill@sanera.net>@ece.cmu.edu on 08/29/2001 08:34:11 AM

Sent by:  owner-ips@ece.cmu.edu


To:   "Ips@Ece. Cmu. Edu" <ips@ece.cmu.edu>
cc:
Subject:  ISCSI: Required Crytographic transforms for iSCSI



When we were talking about required transforms yesterday in Los Angeles, I
believe that we forgot a VERY important transform that need to be a MUST
implement for ESP.  That is the NULL Encryption Algorithm (RFC2410).

I propose that this algorithm is a MUST implement for all iSCSI
implementations

Bill
Sanera Systems Inc.






From owner-ips@ece.cmu.edu  Wed Aug 29 15:35:27 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07137
	for <ips-archive@odin.ietf.org>; Wed, 29 Aug 2001 15:35:27 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7THlRD07237
	for ips-outgoing; Wed, 29 Aug 2001 13:47:27 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7THlIP07228
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 13:47:18 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id TAA52490
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 19:47:06 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7THkuv194296
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 19:46:56 +0200
Importance: Normal
Subject: RE: iSCSI: reusing ISID for recovery
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF16582FC6.BA4171B4-ONC2256AB7.0061837C@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Wed, 29 Aug 2001 20:46:18 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 29/08/2001 20:46:56
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Thanks - I started feeling bad. I could not get a message through. Julo

"Dev" <deva@stargateip.com> on 29-08-2001 19:03:40

Please respond to <deva@stargateip.com>

To:   Julian Satran/Haifa/IBM@IBMIL, <ips@ece.cmu.edu>
cc:
Subject:  RE: iSCSI: reusing ISID for recovery



Julian,

>But - as this is bound to bring
>many an initiator writer to set always
>the bit to "just cover for the case" I propose that the command fails if
>the X bit was on but there was no need for it to be on.

The only need to set the X-bit (when ISID, TSID=0) could be to forcibly
close a pre-existing session, if any in the target right?

I agree with this proposal, as this forces the initiator to issue the
command
with an X-bit only when there is an error (a session already exists).
I also like that returning an error when there is no need to set an X-bit,
as it discourages the initiators to set the X-bit by default, for opening
a session.

Thanks

Deva
Platys Communications.




I think that making a new session bring down an old one makes just too easy
for common mistakes.

The scheme I've proposed - like the original option B - avoids just that by
letting the target know that this
was intentional - by adding the X bit.   But - as this is bound to bring
many an initiator writer to set always
the bit to "just cover for the case" I propose that the command fails if
the X bit was on but there was no need for it to be on.

I hope that this will get us to have a scheme in which both the common
mistakes can't do harm and the initiator writers
will not get away by always having the X bit on.

The price is a login in 2 steps in case of recovery - and I think this is
acceptable.

Julo

Jim Hafner/Almaden/IBM@IBMUS@ece.cmu.edu on 28-08-2001 19:04:34

Please respond to Jim Hafner/Almaden/IBM@IBMUS

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery




Julo,

I'm unclear why you think that option A isn't viable and why you think a
more complicated protocol is required here.

If the initiator 'lost his way' such that he thinks he has an existing
session, then he does the normal error recovery for that scenario (a la the
mechanisms Mallikarjun noted).  If he 'lost his way' so badly that he
doesn't even know he has an existing session, then option A is probably the
right thing to do.  In this case, he won't even know he's lost his way so
can't expect to set the X bit rationally.  He'd either not set it, and then
we need a rule for what the target does then OR he sets it knee-jerk in
which case there's no point in having it (as Marj, Deva, et al, have
argued).

In short, if he has knowledge of a lost session, he does session recovery.
If not, he just logs in and the target cleans up its end.

I'd like to close this issue as well, should there be a call for consensus?

Jim Hafner


Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 08/27/2001 09:39:03 pm

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery




Marjorie, Jim, Mallikarjun, Deva & all

Let's attemp to close that optimization that is so dear to your hearts.
If we go for the following scheme (very close to B):

The initiator knows "that he lost his way" (in the initiator jungle tough)
and issues a Login + ISID + TSID=0 + X bit on (meaning
" I think I have an old session - please clean it up for me" and open a new
one) then the target may do one of the following:

- before going to the effort of authenticating the new initiator check if a
session exist (if he has the initiator name) or go to authentication if it
does not
- If he has a session then clean it and create a new one
- If he does not have a session - we have 3 options:
a)- tell him hid did not have an old session and drop him
b)- tell him he did not have an old session but nevertheless create a new
one
c)- create a new session and do not tell him

With option a we are close to the old option c but the initiator does not
have to find the old session he can do now safely a new login
With b & c  we are back at the old b.

Which one would you give your kingdom for ( and my peace!).

Julo

"Dev" <deva@stargateip.com>@ece.cmu.edu on 28-08-2001 01:44:15

Please respond to <deva@stargateip.com>

Sent by:  owner-ips@ece.cmu.edu


To:   "KRUEGER,MARJORIE \(HP-Roseville,ex1\)" <marjorie_krueger@hp.com>,
      <ips@ece.cmu.edu>
cc:
Subject:  RE: iSCSI: reusing ISID for recovery



All,

When a session is already running authenticated, a login request with the
same
ISID + initiator fails authentication. Will the session continue to run?
Or
if the target fails during parameter negotiation?

I guess, yes. i.e. target will not act on the existing session, until
the login completes successfully. Or are there exception to these?

Thanks

Deva
Platys Communications





> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Saturday, August 25, 2001 12:23 AM
> To: ips@ece.cmu.edu
> Subject: RE: iSCSI: reusing ISID for recovery
>
>
>
> It may be another OS running on the same machine or CPU
> complex or it could
> be an attack.
> In any case if the initiator is up and fine he can as well do logout.
> It is a rare enough event for us not to try to optimize.
>
> The reboot is the only case in which the initiator can't
> logout and about
> which we care.
>
> And I would like to remind you all that we where on this
> exact thread more
> tan 3 months ago (other players).
> I just restated the rationale for an (apparent) newcomer.
>
> Julo
>
> "KRUEGER,MARJORIE (HP-Roseville,ex1)"
> <marjorie_krueger@hp.com>@ece.cmu.edu
> on 25-08-2001 03:51:43
>
> Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"
>       <marjorie_krueger@hp.com>
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   ips@ece.cmu.edu
> cc:
> Subject:  RE: iSCSI: reusing ISID for recovery
>
>
>
> I don't see how Option A is prone to "wild closing of sessions".  The
> target
> is only looking for sessions with this particular initiator
> and closing
> them
> if the ISID matches.
>
> If an initiator doesn't have a valid TSID (login w/TSID=0),
> it means it has
> lost state entirely (reboot) or knows it wants to immediately reset a
> session (NIC failure).  How could there possibly be a case where the
> initiator has an active valid session with the same ISID, but
> just doesn't
> know about it??  Rejecting the login seems pointless, since
> obviously the
> initiator either has a bug or intends to quickly reset the session.
>
> The behavior chosen (Option C) will cause the initiator's
> recovery to be
> delayed while the target NOPs all the connections and waits
> for them to
> time
> out - this will only delay the initiators recovery
> unnecessarily.  I can't
> help but think this will cause long term problems for the protocol.
>
> Marjorie Krueger
> Networked Storage Architecture
> Networked Storage Solutions Org.
> Hewlett-Packard
> tel: +1 916 785 2656
> fax: +1 916 785 0391
> email: marjorie_krueger@hp.com
>
> > -----Original Message-----
> > From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > Sent: Thursday, August 23, 2001 9:39 PM
> > To: ips@ece.cmu.edu
> > Subject: Re: iSCSI: reusing ISID for recovery (Was: RE: iSCSI
> > - Change -
> > Login/Text...)
> >
> >
> >
> > Mallikarjun,
> >
> > On  your point 1 that is what is stated today in the draft.
> >
> > On your point 2 option C is the one we took in the draft, after some
> > debate.
> >
> > Option A is prone to "wild closing of sessions" and option B is also
> > relaying to much on the good behaviour of the
> > client. It also introduces a "feature" that complicates
> login/logout.
> >
> > Our postion on this is  that the initiator should logout the session
> > explicitly if it can (and in this case it can as the target
> > has ascertained
> > that the session is alive).
> >
> > I agree that you may want to update the stayte diagram to
> > reflect this.
> >
> > Julo
> >
> >
> > "Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on
> 24-08-2001 01:46:40
> >
> > Please respond to cbm@rose.hp.com
> >
> > Sent by:  owner-ips@ece.cmu.edu
> >
> >
> > To:   ips@ece.cmu.edu
> > cc:
> > Subject:  iSCSI: reusing ISID for recovery (Was: RE: iSCSI
> - Change -
> >       Login/Text...)
> >
> >
> >
> > Julian and all:
> >
> > This thread mirrors another discussion some of us are
> > having in a different forum.  Following (two bullets 1
> > & 2 below) is what I proposed there, attempting to address
> > two issues -
> >      a) how to recover sessions when target and the initiator
> >            have conflicting views of the same TCP connection(s)?
> >            (Initiator NIC fails, but there's no I/O activity,
> >            and the target doesn't see any connection failure.)
> >      b) More specifically, how to address the above problem
> >            when the initiator *does not want* to re-instate failed
> >            connections since it only implements the mandatory
> >            session recovery?
> >
> > This could add clarity or muddle things up here, though hopefully
> > the former...
> >
> > 1 If login is sent with the same ISID, same TSID, same CID
> and X-bit,
> >   then it means a failed connection is being re-instated (whether
> >   or not there are multiple connections in the session).  This login
> >   attempt must be done before the connection timeout
> (transition M1),
> >   or if this is the only connection in the session, also before the
> >   session timeout (transition N6) - to be counted as a connection
> >   reinstatement effort.
> >            o CmdSN counters (CmdSN, ExpCmdSN) are continued.
> > Initiator
> >              must do command plugging when there's a mismatch
> >              between its CmdSN and ExpCmdSN in the login response.
> >            o Since this is an implicit connection logout, all
> > the active
> >              tasks on the connection are either internally
> terminated,
> >              or made non-allegiant (based on ErrorRecoveryLevel=x/y,
> >              TBD) for recovery.
> >
> > 2 If login is sent with the same ISID and TSID=0, the session (if it
> >   exists on the target) is being cleared and any active connections
> >   that the target sees must be immediately (at the end of the login
> >   process including any initiator authentication) transport reset.
> >   Initiator may attempt this only after it ascertains a
> > session failure
> >   on its end (ie. all connections entered RECOVERY_START).
> >            o CmdSN counters get reset.  Initiator has to perform the
> >              currently defined session recovery actions.
> >            o All active tasks of the session are internally
> > terminated.
> >
> >
> > Essentially, I was proposing extending the same notion of "implicit
> > logout" of a connection to the session level.  The options that I
> > see are -
> >
> >        A) Should iSCSI let it happen by default as stated above (ie.
> >           same ISID, TSID=0 always wipes out the
> pre-existing session
> >           on target, since we are mandating it to be used only when
> >           initiator sees a session failure)?
> >        B) Should iSCSI mandate making this intended cleanup explicit
> >           by setting a bit (Say C-bit, for Clear) in the
> Login Command
> >           PDU to prevent an accidental session cleanup with a buggy
> >           initiator code?
> >        C) Should iSCSI merely state that targets must ascertain
> >           the connection state(s) whenever a new session creation
> >           attempt is made with a known ISID and TSID=0?  (sort of
> >           defeats the intention of the initiator wanting quicker
> >           session recovery since the Login command PDU would have
> >           to idle till target ascertains the connection state(s)).
> >
> > I prefer A, or B.
> >
> > Going with A or B means that the description of transition N3
> > in the session state diagram would have to change to:
> >      Last LOGGED_IN connection had ceased to be LOGGED_IN,
> >         or a Login Command requesting clearing the session (also
> >         with C-bit set, if option B) was received by the target.
> >
> > The transition N7's description would have to be augmented as
> > well to:
> >         Session recovery attempt with an implicit logout,
> >         or connection reinstatement/new CID addition.
> >
> > Comments?
> > --
> > Mallikarjun
> >
> >
> > Mallikarjun Chadalapaka
> > Networked Storage Architecture
> > Network Storage Solutions Organization
> > MS 5668   Hewlett-Packard, Roseville.
> > cbm@rose.hp.com
> >
> >
> > >Stephen,
> > >
> > >That can happen as the target may set-up completely new TCP
> > connections
> > >(the old sockets are still there and look OK).
> > >Untill the login is  progessing he assumes that this is
> just another
> > >open-session attempt. Then he checks the old session and the
> > session is
> > >dead (initiator has closed the connections).
> > >
> > >The target has to distinguish only between a session that is
> > alive (and
> > >reject the new one) and one that its dead in which case it
> > can clean-up.
> > >
> > >Julo
> > >
> > >"Wheat, Stephen R" <stephen.r.wheat@intel.com> on
> 23-08-2001 22:50:56
> > >
> > >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> > >
> > >To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> > >cc:
> > >Subject:  RE: iSCSI - Change - Login/Text commands with the
> > binary stage
> > co
> > >          de
> > >
> > >
> > >
> > >Julian,
> > >
> > >I don't understand your answer.  For the scenario given, I
> > would presume
> > >then that the target would reject the new session attempt,
> > as it sees the
> > >previous session still "alive".  What is there to tell the
> > target that
> > this
> > >is any different from when the Initiator is erroneously using the
> > >repetitive
> > >session id?
> > >
> > >Thanks,
> > >Stephen
> > >
> > >-----Original Message-----
> > >From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > >Sent: Thursday, August 23, 2001 11:15 AM
> > >To: ips@ece.cmu.edu
> > >Subject: Re: iSCSI - Change - Login/Text commands with the
> > binary stage
> > >co de
> > >
> > >
> > >Stephen,
> > >
> > >1.If the initiator goes away for a while and reboots and
> there was no
> > >activity on the connections
> > >the target may see a session alive (I am not sure that it
> > has to appear on
> > >the state diagram but maybe).
> > >
> > >2.Again - I am not sure that the curent state diagram
> > includes death of
> > the
> > >initiator
> > >
> > >Julo
> > >
> > >"Wheat, Stephen R" <stephen.r.wheat@intel.com>@ece.cmu.edu
> > on 23-08-2001
> > >19:58:34
> > >
> > >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> > >
> > >Sent by:  owner-ips@ece.cmu.edu
> > >
> > >
> > >To:   ips@ece.cmu.edu
> > >cc:
> > >Subject:  Re: iSCSI - Change - Login/Text commands with the
> > binary stage
> > co
> > >      de
> > >
> > >
> > >
> > >Julian,
> > >
> > >1.3.6 ISID states that the target should check to see if the
> > old session
> > is
> > >still active when a duplicate session is detected.
> > >
> > >I have two questions, the second only if you answer in the
> > affirmative on
> > >the first ;^)
> > >
> > >1. Is there a properly executed sequence of events (i.e., no
> > coding error
> > >on
> > >the target side) where the session is not active, but the
> > target hadn't
> > >taken notice of it?  It appears this as a protocol-specified
> > means to work
> > >around a flaw in a target's implementation.  I interpret the
> > state diagram
> > >transitions as being atomic wrt other commands.  I.e., the
> > last logout
> > >would
> > >result in the various transitions of the connection/session
> > prior to the
> > >initiator starting the session up again.  And the target would have
> > >completed the transitions prior to handling a new session request.
> > >
> > >2. If you answered (1) in the affirmative, then the word
> > "Active" is not
> > >consistent with the 6.3 Session State Diagram.  Does this
> > mean the target
> > >got lost, due to transport failures of any sort, in its
> > transition from
> > >Q3-to-Q2-to-Q1?  It sounds like the intent is to close the
> > old session if
> > >the session was in Q2 or Q4, presuming if it were in Q1,  it
> > would not
> > have
> > >been found as a duplicate.
> > >
> > >Stephen
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
>
>
>















From owner-ips@ece.cmu.edu  Wed Aug 29 17:10:07 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10217
	for <ips-archive@odin.ietf.org>; Wed, 29 Aug 2001 17:10:05 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7TK3Rg15754
	for ips-outgoing; Wed, 29 Aug 2001 16:03:27 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7TK3PP15749
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 16:03:25 -0400 (EDT)
Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203])
	by palrel2.hp.com (Postfix) with ESMTP id 5F3C32001
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 13:03:20 -0700 (PDT)
Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197])
	by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id NAA20483
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 13:03:15 -0700 (PDT)
Message-ID: <3B8D4BC4.A8B09FB7@cup.hp.com>
Date: Wed, 29 Aug 2001 13:08:36 -0700
From: Santosh Rao <santoshr@cup.hp.com>
Organization: Hewlett Packard, Cupertino.
X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778)
X-Accept-Language: en
MIME-Version: 1.0
To: IPS Reflector <ips@ece.cmu.edu>
Subject: iscsi : Async Message "target requests logout".
Content-Type: multipart/mixed;
 boundary="------------7FFFB8DCCD81ADCA0B7011BE"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

This is a multi-part message in MIME format.
--------------7FFFB8DCCD81ADCA0B7011BE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

All,

I've some concerns on the new wording for async messages in rev 07. The
new wording for the async message iscsi event "target requests logout"
reads :

 "2    Target requests Logout. This Async Message MUST be sent on the
same connection as the one being  requested to be logged out.  Initiator
MUST honor this request by issuing a Logout as early as possible, but no
later than Parameter3 seconds.  Initiator MUST send a Logout with a
reason code of "Close the   connection" to cleanly shutdown the
connection.  If the initiator does not Logout in Parameter3 seconds, the

target MAY send an Async PDU with iSCSI event code "Dropped the
connection" if possible, or simply terminate the transport connection."

In the following cases, the initiator may be unable to or may choose not

to use "close the cxn" logout :

1) initiator is only implementing session recovery and is using single
cxn sessions. In this case, it would just perform a session logout
+ re-login [or an implicit session
logout and  re-login by sending another session login
with the same ISID and NULL TSID.]

2) Initiator does not provide support for async messages and chooses to
ignore async messgaes. Async messages are provided for diagnostic
capabilities and differing classes of initiators may have differing
level of diagnostic & recovery support. Simple initiators may just
ignore the async messages as the message is bound to be followed by some

action from the target end. Mandating the responses to async messages
does not allow for this initiator behaviour.

The "close the cxn" flavor of logout or the initiator responses to async
messages must not be mandated, since differing levels of error recovery
support in initiators can result in different behaviours.

Regards,
Santosh

--------------7FFFB8DCCD81ADCA0B7011BE
Content-Type: text/x-vcard; charset=us-ascii;
 name="santoshr.vcf"
Content-Description: Card for Santosh Rao
Content-Disposition: attachment;
 filename="santoshr.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Rao;Santosh 
tel;work:408-447-3751
x-mozilla-html:FALSE
org:Hewlett Packard, Cupertino.;SISL
adr:;;19420, Homestead Road, M\S 43LN,	;Cupertino.;CA.;95014.;USA.
version:2.1
email;internet:santoshr@cup.hp.com
title:Software Design Engineer
x-mozilla-cpt:;21088
fn:Santosh Rao
end:vcard

--------------7FFFB8DCCD81ADCA0B7011BE--



From owner-ips@ece.cmu.edu  Wed Aug 29 17:11:12 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10258
	for <ips-archive@odin.ietf.org>; Wed, 29 Aug 2001 17:11:12 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7TKMMV16801
	for ips-outgoing; Wed, 29 Aug 2001 16:22:22 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7TKMJP16795
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 16:22:19 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id WAA94852
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 22:22:12 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7TKMCJ224028
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 22:22:12 +0200
Importance: Normal
Subject: Re: iscsi : Async Message "target requests logout".
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF7F6DBDE5.B2CE11F3-ONC2256AB7.006F05C5@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Wed, 29 Aug 2001 23:21:36 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 29/08/2001 23:22:11
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Due to security reasons we adopted the rule of only one login / TCP
connection. You can't relogin on the same TCP connection.

iSCSI asynchronous messages are not SCSI AENs (although they carry those
too). Support for iSCSI Async. Messages is not optional.

The close connection flavor of the message is the handiest for recovery
(initiator knows when he gets it
that the target will close the target end of it).

I think that the text saying perform a logout - implied also the "implicit"
logout from a login with restart but I will check again.

Julo



Santosh Rao <santoshr@cup.hp.com>@ece.cmu.edu on 29-08-2001 23:08:36

Please respond to Santosh Rao <santoshr@cup.hp.com>

Sent by:  owner-ips@ece.cmu.edu


To:   IPS Reflector <ips@ece.cmu.edu>
cc:
Subject:  iscsi : Async Message "target requests logout".



All,

I've some concerns on the new wording for async messages in rev 07. The
new wording for the async message iscsi event "target requests logout"
reads :

 "2    Target requests Logout. This Async Message MUST be sent on the
same connection as the one being  requested to be logged out.  Initiator
MUST honor this request by issuing a Logout as early as possible, but no
later than Parameter3 seconds.  Initiator MUST send a Logout with a
reason code of "Close the   connection" to cleanly shutdown the
connection.  If the initiator does not Logout in Parameter3 seconds, the

target MAY send an Async PDU with iSCSI event code "Dropped the
connection" if possible, or simply terminate the transport connection."

In the following cases, the initiator may be unable to or may choose not

to use "close the cxn" logout :

1) initiator is only implementing session recovery and is using single
cxn sessions. In this case, it would just perform a session logout
+ re-login [or an implicit session
logout and  re-login by sending another session login
with the same ISID and NULL TSID.]

2) Initiator does not provide support for async messages and chooses to
ignore async messgaes. Async messages are provided for diagnostic
capabilities and differing classes of initiators may have differing
level of diagnostic & recovery support. Simple initiators may just
ignore the async messages as the message is bound to be followed by some

action from the target end. Mandating the responses to async messages
does not allow for this initiator behaviour.

The "close the cxn" flavor of logout or the initiator responses to async
messages must not be mandated, since differing levels of error recovery
support in initiators can result in different behaviours.

Regards,
Santosh

 - santoshr.vcf





From owner-ips@ece.cmu.edu  Wed Aug 29 17:12:24 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10295
	for <ips-archive@odin.ietf.org>; Wed, 29 Aug 2001 17:12:22 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7TJR7T13440
	for ips-outgoing; Wed, 29 Aug 2001 15:27:07 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7TJR5P13436
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 15:27:05 -0400 (EDT)
Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203])
	by palrel2.hp.com (Postfix) with ESMTP id 996D2176E
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 12:27:04 -0700 (PDT)
Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197])
	by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id MAA17930
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 12:26:59 -0700 (PDT)
Message-ID: <3B8D4344.12767C92@cup.hp.com>
Date: Wed, 29 Aug 2001 12:32:21 -0700
From: Santosh Rao <santoshr@cup.hp.com>
Organization: Hewlett Packard, Cupertino.
X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778)
X-Accept-Language: en
MIME-Version: 1.0
To: ips@ece.cmu.edu
Subject: Re: iSCSI: reusing ISID for recovery
References: <OF98EDA907.87D6DF4B-ONC2256AB7.00222B9A@telaviv.ibm.com>
Content-Type: multipart/mixed;
 boundary="------------A03B637A655CE2E85832E64F"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

This is a multi-part message in MIME format.
--------------A03B637A655CE2E85832E64F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Julian,

I dis-agree with the below proposal. I am in favor of proposal (A) as
suggested by Mallikarjun, Marj & Jim Hafner. The same was earlier proposed by
myself in a previous thread on this issue a few months ago. The iscsi draft
should not be optimizing to deal with coding errors, but to optimize the
behaviour for the typical functional scenario.

For initiators that use session recovery on any iscsi errors (ex : format
error, digest error, protocol error, sequence error), it is an optimization to
perform the logout + re-login in 1 step using the session login with the same
ISID and 0 TSID to indicate an implicit logout + re-login. (what has been
described as option A).

The above semantics are also required in the case wherein the initiator lost
its prior state information and attempts to establish a session with the same
ISID and 0 TSID.

I disagree with the proposal made below since it adds additional complexity to
initiators cleanup & re-login in the case where they are booting up and
establishing the session for the first time. The initiator has no idea if a
previously established session exists, that requires clean-up. It would set
the X-bit [or C-bit as proposed in option B] to clear any pre-existing
session. This would cause the target to reject the session login since there
was no session that required cleanup, thereby, requiring the initiator to
login again without the X bit set.

All these extra handshakes in the above case during system startup are going
to cause a bloat in login time which should be avoided. There is no need for
all this extra complexity just to protect against coding errors by an
initiator that accidentally cleared its own session.

The semantics of option (A) are also used in FC and there are no complaints
with that model there. In fact, that is an often used technique to logout &
re-login in FC.

Regards,
Santosh


Julian Satran wrote:

> Jim,
>
> I think that making a new session bring down an old one makes just too easy
> for common mistakes.
>
> The scheme I've proposed - like the original option B - avoids just that by
> letting the target know that this
> was intentional - by adding the X bit.   But - as this is bound to bring
> many an initiator writer to set always
> the bit to "just cover for the case" I propose that the command fails if
> the X bit was on but there was no need for it to be on.
>
> I hope that this will get us to have a scheme in which both the common
> mistakes can't do harm and the initiator writers
> will not get away by always having the X bit on.
>
> The price is a login in 2 steps in case of recovery - and I think this is
> acceptable.
>
> Julo
>
> Jim Hafner/Almaden/IBM@IBMUS@ece.cmu.edu on 28-08-2001 19:04:34
>
> Please respond to Jim Hafner/Almaden/IBM@IBMUS
>
> Sent by:  owner-ips@ece.cmu.edu
>
> To:   ips@ece.cmu.edu
> cc:
> Subject:  RE: iSCSI: reusing ISID for recovery
>
> Julo,
>
> I'm unclear why you think that option A isn't viable and why you think a
> more complicated protocol is required here.
>
> If the initiator 'lost his way' such that he thinks he has an existing
> session, then he does the normal error recovery for that scenario (a la the
> mechanisms Mallikarjun noted).  If he 'lost his way' so badly that he
> doesn't even know he has an existing session, then option A is probably the
> right thing to do.  In this case, he won't even know he's lost his way so
> can't expect to set the X bit rationally.  He'd either not set it, and then
> we need a rule for what the target does then OR he sets it knee-jerk in
> which case there's no point in having it (as Marj, Deva, et al, have
> argued).
>
> In short, if he has knowledge of a lost session, he does session recovery.
> If not, he just logs in and the target cleans up its end.
>
> I'd like to close this issue as well, should there be a call for consensus?
>
> Jim Hafner
>
> Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 08/27/2001 09:39:03 pm
>
> Sent by:  owner-ips@ece.cmu.edu
>
> To:   ips@ece.cmu.edu
> cc:
> Subject:  RE: iSCSI: reusing ISID for recovery
>
> Marjorie, Jim, Mallikarjun, Deva & all
>
> Let's attemp to close that optimization that is so dear to your hearts.
> If we go for the following scheme (very close to B):
>
> The initiator knows "that he lost his way" (in the initiator jungle tough)
> and issues a Login + ISID + TSID=0 + X bit on (meaning
> " I think I have an old session - please clean it up for me" and open a new
> one) then the target may do one of the following:
>
> - before going to the effort of authenticating the new initiator check if a
> session exist (if he has the initiator name) or go to authentication if it
> does not
> - If he has a session then clean it and create a new one
> - If he does not have a session - we have 3 options:
> a)- tell him hid did not have an old session and drop him
> b)- tell him he did not have an old session but nevertheless create a new
> one
> c)- create a new session and do not tell him
>
> With option a we are close to the old option c but the initiator does not
> have to find the old session he can do now safely a new login
> With b & c  we are back at the old b.
>
> Which one would you give your kingdom for ( and my peace!).
>
> Julo
>
> "Dev" <deva@stargateip.com>@ece.cmu.edu on 28-08-2001 01:44:15
>
> Please respond to <deva@stargateip.com>
>
> Sent by:  owner-ips@ece.cmu.edu
>
> To:   "KRUEGER,MARJORIE \(HP-Roseville,ex1\)" <marjorie_krueger@hp.com>,
>       <ips@ece.cmu.edu>
> cc:
> Subject:  RE: iSCSI: reusing ISID for recovery
>
> All,
>
> When a session is already running authenticated, a login request with the
> same
> ISID + initiator fails authentication. Will the session continue to run?
> Or
> if the target fails during parameter negotiation?
>
> I guess, yes. i.e. target will not act on the existing session, until
> the login completes successfully. Or are there exception to these?
>
> Thanks
>
> Deva
> Platys Communications
>
> > -----Original Message-----
> > From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > Sent: Saturday, August 25, 2001 12:23 AM
> > To: ips@ece.cmu.edu
> > Subject: RE: iSCSI: reusing ISID for recovery
> >
> >
> >
> > It may be another OS running on the same machine or CPU
> > complex or it could
> > be an attack.
> > In any case if the initiator is up and fine he can as well do logout.
> > It is a rare enough event for us not to try to optimize.
> >
> > The reboot is the only case in which the initiator can't
> > logout and about
> > which we care.
> >
> > And I would like to remind you all that we where on this
> > exact thread more
> > tan 3 months ago (other players).
> > I just restated the rationale for an (apparent) newcomer.
> >
> > Julo
> >
> > "KRUEGER,MARJORIE (HP-Roseville,ex1)"
> > <marjorie_krueger@hp.com>@ece.cmu.edu
> > on 25-08-2001 03:51:43
> >
> > Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"
> >       <marjorie_krueger@hp.com>
> >
> > Sent by:  owner-ips@ece.cmu.edu
> >
> >
> > To:   ips@ece.cmu.edu
> > cc:
> > Subject:  RE: iSCSI: reusing ISID for recovery
> >
> >
> >
> > I don't see how Option A is prone to "wild closing of sessions".  The
> > target
> > is only looking for sessions with this particular initiator
> > and closing
> > them
> > if the ISID matches.
> >
> > If an initiator doesn't have a valid TSID (login w/TSID=0),
> > it means it has
> > lost state entirely (reboot) or knows it wants to immediately reset a
> > session (NIC failure).  How could there possibly be a case where the
> > initiator has an active valid session with the same ISID, but
> > just doesn't
> > know about it??  Rejecting the login seems pointless, since
> > obviously the
> > initiator either has a bug or intends to quickly reset the session.
> >
> > The behavior chosen (Option C) will cause the initiator's
> > recovery to be
> > delayed while the target NOPs all the connections and waits
> > for them to
> > time
> > out - this will only delay the initiators recovery
> > unnecessarily.  I can't
> > help but think this will cause long term problems for the protocol.
> >
> > Marjorie Krueger
> > Networked Storage Architecture
> > Networked Storage Solutions Org.
> > Hewlett-Packard
> > tel: +1 916 785 2656
> > fax: +1 916 785 0391
> > email: marjorie_krueger@hp.com
> >
> > > -----Original Message-----
> > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > > Sent: Thursday, August 23, 2001 9:39 PM
> > > To: ips@ece.cmu.edu
> > > Subject: Re: iSCSI: reusing ISID for recovery (Was: RE: iSCSI
> > > - Change -
> > > Login/Text...)
> > >
> > >
> > >
> > > Mallikarjun,
> > >
> > > On  your point 1 that is what is stated today in the draft.
> > >
> > > On your point 2 option C is the one we took in the draft, after some
> > > debate.
> > >
> > > Option A is prone to "wild closing of sessions" and option B is also
> > > relaying to much on the good behaviour of the
> > > client. It also introduces a "feature" that complicates
> > login/logout.
> > >
> > > Our postion on this is  that the initiator should logout the session
> > > explicitly if it can (and in this case it can as the target
> > > has ascertained
> > > that the session is alive).
> > >
> > > I agree that you may want to update the stayte diagram to
> > > reflect this.
> > >
> > > Julo
> > >
> > >
> > > "Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on
> > 24-08-2001 01:46:40
> > >
> > > Please respond to cbm@rose.hp.com
> > >
> > > Sent by:  owner-ips@ece.cmu.edu
> > >
> > >
> > > To:   ips@ece.cmu.edu
> > > cc:
> > > Subject:  iSCSI: reusing ISID for recovery (Was: RE: iSCSI
> > - Change -
> > >       Login/Text...)
> > >
> > >
> > >
> > > Julian and all:
> > >
> > > This thread mirrors another discussion some of us are
> > > having in a different forum.  Following (two bullets 1
> > > & 2 below) is what I proposed there, attempting to address
> > > two issues -
> > >      a) how to recover sessions when target and the initiator
> > >            have conflicting views of the same TCP connection(s)?
> > >            (Initiator NIC fails, but there's no I/O activity,
> > >            and the target doesn't see any connection failure.)
> > >      b) More specifically, how to address the above problem
> > >            when the initiator *does not want* to re-instate failed
> > >            connections since it only implements the mandatory
> > >            session recovery?
> > >
> > > This could add clarity or muddle things up here, though hopefully
> > > the former...
> > >
> > > 1 If login is sent with the same ISID, same TSID, same CID
> > and X-bit,
> > >   then it means a failed connection is being re-instated (whether
> > >   or not there are multiple connections in the session).  This login
> > >   attempt must be done before the connection timeout
> > (transition M1),
> > >   or if this is the only connection in the session, also before the
> > >   session timeout (transition N6) - to be counted as a connection
> > >   reinstatement effort.
> > >            o CmdSN counters (CmdSN, ExpCmdSN) are continued.
> > > Initiator
> > >              must do command plugging when there's a mismatch
> > >              between its CmdSN and ExpCmdSN in the login response.
> > >            o Since this is an implicit connection logout, all
> > > the active
> > >              tasks on the connection are either internally
> > terminated,
> > >              or made non-allegiant (based on ErrorRecoveryLevel=x/y,
> > >              TBD) for recovery.
> > >
> > > 2 If login is sent with the same ISID and TSID=0, the session (if it
> > >   exists on the target) is being cleared and any active connections
> > >   that the target sees must be immediately (at the end of the login
> > >   process including any initiator authentication) transport reset.
> > >   Initiator may attempt this only after it ascertains a
> > > session failure
> > >   on its end (ie. all connections entered RECOVERY_START).
> > >            o CmdSN counters get reset.  Initiator has to perform the
> > >              currently defined session recovery actions.
> > >            o All active tasks of the session are internally
> > > terminated.
> > >
> > >
> > > Essentially, I was proposing extending the same notion of "implicit
> > > logout" of a connection to the session level.  The options that I
> > > see are -
> > >
> > >        A) Should iSCSI let it happen by default as stated above (ie.
> > >           same ISID, TSID=0 always wipes out the
> > pre-existing session
> > >           on target, since we are mandating it to be used only when
> > >           initiator sees a session failure)?
> > >        B) Should iSCSI mandate making this intended cleanup explicit
> > >           by setting a bit (Say C-bit, for Clear) in the
> > Login Command
> > >           PDU to prevent an accidental session cleanup with a buggy
> > >           initiator code?
> > >        C) Should iSCSI merely state that targets must ascertain
> > >           the connection state(s) whenever a new session creation
> > >           attempt is made with a known ISID and TSID=0?  (sort of
> > >           defeats the intention of the initiator wanting quicker
> > >           session recovery since the Login command PDU would have
> > >           to idle till target ascertains the connection state(s)).
> > >
> > > I prefer A, or B.
> > >
> > > Going with A or B means that the description of transition N3
> > > in the session state diagram would have to change to:
> > >      Last LOGGED_IN connection had ceased to be LOGGED_IN,
> > >         or a Login Command requesting clearing the session (also
> > >         with C-bit set, if option B) was received by the target.
> > >
> > > The transition N7's description would have to be augmented as
> > > well to:
> > >         Session recovery attempt with an implicit logout,
> > >         or connection reinstatement/new CID addition.
> > >
> > > Comments?
> > > --
> > > Mallikarjun
> > >
> > >
> > > Mallikarjun Chadalapaka
> > > Networked Storage Architecture
> > > Network Storage Solutions Organization
> > > MS 5668   Hewlett-Packard, Roseville.
> > > cbm@rose.hp.com
> > >
> > >
> > > >Stephen,
> > > >
> > > >That can happen as the target may set-up completely new TCP
> > > connections
> > > >(the old sockets are still there and look OK).
> > > >Untill the login is  progessing he assumes that this is
> > just another
> > > >open-session attempt. Then he checks the old session and the
> > > session is
> > > >dead (initiator has closed the connections).
> > > >
> > > >The target has to distinguish only between a session that is
> > > alive (and
> > > >reject the new one) and one that its dead in which case it
> > > can clean-up.
> > > >
> > > >Julo
> > > >
> > > >"Wheat, Stephen R" <stephen.r.wheat@intel.com> on
> > 23-08-2001 22:50:56
> > > >
> > > >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> > > >
> > > >To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> > > >cc:
> > > >Subject:  RE: iSCSI - Change - Login/Text commands with the
> > > binary stage
> > > co
> > > >          de
> > > >
> > > >
> > > >
> > > >Julian,
> > > >
> > > >I don't understand your answer.  For the scenario given, I
> > > would presume
> > > >then that the target would reject the new session attempt,
> > > as it sees the
> > > >previous session still "alive".  What is there to tell the
> > > target that
> > > this
> > > >is any different from when the Initiator is erroneously using the
> > > >repetitive
> > > >session id?
> > > >
> > > >Thanks,
> > > >Stephen
> > > >
> > > >-----Original Message-----
> > > >From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > > >Sent: Thursday, August 23, 2001 11:15 AM
> > > >To: ips@ece.cmu.edu
> > > >Subject: Re: iSCSI - Change - Login/Text commands with the
> > > binary stage
> > > >co de
> > > >
> > > >
> > > >Stephen,
> > > >
> > > >1.If the initiator goes away for a while and reboots and
> > there was no
> > > >activity on the connections
> > > >the target may see a session alive (I am not sure that it
> > > has to appear on
> > > >the state diagram but maybe).
> > > >
> > > >2.Again - I am not sure that the curent state diagram
> > > includes death of
> > > the
> > > >initiator
> > > >
> > > >Julo
> > > >
> > > >"Wheat, Stephen R" <stephen.r.wheat@intel.com>@ece.cmu.edu
> > > on 23-08-2001
> > > >19:58:34
> > > >
> > > >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> > > >
> > > >Sent by:  owner-ips@ece.cmu.edu
> > > >
> > > >
> > > >To:   ips@ece.cmu.edu
> > > >cc:
> > > >Subject:  Re: iSCSI - Change - Login/Text commands with the
> > > binary stage
> > > co
> > > >      de
> > > >
> > > >
> > > >
> > > >Julian,
> > > >
> > > >1.3.6 ISID states that the target should check to see if the
> > > old session
> > > is
> > > >still active when a duplicate session is detected.
> > > >
> > > >I have two questions, the second only if you answer in the
> > > affirmative on
> > > >the first ;^)
> > > >
> > > >1. Is there a properly executed sequence of events (i.e., no
> > > coding error
> > > >on
> > > >the target side) where the session is not active, but the
> > > target hadn't
> > > >taken notice of it?  It appears this as a protocol-specified
> > > means to work
> > > >around a flaw in a target's implementation.  I interpret the
> > > state diagram
> > > >transitions as being atomic wrt other commands.  I.e., the
> > > last logout
> > > >would
> > > >result in the various transitions of the connection/session
> > > prior to the
> > > >initiator starting the session up again.  And the target would have
> > > >completed the transitions prior to handling a new session request.
> > > >
> > > >2. If you answered (1) in the affirmative, then the word
> > > "Active" is not
> > > >consistent with the 6.3 Session State Diagram.  Does this
> > > mean the target
> > > >got lost, due to transport failures of any sort, in its
> > > transition from
> > > >Q3-to-Q2-to-Q1?  It sounds like the intent is to close the
> > > old session if
> > > >the session was in Q2 or Q4, presuming if it were in Q1,  it
> > > would not
> > > have
> > > >been found as a duplicate.
> > > >
> > > >Stephen
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >

--------------A03B637A655CE2E85832E64F
Content-Type: text/x-vcard; charset=us-ascii;
 name="santoshr.vcf"
Content-Description: Card for Santosh Rao
Content-Disposition: attachment;
 filename="santoshr.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Rao;Santosh 
tel;work:408-447-3751
x-mozilla-html:FALSE
org:Hewlett Packard, Cupertino.;SISL
adr:;;19420, Homestead Road, M\S 43LN,	;Cupertino.;CA.;95014.;USA.
version:2.1
email;internet:santoshr@cup.hp.com
title:Software Design Engineer
x-mozilla-cpt:;21088
fn:Santosh Rao
end:vcard

--------------A03B637A655CE2E85832E64F--



From owner-ips@ece.cmu.edu  Wed Aug 29 17:12:34 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10306
	for <ips-archive@odin.ietf.org>; Wed, 29 Aug 2001 17:12:34 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7TJvM615273
	for ips-outgoing; Wed, 29 Aug 2001 15:57:22 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7TJvJP15265
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 15:57:19 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id VAA10464
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 21:57:00 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7TJuxv266446
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 21:56:59 +0200
Importance: Normal
Subject: RE: iSCSI: reusing ISID for recovery
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF9CA38A65.D53E4AD4-ONC2256AB7.006C410B@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Wed, 29 Aug 2001 22:56:24 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 29/08/2001 22:56:59
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Marjorie,

I probably have some difficulties in explaining and you in reading ... and
that contributes to increasing distance.
Doing an automatic logout when a new session is seen can be performed by
mistake by an OS in a multi OS machine. It is just to easy to let it
through.  After a reboot the right procedure would be to login cleanly (no
previous knowledge needed). The target will ascertain that the old session
is dead and let you in.

You will need the X only when the old session is alive (answering to NOP)
but you don't know how to clean it.

Reboot behavior is close to what you have in the current draft ( a single
login needed - no X).

The difference is when you have a living connection - then you have for the
session the same thing as for a connection you have to restart it.

Julo

"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>@ece.cmu.edu
on 29-08-2001 22:27:35

Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"
      <marjorie_krueger@hp.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery



It would help to get your message thru if you could answer our requests for
an explanation of your thinking.  We have tried several times to explain
our
logic (w/examples) but I haven't seen an example from you supporting a
scenario in which you see a problem.

If an initiator reboots, and has no context information, how can it know
whether or not a target has a pre-existing session?  Since there is no nice
way to know that, I would probably code my initiator to request a login
with
the X bit set (but as Mallikarjun said, I don't like this overloading of
the
X bit, it's a special case and makes the coding extra convoluted).  In your
preferred scenario, this would cause the target to reject the login "cause
there is no pre-existing session", and the initiator would re-issues the
login without the X bit set.  What have you saved anyone from here?  You've
just added latency to the login process.  And either way the initiator
codes
it's login after reboot, there's a presumably equal probability of
encountering this extra exchange.

I still haven't seen a plausable example where it does harm to have a login
w/ ISID=n, TSID=0 close an existing session with this initiator.  I can see
no case where this would be the wrong decision.  If "this isn't what the
initiator intended", this is a defective initiator implementation and
closing the other session at least does no harm.

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: marjorie_krueger@hp.com

> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Wednesday, August 29, 2001 10:46 AM
> To: ips@ece.cmu.edu
> Subject: RE: iSCSI: reusing ISID for recovery
>
>
> Thanks - I started feeling bad. I could not get a message
> through. Julo
>
> "Dev" <deva@stargateip.com> on 29-08-2001 19:03:40
>
> Please respond to <deva@stargateip.com>
>
> To:   Julian Satran/Haifa/IBM@IBMIL, <ips@ece.cmu.edu>
> cc:
> Subject:  RE: iSCSI: reusing ISID for recovery
>
>
>
> Julian,
>
> >But - as this is bound to bring
> >many an initiator writer to set always
> >the bit to "just cover for the case" I propose that the
> command fails if
> >the X bit was on but there was no need for it to be on.
>
> The only need to set the X-bit (when ISID, TSID=0) could be
> to forcibly
> close a pre-existing session, if any in the target right?
>
> I agree with this proposal, as this forces the initiator to issue the
> command
> with an X-bit only when there is an error (a session already exists).
> I also like that returning an error when there is no need to
> set an X-bit,
> as it discourages the initiators to set the X-bit by default,
> for opening
> a session.
>
> Thanks
>
> Deva
> Platys Communications.
>
>





From owner-ips@ece.cmu.edu  Wed Aug 29 17:58:32 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11794
	for <ips-archive@odin.ietf.org>; Wed, 29 Aug 2001 17:58:26 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7TKsEK18643
	for ips-outgoing; Wed, 29 Aug 2001 16:54:14 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from sandmail.sandburst.com (sandmail.sandburst.com [216.57.132.42])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7TKsAP18629
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 16:54:10 -0400 (EDT)
To: Santosh Rao <santoshr@cup.hp.com>
Cc: ips@ece.cmu.edu
Subject: Re: iSCSI: reusing ISID for recovery 
In-Reply-To: Message from Santosh Rao <santoshr@cup.hp.com> 
   of "Wed, 29 Aug 2001 12:32:21 PDT." <3B8D4344.12767C92@cup.hp.com> 
References: <OF98EDA907.87D6DF4B-ONC2256AB7.00222B9A@telaviv.ibm.com>  <3B8D4344.12767C92@cup.hp.com> 
Date: Wed, 29 Aug 2001 16:53:14 -0400
From: Stephen Bailey <steph@cs.uchicago.edu>
Message-Id: <20010829205343.C0B654E8F@sandmail.sandburst.com>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

> The same was earlier proposed by myself in a previous thread on this
> issue a few months ago.

You're not the only one.  I'm also in favor of (A).  I have also
carefully laid out the chain that Marjorie's following on at least one
(and probably several) past occasions.  It seems sound to me.  An
initiator that has lost its mind (this might be an OS reboot, or
`simply' a fat adapter crash & restart) is going to want to stomp out
any existing sessions in its name.  It's not going to want to pick up
old context unless it's aware that there IS old context, in which case
it hasn't completely lost its mind.

I've been keeping my mouth shut in hopes that it would actually pass,
but I guess I don't have to articulate a position so much as just hold
it to ensure it gets killed.  Given my track record, I'm now for sale
to the highest bidder.

Steph


From owner-ips@ece.cmu.edu  Wed Aug 29 17:58:58 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11807
	for <ips-archive@odin.ietf.org>; Wed, 29 Aug 2001 17:58:57 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7TLDQk19948
	for ips-outgoing; Wed, 29 Aug 2001 17:13:26 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7TLDMP19935
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 17:13:23 -0400 (EDT)
Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA13067; Wed, 29 Aug 2001 17:13:05 -0400 (EDT)
Message-ID: <3B8D5932.42869881@cisco.com>
Date: Wed, 29 Aug 2001 16:05:54 -0500
From: Mark Bakke <mbakke@cisco.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686)
X-Accept-Language: en, de
MIME-Version: 1.0
To: Bill Strahm <bill@sanera.net>
CC: "Ips@Ece. Cmu. Edu" <ips@ece.cmu.edu>
Subject: Re: ISCSI: User authentication vs. Machine Authentication for iSCSI
References: <HDECJFNIFJBIAINDCFOMKEJOCAAA.bill@sanera.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Bill Strahm wrote:
> 
> I have been fighting with this problem since I left LA.
> 
> I am not aware of any usage scenarios today where block devices are owned by
> the user rather than the machine.  I will conceed that in many instances the
> first thing the system does is assign the resource to a use (tape, scanner,
> etc.) but the machine still owns the resource and can in fact remove it out
> from under the user...
> 
> I am not to certain how I could build a trusted iSCSI environment where one
> user would have no knowledge about what was happening with other users in a
> malicious environment (especially where a system was participating in the
> exposure of resourses).  Examples of this include things like co-located Web
> hosting where a single user scans process memory looking for 1Kbit of random
> data, and when finding it attempts to determine if that is the private key
> of a user sharing the resource.
> 
> The reason I am bringing this up, is I am not sure trying to define security
> above the machine level makes any sense for iSCSI.  Aren't most SCSI devices
> owned by the Operating System not the User and partitioned out by the
> Operating System to the users ?  If this is the case many of our
> authentication methods simplify to simple IKE identities.
> 
> Bill

Bill-

As you pointed out, there is a case where just using IKE with
an iSCSI AuthMethod of "none" is valid.  That case is where:

- There a one-to-one correspondence between an initiator and an
  operating system
- IPsec is being used for all iSCSI traffic
- The customer is willing to deploy public key certificates on the
  client side (for each initiator) as well as on the devices

If all of the above are true, iSCSI can certainly use an AuthMethod
of none, and be done with it.

However,

- There are cases (David Black brought up some tape applications) where
  more than one initiator might exist on an operating system

- IPsec is not likely to be used for a large percentage of iSCSI
  traffic any time soon

- When IPsec is used, many customers will have an easier time with the
  familiar model of authenticating the server "machine" but using a
  dummy certificate for the client.

If any of the above are true, iSCSI-level of authentication is
required.

Hope this helps,

Mark


From owner-ips@ece.cmu.edu  Wed Aug 29 17:59:15 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11821
	for <ips-archive@odin.ietf.org>; Wed, 29 Aug 2001 17:59:15 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7TJxGD15452
	for ips-outgoing; Wed, 29 Aug 2001 15:59:16 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7TJx6P15424
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 15:59:06 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id VAA46334
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 21:58:51 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7TJwov267444
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 21:58:50 +0200
Importance: Normal
Subject: Re: iSCSI: reusing ISID for recovery
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFE839E73C.436F4241-ONC2256AB7.006DA939@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Wed, 29 Aug 2001 22:58:13 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 29/08/2001 22:58:50
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Please read my answer to Marjorie. Julo

Santosh Rao <santoshr@cup.hp.com>@ece.cmu.edu on 29-08-2001 22:32:21

Please respond to Santosh Rao <santoshr@cup.hp.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  Re: iSCSI: reusing ISID for recovery



Julian,

I dis-agree with the below proposal. I am in favor of proposal (A) as
suggested by Mallikarjun, Marj & Jim Hafner. The same was earlier proposed
by
myself in a previous thread on this issue a few months ago. The iscsi draft
should not be optimizing to deal with coding errors, but to optimize the
behaviour for the typical functional scenario.

For initiators that use session recovery on any iscsi errors (ex : format
error, digest error, protocol error, sequence error), it is an optimization
to
perform the logout + re-login in 1 step using the session login with the
same
ISID and 0 TSID to indicate an implicit logout + re-login. (what has been
described as option A).

The above semantics are also required in the case wherein the initiator
lost
its prior state information and attempts to establish a session with the
same
ISID and 0 TSID.

I disagree with the proposal made below since it adds additional complexity
to
initiators cleanup & re-login in the case where they are booting up and
establishing the session for the first time. The initiator has no idea if a
previously established session exists, that requires clean-up. It would set
the X-bit [or C-bit as proposed in option B] to clear any pre-existing
session. This would cause the target to reject the session login since
there
was no session that required cleanup, thereby, requiring the initiator to
login again without the X bit set.

All these extra handshakes in the above case during system startup are
going
to cause a bloat in login time which should be avoided. There is no need
for
all this extra complexity just to protect against coding errors by an
initiator that accidentally cleared its own session.

The semantics of option (A) are also used in FC and there are no complaints
with that model there. In fact, that is an often used technique to logout &
re-login in FC.

Regards,
Santosh


Julian Satran wrote:

> Jim,
>
> I think that making a new session bring down an old one makes just too
easy
> for common mistakes.
>
> The scheme I've proposed - like the original option B - avoids just that
by
> letting the target know that this
> was intentional - by adding the X bit.   But - as this is bound to bring
> many an initiator writer to set always
> the bit to "just cover for the case" I propose that the command fails if
> the X bit was on but there was no need for it to be on.
>
> I hope that this will get us to have a scheme in which both the common
> mistakes can't do harm and the initiator writers
> will not get away by always having the X bit on.
>
> The price is a login in 2 steps in case of recovery - and I think this is
> acceptable.
>
> Julo
>
> Jim Hafner/Almaden/IBM@IBMUS@ece.cmu.edu on 28-08-2001 19:04:34
>
> Please respond to Jim Hafner/Almaden/IBM@IBMUS
>
> Sent by:  owner-ips@ece.cmu.edu
>
> To:   ips@ece.cmu.edu
> cc:
> Subject:  RE: iSCSI: reusing ISID for recovery
>
> Julo,
>
> I'm unclear why you think that option A isn't viable and why you think a
> more complicated protocol is required here.
>
> If the initiator 'lost his way' such that he thinks he has an existing
> session, then he does the normal error recovery for that scenario (a la
the
> mechanisms Mallikarjun noted).  If he 'lost his way' so badly that he
> doesn't even know he has an existing session, then option A is probably
the
> right thing to do.  In this case, he won't even know he's lost his way so
> can't expect to set the X bit rationally.  He'd either not set it, and
then
> we need a rule for what the target does then OR he sets it knee-jerk in
> which case there's no point in having it (as Marj, Deva, et al, have
> argued).
>
> In short, if he has knowledge of a lost session, he does session
recovery.
> If not, he just logs in and the target cleans up its end.
>
> I'd like to close this issue as well, should there be a call for
consensus?
>
> Jim Hafner
>
> Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 08/27/2001 09:39:03 pm
>
> Sent by:  owner-ips@ece.cmu.edu
>
> To:   ips@ece.cmu.edu
> cc:
> Subject:  RE: iSCSI: reusing ISID for recovery
>
> Marjorie, Jim, Mallikarjun, Deva & all
>
> Let's attemp to close that optimization that is so dear to your hearts.
> If we go for the following scheme (very close to B):
>
> The initiator knows "that he lost his way" (in the initiator jungle
tough)
> and issues a Login + ISID + TSID=0 + X bit on (meaning
> " I think I have an old session - please clean it up for me" and open a
new
> one) then the target may do one of the following:
>
> - before going to the effort of authenticating the new initiator check if
a
> session exist (if he has the initiator name) or go to authentication if
it
> does not
> - If he has a session then clean it and create a new one
> - If he does not have a session - we have 3 options:
> a)- tell him hid did not have an old session and drop him
> b)- tell him he did not have an old session but nevertheless create a new
> one
> c)- create a new session and do not tell him
>
> With option a we are close to the old option c but the initiator does not
> have to find the old session he can do now safely a new login
> With b & c  we are back at the old b.
>
> Which one would you give your kingdom for ( and my peace!).
>
> Julo
>
> "Dev" <deva@stargateip.com>@ece.cmu.edu on 28-08-2001 01:44:15
>
> Please respond to <deva@stargateip.com>
>
> Sent by:  owner-ips@ece.cmu.edu
>
> To:   "KRUEGER,MARJORIE \(HP-Roseville,ex1\)" <marjorie_krueger@hp.com>,
>       <ips@ece.cmu.edu>
> cc:
> Subject:  RE: iSCSI: reusing ISID for recovery
>
> All,
>
> When a session is already running authenticated, a login request with the
> same
> ISID + initiator fails authentication. Will the session continue to run?
> Or
> if the target fails during parameter negotiation?
>
> I guess, yes. i.e. target will not act on the existing session, until
> the login completes successfully. Or are there exception to these?
>
> Thanks
>
> Deva
> Platys Communications
>
> > -----Original Message-----
> > From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > Sent: Saturday, August 25, 2001 12:23 AM
> > To: ips@ece.cmu.edu
> > Subject: RE: iSCSI: reusing ISID for recovery
> >
> >
> >
> > It may be another OS running on the same machine or CPU
> > complex or it could
> > be an attack.
> > In any case if the initiator is up and fine he can as well do logout.
> > It is a rare enough event for us not to try to optimize.
> >
> > The reboot is the only case in which the initiator can't
> > logout and about
> > which we care.
> >
> > And I would like to remind you all that we where on this
> > exact thread more
> > tan 3 months ago (other players).
> > I just restated the rationale for an (apparent) newcomer.
> >
> > Julo
> >
> > "KRUEGER,MARJORIE (HP-Roseville,ex1)"
> > <marjorie_krueger@hp.com>@ece.cmu.edu
> > on 25-08-2001 03:51:43
> >
> > Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"
> >       <marjorie_krueger@hp.com>
> >
> > Sent by:  owner-ips@ece.cmu.edu
> >
> >
> > To:   ips@ece.cmu.edu
> > cc:
> > Subject:  RE: iSCSI: reusing ISID for recovery
> >
> >
> >
> > I don't see how Option A is prone to "wild closing of sessions".  The
> > target
> > is only looking for sessions with this particular initiator
> > and closing
> > them
> > if the ISID matches.
> >
> > If an initiator doesn't have a valid TSID (login w/TSID=0),
> > it means it has
> > lost state entirely (reboot) or knows it wants to immediately reset a
> > session (NIC failure).  How could there possibly be a case where the
> > initiator has an active valid session with the same ISID, but
> > just doesn't
> > know about it??  Rejecting the login seems pointless, since
> > obviously the
> > initiator either has a bug or intends to quickly reset the session.
> >
> > The behavior chosen (Option C) will cause the initiator's
> > recovery to be
> > delayed while the target NOPs all the connections and waits
> > for them to
> > time
> > out - this will only delay the initiators recovery
> > unnecessarily.  I can't
> > help but think this will cause long term problems for the protocol.
> >
> > Marjorie Krueger
> > Networked Storage Architecture
> > Networked Storage Solutions Org.
> > Hewlett-Packard
> > tel: +1 916 785 2656
> > fax: +1 916 785 0391
> > email: marjorie_krueger@hp.com
> >
> > > -----Original Message-----
> > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > > Sent: Thursday, August 23, 2001 9:39 PM
> > > To: ips@ece.cmu.edu
> > > Subject: Re: iSCSI: reusing ISID for recovery (Was: RE: iSCSI
> > > - Change -
> > > Login/Text...)
> > >
> > >
> > >
> > > Mallikarjun,
> > >
> > > On  your point 1 that is what is stated today in the draft.
> > >
> > > On your point 2 option C is the one we took in the draft, after some
> > > debate.
> > >
> > > Option A is prone to "wild closing of sessions" and option B is also
> > > relaying to much on the good behaviour of the
> > > client. It also introduces a "feature" that complicates
> > login/logout.
> > >
> > > Our postion on this is  that the initiator should logout the session
> > > explicitly if it can (and in this case it can as the target
> > > has ascertained
> > > that the session is alive).
> > >
> > > I agree that you may want to update the stayte diagram to
> > > reflect this.
> > >
> > > Julo
> > >
> > >
> > > "Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on
> > 24-08-2001 01:46:40
> > >
> > > Please respond to cbm@rose.hp.com
> > >
> > > Sent by:  owner-ips@ece.cmu.edu
> > >
> > >
> > > To:   ips@ece.cmu.edu
> > > cc:
> > > Subject:  iSCSI: reusing ISID for recovery (Was: RE: iSCSI
> > - Change -
> > >       Login/Text...)
> > >
> > >
> > >
> > > Julian and all:
> > >
> > > This thread mirrors another discussion some of us are
> > > having in a different forum.  Following (two bullets 1
> > > & 2 below) is what I proposed there, attempting to address
> > > two issues -
> > >      a) how to recover sessions when target and the initiator
> > >            have conflicting views of the same TCP connection(s)?
> > >            (Initiator NIC fails, but there's no I/O activity,
> > >            and the target doesn't see any connection failure.)
> > >      b) More specifically, how to address the above problem
> > >            when the initiator *does not want* to re-instate failed
> > >            connections since it only implements the mandatory
> > >            session recovery?
> > >
> > > This could add clarity or muddle things up here, though hopefully
> > > the former...
> > >
> > > 1 If login is sent with the same ISID, same TSID, same CID
> > and X-bit,
> > >   then it means a failed connection is being re-instated (whether
> > >   or not there are multiple connections in the session).  This login
> > >   attempt must be done before the connection timeout
> > (transition M1),
> > >   or if this is the only connection in the session, also before the
> > >   session timeout (transition N6) - to be counted as a connection
> > >   reinstatement effort.
> > >            o CmdSN counters (CmdSN, ExpCmdSN) are continued.
> > > Initiator
> > >              must do command plugging when there's a mismatch
> > >              between its CmdSN and ExpCmdSN in the login response.
> > >            o Since this is an implicit connection logout, all
> > > the active
> > >              tasks on the connection are either internally
> > terminated,
> > >              or made non-allegiant (based on ErrorRecoveryLevel=x/y,
> > >              TBD) for recovery.
> > >
> > > 2 If login is sent with the same ISID and TSID=0, the session (if it
> > >   exists on the target) is being cleared and any active connections
> > >   that the target sees must be immediately (at the end of the login
> > >   process including any initiator authentication) transport reset.
> > >   Initiator may attempt this only after it ascertains a
> > > session failure
> > >   on its end (ie. all connections entered RECOVERY_START).
> > >            o CmdSN counters get reset.  Initiator has to perform the
> > >              currently defined session recovery actions.
> > >            o All active tasks of the session are internally
> > > terminated.
> > >
> > >
> > > Essentially, I was proposing extending the same notion of "implicit
> > > logout" of a connection to the session level.  The options that I
> > > see are -
> > >
> > >        A) Should iSCSI let it happen by default as stated above (ie.
> > >           same ISID, TSID=0 always wipes out the
> > pre-existing session
> > >           on target, since we are mandating it to be used only when
> > >           initiator sees a session failure)?
> > >        B) Should iSCSI mandate making this intended cleanup explicit
> > >           by setting a bit (Say C-bit, for Clear) in the
> > Login Command
> > >           PDU to prevent an accidental session cleanup with a buggy
> > >           initiator code?
> > >        C) Should iSCSI merely state that targets must ascertain
> > >           the connection state(s) whenever a new session creation
> > >           attempt is made with a known ISID and TSID=0?  (sort of
> > >           defeats the intention of the initiator wanting quicker
> > >           session recovery since the Login command PDU would have
> > >           to idle till target ascertains the connection state(s)).
> > >
> > > I prefer A, or B.
> > >
> > > Going with A or B means that the description of transition N3
> > > in the session state diagram would have to change to:
> > >      Last LOGGED_IN connection had ceased to be LOGGED_IN,
> > >         or a Login Command requesting clearing the session (also
> > >         with C-bit set, if option B) was received by the target.
> > >
> > > The transition N7's description would have to be augmented as
> > > well to:
> > >         Session recovery attempt with an implicit logout,
> > >         or connection reinstatement/new CID addition.
> > >
> > > Comments?
> > > --
> > > Mallikarjun
> > >
> > >
> > > Mallikarjun Chadalapaka
> > > Networked Storage Architecture
> > > Network Storage Solutions Organization
> > > MS 5668   Hewlett-Packard, Roseville.
> > > cbm@rose.hp.com
> > >
> > >
> > > >Stephen,
> > > >
> > > >That can happen as the target may set-up completely new TCP
> > > connections
> > > >(the old sockets are still there and look OK).
> > > >Untill the login is  progessing he assumes that this is
> > just another
> > > >open-session attempt. Then he checks the old session and the
> > > session is
> > > >dead (initiator has closed the connections).
> > > >
> > > >The target has to distinguish only between a session that is
> > > alive (and
> > > >reject the new one) and one that its dead in which case it
> > > can clean-up.
> > > >
> > > >Julo
> > > >
> > > >"Wheat, Stephen R" <stephen.r.wheat@intel.com> on
> > 23-08-2001 22:50:56
> > > >
> > > >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> > > >
> > > >To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> > > >cc:
> > > >Subject:  RE: iSCSI - Change - Login/Text commands with the
> > > binary stage
> > > co
> > > >          de
> > > >
> > > >
> > > >
> > > >Julian,
> > > >
> > > >I don't understand your answer.  For the scenario given, I
> > > would presume
> > > >then that the target would reject the new session attempt,
> > > as it sees the
> > > >previous session still "alive".  What is there to tell the
> > > target that
> > > this
> > > >is any different from when the Initiator is erroneously using the
> > > >repetitive
> > > >session id?
> > > >
> > > >Thanks,
> > > >Stephen
> > > >
> > > >-----Original Message-----
> > > >From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > > >Sent: Thursday, August 23, 2001 11:15 AM
> > > >To: ips@ece.cmu.edu
> > > >Subject: Re: iSCSI - Change - Login/Text commands with the
> > > binary stage
> > > >co de
> > > >
> > > >
> > > >Stephen,
> > > >
> > > >1.If the initiator goes away for a while and reboots and
> > there was no
> > > >activity on the connections
> > > >the target may see a session alive (I am not sure that it
> > > has to appear on
> > > >the state diagram but maybe).
> > > >
> > > >2.Again - I am not sure that the curent state diagram
> > > includes death of
> > > the
> > > >initiator
> > > >
> > > >Julo
> > > >
> > > >"Wheat, Stephen R" <stephen.r.wheat@intel.com>@ece.cmu.edu
> > > on 23-08-2001
> > > >19:58:34
> > > >
> > > >Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
> > > >
> > > >Sent by:  owner-ips@ece.cmu.edu
> > > >
> > > >
> > > >To:   ips@ece.cmu.edu
> > > >cc:
> > > >Subject:  Re: iSCSI - Change - Login/Text commands with the
> > > binary stage
> > > co
> > > >      de
> > > >
> > > >
> > > >
> > > >Julian,
> > > >
> > > >1.3.6 ISID states that the target should check to see if the
> > > old session
> > > is
> > > >still active when a duplicate session is detected.
> > > >
> > > >I have two questions, the second only if you answer in the
> > > affirmative on
> > > >the first ;^)
> > > >
> > > >1. Is there a properly executed sequence of events (i.e., no
> > > coding error
> > > >on
> > > >the target side) where the session is not active, but the
> > > target hadn't
> > > >taken notice of it?  It appears this as a protocol-specified
> > > means to work
> > > >around a flaw in a target's implementation.  I interpret the
> > > state diagram
> > > >transitions as being atomic wrt other commands.  I.e., the
> > > last logout
> > > >would
> > > >result in the various transitions of the connection/session
> > > prior to the
> > > >initiator starting the session up again.  And the target would have
> > > >completed the transitions prior to handling a new session request.
> > > >
> > > >2. If you answered (1) in the affirmative, then the word
> > > "Active" is not
> > > >consistent with the 6.3 Session State Diagram.  Does this
> > > mean the target
> > > >got lost, due to transport failures of any sort, in its
> > > transition from
> > > >Q3-to-Q2-to-Q1?  It sounds like the intent is to close the
> > > old session if
> > > >the session was in Q2 or Q4, presuming if it were in Q1,  it
> > > would not
> > > have
> > > >been found as a duplicate.
> > > >
> > > >Stephen
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >

 - santoshr.vcf





From owner-ips@ece.cmu.edu  Wed Aug 29 18:02:10 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11882
	for <ips-archive@odin.ietf.org>; Wed, 29 Aug 2001 18:02:10 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7TKxwn19073
	for ips-outgoing; Wed, 29 Aug 2001 16:59:58 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7TKxvP19065
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 16:59:57 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-68-173.cisco.com [161.44.68.173]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA26642 for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 16:59:46 -0400 (EDT)
Message-ID: <3B8D57B8.4AC35C23@cisco.com>
Date: Wed, 29 Aug 2001 15:59:36 -0500
From: Steve Senum <ssenum@cisco.com>
X-Mailer: Mozilla 4.73 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-ips <ips@ece.cmu.edu>
Subject: Re: iSCSI - Change - Login/Text commands with the binary stage code
References: <OF88AAECCB.EA2695E6-ONC2256AB3.0022BC92@telaviv.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Julian,

A couple of ideas from Matthew Burbridge & Co.'s
login proposal that has generated some interest here:

1. Removal of partial login response.  Is it still needed?

2. Requiring Initiator and (if not a discovery session)
   Target names on login command, so they are always
   available if needed by the initial phase.

Comments?

Regards,
Steve Senum


From owner-ips@ece.cmu.edu  Wed Aug 29 18:03:58 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11941
	for <ips-archive@odin.ietf.org>; Wed, 29 Aug 2001 18:03:57 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7TKwSY18900
	for ips-outgoing; Wed, 29 Aug 2001 16:58:28 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e34.bld.us.ibm.com (e34.co.us.ibm.com [32.97.110.132])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7TKwRP18896
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 16:58:27 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e34.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id QAA60556
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 16:56:05 -0400
Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7TKv11196532
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 14:57:01 -0600
Importance: Normal
Subject: RE: iSCSI: reusing ISID for recovery
To: ips@ece.cmu.edu
From: "Jim Hafner" <hafner@almaden.ibm.com>
Date: Wed, 29 Aug 2001 13:56:59 -0700
Message-ID: <OFB33332D3.080A315D-ON88256AB7.007219E2@boulder.ibm.com>
X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at
 08/29/2001 01:57:00 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Julian,

In the first place, a multi OS machine should have a different iSCSI name
for each OS image (that's what the iSCSI Name is supposed to name).  So,
this sort of collision shouldn't occur.  If these OS's are sharing the same
SCSI stack or iSCSI stack (and same iSCSI name), then the iSCSI layer
should be handling this problem directly.  This is one of the reasons why
"configuring and partitioning of the ISID"s among the components (session
coordinators) that drive/coordinate/handle/process/instantiate/etc. the
sessions is an important and desireable feature of these components.  You
should be able to stuff an iSCSI Name and a set of ISIDs down through the
layers to the session coordinators (be they hardware or software) so that
they can independently handle their responsibility without name collisions
with other components.  The problem you think is going to happen, I think,
should never happen in a well-behaved system.

So, as I read your model now, you've still got the target "checking to see
if the session is alive".   I think we're trying to avoid this.  It's not
so much for optimization (as you alluded to).  For me, its to make the
target's behavior completely predictable.  Can the initiator judge a priori
what the target thinks is going on with the other session if it doesn't
have a context to check on itself?

If the old session is alive enough to answer to NOP, isn't it alive enough
to clean it up?  When wouldn't it be?

Jim Hafner


Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 08/29/2001 12:56:24 pm

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery




Marjorie,

I probably have some difficulties in explaining and you in reading ... and
that contributes to increasing distance.
Doing an automatic logout when a new session is seen can be performed by
mistake by an OS in a multi OS machine. It is just to easy to let it
through.  After a reboot the right procedure would be to login cleanly (no
previous knowledge needed). The target will ascertain that the old session
is dead and let you in.

You will need the X only when the old session is alive (answering to NOP)
but you don't know how to clean it.

Reboot behavior is close to what you have in the current draft ( a single
login needed - no X).

The difference is when you have a living connection - then you have for the
session the same thing as for a connection you have to restart it.

Julo

"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>@ece.cmu.edu
on 29-08-2001 22:27:35

Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"
      <marjorie_krueger@hp.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: reusing ISID for recovery



It would help to get your message thru if you could answer our requests for
an explanation of your thinking.  We have tried several times to explain
our
logic (w/examples) but I haven't seen an example from you supporting a
scenario in which you see a problem.

If an initiator reboots, and has no context information, how can it know
whether or not a target has a pre-existing session?  Since there is no nice
way to know that, I would probably code my initiator to request a login
with
the X bit set (but as Mallikarjun said, I don't like this overloading of
the
X bit, it's a special case and makes the coding extra convoluted).  In your
preferred scenario, this would cause the target to reject the login "cause
there is no pre-existing session", and the initiator would re-issues the
login without the X bit set.  What have you saved anyone from here?  You've
just added latency to the login process.  And either way the initiator
codes
it's login after reboot, there's a presumably equal probability of
encountering this extra exchange.

I still haven't seen a plausable example where it does harm to have a login
w/ ISID=n, TSID=0 close an existing session with this initiator.  I can see
no case where this would be the wrong decision.  If "this isn't what the
initiator intended", this is a defective initiator implementation and
closing the other session at least does no harm.

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: marjorie_krueger@hp.com

> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Wednesday, August 29, 2001 10:46 AM
> To: ips@ece.cmu.edu
> Subject: RE: iSCSI: reusing ISID for recovery
>
>
> Thanks - I started feeling bad. I could not get a message
> through. Julo
>
> "Dev" <deva@stargateip.com> on 29-08-2001 19:03:40
>
> Please respond to <deva@stargateip.com>
>
> To:   Julian Satran/Haifa/IBM@IBMIL, <ips@ece.cmu.edu>
> cc:
> Subject:  RE: iSCSI: reusing ISID for recovery
>
>
>
> Julian,
>
> >But - as this is bound to bring
> >many an initiator writer to set always
> >the bit to "just cover for the case" I propose that the
> command fails if
> >the X bit was on but there was no need for it to be on.
>
> The only need to set the X-bit (when ISID, TSID=0) could be
> to forcibly
> close a pre-existing session, if any in the target right?
>
> I agree with this proposal, as this forces the initiator to issue the
> command
> with an X-bit only when there is an error (a session already exists).
> I also like that returning an error when there is no need to
> set an X-bit,
> as it discourages the initiators to set the X-bit by default,
> for opening
> a session.
>
> Thanks
>
> Deva
> Platys Communications.
>
>








From owner-ips@ece.cmu.edu  Wed Aug 29 18:09:23 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10218
	for <ips-archive@odin.ietf.org>; Wed, 29 Aug 2001 17:10:05 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7TJRmU13485
	for ips-outgoing; Wed, 29 Aug 2001 15:27:48 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7TJRjP13477
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 15:27:45 -0400 (EDT)
Received: from xparelay1.corp.hp.com (unknown [15.58.136.173])
	by palrel2.hp.com (Postfix) with ESMTP id 171AF192D
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 12:27:45 -0700 (PDT)
Received: from xpabh2.corp.hp.com (xpabh2.corp.hp.com [15.58.136.192])
	by xparelay1.corp.hp.com (Postfix) with ESMTP id AE2C81F52B
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 12:27:39 -0700 (PDT)
Received: by xpabh2.corp.hp.com with Internet Mail Service (5.5.2653.19)
	id <RHJ5JVH2>; Wed, 29 Aug 2001 12:27:39 -0700
Message-ID: <6BD67FFB937FD411A04F00D0B74FE87802A0928C@xrose06.rose.hp.com>
From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
To: ips@ece.cmu.edu
Subject: RE: iSCSI: reusing ISID for recovery
Date: Wed, 29 Aug 2001 12:27:35 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

It would help to get your message thru if you could answer our requests for
an explanation of your thinking.  We have tried several times to explain our
logic (w/examples) but I haven't seen an example from you supporting a
scenario in which you see a problem.

If an initiator reboots, and has no context information, how can it know
whether or not a target has a pre-existing session?  Since there is no nice
way to know that, I would probably code my initiator to request a login with
the X bit set (but as Mallikarjun said, I don't like this overloading of the
X bit, it's a special case and makes the coding extra convoluted).  In your
preferred scenario, this would cause the target to reject the login "cause
there is no pre-existing session", and the initiator would re-issues the
login without the X bit set.  What have you saved anyone from here?  You've
just added latency to the login process.  And either way the initiator codes
it's login after reboot, there's a presumably equal probability of
encountering this extra exchange.

I still haven't seen a plausable example where it does harm to have a login
w/ ISID=n, TSID=0 close an existing session with this initiator.  I can see
no case where this would be the wrong decision.  If "this isn't what the
initiator intended", this is a defective initiator implementation and
closing the other session at least does no harm.

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: marjorie_krueger@hp.com 

> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Wednesday, August 29, 2001 10:46 AM
> To: ips@ece.cmu.edu
> Subject: RE: iSCSI: reusing ISID for recovery
> 
> 
> Thanks - I started feeling bad. I could not get a message 
> through. Julo
> 
> "Dev" <deva@stargateip.com> on 29-08-2001 19:03:40
> 
> Please respond to <deva@stargateip.com>
> 
> To:   Julian Satran/Haifa/IBM@IBMIL, <ips@ece.cmu.edu>
> cc:
> Subject:  RE: iSCSI: reusing ISID for recovery
> 
> 
> 
> Julian,
> 
> >But - as this is bound to bring
> >many an initiator writer to set always
> >the bit to "just cover for the case" I propose that the 
> command fails if
> >the X bit was on but there was no need for it to be on.
> 
> The only need to set the X-bit (when ISID, TSID=0) could be 
> to forcibly
> close a pre-existing session, if any in the target right?
> 
> I agree with this proposal, as this forces the initiator to issue the
> command
> with an X-bit only when there is an error (a session already exists).
> I also like that returning an error when there is no need to 
> set an X-bit,
> as it discourages the initiators to set the X-bit by default, 
> for opening
> a session.
> 
> Thanks
> 
> Deva
> Platys Communications.
> 
> 


From owner-ips@ece.cmu.edu  Wed Aug 29 18:15:01 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12116
	for <ips-archive@odin.ietf.org>; Wed, 29 Aug 2001 18:15:00 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7TLCqi19893
	for ips-outgoing; Wed, 29 Aug 2001 17:12:52 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7TLClP19883
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 17:12:47 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-68-173.cisco.com [161.44.68.173]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA12409 for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 17:12:38 -0400 (EDT)
Message-ID: <3B8D5ABC.C2D84C7E@cisco.com>
Date: Wed, 29 Aug 2001 16:12:28 -0500
From: Steve Senum <ssenum@cisco.com>
X-Mailer: Mozilla 4.73 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-ips <ips@ece.cmu.edu>
Subject: Re: iSCSI - Change - Login/Text commands with the binary stage code
References: <OF88AAECCB.EA2695E6-ONC2256AB3.0022BC92@telaviv.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Julian,

In the following section:

   If the initiator decides to forego the SecurityNegotiation stage it
   issues the Login with the CNxSG set to LoginOperationalNegotiation in
   the current stage and the target may replay with a Login Response
   indicating that it is unwilling to accept the connection without
   SecurityNegotiation and terminate the connection.

This seems contrary to the requirement to implement
authentication (at least AuthMethod=SRP).  I realize
this could also be a configuration issue, but I wonder
if the spec should at least strongly recommend starting
with phase SecurityNegotiation, or better yet, make it
a SHOULD?

Regards,
Steve Senum


From owner-ips@ece.cmu.edu  Wed Aug 29 18:17:11 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12152
	for <ips-archive@odin.ietf.org>; Wed, 29 Aug 2001 18:17:06 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7TLNvv20568
	for ips-outgoing; Wed, 29 Aug 2001 17:23:57 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from sentinel.sanera.net (ns1.sanera.net [208.253.254.10] (may be forged))
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7TLNtP20560
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 17:23:55 -0400 (EDT)
Received: from newton.sanera.net (newton [192.168.254.11])
	by sentinel.sanera.net (8.11.2/8.11.2) with ESMTP id f7TLNi222104;
	Wed, 29 Aug 2001 14:23:44 -0700
Received: from strahmw2k (dhcp-pc-100-165.sanera.net [192.168.100.165])
	by newton.sanera.net (8.11.4/8.11.4) with SMTP id f7TLNbU08401;
	Wed, 29 Aug 2001 14:23:37 -0700 (PDT)
From: "Bill Strahm" <bill@sanera.net>
To: <mbakke@cisco.com>
Cc: "Ips@Ece. Cmu. Edu" <ips@ece.cmu.edu>
Subject: RE: ISCSI: User authentication vs. Machine Authentication for iSCSI
Date: Wed, 29 Aug 2001 14:23:20 -0700
Message-ID: <HDECJFNIFJBIAINDCFOMMEKCCAAA.bill@sanera.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Importance: Normal
In-Reply-To: <3B8D5932.42869881@cisco.com>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

I am not sure that helped.  Again, the model of a Tape drive...

The user does not own the tape drive, the operating system owns the tape
drive, when I (as a user) wants to use the tape drive, I ask the operating
system, it grants me access, and I go on.

In fact from a purely SCSI level, I do not believe there is any concept of a
user at all, the Operating system on the device provides the concept of a
user through the OS abstraction layer.

The problem that I am having is that I do not see how I can make user
security work through the OS abstraction.  And if the OS HAS to know about
the multiple users, I now have to trust the OS as well, which means that
effectively I have one user on the machine anyway...

Bill

-----Original Message-----
From: mbakke@cisco.com [mailto:mbakke@cisco.com]
Sent: Wednesday, August 29, 2001 2:06 PM
To: Bill Strahm
Cc: Ips@Ece. Cmu. Edu
Subject: Re: ISCSI: User authentication vs. Machine Authentication for
iSCSI


Bill Strahm wrote:
>
> I have been fighting with this problem since I left LA.
>
> I am not aware of any usage scenarios today where block devices are owned
by
> the user rather than the machine.  I will conceed that in many instances
the
> first thing the system does is assign the resource to a use (tape,
scanner,
> etc.) but the machine still owns the resource and can in fact remove it
out
> from under the user...
>
> I am not to certain how I could build a trusted iSCSI environment where
one
> user would have no knowledge about what was happening with other users in
a
> malicious environment (especially where a system was participating in the
> exposure of resourses).  Examples of this include things like co-located
Web
> hosting where a single user scans process memory looking for 1Kbit of
random
> data, and when finding it attempts to determine if that is the private key
> of a user sharing the resource.
>
> The reason I am bringing this up, is I am not sure trying to define
security
> above the machine level makes any sense for iSCSI.  Aren't most SCSI
devices
> owned by the Operating System not the User and partitioned out by the
> Operating System to the users ?  If this is the case many of our
> authentication methods simplify to simple IKE identities.
>
> Bill

Bill-

As you pointed out, there is a case where just using IKE with
an iSCSI AuthMethod of "none" is valid.  That case is where:

- There a one-to-one correspondence between an initiator and an
  operating system
- IPsec is being used for all iSCSI traffic
- The customer is willing to deploy public key certificates on the
  client side (for each initiator) as well as on the devices

If all of the above are true, iSCSI can certainly use an AuthMethod
of none, and be done with it.

However,

- There are cases (David Black brought up some tape applications) where
  more than one initiator might exist on an operating system

- IPsec is not likely to be used for a large percentage of iSCSI
  traffic any time soon

- When IPsec is used, many customers will have an easier time with the
  familiar model of authenticating the server "machine" but using a
  dummy certificate for the client.

If any of the above are true, iSCSI-level of authentication is
required.

Hope this helps,

Mark



From owner-ips@ece.cmu.edu  Wed Aug 29 18:35:28 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12604
	for <ips-archive@odin.ietf.org>; Wed, 29 Aug 2001 18:35:27 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7TLIKj20232
	for ips-outgoing; Wed, 29 Aug 2001 17:18:20 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7TLIIP20227
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 17:18:18 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id XAA25014
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 23:18:06 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7TLI6J131228
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 23:18:06 +0200
Importance: Normal
Subject: Re: iSCSI - Change - Login/Text commands with the binary stage code
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF2313AAC4.E7FE1FCD-ONC2256AB7.0073B96F@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Thu, 30 Aug 2001 00:17:31 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 30/08/2001 00:18:06
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Steve,

The partial response is not strictly needed it is just handy to have the
login request answered
with a login response. On this we can put the partial/final answer. For a
text it would have been arbitrary (text outside login does not need it).

As for the names - I though that security people might object having the
name in clear if the security phase does not make use of the name.
Otherwise we can mandate them on the login but I wonder if that is a real
improvement or we are getting carelles.

Julo


Steve Senum <ssenum@cisco.com>@ece.cmu.edu on 29-08-2001 23:59:36

Please respond to Steve Senum <ssenum@cisco.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ietf-ips <ips@ece.cmu.edu>
cc:
Subject:  Re: iSCSI - Change - Login/Text commands with the binary stage
      code



Julian,

A couple of ideas from Matthew Burbridge & Co.'s
login proposal that has generated some interest here:

1. Removal of partial login response.  Is it still needed?

2. Requiring Initiator and (if not a discovery session)
   Target names on login command, so they are always
   available if needed by the initial phase.

Comments?

Regards,
Steve Senum





From owner-ips@ece.cmu.edu  Wed Aug 29 19:10:20 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13210
	for <ips-archive@odin.ietf.org>; Wed, 29 Aug 2001 19:10:15 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7TLcs721386
	for ips-outgoing; Wed, 29 Aug 2001 17:38:54 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7TLcrP21382
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 17:38:53 -0400 (EDT)
Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203])
	by palrel2.hp.com (Postfix) with ESMTP id EC8AB1F26
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 14:38:48 -0700 (PDT)
Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197])
	by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id OAA27271
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 14:38:43 -0700 (PDT)
Message-ID: <3B8D6225.324BC149@cup.hp.com>
Date: Wed, 29 Aug 2001 14:44:05 -0700
From: Santosh Rao <santoshr@cup.hp.com>
Organization: Hewlett Packard, Cupertino.
X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778)
X-Accept-Language: en
MIME-Version: 1.0
To: ips@ece.cmu.edu
Subject: Re: iscsi : Async Message "target requests logout".
References: <OF7F6DBDE5.B2CE11F3-ONC2256AB7.006F05C5@telaviv.ibm.com>
Content-Type: multipart/mixed;
 boundary="------------E0CA5E6AB210C9A8029D6919"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

This is a multi-part message in MIME format.
--------------E0CA5E6AB210C9A8029D6919
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Julian,

The jist of my issue is that the draft must not mandate that the "close the
cxn" logout be used in response to an async msg of type "target requests
logout". In the case of initiators deploying session recovery, this flavor of
logout may not be used/supported at all !

Such initiators would always resort to a session logout (reason "close the
session") & re-login. [Whether they have to do this in 2 steps or 1, is the
subject of a seperate mail thread discussing logout optimization, also
currently under discussion.].

In general, initiators with different error recovery capabilites may respond
in different ways to these async messages and the draft must not mandate what
the initiator must do in response to these async messages.

Regards,
Santosh


Julian Satran wrote:

> Due to security reasons we adopted the rule of only one login / TCP
> connection. You can't relogin on the same TCP connection.
>
> iSCSI asynchronous messages are not SCSI AENs (although they carry those
> too). Support for iSCSI Async. Messages is not optional.
>
> The close connection flavor of the message is the handiest for recovery
> (initiator knows when he gets it
> that the target will close the target end of it).
>
> I think that the text saying perform a logout - implied also the "implicit"
> logout from a login with restart but I will check again.
>
> Julo
>
> Santosh Rao <santoshr@cup.hp.com>@ece.cmu.edu on 29-08-2001 23:08:36
>
> Please respond to Santosh Rao <santoshr@cup.hp.com>
>
> Sent by:  owner-ips@ece.cmu.edu
>
> To:   IPS Reflector <ips@ece.cmu.edu>
> cc:
> Subject:  iscsi : Async Message "target requests logout".
>
> All,
>
> I've some concerns on the new wording for async messages in rev 07. The
> new wording for the async message iscsi event "target requests logout"
> reads :
>
>  "2    Target requests Logout. This Async Message MUST be sent on the
> same connection as the one being  requested to be logged out.  Initiator
> MUST honor this request by issuing a Logout as early as possible, but no
> later than Parameter3 seconds.  Initiator MUST send a Logout with a
> reason code of "Close the   connection" to cleanly shutdown the
> connection.  If the initiator does not Logout in Parameter3 seconds, the
>
> target MAY send an Async PDU with iSCSI event code "Dropped the
> connection" if possible, or simply terminate the transport connection."
>
> In the following cases, the initiator may be unable to or may choose not
>
> to use "close the cxn" logout :
>
> 1) initiator is only implementing session recovery and is using single
> cxn sessions. In this case, it would just perform a session logout
> + re-login [or an implicit session
> logout and  re-login by sending another session login
> with the same ISID and NULL TSID.]
>
> 2) Initiator does not provide support for async messages and chooses to
> ignore async messgaes. Async messages are provided for diagnostic
> capabilities and differing classes of initiators may have differing
> level of diagnostic & recovery support. Simple initiators may just
> ignore the async messages as the message is bound to be followed by some
>
> action from the target end. Mandating the responses to async messages
> does not allow for this initiator behaviour.
>
> The "close the cxn" flavor of logout or the initiator responses to async
> messages must not be mandated, since differing levels of error recovery
> support in initiators can result in different behaviours.
>
> Regards,
> Santosh
>
>  - santoshr.vcf

--------------E0CA5E6AB210C9A8029D6919
Content-Type: text/x-vcard; charset=us-ascii;
 name="santoshr.vcf"
Content-Description: Card for Santosh Rao
Content-Disposition: attachment;
 filename="santoshr.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Rao;Santosh 
tel;work:408-447-3751
x-mozilla-html:FALSE
org:Hewlett Packard, Cupertino.;SISL
adr:;;19420, Homestead Road, M\S 43LN,	;Cupertino.;CA.;95014.;USA.
version:2.1
email;internet:santoshr@cup.hp.com
title:Software Design Engineer
x-mozilla-cpt:;21088
fn:Santosh Rao
end:vcard

--------------E0CA5E6AB210C9A8029D6919--



From owner-ips@ece.cmu.edu  Wed Aug 29 19:16:14 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13263
	for <ips-archive@odin.ietf.org>; Wed, 29 Aug 2001 19:16:14 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7TLn4n21985
	for ips-outgoing; Wed, 29 Aug 2001 17:49:04 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7TLn1P21981
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 17:49:02 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id XAA38728
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 23:48:54 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7TLmsv289532
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 23:48:54 +0200
Importance: Normal
Subject: Re: iSCSI - Change - Login/Text commands with the binary stage code
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFCDF400C1.1FFD51D6-ONC2256AB7.0076E777@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Thu, 30 Aug 2001 00:40:29 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 30/08/2001 00:48:53
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Steve,

Implement and use are different terms. An administrator might set it up not
to use security under specific conditions.

Julo

Steve Senum <ssenum@cisco.com>@ece.cmu.edu on 30-08-2001 00:12:28

Please respond to Steve Senum <ssenum@cisco.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ietf-ips <ips@ece.cmu.edu>
cc:
Subject:  Re: iSCSI - Change - Login/Text commands with the binary stage
      code



Julian,

In the following section:

   If the initiator decides to forego the SecurityNegotiation stage it
   issues the Login with the CNxSG set to LoginOperationalNegotiation in
   the current stage and the target may replay with a Login Response
   indicating that it is unwilling to accept the connection without
   SecurityNegotiation and terminate the connection.

This seems contrary to the requirement to implement
authentication (at least AuthMethod=SRP).  I realize
this could also be a configuration issue, but I wonder
if the spec should at least strongly recommend starting
with phase SecurityNegotiation, or better yet, make it
a SHOULD?

Regards,
Steve Senum





From owner-ips@ece.cmu.edu  Wed Aug 29 19:16:41 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13274
	for <ips-archive@odin.ietf.org>; Wed, 29 Aug 2001 19:16:41 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7TM1Zh22619
	for ips-outgoing; Wed, 29 Aug 2001 18:01:35 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e32.bld.us.ibm.com (e32.co.us.ibm.com [32.97.110.130])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7TM1XP22614
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 18:01:33 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e32.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA103878
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 17:59:20 -0400
Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7TM0G187404
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 16:00:16 -0600
Importance: Normal
Subject: RE: ISCSI: User authentication vs. Machine Authentication for iSCSI
To: ips@ece.cmu.edu
From: "Jim Hafner" <hafner@almaden.ibm.com>
Date: Wed, 29 Aug 2001 15:00:13 -0700
Message-ID: <OF7B1C0390.9FE2EC29-ON88256AB7.007886F1@boulder.ibm.com>
X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at
 08/29/2001 03:00:15 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Bill,
I think I understand your question, so here's a remark.

I think a problem that creeps in to the iSCSI space (that doesn't exist in
essentially every other existing SCSI stack) is that a user can write an
application that acts like an iSCSI initiator and never ever go through the
OS stack.  (I've written an iSCSI initiator in Java that doesn't ever use
the host stack at all, just the standard network interfaces).   So, I could
easily have multiple iSCSI Initiators running (even in user space) on the
same machine.  At that point, I may want user level security.

If I didn't understand your question, I'll shut up (on this topic :-{))

Jim Hafner


"Bill Strahm" <bill@sanera.net>@ece.cmu.edu on 08/29/2001 02:23:20 pm

Sent by:  owner-ips@ece.cmu.edu


To:   <mbakke@cisco.com>
cc:   "Ips@Ece. Cmu. Edu" <ips@ece.cmu.edu>
Subject:  RE: ISCSI: User authentication vs. Machine Authentication for
      iSCSI



I am not sure that helped.  Again, the model of a Tape drive...

The user does not own the tape drive, the operating system owns the tape
drive, when I (as a user) wants to use the tape drive, I ask the operating
system, it grants me access, and I go on.

In fact from a purely SCSI level, I do not believe there is any concept of
a
user at all, the Operating system on the device provides the concept of a
user through the OS abstraction layer.

The problem that I am having is that I do not see how I can make user
security work through the OS abstraction.  And if the OS HAS to know about
the multiple users, I now have to trust the OS as well, which means that
effectively I have one user on the machine anyway...

Bill

-----Original Message-----
From: mbakke@cisco.com [mailto:mbakke@cisco.com]
Sent: Wednesday, August 29, 2001 2:06 PM
To: Bill Strahm
Cc: Ips@Ece. Cmu. Edu
Subject: Re: ISCSI: User authentication vs. Machine Authentication for
iSCSI


Bill Strahm wrote:
>
> I have been fighting with this problem since I left LA.
>
> I am not aware of any usage scenarios today where block devices are owned
by
> the user rather than the machine.  I will conceed that in many instances
the
> first thing the system does is assign the resource to a use (tape,
scanner,
> etc.) but the machine still owns the resource and can in fact remove it
out
> from under the user...
>
> I am not to certain how I could build a trusted iSCSI environment where
one
> user would have no knowledge about what was happening with other users in
a
> malicious environment (especially where a system was participating in the
> exposure of resourses).  Examples of this include things like co-located
Web
> hosting where a single user scans process memory looking for 1Kbit of
random
> data, and when finding it attempts to determine if that is the private
key
> of a user sharing the resource.
>
> The reason I am bringing this up, is I am not sure trying to define
security
> above the machine level makes any sense for iSCSI.  Aren't most SCSI
devices
> owned by the Operating System not the User and partitioned out by the
> Operating System to the users ?  If this is the case many of our
> authentication methods simplify to simple IKE identities.
>
> Bill

Bill-

As you pointed out, there is a case where just using IKE with
an iSCSI AuthMethod of "none" is valid.  That case is where:

- There a one-to-one correspondence between an initiator and an
  operating system
- IPsec is being used for all iSCSI traffic
- The customer is willing to deploy public key certificates on the
  client side (for each initiator) as well as on the devices

If all of the above are true, iSCSI can certainly use an AuthMethod
of none, and be done with it.

However,

- There are cases (David Black brought up some tape applications) where
  more than one initiator might exist on an operating system

- IPsec is not likely to be used for a large percentage of iSCSI
  traffic any time soon

- When IPsec is used, many customers will have an easier time with the
  familiar model of authenticating the server "machine" but using a
  dummy certificate for the client.

If any of the above are true, iSCSI-level of authentication is
required.

Hope this helps,

Mark






From owner-ips@ece.cmu.edu  Wed Aug 29 19:18:06 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13302
	for <ips-archive@odin.ietf.org>; Wed, 29 Aug 2001 19:18:06 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7TLmnT21972
	for ips-outgoing; Wed, 29 Aug 2001 17:48:49 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7TLmmP21968
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 17:48:48 -0400 (EDT)
Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190])
	by atlrel1.hp.com (Postfix) with ESMTP
	id A2825CD3; Wed, 29 Aug 2001 17:48:47 -0400 (EDT)
Received: from xatlbh3.atl.hp.com (xatlbh3.atl.hp.com [15.45.89.188])
	by xatlrelay1.atl.hp.com (Postfix) with ESMTP
	id 8CA681F530; Wed, 29 Aug 2001 17:48:41 -0400 (EDT)
Received: by xatlbh3.atl.hp.com with Internet Mail Service (5.5.2653.19)
	id <R6XPTNL4>; Wed, 29 Aug 2001 17:48:32 -0400
Message-ID: <6BD67FFB937FD411A04F00D0B74FE87802A0928F@xrose06.rose.hp.com>
From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
To: "'Michele Hallak - Stamler'" <michele@sanrad.com>, mbakke@cisco.com
Cc: ips@ece.cmu.edu
Subject: iSCSI: state of a SCSI MIB (was RE: ISCSI: A propos  MIB and spec
	ially iSCSI MIB)
Date: Wed, 29 Aug 2001 17:48:30 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Regarding your question on the state of a SCSI MIB, we are looking for a MIB
designer that is SCSI aware to head this effort, as Mark and I have too many
other committments.  The iSCSI MIB design team will contribute to the basis
for a SCSI MIB, but we are still looking for a leader in the SCSI MIB
effort.  We have taken this issue to the T10 CAP group to solicite help, but
the MIB must ultimately be submitted as an IETF draft.  Hopefully, this
effort will take shape soon.

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: marjorie_krueger@hp.com 

> -----Original Message-----
> From: Michele Hallak - Stamler [mailto:michele@sanrad.com]
> Sent: Tuesday, August 28, 2001 9:20 AM
> To: mbakke@cisco.com
> Cc: ips@ece.cmu.edu
> Subject: RE: ISCSI: A propos MIB and specially iSCSI MIB
> 
> 
> Mark,
> Thanks a lot for your prompt answer...
> My comments are prefixed by MHS.
> Thanks again,
> 	Michele
> 
> > -----Original Message-----
> > From: Mark Bakke [mailto:mbakke@cisco.com]
> > Sent: Monday, August 27, 2001 3:47 PM
> > To: Michele Hallak - Stamler
> > Cc: ips@ece.cmu.edu
> > Subject: Re: ISCSI: A propos MIB and specially iSCSI MIB
> > 
> > 
> > Michele-
> > 
> > Thanks for the comments.  My comments are below.
> > 
> > --
> > Mark
> > 
> > Michele Hallak - Stamler wrote:
> > > 
> > > Since you are meeting at interim meetings on MIBs:
> > > 
> > > The following mail summarizes my suggestions concerning the
> > improvement
> > > of iSCSI MIB:
> > > 
> > > 1. New Textual Convention:
> > >  AuthenticationMethodTC  ::= TEXTUAL-CONVENTION
> > >     STATUS current
> > >     DESCRIPTION
> > >         "List of possible authentication methods."
> > >     SYNTAX INTEGER {
> > >                 none(1),
> > >                 crc32(2),
> > >                 crc64(3),
> > >                 md5(4),
> > >                 kerberosMd5(5),
> > >                 kerberosMd5des(6),
> > >                 kerberosMd5desHmark(7)
> > >         }
> > 
> > This is a text field in the current MIB; it will change to
> > an OID field in the next version, which acts a little like
> > your enumerated types, but is extensible without modifying
> > the MIB.  BTW, this is a set of two attributes called DataDigest
> > and HeaderDigest; AuthMethod is something completely different.
> > All of the digest methods will be removed from draft-08 with
> > the exception of "none" and "crc-32c".  With the new OID scheme;
> > values for these can be added to your enterprise MIB if you
> > choose to implement them.
> > 
> 	[MHS]  If it will be OIDs, it's fine with me. I was
> inconfortable with simple strings.
> > > 
> > > 2. Add RowStatus and Read-Write Access to the portals and to the
> > > authorized list of initiators.
> > 
> > Which attributes to write and which rows to delete are currently
> > under consideration.  We are looking for detailed input on this.
> > 
> > Please send the list of attributes you wish to write, and why
> > you wish to write them.
> 	[MHS]  Mainly, we would like to add the type of access for each
> initiator: read-only or read-write.
> 
> > > 3. Add RowStatus to iscsiTargetAttributesTable in order 
> to allow an
> > > administrator to create target and
> > > set the access of the fields:     iscsiTgtName  and 
> iscsiTgtAlias as
> > > read-create
> > 
> > It's not possible to create an iSCSI target without first creating
> > a SCSI target.  I don't think we will be ready to explore this until
> > we have made progress on a SCSI MIB.  If you have some ideas on how
> > a management station would make use of this (with both 
> MIBs) to create
> > new targets, please send them.
> > 
> 	[MHS]  After having made some clarifications, I understand what
> you mean now.
> 	What is the status of the SCSI MIB? Is there any work done on
> the matter? 
> 	And at which organization?
> 	For our management we need the ability to create targets. What
> is your suggestion?
> 	(Apart of private MIB)
> 	I think that anyway we can allow to create targets via iSCSI
> MIB; it is MAX-ACCESS and it
> 	will be the responsibility of the implementation to update SCSI
> modules about new targets.
> 	Your opinion?
> 
> 
> > > I hope that you'll aggree to make the change,
> > > 
> > >         Michele
> > 
> > -- 
> > Mark A. Bakke
> > Cisco Systems
> > mbakke@cisco.com
> > 763.398.1054
> 	[MHS]  
> 	Again Thanks a lot,
> 
> 	Michele Hallak-Stamler
> 	Sanrad Intelligent Storage
> 	michele@sanrad.com
> 	972-3-7674809
> 


From owner-ips@ece.cmu.edu  Wed Aug 29 19:33:45 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13436
	for <ips-archive@odin.ietf.org>; Wed, 29 Aug 2001 19:33:45 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7TMJKp23486
	for ips-outgoing; Wed, 29 Aug 2001 18:19:20 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from ariel.nishansystems.com (smtp.nishansystems.com [216.217.36.162])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7TMJHP23476
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 18:19:17 -0400 (EDT)
Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19)
	id <RDTY6TKL>; Wed, 29 Aug 2001 15:19:05 -0700
Message-ID: <B300BD9620BCD411A366009027C21D9B551FC9@ariel.nishansystems.com>
From: Charles Monia <cmonia@NishanSystems.com>
To: "Ips (E-mail)" <ips@ece.cmu.edu>
Subject: iFCP:PDF's with markup
Date: Wed, 29 Aug 2001 15:19:05 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Hi:

Sorry if this has been asked before.  For a rev of an evolving draft, is it
ok to submit a PDF file with change bars to the archive as well as (or in
lieu of) the txt file?

Charles
Charles Monia
Senior Technology Consultant
Nishan Systems
email: cmonia@nishansystems.com
voice: (408) 519-3986
fax:   (408) 435-8385
 


From owner-ips@ece.cmu.edu  Wed Aug 29 19:56:38 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13642
	for <ips-archive@odin.ietf.org>; Wed, 29 Aug 2001 19:56:38 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7TMT3423986
	for ips-outgoing; Wed, 29 Aug 2001 18:29:03 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7TMT1P23981
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 18:29:01 -0400 (EDT)
Received: from xparelay1.corp.hp.com (unknown [15.58.136.173])
	by palrel1.hp.com (Postfix) with ESMTP id 767671E4
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 15:29:00 -0700 (PDT)
Received: from xpabh3.corp.hp.com (xpabh3.corp.hp.com [15.58.136.223])
	by xparelay1.corp.hp.com (Postfix) with ESMTP id 2973C1F52B
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 15:29:00 -0700 (PDT)
Received: by xpabh3.corp.hp.com with Internet Mail Service (5.5.2653.19)
	id <RTRG1T4A>; Wed, 29 Aug 2001 15:29:00 -0700
Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF08E@xrose06.rose.hp.com>
From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
To: "Ips Reflector (E-mail)" <ips@ece.cmu.edu>
Subject: iSCSI: SCSI arch model mapping for iSCSI
Date: Wed, 29 Aug 2001 15:28:59 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

There a presentation scheduled at the London IETF on the current state of
the SCSI architectural model mapping for iSCSI.  The lively discussion
resulting from other topics squeezed the meetings into overtime and I wasn't
able to give the presentation, however I've posted it on our website for
everyone's viewing pleasure.  The URL is http://storage-arch.hp.com and the
presentation is under the "SAM2-iSCSI Model slides" link.

I just wanted to reiterate here the most important summary of rules for
iSCSI implementations.  Some of these are rules (MUSTs) and some are merely
suggestions for ease of implementation and desired behavior.


Initiators:
	-MUST assign a unique ISID for each session to a 
       target portal group.
	-SHOULD partition ISID namespace between "session
       managers" (eg, HBA)
	-Initiator name should be associated with the
       OS image

Targets:
	-MUST enforce uniqueness rules
	-SHOULD partition TSID namespace between target portal 
       groups (session managers)

There is a more comprehensive discussion of the model and reasoning, as well
as examples in the slides.

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: marjorie_krueger@hp.com 


From owner-ips@ece.cmu.edu  Wed Aug 29 19:56:56 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13653
	for <ips-archive@odin.ietf.org>; Wed, 29 Aug 2001 19:56:56 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7TMpcJ24962
	for ips-outgoing; Wed, 29 Aug 2001 18:51:38 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from ariel.nishansystems.com (smtp.nishansystems.com [216.217.36.162])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7TMpNP24951
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 18:51:28 -0400 (EDT)
Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19)
	id <RDTY6TKZ>; Wed, 29 Aug 2001 15:51:17 -0700
Message-ID: <B300BD9620BCD411A366009027C21D9B551FCA@ariel.nishansystems.com>
From: Charles Monia <cmonia@NishanSystems.com>
To: "Ips@Ece. Cmu. Edu" <ips@ece.cmu.edu>
Subject: RE: ISCSI: User authentication vs. Machine Authentication for iSC
	SI
Date: Wed, 29 Aug 2001 15:51:16 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Hi Bill:

Everything you say is right, up to a point. The functionality envisioned is
a virtualization environment in which the operating system, acting on behalf
of a user, instantiates an initiator entity at the bottom of the O/S driver
stack.  That entity in turn, may be logged into a virtualized storage
environment created specifically for that user. Afterwords, all i/o directed
to that initiator is controlled by the standard O/S mechanisms.

All this is analogous to plugging in a new hardware HBA. The powerful
feature in this case is the ability to totally control the 'HBA's' view of
the storage network.

Charles 
> -----Original Message-----
> From: Bill Strahm [mailto:bill@sanera.net]
> Sent: Wednesday, August 29, 2001 2:23 PM
> To: mbakke@cisco.com
> Cc: Ips@Ece. Cmu. Edu
> Subject: RE: ISCSI: User authentication vs. Machine Authentication for
> iSCSI
> 
> 
> I am not sure that helped.  Again, the model of a Tape drive...
> 
> The user does not own the tape drive, the operating system 
> owns the tape
> drive, when I (as a user) wants to use the tape drive, I ask 
> the operating
> system, it grants me access, and I go on.
> 
> In fact from a purely SCSI level, I do not believe there is 
> any concept of a
> user at all, the Operating system on the device provides the 
> concept of a
> user through the OS abstraction layer.
> 
> The problem that I am having is that I do not see how I can make user
> security work through the OS abstraction.  And if the OS HAS 
> to know about
> the multiple users, I now have to trust the OS as well, which 
> means that
> effectively I have one user on the machine anyway...
> 
> Bill
> 
> -----Original Message-----
> From: mbakke@cisco.com [mailto:mbakke@cisco.com]
> Sent: Wednesday, August 29, 2001 2:06 PM
> To: Bill Strahm
> Cc: Ips@Ece. Cmu. Edu
> Subject: Re: ISCSI: User authentication vs. Machine Authentication for
> iSCSI
> 
> 
> Bill Strahm wrote:
> >
> > I have been fighting with this problem since I left LA.
> >
> > I am not aware of any usage scenarios today where block 
> devices are owned
> by
> > the user rather than the machine.  I will conceed that in 
> many instances
> the
> > first thing the system does is assign the resource to a use (tape,
> scanner,
> > etc.) but the machine still owns the resource and can in 
> fact remove it
> out
> > from under the user...
> >
> > I am not to certain how I could build a trusted iSCSI 
> environment where
> one
> > user would have no knowledge about what was happening with 
> other users in
> a
> > malicious environment (especially where a system was 
> participating in the
> > exposure of resourses).  Examples of this include things 
> like co-located
> Web
> > hosting where a single user scans process memory looking 
> for 1Kbit of
> random
> > data, and when finding it attempts to determine if that is 
> the private key
> > of a user sharing the resource.
> >
> > The reason I am bringing this up, is I am not sure trying to define
> security
> > above the machine level makes any sense for iSCSI.  Aren't most SCSI
> devices
> > owned by the Operating System not the User and partitioned 
> out by the
> > Operating System to the users ?  If this is the case many of our
> > authentication methods simplify to simple IKE identities.
> >
> > Bill
> 
> Bill-
> 
> As you pointed out, there is a case where just using IKE with
> an iSCSI AuthMethod of "none" is valid.  That case is where:
> 
> - There a one-to-one correspondence between an initiator and an
>   operating system
> - IPsec is being used for all iSCSI traffic
> - The customer is willing to deploy public key certificates on the
>   client side (for each initiator) as well as on the devices
> 
> If all of the above are true, iSCSI can certainly use an AuthMethod
> of none, and be done with it.
> 
> However,
> 
> - There are cases (David Black brought up some tape 
> applications) where
>   more than one initiator might exist on an operating system
> 
> - IPsec is not likely to be used for a large percentage of iSCSI
>   traffic any time soon
> 
> - When IPsec is used, many customers will have an easier time with the
>   familiar model of authenticating the server "machine" but using a
>   dummy certificate for the client.
> 
> If any of the above are true, iSCSI-level of authentication is
> required.
> 
> Hope this helps,
> 
> Mark
> 


From owner-ips@ece.cmu.edu  Wed Aug 29 19:58:30 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13681
	for <ips-archive@odin.ietf.org>; Wed, 29 Aug 2001 19:58:29 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7TN15N25426
	for ips-outgoing; Wed, 29 Aug 2001 19:01:05 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e34.bld.us.ibm.com (e34.co.us.ibm.com [32.97.110.132])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7TN13P25420;
	Wed, 29 Aug 2001 19:01:03 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e34.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA99088;
	Wed, 29 Aug 2001 18:58:42 -0400
Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7TMxb1230848;
	Wed, 29 Aug 2001 16:59:37 -0600
Subject: RE: ISCSI: User authentication vs. Machine Authentication for iSCSI
To: "Jim Hafner" <hafner@almaden.ibm.com>
Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <OFD9DB9F88.FFE2E395-ON88256AB7.007DB466@boulder.ibm.com>
From: "Prasenjit Sarkar" <psarkar@almaden.ibm.com>
Date: Wed, 29 Aug 2001 15:59:33 -0700
X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at
 08/29/2001 03:59:37 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Jim,

I'm not sure the problem you mentioned is specific to iSCSI as I have seen
a user-level Fibre Channel driver in action.

The issue here is that the notion of user is an operating system
abstraction and has no meaning in domains in which the
OS has no administrative control (such as a SAN). Extending
the notion of an user outside the domain of an OS requires
primitives current SAN technology does not support (yet!)


   Prasenjit Sarkar
   Research Staff Member
   IBM Almaden Research
   San Jose



                                                                                                                                              
                    Jim                                                                                                                       
                    Hafner/Almaden       To:     ips@ece.cmu.edu                                                                              
                    /IBM@IBMUS           cc:                                                                                                  
                    Sent by:             Subject:     RE: ISCSI: User authentication vs. Machine Authentication for iSCSI                     
                    owner-ips@ece.                                                                                                            
                    cmu.edu                                                                                                                   
                                                                                                                                              
                                                                                                                                              
                    08/29/2001                                                                                                                
                    03:00 PM                                                                                                                  
                                                                                                                                              
                                                                                                                                              




Bill,
I think I understand your question, so here's a remark.

I think a problem that creeps in to the iSCSI space (that doesn't exist in
essentially every other existing SCSI stack) is that a user can write an
application that acts like an iSCSI initiator and never ever go through the
OS stack.  (I've written an iSCSI initiator in Java that doesn't ever use
the host stack at all, just the standard network interfaces).   So, I could
easily have multiple iSCSI Initiators running (even in user space) on the
same machine.  At that point, I may want user level security.

If I didn't understand your question, I'll shut up (on this topic :-{))

Jim Hafner


"Bill Strahm" <bill@sanera.net>@ece.cmu.edu on 08/29/2001 02:23:20 pm

Sent by:  owner-ips@ece.cmu.edu


To:   <mbakke@cisco.com>
cc:   "Ips@Ece. Cmu. Edu" <ips@ece.cmu.edu>
Subject:  RE: ISCSI: User authentication vs. Machine Authentication for
      iSCSI



I am not sure that helped.  Again, the model of a Tape drive...

The user does not own the tape drive, the operating system owns the tape
drive, when I (as a user) wants to use the tape drive, I ask the operating
system, it grants me access, and I go on.

In fact from a purely SCSI level, I do not believe there is any concept of
a
user at all, the Operating system on the device provides the concept of a
user through the OS abstraction layer.

The problem that I am having is that I do not see how I can make user
security work through the OS abstraction.  And if the OS HAS to know about
the multiple users, I now have to trust the OS as well, which means that
effectively I have one user on the machine anyway...

Bill

-----Original Message-----
From: mbakke@cisco.com [mailto:mbakke@cisco.com]
Sent: Wednesday, August 29, 2001 2:06 PM
To: Bill Strahm
Cc: Ips@Ece. Cmu. Edu
Subject: Re: ISCSI: User authentication vs. Machine Authentication for
iSCSI


Bill Strahm wrote:
>
> I have been fighting with this problem since I left LA.
>
> I am not aware of any usage scenarios today where block devices are owned
by
> the user rather than the machine.  I will conceed that in many instances
the
> first thing the system does is assign the resource to a use (tape,
scanner,
> etc.) but the machine still owns the resource and can in fact remove it
out
> from under the user...
>
> I am not to certain how I could build a trusted iSCSI environment where
one
> user would have no knowledge about what was happening with other users in
a
> malicious environment (especially where a system was participating in the
> exposure of resourses).  Examples of this include things like co-located
Web
> hosting where a single user scans process memory looking for 1Kbit of
random
> data, and when finding it attempts to determine if that is the private
key
> of a user sharing the resource.
>
> The reason I am bringing this up, is I am not sure trying to define
security
> above the machine level makes any sense for iSCSI.  Aren't most SCSI
devices
> owned by the Operating System not the User and partitioned out by the
> Operating System to the users ?  If this is the case many of our
> authentication methods simplify to simple IKE identities.
>
> Bill

Bill-

As you pointed out, there is a case where just using IKE with
an iSCSI AuthMethod of "none" is valid.  That case is where:

- There a one-to-one correspondence between an initiator and an
  operating system
- IPsec is being used for all iSCSI traffic
- The customer is willing to deploy public key certificates on the
  client side (for each initiator) as well as on the devices

If all of the above are true, iSCSI can certainly use an AuthMethod
of none, and be done with it.

However,

- There are cases (David Black brought up some tape applications) where
  more than one initiator might exist on an operating system

- IPsec is not likely to be used for a large percentage of iSCSI
  traffic any time soon

- When IPsec is used, many customers will have an easier time with the
  familiar model of authenticating the server "machine" but using a
  dummy certificate for the client.

If any of the above are true, iSCSI-level of authentication is
required.

Hope this helps,

Mark










From owner-ips@ece.cmu.edu  Wed Aug 29 21:39:23 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15458
	for <ips-archive@odin.ietf.org>; Wed, 29 Aug 2001 21:39:23 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7TNmsX27481
	for ips-outgoing; Wed, 29 Aug 2001 19:48:54 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7TNmqP27476
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 19:48:52 -0400 (EDT)
Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203])
	by palrel1.hp.com (Postfix) with ESMTP id C9EBF2779
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 16:48:51 -0700 (PDT)
Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197])
	by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id QAA09239
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 16:48:46 -0700 (PDT)
Message-ID: <3B8D80A0.194F25CE@cup.hp.com>
Date: Wed, 29 Aug 2001 16:54:09 -0700
From: Santosh Rao <santoshr@cup.hp.com>
Organization: Hewlett Packard, Cupertino.
X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778)
X-Accept-Language: en
MIME-Version: 1.0
To: ips@ece.cmu.edu
Subject: Re: iSCSI: reusing ISID for recovery
References: <OF9CA38A65.D53E4AD4-ONC2256AB7.006C410B@telaviv.ibm.com>
Content-Type: multipart/mixed;
 boundary="------------DB972D7F233A74946014068F"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

This is a multi-part message in MIME format.
--------------DB972D7F233A74946014068F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Julian Satran wrote:

> Doing an automatic logout when a new session is seen can be performed by
> mistake by an OS in a multi OS machine. It is just to easy to let it
> through.

A multi-OS system would use a different iSCSI initiator name for each O.S.


> After a reboot the right procedure would be to login cleanly (no
> previous knowledge needed). The target will ascertain that the old session
> is dead and let you in.

Are you suggesting a combination of the existing login target behaviour
wherein the target checks the olde session if it exists when the X bit is not
set, coupled with an unconditional cleanup when the X bit is set ?

Having the target test the old session, prior to responding to a login can
bloat login time to unacceptable levels and increase system bootup time as
well as I/O scan time.


>
> You will need the X only when the old session is alive (answering to NOP)
> but you don't know how to clean it.

The initiator may not know if an old session had been established by it
previously. Hence, it will either always need to set the X bit, or risk the
chance of a login reject.

What are we trying to achieve by having the target validate the initiator's
attempt to clean up an old session ? The target must trust the initiator's
decision to clean up [after first completing login authentication to avoid
malicious logout type attacks], rather than have to validate it first. Targets
should not be expected to do all this extra work of validation to protect
against initiator coding bugs.

The draft should not be trying to optimize for a coding bug scenario, wherein
the initiator accidentally re-logs in with the same (iscsi initiator name,
ISID, NULL TSID).

FC exhibits the same semantics that are being asked for here. Implicit logout
+ re-login behaviour is oft used by FC initiators. Similar login semantics
will make the life of iscsi-fc convertor products easier as well.


>
> Reboot behavior is close to what you have in the current draft ( a single
> login needed - no X).

On a reboot, the initiator does not know if it has previously logged out of
the session prior to the reboot. Thus, it would need to clean up any stale
sessions, if they exist. Rather than attempt 2 logins [one with an X and then,
one without], the login should be allowed to imply a logout of any stale
session, if one such exists.

This issue is applicable to the reboot of initiators.

- Santosh

>
> "KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>@ece.cmu.edu
> on 29-08-2001 22:27:35
>
> Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"
>       <marjorie_krueger@hp.com>
>
> Sent by:  owner-ips@ece.cmu.edu
>
> To:   ips@ece.cmu.edu
> cc:
> Subject:  RE: iSCSI: reusing ISID for recovery
>
> It would help to get your message thru if you could answer our requests for
> an explanation of your thinking.  We have tried several times to explain
> our
> logic (w/examples) but I haven't seen an example from you supporting a
> scenario in which you see a problem.
>
> If an initiator reboots, and has no context information, how can it know
> whether or not a target has a pre-existing session?  Since there is no nice
> way to know that, I would probably code my initiator to request a login
> with
> the X bit set (but as Mallikarjun said, I don't like this overloading of
> the
> X bit, it's a special case and makes the coding extra convoluted).  In your
> preferred scenario, this would cause the target to reject the login "cause
> there is no pre-existing session", and the initiator would re-issues the
> login without the X bit set.  What have you saved anyone from here?  You've
> just added latency to the login process.  And either way the initiator
> codes
> it's login after reboot, there's a presumably equal probability of
> encountering this extra exchange.
>
> I still haven't seen a plausable example where it does harm to have a login
> w/ ISID=n, TSID=0 close an existing session with this initiator.  I can see
> no case where this would be the wrong decision.  If "this isn't what the
> initiator intended", this is a defective initiator implementation and
> closing the other session at least does no harm.
>

--------------DB972D7F233A74946014068F
Content-Type: text/x-vcard; charset=us-ascii;
 name="santoshr.vcf"
Content-Description: Card for Santosh Rao
Content-Disposition: attachment;
 filename="santoshr.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Rao;Santosh 
tel;work:408-447-3751
x-mozilla-html:FALSE
org:Hewlett Packard, Cupertino.;SISL
adr:;;19420, Homestead Road, M\S 43LN,	;Cupertino.;CA.;95014.;USA.
version:2.1
email;internet:santoshr@cup.hp.com
title:Software Design Engineer
x-mozilla-cpt:;21088
fn:Santosh Rao
end:vcard

--------------DB972D7F233A74946014068F--



From owner-ips@ece.cmu.edu  Wed Aug 29 22:14:04 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15876
	for <ips-archive@odin.ietf.org>; Wed, 29 Aug 2001 22:14:04 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7U0cgJ29773
	for ips-outgoing; Wed, 29 Aug 2001 20:38:42 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from calliope1.fm.intel.com (fmfdns01.fm.intel.com [132.233.247.10])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7U0cfP29769
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 20:38:41 -0400 (EDT)
Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110])
	by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id AAA01454
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 00:38:40 GMT
Received: from fmsmsx19.fm.intel.com ([132.233.48.19])
 by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001082917373925213
 ; Wed, 29 Aug 2001 17:37:39 -0700
Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id <R579D05N>; Wed, 29 Aug 2001 17:38:39 -0700
Message-ID: <3677E033A5F3D211AC4000A0C96B53EB05C2EB53@FMSMSX94>
From: "Herbert, Howard C" <howard.c.herbert@intel.com>
To: "'Bill Strahm'" <bill@sanera.net>, "Ips@Ece. Cmu. Edu" <ips@ece.cmu.edu>
Subject: RE: ISCSI: Required Crytographic transforms for iSCSI
Date: Wed, 29 Aug 2001 17:38:38 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Would the following wording capture the results of yesterday's meeting?

IPsec ESP Authentication-Only:

SHA-1 HMAC and NULL confidentiality - Must implement
AES in CBC MAC mode with XCBC extensions** and NULL confidentiality - Should
implement

IPsec ESP Authentication and Confidentiality:
   
SHA-1 HMAC and Triple DES in CBC mode - Must implement
AES in CBC MAC mode with XCBC extensions** and AES in CTR mode - Should
implement

**Pending closure with NIST and IPsec working group chairs (AR Howard
Herbert)

-----Original Message-----
From: Bill Strahm [mailto:bill@sanera.net]
Sent: Wednesday, August 29, 2001 8:34 AM
To: Ips@Ece. Cmu. Edu
Subject: ISCSI: Required Crytographic transforms for iSCSI


When we were talking about required transforms yesterday in Los Angeles, I
believe that we forgot a VERY important transform that need to be a MUST
implement for ESP.  That is the NULL Encryption Algorithm (RFC2410).

I propose that this algorithm is a MUST implement for all iSCSI
implementations

Bill
Sanera Systems Inc.


From owner-ips@ece.cmu.edu  Wed Aug 29 23:03:20 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17309
	for <ips-archive@odin.ietf.org>; Wed, 29 Aug 2001 23:03:20 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7U1TuM01935
	for ips-outgoing; Wed, 29 Aug 2001 21:29:56 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7U1TtP01930
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 21:29:55 -0400 (EDT)
Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77])
	by msgbas1.cos.agilent.com (Postfix) with ESMTP id 7D8FA1268
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 19:29:50 -0600 (MDT)
Received: from acropora.rose.agilent.com (acropora.rose.agilent.com [130.30.179.5])
	by msgrel1.cos.agilent.com (Postfix) with ESMTP id 072092F1
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 19:29:50 -0600 (MDT)
Received: (from dbs@localhost)
	by acropora.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) id SAA20372
	for ips@ece.cmu.edu; Wed, 29 Aug 2001 18:28:56 -0700 (PDT)
From: Dave Sheehy <dbs@acropora.rose.agilent.com>
Message-Id: <200108300128.SAA20372@acropora.rose.agilent.com>
Subject: Re: iSCSI: draft 7: remove S bit and Status field from the Data-i (fwd)
To: ips@ece.cmu.edu (IETF IP SAN Reflector)
Date: Wed, 29 Aug 2001 18:28:55 PDT
X-Mailer: Elm [revision: 212.4]
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


> I am sure we don't want to enter this. The sequencing rules are there to
> asure:
> 
>    that there is no deadlock (order of data must follow the order of
>    commands)
>    that the target command buffer does not overflow (MaxCmdSN) - this will
>    eliminate an "unlimited number of immediate"

So, if my target concurrently supports 1000 solicited data commands and has 
buffering for 8 unsolicited data commands I must set my CmdSN window to 8 
(instead of 1008) to avoid overflowing my buffering. That does not sound to 
me like a good thing.

Dave Sheehy



From owner-ips@ece.cmu.edu  Wed Aug 29 23:07:43 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17328
	for <ips-archive@odin.ietf.org>; Wed, 29 Aug 2001 23:07:41 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7U240R03354
	for ips-outgoing; Wed, 29 Aug 2001 22:04:00 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e33.bld.us.ibm.com (e33.co.us.ibm.com [32.97.110.131])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7U23jP03340
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 22:03:45 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e33.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id VAA78700;
	Wed, 29 Aug 2001 21:01:32 -0500
Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7U22R1193580;
	Wed, 29 Aug 2001 20:02:27 -0600
X-Priority: 1 (High)
Importance: Normal
Subject: Re: ISCSI: User authentication vs. Machine Authentication for iSCSI
To: "Bill Strahm" <bill@sanera.net>
Cc: "Ips@Ece. Cmu. Edu" <ips@ece.cmu.edu>
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OF7F53A14D.D8E9C3B4-ON88256AB7.0061F075@boulder.ibm.com>
From: "John Hufferd" <hufferd@us.ibm.com>
Date: Wed, 29 Aug 2001 19:02:02 -0700
X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at
 08/29/2001 08:02:27 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Bill,
You are correct, in my opinion, on the problem statement, but not  on the
solution.

The IKE stuff will Get a system identified, and perhaps ensure that a
encrypted connection is put in place.  This then give the Source and Target
the Freedom to exchange stuff that would otherwise be in the clear, such as
iSCSI Node Names etc.  But after the iSCSI session is established, it is
between an OS and a target.  The OS, is the thing that actually owns the
resource, it only loans the resources, in some manor, to applications.

I was having a similar problem to what you stated, at the Irvine meeting,
and kept digging and objecting (off-stage) until I got the following more
acceptable response.

Environment 1: (Use of IKE with complete Certificates processing ( or
pre-Shared password), with ESP equal to something other then Null)
1. We use IKE to get a mutually authenticated and Encrypted communication
link.  This means that the Target knows that (at the IKE/TCP Layer) there
is, at the other end, an authorized thing.  (What or who that thing is,
relative to iSCSI is not really known).  This secure link can be
established either via Certificates or via a pre-Shared password.
2. An iSCSI Login can now be done, over a secure link, so the iSCSI
Initiator Name, and iSCSI Target Name etc can be exchanged securely.
Please note, just because you passed the IKE certificate gate does not mean
you are the iSCSI Initiator that you claim to be.  Therefore, a password,
for example, that is associated with the iSCSI Initiator Name can now be
used to perform an iSCSI validation of the Initiator.  (Please note, this
could, instead of a password,  be a Kerberos type Validation etc.)
3. David, and perhaps other used the words "User" or "Application" name to
address what was being addressed in 2 above.  But there was more to this
then just assuming that the iSCSI Initiator Name was the User name.  Since
folks may actually want to use existing infrastructure, to handle the
password management and authentication process, they will need to assign
what I might call an "Alias for the iSCSI Initiator" which can actually be
saved in the existing infrastructure user authentication repository.  The
point that was made to me, is that iSCSI Initiator Name (iqn, or eui) will
not "fit" into things that contain "User Names" so we need to have a
corresponding "User Name" that we can actually authenticate using, for
example Microsoft Active Directory etc. Hence the need for a "Alias for the
iSCSI initiator.  (I really hate this, and wish there was something else we
could do.)

Environment 2: (Use of IKE with Asymmetrical authentication,  and ESP equal
to something other then Null.  This example was pushed by Mark Bakke.)
1. We use IKE to get a mutually authenticated Encrypted communication link,
but this is done by giving the Initiators a "Dummy" (self signed?)
Certificate and that this is used to permit the Initiator side to assure
that it is talking to the correct target but gives no such assurance to the
Target that it is talking to an approprate Initiator.  However, it does
setup a secure (encrypted) connection.  (Note: a similar thing can be done
with pre-shared Keys, where the Initiator systems are all given the same
pre-shared password.)
2. The iSCSI Login can now occur, as in Environment-1 above.  In this mode
the only time the Initiator has any real authentication, by the target is
in this iSCSI stage.
Note: Mark pointed out that this was the way Web servers worked.
3. Chap can  be used in this environment since the Link is already secure
and encrypted, and sending the password in what otherwise would have been
in the clear, is protected by the link encryption.

Environment 3: (no use of IKE)
1. No authenticated private Link is established via IKE, so -- in many
environments, a Chap type solution is just not secure enough, therefore the
recommendation will be to use SRP, since that will add some hashing etc. to
protect the password.

The problem I have with all the above, is that their needs to  be some
method that the target can use ensure that the "USERNAME" that has the
password associated with it, is actually the approprate iSCSI Initiator
NAME.

If we do not ensure, at the target, that the "USERNAME" is THE username to
be associated with the iSCSI Target Name, then all the IKE and CHAP or SRP
stuff does is permits us to know that the initiator side is one of some set
of systems that are authorized to contact the physical Device know as the
iSCSI Target Node.  Now remember there could be more then one iSCSI Target
Names (SCSI Target) within the same iSCSI Target Node.  It is even possible
that the different SCSI Targets may want to have different LUNs attached to
each of them.  Further, I expect that many of us wanted to associate
certain LUNs with certain iSCSI Initiators, as we do today with Fibre
Channel.  However, if we do that, then we must have a hard lock between
"username" (aka "Alias for the iSCSI initiator") and iSCSI Initiator Name.

It is not clear that we have thought through all the ramifications of this
dependance on "USERIDs/USERNAMEs" (aka "Alias for the iSCSI initiator").
Did any of us understand that we needed a binding association database, on
the targets, to keep associations between iSCSI Initiator Names and
"USERIDs/USERNAMEs"?  If so, I bet there were not many.

I would like to know if their is a better approach to what I call the
second stage authentication, without requiring yet another name for the
iSCSI Initiator Node.



.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com


"Bill Strahm" <bill@sanera.net>@ece.cmu.edu on 08/29/2001 08:40:54 AM

Sent by:  owner-ips@ece.cmu.edu


To:   "Ips@Ece. Cmu. Edu" <ips@ece.cmu.edu>
cc:
Subject:  ISCSI: User authentication vs. Machine Authentication for iSCSI



I have been fighting with this problem since I left LA.

I am not aware of any usage scenarios today where block devices are owned
by
the user rather than the machine.  I will conceed that in many instances
the
first thing the system does is assign the resource to a use (tape, scanner,
etc.) but the machine still owns the resource and can in fact remove it out
from under the user...

I am not to certain how I could build a trusted iSCSI environment where one
user would have no knowledge about what was happening with other users in a
malicious environment (especially where a system was participating in the
exposure of resourses).  Examples of this include things like co-located
Web
hosting where a single user scans process memory looking for 1Kbit of
random
data, and when finding it attempts to determine if that is the private key
of a user sharing the resource.

The reason I am bringing this up, is I am not sure trying to define
security
above the machine level makes any sense for iSCSI.  Aren't most SCSI
devices
owned by the Operating System not the User and partitioned out by the
Operating System to the users ?  If this is the case many of our
authentication methods simplify to simple IKE identities.

Bill






From owner-ips@ece.cmu.edu  Wed Aug 29 23:42:21 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17976
	for <ips-archive@odin.ietf.org>; Wed, 29 Aug 2001 23:42:20 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7U2aBQ04674
	for ips-outgoing; Wed, 29 Aug 2001 22:36:11 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from chmls05.mediaone.net (chmls05.mediaone.net [24.147.1.143])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7U2ZtP04662
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 22:35:55 -0400 (EDT)
Received: from cs.uchicago.edu (h005018030f43.ne.mediaone.net [24.91.87.144])
	by chmls05.mediaone.net (8.11.1/8.11.1) with ESMTP id f7U2ZiZ16514
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 22:35:45 -0400 (EDT)
Message-Id: <200108300235.f7U2ZiZ16514@chmls05.mediaone.net>
To: ips@ece.cmu.edu
Subject: Re: ISCSI: User authentication vs. Machine Authentication for iSCSI 
In-Reply-To: Message from "Prasenjit Sarkar" <psarkar@almaden.ibm.com> 
   of "Wed, 29 Aug 2001 15:59:33 PDT." <OFD9DB9F88.FFE2E395-ON88256AB7.007DB466@boulder.ibm.com> 
References: <OFD9DB9F88.FFE2E395-ON88256AB7.007DB466@boulder.ibm.com> 
Date: Wed, 29 Aug 2001 22:35:15 -0400
From: Stephen Bailey <steph@cs.uchicago.edu>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Prasenjit,

I agree with Jim Hafner.  The notion of `user level security' is
exactly what iSCSI needs, due to the unique combination of factors
that compose an iSCSI system.  In the initial case, where the iSCSI
client is the host OS, the OS is fully capable of representing an
identity (being a user) and hiding that identity from unprivileged
users of that system.

> I'm not sure the problem you mentioned is specific to iSCSI as I have seen
> a user-level Fibre Channel driver in action.

True.  However, the user-mode driver is granted full `control'
(i.e. root) privs if it is allowed to execute arbitrary SCSI commands.

Access to raw storage has traditionally been a rigidly protected
resource, which when granted, gives complete control of the associated
domain (which might be more than one system in a SAN or cluster).
This is a well-understood characteristic of the raw storage trust
model.

In the Berkeley networking model (praise the mighty), access to
network communication (other than evesdropping) is not a rigidly
protected resource.  The assumption is that the local endpoint is not
granted any additional power by being able to communicate arbitrarily,
and the remote endpoint must protect itself as appropriate to the
service it offers.

> The issue here is that the notion of user is an operating system
> abstraction and has no meaning in domains in which the
> OS has no administrative control (such as a SAN).

Not really.  A user is an authenticable identity in any form.  The
control is the access provided.

> Extending the notion of an user outside the domain of an OS requires
> primitives current SAN technology does not support (yet!)

I agree that the present infrastructure doesn't support this idea
well.  However, what we should do is define our security in such a way
that the SAN infrastructure can evolve towards the same type of
identity mechanisms that other networking services (try to) support.

If we do this right (and I think Jim's got the idea) it can support
both `the OS is completely trusted' (for now) and `each user has their
own credentials' (later) models.  We just need to make sure we don't
do anything stupid like claim that authenticable entity == IP address
in the protocol itself.  At present we're not in risk of doing that,
but maybe I should come out in support of it just in case :^)

I don't think there's any concrete change to what's already specified
to support this.  We certainly don't have to dot every I and cross
every T on the multiple identities per system model
(i.e. authentication and authorization infrastructure needn't
instantly be created to solve the full problem), but I guess we should
be aware of what we're shooting for as we specify additional security
behavior.

Steph


From owner-ips@ece.cmu.edu  Wed Aug 29 23:44:47 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18004
	for <ips-archive@odin.ietf.org>; Wed, 29 Aug 2001 23:44:47 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7U2RUR04313
	for ips-outgoing; Wed, 29 Aug 2001 22:27:30 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7U2RRP04308
	for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 22:27:27 -0400 (EDT)
Received: from ahganemw2k (sjc-vpn-435.cisco.com [10.21.65.179]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id WAA16435 for <ips@ece.cmu.edu>; Wed, 29 Aug 2001 22:27:19 -0400 (EDT)
From: "Ayman Ghanem" <aghanem@cisco.com>
To: <ips@ece.cmu.edu>
Subject: RE: iSCSI - Change - Login/Text commands with the binary stage code
Date: Wed, 29 Aug 2001 21:26:27 -0500
Message-ID: <LOEPJENHBHAHEABBNDAJCEDHCDAA.aghanem@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <OF2313AAC4.E7FE1FCD-ONC2256AB7.0073B96F@telaviv.ibm.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Julian,

One could also argue for symmetry; only one login response per login cmd. On
the other hand, the only time a partial login is returned at the moment is
when status class is 0 and F=0. Any other status class results in a final
login response. For status class 0, there exists 3 status detail codes: 0,
1, and 2. The first two are implied from the negotiation phase, and the
third case will no longer exist if we enforce the ITN to be sent in the
login cmd. The session parameters returned in a partial login response are
not needed because the connection has not joined the session yet during
login.

-Ayman


> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Julian Satran
> Sent: Wednesday, August 29, 2001 4:18 PM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI - Change - Login/Text commands with the binary stage
> code
>
>
> Steve,
>
> The partial response is not strictly needed it is just handy to have the
> login request answered
> with a login response. On this we can put the partial/final answer. For a
> text it would have been arbitrary (text outside login does not need it).
>
> As for the names - I though that security people might object having the
> name in clear if the security phase does not make use of the name.
> Otherwise we can mandate them on the login but I wonder if that is a real
> improvement or we are getting carelles.
>
> Julo
>
>
> Steve Senum <ssenum@cisco.com>@ece.cmu.edu on 29-08-2001 23:59:36
>
> Please respond to Steve Senum <ssenum@cisco.com>
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   ietf-ips <ips@ece.cmu.edu>
> cc:
> Subject:  Re: iSCSI - Change - Login/Text commands with the binary stage
>       code
>
>
>
> Julian,
>
> A couple of ideas from Matthew Burbridge & Co.'s
> login proposal that has generated some interest here:
>
> 1. Removal of partial login response.  Is it still needed?
>
> 2. Requiring Initiator and (if not a discovery session)
>    Target names on login command, so they are always
>    available if needed by the initial phase.
>
> Comments?
>
> Regards,
> Steve Senum
>
>
>
>



From owner-ips@ece.cmu.edu  Thu Aug 30 01:43:36 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24553
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 01:43:36 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7U4Ilm08916
	for ips-outgoing; Thu, 30 Aug 2001 00:18:47 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from smtp018.mail.yahoo.com (smtp018.mail.yahoo.com [216.136.174.115])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f7U4IfP08909
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 00:18:46 -0400 (EDT)
Received: from sdsl-216-36-75-164.dsl.sjc.megapath.net (HELO somesh) (216.36.75.164)
  by smtp.mail.vip.sc5.yahoo.com with SMTP; 30 Aug 2001 04:18:32 -0000
X-Apparently-From: <someshg@yahoo.com>
Reply-To: <someshg@yahoo.com>
From: "Somesh Gupta" <someshg@yahoo.com>
To: "Stephen Bailey" <steph@cs.uchicago.edu>,
        "Santosh Rao" <santoshr@cup.hp.com>
Cc: <ips@ece.cmu.edu>
Subject: RE: iSCSI: reusing ISID for recovery 
Date: Wed, 29 Aug 2001 21:06:57 -0700
Message-ID: <NMEALCLOIBCHBDHLCMIJGEOKCGAA.someshg@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <20010829205343.C0B654E8F@sandmail.sandburst.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

In case we start counting votes, A is my answer.
If someone is lost, they are lost. Machines don't
have anywhere near Julian's IQ and my programs
are even worse.

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Stephen Bailey
> Sent: Wednesday, August 29, 2001 1:53 PM
> To: Santosh Rao
> Cc: ips@ece.cmu.edu
> Subject: Re: iSCSI: reusing ISID for recovery 
> 
> 
> > The same was earlier proposed by myself in a previous thread on this
> > issue a few months ago.
> 
> You're not the only one.  I'm also in favor of (A).  I have also
> carefully laid out the chain that Marjorie's following on at least one
> (and probably several) past occasions.  It seems sound to me.  An
> initiator that has lost its mind (this might be an OS reboot, or
> `simply' a fat adapter crash & restart) is going to want to stomp out
> any existing sessions in its name.  It's not going to want to pick up
> old context unless it's aware that there IS old context, in which case
> it hasn't completely lost its mind.
> 
> I've been keeping my mouth shut in hopes that it would actually pass,
> but I guess I don't have to articulate a position so much as just hold
> it to ensure it gets killed.  Given my track record, I'm now for sale
> to the highest bidder.
> 
> Steph

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com



From owner-ips@ece.cmu.edu  Thu Aug 30 03:03:58 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07111
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 03:03:58 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7U68ML13246
	for ips-outgoing; Thu, 30 Aug 2001 02:08:22 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from ariel.nishansystems.com (smtp.nishansystems.com [216.217.36.162])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7U68KP13241
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 02:08:20 -0400 (EDT)
Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19)
	id <RDTY6TQJ>; Wed, 29 Aug 2001 23:08:10 -0700
Message-ID: <B300BD9620BCD411A366009027C21D9B5BAE36@ariel.nishansystems.com>
From: Joshua Tseng <jtseng@NishanSystems.com>
To: "'Stephen Bailey'" <steph@cs.uchicago.edu>, ips@ece.cmu.edu
Subject: RE: ISCSI: User authentication vs. Machine Authentication for iSC
	SI 
Date: Wed, 29 Aug 2001 23:08:09 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Stephen,
> 
> I agree with Jim Hafner.  The notion of `user level security' is
> exactly what iSCSI needs, due to the unique combination of factors
> that compose an iSCSI system.  In the initial case, where the iSCSI
> client is the host OS, the OS is fully capable of representing an
> identity (being a user) and hiding that identity from unprivileged
> users of that system.

iSCSI is a transport protocol.  Its role is to transport SCSI commands
and data.  Therefore, the security associations negotiated during the
inband iSCSI security login phase should be bound to the principals
that define the iSCSI endpoints.  I believe this is the "iSCSI Name"
(formerly WWUI).  Attempting to bind iSCSI security to something that
sits above iSCSI is a layering violation.  This includes SCSI, OS, or
user identities, which all should be transparent to iSCSI.

> 
> > I'm not sure the problem you mentioned is specific to iSCSI 
> as I have seen
> > a user-level Fibre Channel driver in action.
> 
> True.  However, the user-mode driver is granted full `control'
> (i.e. root) privs if it is allowed to execute arbitrary SCSI commands.
> 
> Access to raw storage has traditionally been a rigidly protected
> resource, which when granted, gives complete control of the associated
> domain (which might be more than one system in a SAN or cluster).
> This is a well-understood characteristic of the raw storage trust
> model.

This is SCSI's problem.  You should bring this up with T10.

Josh

> 
> In the Berkeley networking model (praise the mighty), access to
> network communication (other than evesdropping) is not a rigidly
> protected resource.  The assumption is that the local endpoint is not
> granted any additional power by being able to communicate arbitrarily,
> and the remote endpoint must protect itself as appropriate to the
> service it offers.
> 
> > The issue here is that the notion of user is an operating system
> > abstraction and has no meaning in domains in which the
> > OS has no administrative control (such as a SAN).
> 
> Not really.  A user is an authenticable identity in any form.  The
> control is the access provided.
> 
> > Extending the notion of an user outside the domain of an OS requires
> > primitives current SAN technology does not support (yet!)
> 
> I agree that the present infrastructure doesn't support this idea
> well.  However, what we should do is define our security in such a way
> that the SAN infrastructure can evolve towards the same type of
> identity mechanisms that other networking services (try to) support.
> 
> If we do this right (and I think Jim's got the idea) it can support
> both `the OS is completely trusted' (for now) and `each user has their
> own credentials' (later) models.  We just need to make sure we don't
> do anything stupid like claim that authenticable entity == IP address
> in the protocol itself.  At present we're not in risk of doing that,
> but maybe I should come out in support of it just in case :^)
> 
> I don't think there's any concrete change to what's already specified
> to support this.  We certainly don't have to dot every I and cross
> every T on the multiple identities per system model
> (i.e. authentication and authorization infrastructure needn't
> instantly be created to solve the full problem), but I guess we should
> be aware of what we're shooting for as we specify additional security
> behavior.
> 
> Steph
> 


From owner-ips@ece.cmu.edu  Thu Aug 30 03:04:43 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07123
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 03:04:43 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7U5db912167
	for ips-outgoing; Thu, 30 Aug 2001 01:39:37 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7U5dZP12162
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 01:39:36 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id HAA89484
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 07:39:27 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7U5dFF111092
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 07:39:17 +0200
Importance: Normal
Subject: Re: iSCSI: draft 7: remove S bit and Status field from the Data-i (fwd)
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFE347345D.1CA855F3-ONC2256AB8.001ED0AE@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Thu, 30 Aug 2001 08:38:39 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 30/08/2001 08:39:17
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


How exactly would ordering help you ease this.  Julo

Dave Sheehy <dbs@acropora.rose.agilent.com>@ece.cmu.edu on 30-08-2001
04:28:55

Please respond to Dave Sheehy <dbs@acropora.rose.agilent.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu (IETF IP SAN Reflector)
cc:
Subject:  Re: iSCSI: draft 7: remove S bit and Status field from the Data-i
      (fwd)




> I am sure we don't want to enter this. The sequencing rules are there to
> asure:
>
>    that there is no deadlock (order of data must follow the order of
>    commands)
>    that the target command buffer does not overflow (MaxCmdSN) - this
will
>    eliminate an "unlimited number of immediate"

So, if my target concurrently supports 1000 solicited data commands and has
buffering for 8 unsolicited data commands I must set my CmdSN window to 8
(instead of 1008) to avoid overflowing my buffering. That does not sound to
me like a good thing.

Dave Sheehy






From owner-ips@ece.cmu.edu  Thu Aug 30 03:07:56 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07154
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 03:07:56 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7U5YWh11963
	for ips-outgoing; Thu, 30 Aug 2001 01:34:32 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7U5YTP11959
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 01:34:29 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id HAA99242
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 07:34:12 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7U5YBL52276
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 07:34:12 +0200
Importance: Normal
Subject: Re: iSCSI: reusing ISID for recovery
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF6A859BF0.D9283101-ONC2256AB8.001D88E1@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Thu, 30 Aug 2001 08:33:35 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 30/08/2001 08:34:11
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


With  regard to time bloat I have two things to say:

1- It is a rare event (connection don't stay alive long if a machine goes
down)
2 - we could remove the checking - going only on reporting and have in
those cases the command reissued with X

As for the mistake I am afraid that anything that is so easy to do badly
will be done badly and causes can range from simple bugs, to management
servers that direct you to same target under two different names and the
target does not care to two user programs doing uncoordinated login (but
only one is bad).

I assume that are many scenarios that we don't even think about.

My long experience tells me not make it easy for a mistake to ruin good
work.

And I think that the proposal that is out (removing the checking and having
Marjory irritated) is a good compromise between simplicity a sound
engineering.

Julo


Santosh Rao <santoshr@cup.hp.com>@ece.cmu.edu on 30-08-2001 02:54:09

Please respond to Santosh Rao <santoshr@cup.hp.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  Re: iSCSI: reusing ISID for recovery



Julian Satran wrote:

> Doing an automatic logout when a new session is seen can be performed by
> mistake by an OS in a multi OS machine. It is just to easy to let it
> through.

A multi-OS system would use a different iSCSI initiator name for each O.S.


> After a reboot the right procedure would be to login cleanly (no
> previous knowledge needed). The target will ascertain that the old
session
> is dead and let you in.

Are you suggesting a combination of the existing login target behaviour
wherein the target checks the olde session if it exists when the X bit is
not
set, coupled with an unconditional cleanup when the X bit is set ?

Having the target test the old session, prior to responding to a login can
bloat login time to unacceptable levels and increase system bootup time as
well as I/O scan time.


>
> You will need the X only when the old session is alive (answering to NOP)
> but you don't know how to clean it.

The initiator may not know if an old session had been established by it
previously. Hence, it will either always need to set the X bit, or risk the
chance of a login reject.

What are we trying to achieve by having the target validate the initiator's
attempt to clean up an old session ? The target must trust the initiator's
decision to clean up [after first completing login authentication to avoid
malicious logout type attacks], rather than have to validate it first.
Targets
should not be expected to do all this extra work of validation to protect
against initiator coding bugs.

The draft should not be trying to optimize for a coding bug scenario,
wherein
the initiator accidentally re-logs in with the same (iscsi initiator name,
ISID, NULL TSID).

FC exhibits the same semantics that are being asked for here. Implicit
logout
+ re-login behaviour is oft used by FC initiators. Similar login semantics
will make the life of iscsi-fc convertor products easier as well.


>
> Reboot behavior is close to what you have in the current draft ( a single
> login needed - no X).

On a reboot, the initiator does not know if it has previously logged out of
the session prior to the reboot. Thus, it would need to clean up any stale
sessions, if they exist. Rather than attempt 2 logins [one with an X and
then,
one without], the login should be allowed to imply a logout of any stale
session, if one such exists.

This issue is applicable to the reboot of initiators.

- Santosh

>
> "KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
@ece.cmu.edu
> on 29-08-2001 22:27:35
>
> Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"
>       <marjorie_krueger@hp.com>
>
> Sent by:  owner-ips@ece.cmu.edu
>
> To:   ips@ece.cmu.edu
> cc:
> Subject:  RE: iSCSI: reusing ISID for recovery
>
> It would help to get your message thru if you could answer our requests
for
> an explanation of your thinking.  We have tried several times to explain
> our
> logic (w/examples) but I haven't seen an example from you supporting a
> scenario in which you see a problem.
>
> If an initiator reboots, and has no context information, how can it know
> whether or not a target has a pre-existing session?  Since there is no
nice
> way to know that, I would probably code my initiator to request a login
> with
> the X bit set (but as Mallikarjun said, I don't like this overloading of
> the
> X bit, it's a special case and makes the coding extra convoluted).  In
your
> preferred scenario, this would cause the target to reject the login
"cause
> there is no pre-existing session", and the initiator would re-issues the
> login without the X bit set.  What have you saved anyone from here?
You've
> just added latency to the login process.  And either way the initiator
> codes
> it's login after reboot, there's a presumably equal probability of
> encountering this extra exchange.
>
> I still haven't seen a plausable example where it does harm to have a
login
> w/ ISID=n, TSID=0 close an existing session with this initiator.  I can
see
> no case where this would be the wrong decision.  If "this isn't what the
> initiator intended", this is a defective initiator implementation and
> closing the other session at least does no harm.
>

 - santoshr.vcf





From owner-ips@ece.cmu.edu  Thu Aug 30 03:10:18 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07215
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 03:10:18 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7U6JjA13681
	for ips-outgoing; Thu, 30 Aug 2001 02:19:45 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e34.bld.us.ibm.com (e34.co.us.ibm.com [32.97.110.132])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7U6JhP13676;
	Thu, 30 Aug 2001 02:19:43 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e34.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id CAA28580;
	Thu, 30 Aug 2001 02:17:30 -0400
Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7U6IQ160964;
	Thu, 30 Aug 2001 00:18:26 -0600
Subject: Re: ISCSI: User authentication vs. Machine Authentication for iSCSI
To: Stephen Bailey <steph@cs.uchicago.edu>
Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OF7DA49F25.4D7AF87C-ON88256AB8.001D2C32@boulder.ibm.com>
From: "Prasenjit Sarkar" <psarkar@almaden.ibm.com>
Date: Wed, 29 Aug 2001 23:22:44 -0700
X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at
 08/29/2001 11:18:25 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Stephen,

You missed my point. The example of an user-mode FC driver was to
illustrate the creation of an networking API (like sockets) that (i) gives
access to the fibre channel
*network* and (ii) does not interpret the communication between the end
points. Such
an FC API (since it already exists) has as much of a user-level security
implication
as was pointed out in the case of iSCSI.

I agree mostly with the rest of what you said.

I hate to get embroiled in long-winded counter-productive mailing list
arguments,
so I shall not be responding any more.

Regards,
Prasenjit




   Prasenjit Sarkar
   Research Staff Member
   IBM Almaden Research
   San Jose



                                                                                           
                    Stephen Bailey                                                         
                    <steph@cs.uchi       To:     ips@ece.cmu.edu                           
                    cago.edu>            cc:                                               
                    Sent by:             Subject:     Re: ISCSI: User authentication vs.   
                    owner-ips@ece.        Machine Authentication for iSCSI                 
                    cmu.edu                                                                
                                                                                           
                                                                                           
                    08/29/2001                                                             
                    07:35 PM                                                               
                                                                                           
                                                                                           



Prasenjit,

I agree with Jim Hafner.  The notion of `user level security' is
exactly what iSCSI needs, due to the unique combination of factors
that compose an iSCSI system.  In the initial case, where the iSCSI
client is the host OS, the OS is fully capable of representing an
identity (being a user) and hiding that identity from unprivileged
users of that system.

> I'm not sure the problem you mentioned is specific to iSCSI as I have
seen
> a user-level Fibre Channel driver in action.

True.  However, the user-mode driver is granted full `control'
(i.e. root) privs if it is allowed to execute arbitrary SCSI commands.

Access to raw storage has traditionally been a rigidly protected
resource, which when granted, gives complete control of the associated
domain (which might be more than one system in a SAN or cluster).
This is a well-understood characteristic of the raw storage trust
model.

In the Berkeley networking model (praise the mighty), access to
network communication (other than evesdropping) is not a rigidly
protected resource.  The assumption is that the local endpoint is not
granted any additional power by being able to communicate arbitrarily,
and the remote endpoint must protect itself as appropriate to the
service it offers.

> The issue here is that the notion of user is an operating system
> abstraction and has no meaning in domains in which the
> OS has no administrative control (such as a SAN).

Not really.  A user is an authenticable identity in any form.  The
control is the access provided.

> Extending the notion of an user outside the domain of an OS requires
> primitives current SAN technology does not support (yet!)

I agree that the present infrastructure doesn't support this idea
well.  However, what we should do is define our security in such a way
that the SAN infrastructure can evolve towards the same type of
identity mechanisms that other networking services (try to) support.

If we do this right (and I think Jim's got the idea) it can support
both `the OS is completely trusted' (for now) and `each user has their
own credentials' (later) models.  We just need to make sure we don't
do anything stupid like claim that authenticable entity == IP address
in the protocol itself.  At present we're not in risk of doing that,
but maybe I should come out in support of it just in case :^)

I don't think there's any concrete change to what's already specified
to support this.  We certainly don't have to dot every I and cross
every T on the multiple identities per system model
(i.e. authentication and authorization infrastructure needn't
instantly be created to solve the full problem), but I guess we should
be aware of what we're shooting for as we specify additional security
behavior.

Steph






From owner-ips@ece.cmu.edu  Thu Aug 30 03:10:39 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07227
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 03:10:39 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7U5pZR12629
	for ips-outgoing; Thu, 30 Aug 2001 01:51:35 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7U5pVP12623
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 01:51:31 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id HAA93202
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 07:51:24 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7U5pNF269806
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 07:51:23 +0200
Importance: Normal
Subject: RE: iSCSI - Change - Login/Text commands with the binary stage code
 - IMPORTANT PROPOSAL
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF60C9BDD3.F0629366-ONC2256AB8.001F3D15@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Thu, 30 Aug 2001 08:50:47 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 30/08/2001 08:51:23
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


The situation is not symmetric anyway. If we keep the final login we have a
text request answered by
a Login request.

I think that considering that text & login are equivalent during login if
you care for complete symmetry you may want to use only login during the
login phase.

This way we could even remove the phases field from the text commands.

So again the proposal is USE ONLY LOGIN during Login (the reason I did no
put initially is now history anyway).

COMMENTS?

Julo


"Ayman Ghanem" <aghanem@cisco.com>@ece.cmu.edu on 30-08-2001 05:26:27

Please respond to "Ayman Ghanem" <aghanem@cisco.com>

Sent by:  owner-ips@ece.cmu.edu


To:   <ips@ece.cmu.edu>
cc:
Subject:  RE: iSCSI - Change - Login/Text commands with the binary stage
      code



Julian,

One could also argue for symmetry; only one login response per login cmd.
On
the other hand, the only time a partial login is returned at the moment is
when status class is 0 and F=0. Any other status class results in a final
login response. For status class 0, there exists 3 status detail codes: 0,
1, and 2. The first two are implied from the negotiation phase, and the
third case will no longer exist if we enforce the ITN to be sent in the
login cmd. The session parameters returned in a partial login response are
not needed because the connection has not joined the session yet during
login.

-Ayman


> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Julian Satran
> Sent: Wednesday, August 29, 2001 4:18 PM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI - Change - Login/Text commands with the binary stage
> code
>
>
> Steve,
>
> The partial response is not strictly needed it is just handy to have the
> login request answered
> with a login response. On this we can put the partial/final answer. For a
> text it would have been arbitrary (text outside login does not need it).
>
> As for the names - I though that security people might object having the
> name in clear if the security phase does not make use of the name.
> Otherwise we can mandate them on the login but I wonder if that is a real
> improvement or we are getting carelles.
>
> Julo
>
>
> Steve Senum <ssenum@cisco.com>@ece.cmu.edu on 29-08-2001 23:59:36
>
> Please respond to Steve Senum <ssenum@cisco.com>
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   ietf-ips <ips@ece.cmu.edu>
> cc:
> Subject:  Re: iSCSI - Change - Login/Text commands with the binary stage
>       code
>
>
>
> Julian,
>
> A couple of ideas from Matthew Burbridge & Co.'s
> login proposal that has generated some interest here:
>
> 1. Removal of partial login response.  Is it still needed?
>
> 2. Requiring Initiator and (if not a discovery session)
>    Target names on login command, so they are always
>    available if needed by the initial phase.
>
> Comments?
>
> Regards,
> Steve Senum
>
>
>
>






From owner-ips@ece.cmu.edu  Thu Aug 30 04:48:45 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08135
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 04:48:45 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7U6x0B15144
	for ips-outgoing; Thu, 30 Aug 2001 02:59:00 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from med.corp.rhapsodynetworks.com (64-160-62-201.rhapsodynetworks.com [64.160.62.201] (may be forged))
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7U5PdP11605
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 01:25:39 -0400 (EDT)
Received: by med.corp.rhapsodynetworks.com with Internet Mail Service (5.5.2653.19)
	id <NXFDF0V2>; Wed, 29 Aug 2001 22:25:30 -0700
Message-ID: <45BEF1D68145D51186C100B0D0AABE6503D6C3@med.corp.rhapsodynetworks.com>
From: Venkat Rangan <vrangan@rhapsodynetworks.com>
To: "'Stephen Bailey'" <steph@cs.uchicago.edu>,
        Santosh Rao
	 <santoshr@cup.hp.com>
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: reusing ISID for recovery 
Date: Wed, 29 Aug 2001 22:25:27 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Steph,

This is a long thread, almost as long as the thread "iSCSI: response to
second login (with same ISID)" we had a few months ago. One aspect from the
other thread that may not have been mentioned is the fact that you could
have a situation where a rogue software on the initiator running in user
mode which simply issues ISID=existing, TSID=0 to the target. (This may be
what was meant by "wild closing of connections" in this thread.) Choosing
option A) would destroy an otherwise well protected ISID managed in the
kernel space. This could also occur when you accidentally start another
application that does not coordinate its ISID selection.

The earlier thread was leaning towards "Reject the second login attempt with
In-Use error code" but the issue of targets cleaning up inactive and failed
sessions still lingers on.

Some observations:

1. There is no way to protect against rogue software at the intiator; even
the best IPSec policies and key management can not prevent such software
from disturbing other well-behaved components. So trying to design
mechanisms to prevent this at the target would be fruitless.

2. There is some value in protecting an accidental use of an existing ISID
by a second client (ISID=<existing>, TSID=0). This can be done with a Reject
of the login attempt, even without verification of login credentials - (less
of a DOS attack). You also do not need to analyze connection states in this
case.

3. From the perspective of the Target, case 2) above is no different from an
initiator rebooting and accidentally choosing an existing ISID with TSID=0.
To distinguish 2) from 3), we can make use of the Clear bit (or the C-bit)
and avoid many unnecessary trips at reboot time, trying to probe for an
unused ISID. The usage is that if C-bit is present, any previous sessions
are also closed by the target. I think this was Option B) in the original
email.

4. If initiators always set the C-bit, then they can't benefit from the
duplicate session identification capability of 2). It is a bad initiator in
that it doesn't respect the presence of other sessions at the initiator
system, but the protocol can't bloat handling these cases of bad initiators.

5. If an initiator only implements mandatory session recovery, it can help a
target recover faster by explicitly logging out the previous session and use
same or different ISID with TSID=0 and an C-bit to really ensure that it can
recover on a new session. This is a fast operation because we are not
waiting for lengthy round trips or timeouts, and the presence of the C-bit
makes the intent clear to the target that it must wipe off the existing
session. The perceived delay noted in Option C) does not arise.

6. If a target determines that all connections in a session are dead (TCP
keepalives can help here), and there is no activity on a session, it can
simply close the session and release the ISID and the TSID and recover
target side resources. This is not driven be explicit protocol action from
initiator, but simply target timer based, and is designed for initiators
that disappear without cleanup of sessions and don't reappear (no reboot for
a long time).

With this limited understanding, my preference would be Option B). One could
argue that B) offers protection only against an accidental use of the same
ISID, but if (as was pointed out earlier and in the other thread by Nick),
there are multiple ways in which iSCSI applications are packaged, so that
there is no shared visibility into ISID space, the protection offered by B)
can be useful.

Venkat Rangan
Rhapsody Networks Inc.
http://www.rhapsodynetworks.com


-----Original Message-----
From: Stephen Bailey [mailto:steph@cs.uchicago.edu]
Sent: Wednesday, August 29, 2001 1:53 PM
To: Santosh Rao
Cc: ips@ece.cmu.edu
Subject: Re: iSCSI: reusing ISID for recovery 


> The same was earlier proposed by myself in a previous thread on this
> issue a few months ago.

You're not the only one.  I'm also in favor of (A).  I have also
carefully laid out the chain that Marjorie's following on at least one
(and probably several) past occasions.  It seems sound to me.  An
initiator that has lost its mind (this might be an OS reboot, or
`simply' a fat adapter crash & restart) is going to want to stomp out
any existing sessions in its name.  It's not going to want to pick up
old context unless it's aware that there IS old context, in which case
it hasn't completely lost its mind.

I've been keeping my mouth shut in hopes that it would actually pass,
but I guess I don't have to articulate a position so much as just hold
it to ensure it gets killed.  Given my track record, I'm now for sale
to the highest bidder.

Steph


From owner-ips@ece.cmu.edu  Thu Aug 30 04:48:55 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08153
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 04:48:55 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7U7FV815785
	for ips-outgoing; Thu, 30 Aug 2001 03:15:31 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from klsifw ([209.157.245.98])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f7U7FNP15777
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 03:15:24 -0400 (EDT)
Received: from West095 ([209.157.254.118])
	by klsi.com (8.9.3/Solaris2.6/3.7W-12/24/99) with SMTP id AAA00050
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 00:15:15 -0700 (PDT)
Message-ID: <029d01c13123$89a6a220$76fe9dd1@klsi.com>
From: "Guru" <guru@klsi.com>
To: <ips@ece.cmu.edu>
References: <OF60C9BDD3.F0629366-ONC2256AB8.001F3D15@telaviv.ibm.com>
Subject: remove
Date: Thu, 30 Aug 2001 00:15:24 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


----- Original Message -----
From: "Julian Satran" <Julian_Satran@il.ibm.com>
To: <ips@ece.cmu.edu>
Sent: Wednesday, August 29, 2001 10:50 PM
Subject: RE: iSCSI - Change - Login/Text commands with the binary stage
code - IMPORTANT PROPOSAL


>
> The situation is not symmetric anyway. If we keep the final login we have
a
> text request answered by
> a Login request.
>
> I think that considering that text & login are equivalent during login if
> you care for complete symmetry you may want to use only login during the
> login phase.
>
> This way we could even remove the phases field from the text commands.
>
> So again the proposal is USE ONLY LOGIN during Login (the reason I did no
> put initially is now history anyway).
>
> COMMENTS?
>
> Julo
>
>
> "Ayman Ghanem" <aghanem@cisco.com>@ece.cmu.edu on 30-08-2001 05:26:27
>
> Please respond to "Ayman Ghanem" <aghanem@cisco.com>
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   <ips@ece.cmu.edu>
> cc:
> Subject:  RE: iSCSI - Change - Login/Text commands with the binary stage
>       code
>
>
>
> Julian,
>
> One could also argue for symmetry; only one login response per login cmd.
> On
> the other hand, the only time a partial login is returned at the moment is
> when status class is 0 and F=0. Any other status class results in a final
> login response. For status class 0, there exists 3 status detail codes: 0,
> 1, and 2. The first two are implied from the negotiation phase, and the
> third case will no longer exist if we enforce the ITN to be sent in the
> login cmd. The session parameters returned in a partial login response are
> not needed because the connection has not joined the session yet during
> login.
>
> -Ayman
>
>
> > -----Original Message-----
> > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> > Julian Satran
> > Sent: Wednesday, August 29, 2001 4:18 PM
> > To: ips@ece.cmu.edu
> > Subject: Re: iSCSI - Change - Login/Text commands with the binary stage
> > code
> >
> >
> > Steve,
> >
> > The partial response is not strictly needed it is just handy to have the
> > login request answered
> > with a login response. On this we can put the partial/final answer. For
a
> > text it would have been arbitrary (text outside login does not need it).
> >
> > As for the names - I though that security people might object having the
> > name in clear if the security phase does not make use of the name.
> > Otherwise we can mandate them on the login but I wonder if that is a
real
> > improvement or we are getting carelles.
> >
> > Julo
> >
> >
> > Steve Senum <ssenum@cisco.com>@ece.cmu.edu on 29-08-2001 23:59:36
> >
> > Please respond to Steve Senum <ssenum@cisco.com>
> >
> > Sent by:  owner-ips@ece.cmu.edu
> >
> >
> > To:   ietf-ips <ips@ece.cmu.edu>
> > cc:
> > Subject:  Re: iSCSI - Change - Login/Text commands with the binary stage
> >       code
> >
> >
> >
> > Julian,
> >
> > A couple of ideas from Matthew Burbridge & Co.'s
> > login proposal that has generated some interest here:
> >
> > 1. Removal of partial login response.  Is it still needed?
> >
> > 2. Requiring Initiator and (if not a discovery session)
> >    Target names on login command, so they are always
> >    available if needed by the initial phase.
> >
> > Comments?
> >
> > Regards,
> > Steve Senum
> >
> >
> >
> >
>
>
>
>



From owner-ips@ece.cmu.edu  Thu Aug 30 11:04:25 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19103
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 11:04:25 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7UDox113571
	for ips-outgoing; Thu, 30 Aug 2001 09:50:59 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from sandmail.sandburst.com (sandmail.sandburst.com [216.57.132.42])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7UDovP13560
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 09:50:57 -0400 (EDT)
To: ips@ece.cmu.edu
Subject: Re: ISCSI: User authentication vs. Machine Authentication for iSC SI 
In-Reply-To: Message from Joshua Tseng <jtseng@NishanSystems.com> 
   of "Wed, 29 Aug 2001 23:08:09 PDT." <B300BD9620BCD411A366009027C21D9B5BAE36@ariel.nishansystems.com> 
References: <B300BD9620BCD411A366009027C21D9B5BAE36@ariel.nishansystems.com> 
Date: Thu, 30 Aug 2001 09:50:23 -0400
From: Stephen Bailey <steph@cs.uchicago.edu>
Message-Id: <20010830135052.9CF644E95@sandmail.sandburst.com>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

> I believe this is the "iSCSI Name" (formerly WWUI).

I guess I was unclear.  I consider the iSCSI name to BE the `user
name' in this discussion.

I was not suggesting that we introduce any additional identities.  I
was only suggesting it might be a mistake to slavishly equate identity
with OS instance.  I don't THINK we're in any risk of doing that.
Somebody please shout if they think we are, or if they think we should
be.

If a user process wants to initiate its own iSCSI connection to a
target, there are two options:
  1) the host OS gives the process ITS identity (& credentials)
  2) the user process uses its own unique identity (obtained through
     some mechanism we're not describing or discussing, e.g. from the
     storage domain administrator).

1) would be the case if you were using SCSI passthru to an iSCSI
driver.  In this situation, it's still really the OS that's doing the
interaction as a proxy for the user.  The OS can ensure (or not) that
its identity isn't being abused.  The OS could also give its identity
to a user-mode iSCSI sockets client through a securable interface.
The OS should never completely freely give away its identity (e.g. to
an untrusted user process), unless it doesn't care how it's used.

2) would be the case if jane helpful-programmer (or joe script-kiddy)
wrote a user-mode iSCSI initiator using sockets for whatever purpose.

Perhaps I'm covering old ground that was already worked out at the
interim meeting.  If so, I apologize.

Steph


From owner-ips@ece.cmu.edu  Thu Aug 30 11:54:17 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20150
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 11:54:17 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7UESBO15773
	for ips-outgoing; Thu, 30 Aug 2001 10:28:11 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e33.bld.us.ibm.com (e33.co.us.ibm.com [32.97.110.131])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7UES8P15768
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 10:28:10 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e33.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA63248
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 09:25:55 -0500
Received: from d03nmx42.almaden.ibm.com (d03nmx42.almaden.ibm.com [9.1.24.146])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7UEQpD129888
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 08:26:51 -0600
Importance: Normal
Subject: RE: iSCSI: reusing ISID for recovery
To: ips@ece.cmu.edu
From: "Jim Hafner" <hafner@almaden.ibm.com>
Date: Thu, 30 Aug 2001 07:26:48 -0700
Message-ID: <OF04CC68EC.FD990160-ON88256AB8.004EE123@almaden.ibm.com>
X-MIMETrack: Serialize by Router on D03NMX42/03/M/IBM(Build M9_05202001 Beta 2|May 20, 2001) at
 08/30/2001 07:26:50 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Venkat,
You wrote that optionA doesn't protect:
  where a rogue software on the initiator running in user
mode which simply issues ISID=existing, TSID=0 to the target.

But what's to prevent that same rogue software from setting the C bit?
It's the same exposure either way. In option A, the old session gets killed
regardless.  In option B the old session gets killed with C=1 (and that's
hardly any sort of extra hurdle you'd want to place on the rogue software).

You also wrote:
  It is a bad initiator in
that it doesn't respect the presence of other sessions at the initiator
system, but the protocol can't bloat handling these cases of bad initiators
.

That's the point exactly.  It's a "bad initiator" that carelessly reuses an
existing ISID (regardless of whether it has to set an extra bit or not).
We can't protect against that at the target.

Jim Hafner


Venkat Rangan <vrangan@rhapsodynetworks.com>@ece.cmu.edu on 08/29/2001
10:25:27 PM

Sent by:  owner-ips@ece.cmu.edu


To:   "'Stephen Bailey'" <steph@cs.uchicago.edu>, Santosh Rao
      <santoshr@cup.hp.com>
cc:   ips@ece.cmu.edu
Subject:  RE: iSCSI: reusing ISID for recovery



Steph,

This is a long thread, almost as long as the thread "iSCSI: response to
second login (with same ISID)" we had a few months ago. One aspect from the
other thread that may not have been mentioned is the fact that you could
have a situation where a rogue software on the initiator running in user
mode which simply issues ISID=existing, TSID=0 to the target. (This may be
what was meant by "wild closing of connections" in this thread.) Choosing
option A) would destroy an otherwise well protected ISID managed in the
kernel space. This could also occur when you accidentally start another
application that does not coordinate its ISID selection.

The earlier thread was leaning towards "Reject the second login attempt
with
In-Use error code" but the issue of targets cleaning up inactive and failed
sessions still lingers on.

Some observations:

1. There is no way to protect against rogue software at the intiator; even
the best IPSec policies and key management can not prevent such software
from disturbing other well-behaved components. So trying to design
mechanisms to prevent this at the target would be fruitless.

2. There is some value in protecting an accidental use of an existing ISID
by a second client (ISID=<existing>, TSID=0). This can be done with a
Reject
of the login attempt, even without verification of login credentials -
(less
of a DOS attack). You also do not need to analyze connection states in this
case.

3. From the perspective of the Target, case 2) above is no different from
an
initiator rebooting and accidentally choosing an existing ISID with TSID=0.
To distinguish 2) from 3), we can make use of the Clear bit (or the C-bit)
and avoid many unnecessary trips at reboot time, trying to probe for an
unused ISID. The usage is that if C-bit is present, any previous sessions
are also closed by the target. I think this was Option B) in the original
email.

4. If initiators always set the C-bit, then they can't benefit from the
duplicate session identification capability of 2). It is a bad initiator in
that it doesn't respect the presence of other sessions at the initiator
system, but the protocol can't bloat handling these cases of bad
initiators.

5. If an initiator only implements mandatory session recovery, it can help
a
target recover faster by explicitly logging out the previous session and
use
same or different ISID with TSID=0 and an C-bit to really ensure that it
can
recover on a new session. This is a fast operation because we are not
waiting for lengthy round trips or timeouts, and the presence of the C-bit
makes the intent clear to the target that it must wipe off the existing
session. The perceived delay noted in Option C) does not arise.

6. If a target determines that all connections in a session are dead (TCP
keepalives can help here), and there is no activity on a session, it can
simply close the session and release the ISID and the TSID and recover
target side resources. This is not driven be explicit protocol action from
initiator, but simply target timer based, and is designed for initiators
that disappear without cleanup of sessions and don't reappear (no reboot
for
a long time).

With this limited understanding, my preference would be Option B). One
could
argue that B) offers protection only against an accidental use of the same
ISID, but if (as was pointed out earlier and in the other thread by Nick),
there are multiple ways in which iSCSI applications are packaged, so that
there is no shared visibility into ISID space, the protection offered by B)
can be useful.

Venkat Rangan
Rhapsody Networks Inc.
http://www.rhapsodynetworks.com


-----Original Message-----
From: Stephen Bailey [mailto:steph@cs.uchicago.edu]
Sent: Wednesday, August 29, 2001 1:53 PM
To: Santosh Rao
Cc: ips@ece.cmu.edu
Subject: Re: iSCSI: reusing ISID for recovery


> The same was earlier proposed by myself in a previous thread on this
> issue a few months ago.

You're not the only one.  I'm also in favor of (A).  I have also
carefully laid out the chain that Marjorie's following on at least one
(and probably several) past occasions.  It seems sound to me.  An
initiator that has lost its mind (this might be an OS reboot, or
`simply' a fat adapter crash & restart) is going to want to stomp out
any existing sessions in its name.  It's not going to want to pick up
old context unless it's aware that there IS old context, in which case
it hasn't completely lost its mind.

I've been keeping my mouth shut in hopes that it would actually pass,
but I guess I don't have to articulate a position so much as just hold
it to ensure it gets killed.  Given my track record, I'm now for sale
to the highest bidder.

Steph





From owner-ips@ece.cmu.edu  Thu Aug 30 11:56:02 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20174
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 11:56:01 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7UEUnX15971
	for ips-outgoing; Thu, 30 Aug 2001 10:30:49 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e34.bld.us.ibm.com (e34.co.us.ibm.com [32.97.110.132])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7UEUkP15964
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 10:30:46 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e34.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA30376
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 10:28:33 -0400
Received: from d03nmx42.almaden.ibm.com (d03nmx42.almaden.ibm.com [9.1.24.146])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7UETSD98826
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 08:29:28 -0600
Importance: Normal
Subject: Re: iSCSI: reusing ISID for recovery
To: ips@ece.cmu.edu
From: "Jim Hafner" <hafner@almaden.ibm.com>
Date: Thu, 30 Aug 2001 07:29:26 -0700
Message-ID: <OF7E09EE57.ADF0DC45-ON88256AB8.004F8F45@almaden.ibm.com>
X-MIMETrack: Serialize by Router on D03NMX42/03/M/IBM(Build M9_05202001 Beta 2|May 20, 2001) at
 08/30/2001 07:29:28 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Julian,

You wrote:
    to management servers that direct you to same target under two
different names

I didn't understand who has the different name, the target or the
initiator.  In either case, however, it doesn't matter because the ISID
scoping is within the *named* pair of (initiator,target), so that there
won't be a collision!

Jim Hafner


Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 08/29/2001 10:33:35 PM

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  Re: iSCSI: reusing ISID for recovery




With  regard to time bloat I have two things to say:

1- It is a rare event (connection don't stay alive long if a machine goes
down)
2 - we could remove the checking - going only on reporting and have in
those cases the command reissued with X

As for the mistake I am afraid that anything that is so easy to do badly
will be done badly and causes can range from simple bugs, to management
servers that direct you to same target under two different names and the
target does not care to two user programs doing uncoordinated login (but
only one is bad).

I assume that are many scenarios that we don't even think about.

My long experience tells me not make it easy for a mistake to ruin good
work.

And I think that the proposal that is out (removing the checking and having
Marjory irritated) is a good compromise between simplicity a sound
engineering.

Julo


Santosh Rao <santoshr@cup.hp.com>@ece.cmu.edu on 30-08-2001 02:54:09

Please respond to Santosh Rao <santoshr@cup.hp.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  Re: iSCSI: reusing ISID for recovery



Julian Satran wrote:

> Doing an automatic logout when a new session is seen can be performed by
> mistake by an OS in a multi OS machine. It is just to easy to let it
> through.

A multi-OS system would use a different iSCSI initiator name for each O.S.


> After a reboot the right procedure would be to login cleanly (no
> previous knowledge needed). The target will ascertain that the old
session
> is dead and let you in.

Are you suggesting a combination of the existing login target behaviour
wherein the target checks the olde session if it exists when the X bit is
not
set, coupled with an unconditional cleanup when the X bit is set ?

Having the target test the old session, prior to responding to a login can
bloat login time to unacceptable levels and increase system bootup time as
well as I/O scan time.


>
> You will need the X only when the old session is alive (answering to NOP)
> but you don't know how to clean it.

The initiator may not know if an old session had been established by it
previously. Hence, it will either always need to set the X bit, or risk the
chance of a login reject.

What are we trying to achieve by having the target validate the initiator's
attempt to clean up an old session ? The target must trust the initiator's
decision to clean up [after first completing login authentication to avoid
malicious logout type attacks], rather than have to validate it first.
Targets
should not be expected to do all this extra work of validation to protect
against initiator coding bugs.

The draft should not be trying to optimize for a coding bug scenario,
wherein
the initiator accidentally re-logs in with the same (iscsi initiator name,
ISID, NULL TSID).

FC exhibits the same semantics that are being asked for here. Implicit
logout
+ re-login behaviour is oft used by FC initiators. Similar login semantics
will make the life of iscsi-fc convertor products easier as well.


>
> Reboot behavior is close to what you have in the current draft ( a single
> login needed - no X).

On a reboot, the initiator does not know if it has previously logged out of
the session prior to the reboot. Thus, it would need to clean up any stale
sessions, if they exist. Rather than attempt 2 logins [one with an X and
then,
one without], the login should be allowed to imply a logout of any stale
session, if one such exists.

This issue is applicable to the reboot of initiators.

- Santosh

>
> "KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
@ece.cmu.edu
> on 29-08-2001 22:27:35
>
> Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"
>       <marjorie_krueger@hp.com>
>
> Sent by:  owner-ips@ece.cmu.edu
>
> To:   ips@ece.cmu.edu
> cc:
> Subject:  RE: iSCSI: reusing ISID for recovery
>
> It would help to get your message thru if you could answer our requests
for
> an explanation of your thinking.  We have tried several times to explain
> our
> logic (w/examples) but I haven't seen an example from you supporting a
> scenario in which you see a problem.
>
> If an initiator reboots, and has no context information, how can it know
> whether or not a target has a pre-existing session?  Since there is no
nice
> way to know that, I would probably code my initiator to request a login
> with
> the X bit set (but as Mallikarjun said, I don't like this overloading of
> the
> X bit, it's a special case and makes the coding extra convoluted).  In
your
> preferred scenario, this would cause the target to reject the login
"cause
> there is no pre-existing session", and the initiator would re-issues the
> login without the X bit set.  What have you saved anyone from here?
You've
> just added latency to the login process.  And either way the initiator
> codes
> it's login after reboot, there's a presumably equal probability of
> encountering this extra exchange.
>
> I still haven't seen a plausable example where it does harm to have a
login
> w/ ISID=n, TSID=0 close an existing session with this initiator.  I can
see
> no case where this would be the wrong decision.  If "this isn't what the
> initiator intended", this is a defective initiator implementation and
> closing the other session at least does no harm.
>

 - santoshr.vcf








From owner-ips@ece.cmu.edu  Thu Aug 30 12:05:43 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20368
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 12:05:41 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7UDUu712441
	for ips-outgoing; Thu, 30 Aug 2001 09:30:56 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from siaar1aa.compuserve.com (siaar1aa.compuserve.com [149.174.40.9])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7UDUmP12424
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 09:30:49 -0400 (EDT)
Received: (from mailgate@localhost)
	by siaar1aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id JAA21335
	for ips@ece.cmu.edu; Thu, 30 Aug 2001 09:30:42 -0400 (EDT)
Received: from compuserve.com (dal-tgn-tkg-vty3.as.wcom.net [206.175.236.3])
	by siaar1aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id JAA21288
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 09:30:35 -0400 (EDT)
Message-ID: <3B8E4114.3C1325C0@compuserve.com>
Date: Thu, 30 Aug 2001 08:35:16 -0500
From: Ralph Weber <ralphoweber@compuserve.com>
Reply-To: ENDL_TX@computer.org
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47  (Win95; I)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: IPS Reflector <ips@ece.cmu.edu>
Subject: Re: iFCP:PDF's with markup
References: <B300BD9620BCD411A366009027C21D9B551FC9@ariel.nishansystems.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Charles,

My belief is that submitting the change bar PDF in addition to the TXT
file is okay.  Submitting only a PDF could be difficult.

I plan to start submitting change bar PDFs with the next FCIP revision.

Ralph...

Charles Monia wrote:

>
> Hi:
>
> Sorry if this has been asked before.  For a rev of an evolving draft, is it
> ok to submit a PDF file with change bars to the archive as well as (or in
> lieu of) the txt file?
>
> Charles
> Charles Monia
> Senior Technology Consultant
> Nishan Systems
> email: cmonia@nishansystems.com
> voice: (408) 519-3986
> fax:   (408) 435-8385
>



From owner-ips@ece.cmu.edu  Thu Aug 30 13:07:09 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22086
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 13:07:09 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7UFJqq18847
	for ips-outgoing; Thu, 30 Aug 2001 11:19:52 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7UFJoP18843
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 11:19:51 -0400 (EDT)
Received: from colosus2.cup.hp.com (colosus2.cup.hp.com [15.13.128.145])
	by palrel1.hp.com (Postfix) with ESMTP
	id 06F331215; Thu, 30 Aug 2001 08:19:50 -0700 (PDT)
Received: from hp.com (IDENT:plabat@pl703521.cup.hp.com [15.13.133.216])
	by colosus2.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id IAA21752;
	Thu, 30 Aug 2001 08:19:45 -0700 (PDT)
Message-ID: <3B8E5DCA.EEAD10DB@hp.com>
Date: Thu, 30 Aug 2001 08:37:46 -0700
From: Pierre Labat <pierre_labat@hp.com>
Organization: Hewlett Packard iSCSI-SISL
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: John Hufferd <hufferd@us.ibm.com>
Cc: ips@ece.cmu.edu
Subject: Re: ISCSI: User authentication vs. Machine Authentication for iSCSI
References: <OF7F53A14D.D8E9C3B4-ON88256AB7.0061F075@boulder.ibm.com>
Content-Type: multipart/alternative;
 boundary="------------E507120818FA66E8CDAA7C8D"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


--------------E507120818FA66E8CDAA7C8D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


John Hufferd wrote:

> Bill,
> You are correct, in my opinion, on the problem statement, but not  on the
> solution.
>
> The IKE stuff will Get a system identified, and perhaps ensure that a
> encrypted connection is put in place.  This then give the Source and Target
> the Freedom to exchange stuff that would otherwise be in the clear, such as
> iSCSI Node Names etc.  But after the iSCSI session is established, it is
> between an OS and a target.  The OS, is the thing that actually owns the
> resource, it only loans the resources, in some manor, to applications.
>
> I was having a similar problem to what you stated, at the Irvine meeting,
> and kept digging and objecting (off-stage) until I got the following more
> acceptable response.
>
> Environment 1: (Use of IKE with complete Certificates processing ( or
> pre-Shared password), with ESP equal to something other then Null)
> 1. We use IKE to get a mutually authenticated and Encrypted communication
> link.  This means that the Target knows that (at the IKE/TCP Layer) there
> is, at the other end, an authorized thing.  (What or who that thing is,
> relative to iSCSI is not really known).  This secure link can be
> established either via Certificates or via a pre-Shared password.
> 2. An iSCSI Login can now be done, over a secure link, so the iSCSI
> Initiator Name, and iSCSI Target Name etc can be exchanged securely.
> Please note, just because you passed the IKE certificate gate does not mean
> you are the iSCSI Initiator that you claim to be.

John,

Do i miss something? Why not use Certificate where
the subjectname is the iSCSI name (iqn or eui)?.
So as soon as the IPSEC SA are established each side
knows what intitiator/target is the other side.
There no need for extra password or alias.
The only problem with that is that some directory
as you mentionned below wouldn't support subjectname
as long as an iqn?

Regards,

Pierre

> Therefore, a password,
> for example, that is associated with the iSCSI Initiator Name can now be
> used to perform an iSCSI validation of the Initiator.  (Please note, this
> could, instead of a password,  be a Kerberos type Validation etc.)
> 3. David, and perhaps other used the words "User" or "Application" name to
> address what was being addressed in 2 above.  But there was more to this
> then just assuming that the iSCSI Initiator Name was the User name.  Since
> folks may actually want to use existing infrastructure, to handle the
> password management and authentication process, they will need to assign
> what I might call an "Alias for the iSCSI Initiator" which can actually be
> saved in the existing infrastructure user authentication repository.  The
> point that was made to me, is that iSCSI Initiator Name (iqn or eui) will
> not "fit" into things that contain "User Names" so we need to have a
> corresponding "User Name" that we can actually authenticate using, for
> example Microsoft Active Directory etc. Hence the need for a "Alias for the
> iSCSI initiator.  (I really hate this, and wish there was something else we
> could do.)
>

--------------E507120818FA66E8CDAA7C8D
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<br>John Hufferd wrote:
<blockquote TYPE=CITE>Bill,
<br>You are correct, in my opinion, on the problem statement, but not&nbsp;
on the
<br>solution.
<p>The IKE stuff will Get a system identified, and perhaps ensure that
a
<br>encrypted connection is put in place.&nbsp; This then give the Source
and Target
<br>the Freedom to exchange stuff that would otherwise be in the clear,
such as
<br>iSCSI Node Names etc.&nbsp; But after the iSCSI session is established,
it is
<br>between an OS and a target.&nbsp; The OS, is the thing that actually
owns the
<br>resource, it only loans the resources, in some manor, to applications.
<p>I was having a similar problem to what you stated, at the Irvine meeting,
<br>and kept digging and objecting (off-stage) until I got the following
more
<br>acceptable response.
<p>Environment 1: (Use of IKE with complete Certificates processing ( or
<br>pre-Shared password), with ESP equal to something other then Null)
<br>1. We use IKE to get a mutually authenticated and Encrypted communication
<br>link.&nbsp; This means that the Target knows that (at the IKE/TCP Layer)
there
<br>is, at the other end, an authorized thing.&nbsp; (What or who that
thing is,
<br>relative to iSCSI is not really known).&nbsp; This secure link can
be
<br>established either via Certificates or via a pre-Shared password.
<br>2. An iSCSI Login can now be done, over a secure link, so the iSCSI
<br>Initiator Name, and iSCSI Target Name etc can be exchanged securely.
<br>Please note, just because you passed the IKE certificate gate does
not mean
<br>you are the iSCSI Initiator that you claim to be.</blockquote>
<tt>John,</tt><tt></tt>
<p><tt>Do i miss something? Why not use Certificate where</tt>
<br><tt>the subjectname is the iSCSI name (iqn or eui)?.</tt>
<br><tt>So as soon as the IPSEC SA are established each side</tt>
<br><tt>knows what intitiator/target is the other side.</tt>
<br><tt>There no need for extra password or alias.</tt>
<br><tt>The only problem with that is that some directory</tt>
<br><tt>as you mentionned below wouldn't support subjectname</tt>
<br><tt>as long as an iqn?</tt><tt></tt>
<p><tt>Regards,</tt><tt></tt>
<p><tt>Pierre</tt>
<blockquote TYPE=CITE>Therefore, a password,
<br>for example, that is associated with the iSCSI Initiator Name can now
be
<br>used to perform an iSCSI validation of the Initiator.&nbsp; (Please
note, this
<br>could, instead of a password,&nbsp; be a Kerberos type Validation etc.)
<br>3. David, and perhaps other used the words "User" or "Application"
name to
<br>address what was being addressed in 2 above.&nbsp; But there was more
to this
<br>then just assuming that the iSCSI Initiator Name was the User name.&nbsp;
Since
<br>folks may actually want to use existing infrastructure, to handle the
<br>password management and authentication process, they will need to assign
<br>what I might call an "Alias for the iSCSI Initiator" which can actually
be
<br>saved in the existing infrastructure user authentication repository.&nbsp;
The
<br>point that was made to me, is that iSCSI Initiator Name (iqn or eui)
will
<br>not "fit" into things that contain "User Names" so we need to have
a
<br>corresponding "User Name" that we can actually authenticate using,
for
<br>example Microsoft Active Directory etc. Hence the need for a "Alias
for the
<br>iSCSI initiator.&nbsp; (I really hate this, and wish there was something
else we
<br>could do.)
<br>&nbsp;</blockquote>
</html>

--------------E507120818FA66E8CDAA7C8D--



From owner-ips@ece.cmu.edu  Thu Aug 30 13:23:38 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22456
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 13:23:36 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7UGLsQ22285
	for ips-outgoing; Thu, 30 Aug 2001 12:21:54 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7UGLrP22281
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 12:21:53 -0400 (EDT)
Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <RNJ883VV>; Thu, 30 Aug 2001 12:21:43 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD68E@CORPMX14>
From: Black_David@emc.com
To: bill@sanera.net, ips@ece.cmu.edu
Subject: RE: ISCSI: Required Crytographic transforms for iSCSI
Date: Thu, 30 Aug 2001 12:15:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Yes, NULL Encryption needs to be a "MUST implement", fortunately,
it's not a lot of code or hardware :-).  It was "MUST implement"
as of the Nashua meeting, and there was no intention to change
that - I'll make sure this appears on the summary of security
directions from the Orange County meeting (which will include
the rationale for those directions) that I intend to get to the
list *today* (i.e., well in advance of the draft minutes).

The good news in the other direction is that we don't need any
additional language to enable Encryption without a MAC - IKE/ISAKMP
allows this by omission of negotiation of the MAC (just to confuse
things, a MAC is an "Authentication Algorithm" in ISAKMP-speak).
Encryption ("Transform" in ISAKMP-speak, includes both the actual
crypto algorithm and its operating mode) negotiation cannot
be omitted for ESP due to design decisions in ESP and ISAKMP,
hence the need to make "NULL encryption" a "MUST implement".

Credit to Bill for catching this.  Thanks,
--David

> -----Original Message-----
> From: Bill Strahm [mailto:bill@sanera.net]
> Sent: Wednesday, August 29, 2001 11:34 AM
> To: Ips@Ece. Cmu. Edu
> Subject: ISCSI: Required Crytographic transforms for iSCSI
> 
> 
> When we were talking about required transforms yesterday in 
> Los Angeles, I
> believe that we forgot a VERY important transform that need 
> to be a MUST
> implement for ESP.  That is the NULL Encryption Algorithm (RFC2410).
> 
> I propose that this algorithm is a MUST implement for all iSCSI
> implementations
> 
> Bill
> Sanera Systems Inc.
> 


From owner-ips@ece.cmu.edu  Thu Aug 30 13:31:04 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22610
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 13:30:58 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7UGE0i21873
	for ips-outgoing; Thu, 30 Aug 2001 12:14:00 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f7UGDwP21869
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 12:13:58 -0400 (EDT)
Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Thu Aug 30 12:12:10 EDT 2001
Received: from aura.research.bell-labs.com ([135.104.46.10]) by grubby; Thu Aug 30 12:12:26 EDT 2001
Received: from research.bell-labs.com (IDENT:sandeepj@sandeepj-pcmh.research.bell-labs.com [135.104.47.90])
	by aura.research.bell-labs.com (8.9.1/8.9.1) with ESMTP id MAA16244
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 12:11:53 -0400 (EDT)
Message-ID: <3B8E65C9.4DD97B0@research.bell-labs.com>
Date: Thu, 30 Aug 2001 12:11:53 -0400
From: Sandeep Joshi <sandeepj@research.bell-labs.com>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-3 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: ips@ece.cmu.edu
Subject: Re: iSCSI - Change - Login/Text commands with the binary stage code
References: <LOEPJENHBHAHEABBNDAJCEDHCDAA.aghanem@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


Julian,

> > As for the names - I though that security people might object having the
> > name in clear if the security phase does not make use of the name.
> > Otherwise we can mandate them on the login but I wonder if that is a real
> > improvement or we are getting carelles.
> >
> > Julo

The problem with these names (and hence the request from Steve and
others 
earlier) is that it is not possible to know when the target wants them. 

Consider the following excerpts from your latest login proposal..

> A target MAY use the iSCSI Initiator Name as part of its access control
> mechanism; therefore, the iSCSI Initiator Name MUST be sent before the
> target is required to disclose its LUs.

The above is _very_ confusing..how can the initiator know if the
 the target is doing access control ?

> If the iSCSI Target Name and/or iSCSI Initiator Name is going to be used
> in determining the security mode or it is implicit part of
> authentication, then the iSCSI Target Name and/or iSCSI Initiator Name
> MUST be sent in the login command for the first connection of a session
> to identify the storage endpoint of the session

In both the above cases, how does the initiator know when the target
requires these names?  The partial login response occurs *only* once.
So when going from the security->operational phase, there is no
indication that the target would like these names sent.

There are 3 options here :
(A) ALways send the names in the login command.  Simplify target
   and initiator and eliminate a few of those partial login 
   response codes.
(B) Maintain a configuration database (per-target) of when names
   must be sent - adds an administration burden.  
(C) Change the wire protocol to allow the target to indicate when
   the names must be sent - again more complications. 

To round up, I prefer Option (A).  These are just names and not
passwords, so the security risks are minimal.  Are we trying to 
protect against traffic analysis ?

-Sandeep

> >
> > Steve Senum <ssenum@cisco.com>@ece.cmu.edu on 29-08-2001 23:59:36
> >
> > Please respond to Steve Senum <ssenum@cisco.com>
> >
> > Sent by:  owner-ips@ece.cmu.edu
> >
> >
> > To:   ietf-ips <ips@ece.cmu.edu>
> > cc:
> > Subject:  Re: iSCSI - Change - Login/Text commands with the binary stage
> >       code
> >
> >
> >
> > Julian,
> >
> > A couple of ideas from Matthew Burbridge & Co.'s
> > login proposal that has generated some interest here:
> >
> > 1. Removal of partial login response.  Is it still needed?
> >
> > 2. Requiring Initiator and (if not a discovery session)
> >    Target names on login command, so they are always
> >    available if needed by the initial phase.
> >
> > Comments?
> >
> > Regards,
> > Steve Senum
> >
> >
> >
> >


From owner-ips@ece.cmu.edu  Thu Aug 30 13:42:39 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAB23109
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 13:42:39 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7UFw7K21029
	for ips-outgoing; Thu, 30 Aug 2001 11:58:07 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7UFw6P21024
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 11:58:06 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-68-173.cisco.com [161.44.68.173]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA14310 for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 11:57:57 -0400 (EDT)
Message-ID: <3B8E627A.87EB8D3F@cisco.com>
Date: Thu, 30 Aug 2001 10:57:46 -0500
From: Steve Senum <ssenum@cisco.com>
X-Mailer: Mozilla 4.73 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-ips <ips@ece.cmu.edu>
Subject: Re: iSCSI - Change - Login/Text commands with the binary stage code
References: <OF2313AAC4.E7FE1FCD-ONC2256AB7.0073B96F@telaviv.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Julian,

> As for the names - I though that security people might object having the
> name in clear if the security phase does not make use of the name.
> Otherwise we can mandate them on the login but I wonder if that is a real
> improvement or we are getting carelles.

The names are in the clear in any case, unless IPsec encryption is
being used, in which case the entire connection is encrypted.

My concern is that an initiator can't know without
configuration when the target needs the names, so I would
prefer we mandate them on the login command.

Regards,
Steve Senum

> 
> Julo
> 
> Steve Senum <ssenum@cisco.com>@ece.cmu.edu on 29-08-2001 23:59:36
> 
> Please respond to Steve Senum <ssenum@cisco.com>
> 
> Sent by:  owner-ips@ece.cmu.edu
> 
> To:   ietf-ips <ips@ece.cmu.edu>
> cc:
> Subject:  Re: iSCSI - Change - Login/Text commands with the binary stage
>       code
> 
> Julian,
> 
> A couple of ideas from Matthew Burbridge & Co.'s
> login proposal that has generated some interest here:
> 
> 1. Removal of partial login response.  Is it still needed?
> 
> 2. Requiring Initiator and (if not a discovery session)
>    Target names on login command, so they are always
>    available if needed by the initial phase.
> 
> Comments?
> 
> Regards,
> Steve Senum


From owner-ips@ece.cmu.edu  Thu Aug 30 13:45:57 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23166
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 13:45:57 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7UGD0a21825
	for ips-outgoing; Thu, 30 Aug 2001 12:13:00 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7UGCwP21820
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 12:12:58 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-68-173.cisco.com [161.44.68.173]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA03841 for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 12:12:49 -0400 (EDT)
Message-ID: <3B8E65F6.1507D03F@cisco.com>
Date: Thu, 30 Aug 2001 11:12:38 -0500
From: Steve Senum <ssenum@cisco.com>
X-Mailer: Mozilla 4.73 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-ips <ips@ece.cmu.edu>
Subject: Re: iSCSI - Change - Login/Text commands with the binary stage code- 
 IMPORTANT PROPOSAL
References: <OF60C9BDD3.F0629366-ONC2256AB8.001F3D15@telaviv.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Julian,

> The situation is not symmetric anyway. If we keep the final login we have a
> text request answered by
> a Login request.
> 
> I think that considering that text & login are equivalent during login if
> you care for complete symmetry you may want to use only login during the
> login phase.
> 
> This way we could even remove the phases field from the text commands.
> 
> So again the proposal is USE ONLY LOGIN during Login (the reason I did no
> put initially is now history anyway).
> 
> COMMENTS?

Ayman and I would prefer having only one login command and one login
response, seperated by zero or more text response/text command
pairs (like in Matthew Burbridge & Co.'s proposal).

Second choice would be leaving the spec as is, with the partial
login response.

Regards,
Steve Senum


From owner-ips@ece.cmu.edu  Thu Aug 30 14:02:59 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23678
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 14:02:58 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7UHBi925193
	for ips-outgoing; Thu, 30 Aug 2001 13:11:44 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from bramg1.net.external.hp.com (bramg1.net.external.hp.com [192.6.126.73])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7UHBgP25188
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 13:11:42 -0400 (EDT)
Received: from quasit.br.itc.hp.com (quasit.br.itc.hp.com [15.145.8.135])
	by bramg1.net.external.hp.com (Postfix) with ESMTP
	id 8715D8A; Thu, 30 Aug 2001 19:12:06 +0200 (METDST)
Received: from loddon.br.itc.hp.com (loddon.br.itc.hp.com [15.145.8.166])
	by quasit.br.itc.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id SAA12224;
	Thu, 30 Aug 2001 18:11:40 +0100 (BST)
Received: from 15.145.8.166 by loddon.br.itc.hp.com (InterScan E-Mail VirusWall NT); Thu, 30 Aug 2001 18:11:40 +0100 (GMT Daylight Time)
Received: by loddon.br.itc.hp.com with Internet Mail Service (5.5.2653.19)
	id <RXW56Z2M>; Thu, 30 Aug 2001 18:11:40 +0100
Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC101E7A870@dickens.bri.hp.com>
From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <matthew_burbridge@hp.com>
To: "'Sandeep Joshi'" <sandeepj@research.bell-labs.com>, ips@ece.cmu.edu
Subject: RE: iSCSI - Change - Login/Text commands with the binary stage co
	de
Date: Thu, 30 Aug 2001 18:11:39 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Julian, Sandeep,

I am very much in favour of the option A (Always send the names
in the login command).

This is inline with what we proposed in the Matthew/Bob/Marj
login proposal and as Sandeep has pointed out it does simplify
the protocol enormously.

Cheers

Matthew Burbridge

-----Original Message-----
From: Sandeep Joshi [mailto:sandeepj@research.bell-labs.com]
Sent: Thursday, August 30, 2001 5:12 PM
To: ips@ece.cmu.edu
Subject: Re: iSCSI - Change - Login/Text commands with the binary stage
code



Julian,

> > As for the names - I though that security people might object having the
> > name in clear if the security phase does not make use of the name.
> > Otherwise we can mandate them on the login but I wonder if that is a
real
> > improvement or we are getting carelles.
> >
> > Julo

The problem with these names (and hence the request from Steve and
others 
earlier) is that it is not possible to know when the target wants them. 

Consider the following excerpts from your latest login proposal..

> A target MAY use the iSCSI Initiator Name as part of its access control
> mechanism; therefore, the iSCSI Initiator Name MUST be sent before the
> target is required to disclose its LUs.

The above is _very_ confusing..how can the initiator know if the
 the target is doing access control ?

> If the iSCSI Target Name and/or iSCSI Initiator Name is going to be used
> in determining the security mode or it is implicit part of
> authentication, then the iSCSI Target Name and/or iSCSI Initiator Name
> MUST be sent in the login command for the first connection of a session
> to identify the storage endpoint of the session

In both the above cases, how does the initiator know when the target
requires these names?  The partial login response occurs *only* once.
So when going from the security->operational phase, there is no
indication that the target would like these names sent.

There are 3 options here :
(A) ALways send the names in the login command.  Simplify target
   and initiator and eliminate a few of those partial login 
   response codes.
(B) Maintain a configuration database (per-target) of when names
   must be sent - adds an administration burden.  
(C) Change the wire protocol to allow the target to indicate when
   the names must be sent - again more complications. 

To round up, I prefer Option (A).  These are just names and not
passwords, so the security risks are minimal.  Are we trying to 
protect against traffic analysis ?

-Sandeep

> >
> > Steve Senum <ssenum@cisco.com>@ece.cmu.edu on 29-08-2001 23:59:36
> >
> > Please respond to Steve Senum <ssenum@cisco.com>
> >
> > Sent by:  owner-ips@ece.cmu.edu
> >
> >
> > To:   ietf-ips <ips@ece.cmu.edu>
> > cc:
> > Subject:  Re: iSCSI - Change - Login/Text commands with the binary stage
> >       code
> >
> >
> >
> > Julian,
> >
> > A couple of ideas from Matthew Burbridge & Co.'s
> > login proposal that has generated some interest here:
> >
> > 1. Removal of partial login response.  Is it still needed?
> >
> > 2. Requiring Initiator and (if not a discovery session)
> >    Target names on login command, so they are always
> >    available if needed by the initial phase.
> >
> > Comments?
> >
> > Regards,
> > Steve Senum
> >
> >
> >
> >


From owner-ips@ece.cmu.edu  Thu Aug 30 14:03:11 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23690
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 14:03:11 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7UGjFO23609
	for ips-outgoing; Thu, 30 Aug 2001 12:45:15 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e32.bld.us.ibm.com (e32.co.us.ibm.com [32.97.110.130])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7UGjDP23601
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 12:45:13 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e32.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA11596;
	Thu, 30 Aug 2001 12:43:00 -0400
Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7UGhuD239488;
	Thu, 30 Aug 2001 10:43:56 -0600
X-Priority: 1 (High)
Importance: Normal
Subject: Re: ISCSI: User authentication vs. Machine Authentication for iSC SI
To: Stephen Bailey <steph@cs.uchicago.edu>
Cc: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OF761F95F7.844FE06F-ON88256AB8.00574D6B@boulder.ibm.com>
From: "John Hufferd" <hufferd@us.ibm.com>
Date: Thu, 30 Aug 2001 09:43:19 -0700
X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at
 08/30/2001 10:43:56 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Comments in line below.


.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com


Stephen Bailey <steph@cs.uchicago.edu>@ece.cmu.edu on 08/30/2001 06:50:23
AM

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  Re: ISCSI: User authentication vs. Machine Authentication for iSC
      SI



> I believe this is the "iSCSI Name" (formerly WWUI).

I guess I was unclear.  I consider the iSCSI name to BE the `user
name' in this discussion.

I was not suggesting that we introduce any additional identities.  I
was only suggesting it might be a mistake to slavishly equate identity
with OS instance.  I don't THINK we're in any risk of doing that.
Somebody please shout if they think we are, or if they think we should
be.

/*Huf**
The new Name (UserID) is exactly what was implied at the meeting in Irvine.
The reason that came in was that it was stated that the iSCSI
Initiator Node Name would not Fit into the installation's normal
Authorization
process (which today is used to Authenticate USERS), such as the
Microsoft Active Directory.
**Huf*/


If a user process wants to initiate its own iSCSI connection to a
target, there are two options:
  1) the host OS gives the process ITS identity (& credentials)
  2) the user process uses its own unique identity (obtained through
     some mechanism we're not describing or discussing, e.g. from the
     storage domain administrator).

1) would be the case if you were using SCSI passthru to an iSCSI
driver.  In this situation, it's still really the OS that's doing the
interaction as a proxy for the user.  The OS can ensure (or not) that
its identity isn't being abused.  The OS could also give its identity
to a user-mode iSCSI sockets client through a securable interface.
The OS should never completely freely give away its identity (e.g. to
an untrusted user process), unless it doesn't care how it's used.

/*Huff**
A number of us, I am sure, think this is a very poor direction for an
implementation. But you are correct. If an OS passes off its identity
to a User Process, a User Process could masquerade as a valid OS and
send its own stuff via a normal TCP/IP Sockets. Since this application
would not be able to use the iSCSI HW HBAs, that most Servers will be
dependent upon to provide the approprate performance and lower the
TCP/IP processing overhead, I believe that this approach will probably
not be an important issue for legitimate applications.
**Huff*/

2) would be the case if jane helpful-programmer (or joe script-kiddy)
wrote a user-mode iSCSI initiator using sockets for whatever purpose.

/*Huff**
This is one of the problems we must protect from. Since an OS (iSCSI
Initiator Node Name can be validated, we must make sure that the
Authorization approach prevents this from happening.  As I stated
above I can not believe that a user mode application (other then in
development) that had to add all its own PDU structures etc.
would be a valid application (especially since it could NOT use any
iSCSI offload HW that might be in place.)
So I believe we must consider such a potential application as
probably a rouge application and do nothing to help this, and work
to prevent it.
**Huff*/

Perhaps I'm covering old ground that was already worked out at the
interim meeting.  If so, I apologize.

/*Huff**
This is just a direction (thread) that got started, based on a
misunderstanding
of what was meant when the concept of UserID came up as part of
authentication during the Irvine meeting.
The important issue is, can we make the iSCSI Initiator Node Name be used
as the UserID.  A separate UserID is only needed if you use an
existing Authentication infrastructure that does not permit the
use of the eui or iqn type names.  This is where we need to focus
and see if we fully understand the problems and the impacts of
such approaches.
**Huff*/


Steph





From owner-ips@ece.cmu.edu  Thu Aug 30 14:17:39 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24323
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 14:17:39 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7UH6Uh24876
	for ips-outgoing; Thu, 30 Aug 2001 13:06:30 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from bramg1.net.external.hp.com (bramg1.net.external.hp.com [192.6.126.73])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7UH6RP24869
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 13:06:28 -0400 (EDT)
Received: from quasit.br.itc.hp.com (quasit.br.itc.hp.com [15.145.8.135])
	by bramg1.net.external.hp.com (Postfix) with ESMTP
	id CB5AA85; Thu, 30 Aug 2001 19:06:50 +0200 (METDST)
Received: from loddon.br.itc.hp.com (loddon.br.itc.hp.com [15.145.8.166])
	by quasit.br.itc.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id SAA11858;
	Thu, 30 Aug 2001 18:06:24 +0100 (BST)
Received: from 15.145.8.166 by loddon.br.itc.hp.com (InterScan E-Mail VirusWall NT); Thu, 30 Aug 2001 18:06:24 +0100 (GMT Daylight Time)
Received: by loddon.br.itc.hp.com with Internet Mail Service (5.5.2653.19)
	id <RXW56Z1C>; Thu, 30 Aug 2001 18:06:24 +0100
Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC101E7A86F@dickens.bri.hp.com>
From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <matthew_burbridge@hp.com>
To: "'Steve Senum'" <ssenum@cisco.com>, ietf-ips <ips@ece.cmu.edu>
Subject: RE: iSCSI - Change - Login/Text commands with the binary stage co
	de-  IMPORTANT PROPOSAL
Date: Thu, 30 Aug 2001 18:06:23 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Hi Steve,

The only problem with having one login command and one login response
separated by zero or more text PDUs is that the target must respond with
the version number (max and active) before continuing with the login 
phase.  I missed this in the proposal that Bob, Marj, and myself put
forward.

Cheers

Matthew

-----Original Message-----
From: Steve Senum [mailto:ssenum@cisco.com]
Sent: Thursday, August 30, 2001 5:13 PM
To: ietf-ips
Subject: Re: iSCSI - Change - Login/Text commands with the binary stage
code- IMPORTANT PROPOSAL


Julian,

> The situation is not symmetric anyway. If we keep the final login we have
a
> text request answered by
> a Login request.
> 
> I think that considering that text & login are equivalent during login if
> you care for complete symmetry you may want to use only login during the
> login phase.
> 
> This way we could even remove the phases field from the text commands.
> 
> So again the proposal is USE ONLY LOGIN during Login (the reason I did no
> put initially is now history anyway).
> 
> COMMENTS?

Ayman and I would prefer having only one login command and one login
response, seperated by zero or more text response/text command
pairs (like in Matthew Burbridge & Co.'s proposal).

Second choice would be leaving the spec as is, with the partial
login response.

Regards,
Steve Senum


From owner-ips@ece.cmu.edu  Thu Aug 30 14:18:09 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24341
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 14:18:09 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7UGmP323782
	for ips-outgoing; Thu, 30 Aug 2001 12:48:25 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7UGmOP23778
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 12:48:24 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-68-173.cisco.com [161.44.68.173]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA22341 for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 12:48:15 -0400 (EDT)
Message-ID: <3B8E6E44.A8683640@cisco.com>
Date: Thu, 30 Aug 2001 11:48:04 -0500
From: Steve Senum <ssenum@cisco.com>
X-Mailer: Mozilla 4.73 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-ips <ips@ece.cmu.edu>
Subject: Re: iSCSI - Change - Login/Text commands with the binary stage code
References: <OFCDF400C1.1FFD51D6-ONC2256AB7.0076E777@telaviv.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Julian,

> Implement and use are different terms. An administrator might set it up not
> to use security under specific conditions.

I understand that.  Still, the only situation I would
consider it valid for the initiator to skip the
SecurityNegotiation stage is if it intended to send out:

I-> AuthMethod:none
    HeaderDigest:none
    DataDigest:none

Otherwise it should give the target the chance to
negotiate these options.

Regards,
Steve Senum


From owner-ips@ece.cmu.edu  Thu Aug 30 14:22:46 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24416
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 14:22:45 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7UGox723917
	for ips-outgoing; Thu, 30 Aug 2001 12:50:59 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from esply02.cnt.com (mailhost.cnt.com [139.93.128.21])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7UGowP23912
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 12:50:58 -0400 (EDT)
Received: by esply02.cnt.com with Internet Mail Service (5.5.2653.19)
	id <RBQ6DQCR>; Thu, 30 Aug 2001 11:50:49 -0500
Message-ID: <3C7122FAF06DD5118ED60050047336482630F1@esply01.cnt.com>
From: Michael Schoberg <michael_schoberg@cnt.com>
To: ips@ece.cmu.edu
Subject: RE: iSCSI - Change - Login/Text commands with the binary stage co
	de
Date: Thu, 30 Aug 2001 11:47:54 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

I'm not sure if this has been suggested, but one possible solution to the
login state confusion could be to eliminate this dual master relationship
between the iSCSI initiator logging in and the iSCSI target.  When the iSCSI
initiator attempts login, it could send an empty (no text options) message
and let the iSCSI Target send back the options it supports as either empty
(InitiatorName=) or with the default (MaxConnections=8).  The login would
proceed until the iSCSI target sends a completion message.  This would
remove the ambiguity of the order in which login variables are presented.


From owner-ips@ece.cmu.edu  Thu Aug 30 15:12:32 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25855
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 15:12:24 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7UH04024468
	for ips-outgoing; Thu, 30 Aug 2001 13:00:04 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7UGxxP24463
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 12:59:59 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id SAA48284
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 18:59:52 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7UGStu167564
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 18:28:55 +0200
Importance: Normal
Subject: iSCSI - proposed login phase change
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFFBDCC138.3132FFBC-ONC2256AB8.0057B5EA@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Thu, 30 Aug 2001 19:28:13 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 30/08/2001 19:28:55
MIME-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=C2256AB80057B5EA8f9e8a93df938690918cC2256AB80057B5EA"
Content-Disposition: inline
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

--0__=C2256AB80057B5EA8f9e8a93df938690918cC2256AB80057B5EA
Content-type: text/plain; charset=us-ascii

As I mentioned in an earlier note it is possible to further rationalize
login by implementing it exclusively with Login requests and responses.

This will simplify login handling and text negotiation.

A first draft of the changed sections is attached.

Matthew Burbridge and I are also trying to reduce the 2 stage field to one
stage field.
Not clear that this is feasible or desirable but we keep trying.

Please comment.

Julo

(See attached file: Login-changes.txt)

--0__=C2256AB80057B5EA8f9e8a93df938690918cC2256AB80057B5EA
Content-type: text/plain; 
	name="Login-changes.txt"
Content-Transfer-Encoding: base64

MS4yLjMgaVNDU0kgTG9naW4NCg0KVGhlIHB1cnBvc2Ugb2YgdGhlIGlTQ1NJIGxvZ2luIGlzIHRv
IGVuYWJsZSBhIFRDUCBjb25uZWN0aW9uIGZvciBpU0NTSSB1c2UsIGF1dGhlbnRpY2F0ZSB0aGUg
cGFydGllcywgbmVnb3RpYXRlIHRoZSBzZXNzaW9uJ3MgcGFyYW1ldGVycywgb3BlbiBhIHNlY3Vy
aXR5IGFzc29jaWF0aW9uIHByb3RvY29sLCBhbmQgbWFyayB0aGUgY29ubmVjdGlvbiBhcyBiZWxv
bmdpbmcgdG8gYW4gaVNDU0kgc2Vzc2lvbi4NCiANCkEgc2Vzc2lvbiBpcyB1c2VkIHRvIGlkZW50
aWZ5IHRvIGEgdGFyZ2V0IGFsbCB0aGUgY29ubmVjdGlvbnMgd2l0aCBhIGdpdmVuIGluaXRpYXRv
ciB0aGF0IGJlbG9uZyB0byB0aGUgc2FtZSBJX1QgbmV4dXMgKFNlZSAxLjUuMiBmb3IgbW9yZSBk
ZXRhaWxzIG9uIGhvdyBhIHNlc3Npb24gcmVsYXRlcyB0byBhbiBJX1QgbmV4dXMpLg0KDQpUaGUg
dGFyZ2V0cyBsaXN0ZW4gb24gYSB3ZWxsLWtub3duIFRDUCBwb3J0IG9yIG90aGVyIFRDUCBwb3J0
IGZvciBpbmNvbWluZyBjb25uZWN0aW9ucy4gVGhlIGluaXRpYXRvciBiZWdpbnMgdGhlIGxvZ2lu
IHByb2Nlc3MgYnkgY29ubmVjdGluZyB0byB0aGF0IHdlbGwta25vd24gVENQIHBvcnQuIA0KDQpB
cyBwYXJ0IG9mIHRoZSBsb2dpbiBwcm9jZXNzLCB0aGUgaW5pdGlhdG9yIGFuZCB0YXJnZXQgTUFZ
IHdpc2ggdG8gYXV0aGVudGljYXRlIGVhY2ggb3RoZXIgYW5kIHNldCBhIHNlY3VyaXR5IGFzc29j
aWF0aW9uIHByb3RvY29sIGZvciB0aGUgc2Vzc2lvbi4gVGhpcyBjYW4gb2NjdXIgaW4gbWFueSBk
aWZmZXJlbnQgd2F5cyBhbmQgaXMgc3ViamVjdCB0byBuZWdvdGlhdGlvbi4gDQoNClNlY3VyaXR5
IGFzc29jaWF0aW9ucyBlc3RhYmxpc2hlZCBiZWZvcmUgdGhlIExvZ2luIHJlcXVlc3QgYXJlIG91
dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQgYWx0aG91Z2ggdGhleSBtYXkgcmVhbGl6
ZSBhIHJlbGF0ZWQgZnVuY3Rpb24gKGUuZy4sIGVzdGFibGlzaCBhIElQc2VjIHR1bm5lbCkuIA0K
DQpUaGUgaVNDU0kgTG9naW4gUGhhc2UgaXMgY2FycmllZCB0aHJvdWdoIExvZ2luIHJlcXVlc3Rz
IGFuZCByZXNwb25zZXMuIE9uY2Ugc3VpdGFibGUgYXV0aGVudGljYXRpb24gaGFzIG9jY3VycmVk
IGFuZCBvcGVyYXRpb25hbCBwYXJhbWV0ZXJzIGhhdmUgYmVlbiBzZXQgdGhlIGluaXRpYXRvciBt
YXkgc3RhcnQgdG8gc2VuZCBTQ1NJIGNvbW1hbmRzLiBIb3cgdGhlIHRhcmdldCBjaG9vc2VzIHRv
IGF1dGhvcml6ZSBhbiBpbml0aWF0b3IgaXMgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIGRvY3Vt
ZW50LiBBIG1vcmUgZGV0YWlsZWQgZGVzY3JpcHRpb24gb2YgdGhlIExvZ2luIFBoYXNlIGNhbiBi
ZSBmb3VuZCBpbiBjaGFwdGVyIDQuDQoNCg0KVGhlIGxvZ2luIFBEVSBpbmNsdWRlcyBhIHNlc3Np
b24gSUQgdGhhdCBpcyBjb21wb3NlZCBvZiBhbiBpbml0aWF0b3IgcGFydCBJU0lEIGFuZCBhIHRh
cmdldCBwYXJ0IFRTSUQuIEZvciBhIG5ldyBzZXNzaW9uLCB0aGUgVFNJRCBpcyBudWxsLiBBcyBw
YXJ0IG9mIHRoZSByZXNwb25zZSwgdGhlIHRhcmdldCBnZW5lcmF0ZXMgYSBUU0lELiANCg0KRHVy
aW5nIHNlc3Npb24gZXN0YWJsaXNobWVudCwgdGhlIHRhcmdldCBpZGVudGlmaWVzIHRoZSBTQ1NJ
IGluaXRpYXRvciBwb3J0ICh0aGUgIkkiIGluIHRoZSAiSV9UIG5leHVzIikgdGhyb3VnaCB0aGUg
dmFsdWUgcGFpciBJbml0aWF0b3JOYW1lIGFuZCBJU0lEIChJbml0aWF0b3JOYW1lIGlzIGRlc2Ny
aWJlZCBsYXRlciBpbiB0aGlzIHBhcnQpLiAgQW55IHN0YXRlIGFzc29jaWF0ZWQgd2l0aCB0aGUg
U0NTSSBpbml0aWF0b3IgcG9ydCB0aGF0IGlzIHBlcnNpc3RlbnQgYWNjb3JkaW5nIHRvIHRoZSBT
Q1NJIHN0YW5kYXJkcyAoZS5nLiwgcGVyc2lzdGVudCByZXNlcnZhdGlvbnMpIGlzIGFzc29jaWF0
ZWQgd2l0aCB0aGUgU0NTSSBpbml0aWF0b3IgcG9ydCBiYXNlZCBvbiB0aGlzIGlkZW50aXR5LiAg
QW55IHN0YXRlIGFzc29jaWF0ZWQgd2l0aCB0aGUgU0NTSSB0YXJnZXQgcG9ydCAodGhlICJUIiBp
biB0aGUgIklfVCBuZXh1cyIpIGlzIGlkZW50aWZpZWQgZXh0ZXJuYWxseSBieSB0aGUgVGFyZ2V0
TmFtZSBhbmQgcG9ydGFsIGdyb3VwIHRhZyAoc2VlIDEuNS4xKSBhbmQgaW50ZXJuYWxseSBpbiBh
biBpbXBsZW1lbnRhdGlvbiBkZXBlbmRlbnQgd2F5LiBBcyBJU0lEIGlzIHVzZWQgdG8gaWRlbnRp
ZnkgcGVyc2lzdGVudCBzdGF0ZSBpdCBpcyBzdWJqZWN0IHRvIHJldXNlIHJlc3RyaWN0aW9ucyAo
c2VlIDEuNS4zKS4NCg0KQmVmb3JlIGZ1bGwgZmVhdHVyZSBwaGFzZSBpcyBlc3RhYmxpc2hlZCwg
b25seSBMb2dpbiBQRFVzIGFyZSBhbGxvd2VkLiBBbnkgb3RoZXIgUERVLCB3aGVuIHJlY2VpdmVk
IGF0IGluaXRpYXRvciBvciB0YXJnZXQsIGlzIGEgcHJvdG9jb2wgZXJyb3IgYW5kIE1VU1QgcmVz
dWx0IGluIHRoZSBjb25uZWN0aW9uIGJlaW5nIHRlcm1pbmF0ZWQuDQoNClNvbWUgdGV4dCBjb21t
YW5kIHBhcmFtZXRlcnMgYXJlIGFsc28gYWxsb3dlZCBvbmx5IGluIGZ1bGwgZmVhdHVyZSBwaGFz
ZSAoZS5nLiwgU2VuZFRhcmdldHMpLiANCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoy
LjEyIExvZ2luIFJlcXVlc3QNCg0KQWZ0ZXIgZXN0YWJsaXNoaW5nIGEgVENQIGNvbm5lY3Rpb24g
YmV0d2VlbiBhbiBpbml0aWF0b3IgYW5kIGEgdGFyZ2V0LCB0aGUgaW5pdGlhdG9yIE1VU1Qgc3Rh
cnQgYSBMb2dpbiBwaGFzZSB0byBnYWluIGZ1cnRoZXIgYWNjZXNzIHRvIHRoZSB0YXJnZXQncyBy
ZXNvdXJjZXMuIA0KDQpUaGUgTG9naW4gUGhhc2UgKHNlZSBjaGFwdGVyIDQpIGNvbnNpc3RzIG9m
IGEgc2VxdWVuY2Ugb2YgTG9naW4gcmVxdWVzdHMgYW5kIHJlc3BvbnNlcykgdGhhdCBjYXJyeSB0
aGUgc2FtZSBJbml0aWF0b3IgVGFzayBUYWcuDQoNCg0KDQoNCkJ5dGUgLyAgICAwICAgICAgIHwg
ICAgICAgMSAgICAgICB8ICAgICAgIDIgICAgICAgfCAgICAgICAzICAgICAgIHwNCiAgIC8gICAg
ICAgICAgICAgIHwgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAg
IHwNCiAgfDcgNiA1IDQgMyAyIDEgMHw3IDYgNSA0IDMgMiAxIDB8NyA2IDUgNCAzIDIgMSAwfDcg
NiA1IDQgMyAyIDEgMHwNCiAgKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0t
LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSsNCiAwfFh8SXwgMHgwMyAgICAgIHxGfEMgMCAwfCBD
TnhTRyB8IFZlcnNpb24tbWF4ICAgfCBWZXJzaW9uLW1pbiAgIHwNCiAgKy0tLS0tLS0tLS0tLS0t
LSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSsNCiA0fCBS
ZXNlcnZlZCAgICAgIHwgRGF0YVNlZ21lbnRMZW5ndGggICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIHwNCiAgKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0t
Ky0tLS0tLS0tLS0tLS0tLSsNCiA4fCBDSUQgICAgICAgICAgICAgICAgICAgICAgICAgICB8IFJl
c2VydmVkICAgICAgICAgICAgICAgICAgICAgIHwNCiAgKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0t
LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSsNCjEyfCBJU0lEICAgICAg
ICAgICAgICAgICAgICAgICAgICB8VFNJRCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAg
Ky0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0t
LS0tLS0tLSsNCjE2fCBJbml0aWF0b3IgVGFzayBUYWcgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIHwNCiAgKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0r
LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSsNCjIwfCBSZXNlcnZlZCAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgKy0tLS0tLS0t
LS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSsN
CjI0fCBDbWRTTiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHwNCiAgKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0t
LS0tLS0tKy0tLS0tLS0tLS0tLS0tLSsNCjI4fCBFeHBTdGF0U04gICBvciAgIFJlc2VydmVkICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgKy0tLS0tLS0tLS0tLS0tLSst
LS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSsNCjMyLyBSZXNl
cnZlZCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IC8NCiArLyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIC8NCiAgKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0t
LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSsNCjQ4LyBEYXRhU2VnbWVudCAtIExvZ2luIFBhcmFt
ZXRlcnMgaW4gVGV4dCBDb21tYW5kIEZvcm1hdCAgICAgICAgIC8NCiArLyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC8NCiAgKy0t
LS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t
LS0tLSsNCg0KMi4xMi4xIFggLSBSZXN0YXJ0IENvbm5lY3Rpb24vU2Vzc2lvbg0KDQpJZiB0aGlz
IGJpdCBpcyBzZXQgdG8gMSB0aGVuIHRoaXMgY29tbWFuZCBpcyBhbiBhdHRlbXB0IHRvIHJlaW5z
dGF0ZSBhIGZhaWxlZCBjb25uZWN0aW9uIG9yIGEgZmFpbGVkIHNlc3Npb24uIA0KDQpJZiBUU0lE
IGlzIG5vdCAwIHRoZW4gdGhpcyBpcyBhIGNvbm5lY3Rpb24gcmVzdGFydC4gQ0lEIGRvZXMgbm90
IGNoYW5nZSBhbmQgdGhpcyBjb21tYW5kIHBlcmZvcm1zIGZpcnN0IHRoZSBsb2dvdXQgZnVuY3Rp
b24gb2YgdGhlIG9sZCBjb25uZWN0aW9uIGlmIGFuIGV4cGxpY2l0IGxvZ291dCB3YXMgbm90IHBl
cmZvcm1lZCBlYXJsaWVyLiBJbiBzZXNzaW9ucyB3aXRoIGEgc2luZ2xlIGNvbm5lY3Rpb24sIHRo
aXMgbWF5IGltcGx5IHRoZSBvcGVuaW5nIG9mIGEgc2Vjb25kIGNvbm5lY3Rpb24gd2l0aCB0aGUg
c29sZSBwdXJwb3NlIG9mIGNsZWFuaW5nLXVwIHRoZSBmaXJzdC4gVGFyZ2V0cyBzaG91bGQgc3Vw
cG9ydCBvcGVuaW5nIGEgc2Vjb25kIGNvbm5lY3Rpb24gZXZlbiB3aGVuIG5vdCBzdXBwb3J0aW5n
IG11bHRpcGxlIGNvbm5lY3Rpb25zIGluIGZ1bGwgZmVhdHVyZSBwaGFzZS4gIEEgcmVzdGFydCBs
b2dpbiBpbmRpY2F0ZXMgdG8gdGhlIHRhcmdldCB0aGF0IGNvbW1hbmRzIG1heSBiZSBtaXNzaW5n
IGFuZCB0aGVyZWZvcmUgaXQgTVVTVCBiZSBpc3N1ZWQgYXMgYW4gaW1tZWRpYXRlIGNvbW1hbmQu
DQoNCklmIFRTSUQgaXMgMCB0aGVuIHRoaXMgaXMgYSBzZXNzaW9uIHJlc3RhcnQuIFRoZSBvbGQg
c2Vzc2lvbiB3aXRoIHRoZSBzYW1lIGluaXRpYXRvciBhbmQgSVNJRCBpcyB0ZXJtaW5hdGVkIGFu
ZCBhIG5ldyBzZXNzaW9uIGlzIGNyZWF0ZWQuIA0KDQpBIHNlc3Npb24gcmVzdGFydCBNVVNUIGJl
IGlzc3VlZCBPTkxZIGlmIGFuIG9sZCBzZXNzaW9uIGV4aXN0cy4NCg0KVGhlIFggYml0IE1BWSBi
ZSBzZXQgb25lIE9OTFkgb24gdGhlIGZpcnN0IHJlcXVlc3Qgb2YgdGhlIExvZ2luIHBoYXNlLg0K
DQoyLjEyLjIgSSAtIEltbWVkaWF0ZSANCg0KTG9naW4gU0hPVUxEIGJlIGlzc3VlZCBhcyBhbiBp
bW1lZGlhdGUgcmVxdWVzdCAoST0xKS4NCg0KMi4xMi4zIEYgKEZpbmFsKSBCaXQNCg0KSWYgc2V0
IHRvIDEgaW5kaWNhdGVzIHRoYXQgdGhlIGluaXRpYXRvciBoYXMgbm8gbW9yZSBwYXJhbWV0ZXJz
IHRvIHNldC4NCg0KMi4xMi40IEMgKENvbnRpbnVhdGlvbikgQml0DQoNCklmIHNldCB0byAxIGlu
ZGljYXRlcyB0aGF0IHRoaXMgaXMgbm90IHRoZSBmaXJzdCBMb2dpbiByZXF1ZXN0IGluIHRoZSBM
b2dpbiBQaGFzZQ0KDQoyLjEyLjUgQ054U0cNCg0KVGhyb3VnaCB0aGlzIGZpZWxkLCBjYWxsZWQg
Q3VycmVudC1OZXh0IFN0YWdlIChDTnhTRyksIHRoZSBMb2dpbiBuZWdvdGlhdGlvbiBjb21tYW5k
cyBhbmQgcmVzcG9uc2VzIGFyZSBhc3NvY2lhdGVkIHdpdGggYSBzcGVjaWZpYyBzdGFnZSBpbiB0
aGUgc2Vzc2lvbiAoU2VjdXJpdHlOZWdvdGlhdGlvbiwgTG9naW5PcGVyYXRpb25hbE5lZ290aWF0
aW9uLCBGdWxsUGhhc2VPcGVyYXRpb25hbE5lZ290aWF0aW9ucykgYW5kIG1heSBpbmRpY2F0ZSB0
aGUgbmV4dCBzdGFnZSB0aGV5IHdhbnQgdG8gbW92ZSB0byAoc2VlIGNoYXB0ZXIgNCkuDQogIA0K
VGhlIGN1cnJlbnQgc3RhZ2UgaXMgY29kZWQgaW4gYml0cyAwLTEgYW5kIHRoZSBuZXh0IHN0YWdl
IGluIGJpdHMgMi0zLiBUaGUgbmV4dCBzdGFnZSB2YWx1ZSBpcyB2YWxpZCBvbmx5IHdoZW4gdGhl
IEYgYml0IGlzIDEgYW5kIGNhbiBiZSBpZ25vcmVkIG90aGVyd2lzZS4NCg0KVGhlIHN0YWdlIGNv
ZGVzIGFyZToNCg0KLSAwIC0gU2VjdXJpdHlOZWdvdGlhdGlvbg0KLSAxIC0gTG9naW5PcGVyYXRp
b25hbE5lZ290aWF0aW9uDQotIDMgLSBGdWxsRmVhdHVyZVBoYXNlDQogDQoyLjEyLjYgVmVyc2lv
bi1tYXgNCg0KTWF4aW11bSBWZXJzaW9uIG51bWJlciBzdXBwb3J0ZWQuDQoNCkFsbCBMb2dpbiBy
ZXF1ZXN0cyB3aXRoaW4gdGhlIExvZ2luIHBoYXNlIE1VU1QgY2FycnkgdGhlIHNhbWUgVmVyc2lv
bi1tYXguDQoNClRoZSB0YXJnZXQgTVVTVCB1c2UgdGhlIHZhbHVlIHByZXNlbnRlZCB3aXRoIHRo
ZSBsb2dpbiByZXF1ZXN0IHdpdGggQz0wIGFuZCBNQVkgY2hlY2sgdGhlIHZhbHVlIHdoZW4gQz0x
Lg0KDQoyLjEyLjcgVmVyc2lvbi1taW4NCg0KTWluaW11bSBWZXJzaW9uIHN1cHBvcnRlZA0KVGhl
IHZlcnNpb24gbnVtYmVyIG9mIHRoZSBjdXJyZW50IGRyYWZ0IGlzIDB4Mi4NCg0KQWxsIExvZ2lu
IHJlcXVlc3RzIHdpdGhpbiB0aGUgTG9naW4gcGhhc2UgTVVTVCBjYXJyeSB0aGUgc2FtZSBWZXJz
aW9uLW1pbi4NCg0KVGhlIHRhcmdldCBNVVNUIHVzZSB0aGUgdmFsdWUgcHJlc2VudGVkIHdpdGgg
dGhlIGxvZ2luIHJlcXVlc3Qgd2l0aCBDPTAgYW5kIE1BWSBjaGVjayB0aGUgdmFsdWUgd2hlbiBD
PTEuDQoNCjIuMTIuOCBDb25uZWN0aW9uIElEIC0gQ0lEDQoNClRoaXMgaXMgYSB1bmlxdWUgSUQg
Zm9yIHRoaXMgY29ubmVjdGlvbiB3aXRoaW4gdGhlIHNlc3Npb24uDQoNCkFsbCBMb2dpbiByZXF1
ZXN0cyB3aXRoaW4gdGhlIExvZ2luIHBoYXNlIE1VU1QgY2FycnkgdGhlIHNhbWUgQ0lELg0KDQpU
aGUgdGFyZ2V0IE1VU1QgdXNlIHRoZSB2YWx1ZSBwcmVzZW50ZWQgd2l0aCB0aGUgbG9naW4gcmVx
dWVzdCB3aXRoIEM9MCBhbmQgTUFZIGNoZWNrIHRoZSB2YWx1ZSB3aGVuIEM9MS4NCg0KMi4xMi45
IElTSUQNCg0KVGhpcyBpcyBhbiBpbml0aWF0b3ItZGVmaW5lZCBzZXNzaW9uLWlkZW50aWZpZXIu
ICBJdCBNVVNUIGJlIHRoZSBzYW1lIGZvciBhbGwgY29ubmVjdGlvbnMgd2l0aGluIGEgc2Vzc2lv
bi4gIEEgU0NTSSBpbml0aWF0b3IgcG9ydCBpcyB1bmlxdWVseSBpZGVudGlmaWVkIGJ5IHRoZSB2
YWx1ZSBwYWlyIChJbml0aWF0b3JOYW1lLCBJU0lEKS4NCg0KV2hlbiBhIHRhcmdldCBkZXRlY3Rz
IGFuIGF0dGVtcHQgdG8gb3BlbiBhIG5ldyBzZXNzaW9uIGJ5IHRoZSBzYW1lIFNDU0kgaW5pdGlh
dG9yIHBvcnQgKHNhbWUgSW5pdGlhdG9yTmFtZSBhbmQgSVNJRCkgdG8gdGhlIHNhbWUgdGFyZ2V0
IHBvcnRhbCBncm91cCBpdCBNVVNUIGNoZWNrIGlmIHRoZSBvbGQgc2Vzc2lvbiBpcyBzdGlsbCBh
Y3RpdmUuICBJZiBpdCBpcyBub3QgYWN0aXZlIGFuZCB0aGVuIHRoZSBvbGQtc2Vzc2lvbiBtdXN0
IGJlIHJlc2V0IGJ5IHRoZSB0YXJnZXQgYW5kIGEgbmV3IHNlc3Npb24gaXMgZXN0YWJsaXNoZWQu
IE90aGVyd2lzZSwgdGhlIExvZ2luIE1VU1QgYmUgdGVybWluYXRlZCB3aXRoIGEgTG9naW4gUmVz
cG9uc2Ugb2YgIlNlc3Npb24gYWxyZWFkeSBvcGVuIHdpdGggdGhpcyBpbml0aWF0b3IiLg0KDQpB
bGwgTG9naW4gcmVxdWVzdHMgd2l0aGluIHRoZSBMb2dpbiBwaGFzZSBNVVNUIGNhcnJ5IHRoZSBz
YW1lIElTSUQuDQoNClRoZSB0YXJnZXQgTVVTVCB1c2UgdGhlIHZhbHVlIHByZXNlbnRlZCB3aXRo
IHRoZSBsb2dpbiByZXF1ZXN0IHdpdGggQz0wIGFuZCBNQVkgY2hlY2sgdGhlIHZhbHVlIHdoZW4g
Qz0xLg0KDQoyLjEyLjEwIENtZFNODQoNCkNtZFNOIGlzIGVpdGhlciB0aGUgaW5pdGlhbCBjb21t
YW5kIHNlcXVlbmNlIG51bWJlciBvZiBhIHNlc3Npb24gKGZvciB0aGUgZmlyc3QgTG9naW4gb2Yg
YSBzZXNzaW9uIC0gdGhlICJsZWFkaW5nIiBsb2dpbikgb3IgdGhlIGNvbW1hbmQgc2VxdWVuY2Ug
bnVtYmVyIGluIHRoZSBjb21tYW5kIHN0cmVhbSAoZS5nLiwgaWYgdGhlIGxlYWRpbmcgbG9naW4g
Y2FycmllcyB0aGUgQ21kU04gMTIzIHRoZSBuZXh0IGNvbW1hbmQgY2FycmllcyB0aGUgbnVtYmVy
IDEyNCBldGMuKS4gDQoNCjIuMTIuMTEgRXhwU3RhdFNODQoNClRoaXMgaXMgRXhwU3RhdFNOIGZv
ciB0aGUgb2xkIGNvbm5lY3Rpb24uDQoNClRoaXMgZmllbGQgaXMgdmFsaWQgb25seSBpZiB0aGUg
TG9naW4gcmVxdWVzdCByZXN0YXJ0cyBhIGNvbm5lY3Rpb24gKGkuZS4sIFggYml0IGlzIDEgYW5k
IFRTSUQgaXMgbm90IHplcm8pLg0KDQoNCjIuMTIuMTIgTG9naW4gUGFyYW1ldGVycw0KDQpUaGUg
aW5pdGlhdG9yIE1BWSBwcm92aWRlIHNvbWUgYmFzaWMgcGFyYW1ldGVycyBpbiBvcmRlciB0byBl
bmFibGUgdGhlIHRhcmdldCB0byBkZXRlcm1pbmUgaWYgdGhlIGluaXRpYXRvciBtYXkgdXNlIHRo
ZSB0YXJnZXQncyByZXNvdXJjZXMgYW5kIHRoZSBpbml0aWFsIHRleHQgcGFyYW1ldGVycyBmb3Ig
dGhlIHNlY3VyaXR5IGV4Y2hhbmdlLiAgVGhlIGZvcm1hdCBvZiB0aGUgcGFyYW1ldGVycyBpcyBh
cyBzcGVjaWZpZWQgZm9yIHRoZSBUZXh0IENvbW1hbmQuICAgIEtleXMgYW5kIHRoZWlyIGV4cGxh
bmF0aW9ucyBhcmUgbGlzdGVkIGluIHRoZSBBcHBlbmRpeGVzLg0KDQoNCiANCg0KMi4xMyBMb2dp
biBSZXNwb25zZQ0KDQpUaGUgTG9naW4gUmVzcG9uc2UgaW5kaWNhdGVzIHRoZSBwcm9ncmVzcyBh
bmQvb3IgZW5kIG9mIHRoZSBsb2dpbiBwaGFzZS4gIE5vdGUgdGhhdCBhZnRlciBzZWN1cml0eSBp
cyBlc3RhYmxpc2hlZCwgdGhlIGxvZ2luIHJlc3BvbnNlIGlzIGF1dGhlbnRpY2F0ZWQuDQoNCg0K
Qnl0ZSAvICAgIDAgICAgICAgfCAgICAgICAxICAgICAgIHwgICAgICAgMiAgICAgICB8ICAgICAg
IDMgICAgICAgfA0KICAgLyAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAgICAg
ICAgICB8ICAgICAgICAgICAgICAgfA0KICB8NyA2IDUgNCAzIDIgMSAwfDcgNiA1IDQgMyAyIDEg
MHw3IDYgNSA0IDMgMiAxIDB8NyA2IDUgNCAzIDIgMSAwfA0KICArLS0tLS0tLS0tLS0tLS0tKy0t
LS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KIDB8MXwxfCAw
eDIzICAgICAgfEZ8MCAwIDB8IENOeFNHIHwgVmVyc2lvbi1tYXggICB8IFZlcnNpb24tYWN0aXZl
fA0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0t
LS0tLS0tLS0tLS0tKw0KIDR8IFJlc2VydmVkICAgICAgfCBEYXRhU2VnbWVudExlbmd0aCAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgfA0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t
LS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KIDh8IFJlc2VydmVkICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICArLS0t
LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t
LS0tKw0KMTJ8IElTSUQgICAgICAgICAgICAgICAgICAgICAgICAgIHxUU0lEICAgICAgICAgICAg
ICAgICAgICAgICAgICAgfA0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0t
LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KMTZ8IEluaXRpYXRvciBUYXNrIFRhZyAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICArLS0tLS0tLS0tLS0t
LS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KMjB8
IFJlc2VydmVkICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgfA0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t
LS0rLS0tLS0tLS0tLS0tLS0tKw0KMjR8IFN0YXRTTiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0t
LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KMjh8IEV4cENtZFNO
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0K
ICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0t
LS0tLS0tLS0tKw0KMzJ8IE1heENtZFNOICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgfA0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t
LSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KMzZ8IFN0YXR1cy1DbGFzcyAgfCBT
dGF0dXMtRGV0YWlsIHwgUmVzZXJ2ZWQgICAgICAgICAgICAgICAgICAgICAgfA0KICArLS0tLS0t
LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0t
Kw0KNDAvIFJlc2VydmVkICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgLw0KICsvICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgLw0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t
LS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KNDh8IERpZ2VzdHMgaWYgYW55
Li4uICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICArLS0t
LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t
LS0tKw0KICAvIERhdGFTZWdtZW50IC0gTG9naW4gUGFyYW1ldGVycyBpbiBUZXh0IENvbW1hbmQg
Rm9ybWF0ICAgICAgICAgLw0KICsvICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgLw0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0t
LS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KDQoyLjEzLjEgRiAoRmlu
YWwpIGJpdA0KDQpGaW5hbCBiaXQgaXMgc2V0IHRvIDEgYXMgYW4gaW5kaWNhdG9yIG9mIGVuZCBv
ZiBzdGFnZS4gSWYgdGhlIG5leHQgc3RhZ2UgcGFydCBpbiBDTnhTRyBpcyBGdWxsRmVhdHVyZVBo
YXNlIGFuZCB0aGUgRiBiaXQgaXMgc2V0IHRvIDEgdGhlbiB0aGlzIGlzIGFsc28gdGhlIEZpbmFs
IExvZ2luIFJlc3BvbnNlIChzZWUgY2hhcHRlciA0KS4gQSBGaW5hbCBiaXQgb2YgMCBpbmRpY2F0
ZXMgYSAicGFydGlhbCIgcmVzcG9uc2UsIHdoaWNoIG1lYW5zICJtb3JlIG5lZ290aWF0aW9uIG5l
ZWRlZCIuDQoNCkEgbG9naW4gcmVzcG9uc2Ugd2l0aCBhIEYgYml0IHNldCB0byAxIE1VU1QgTk9U
IGNvbnRhaW4ga2V5PXZhbHVlIHBhaXJzIHRoYXQgbWF5IHJlcXVpcmUgYWRkaXRpb25hbCBhbnN3
ZXJzIGZyb20gdGhlIGluaXRpYXRvciB3aXRoaW4gdGhlIHNhbWUgc3RhZ2UuDQoNCg0KMi4xMy4y
IFZlcnNpb24tbWF4DQoNClRoaXMgaXMgdGhlIGhpZ2hlc3QgdmVyc2lvbiBudW1iZXIgc3VwcG9y
dGVkIGJ5IHRoZSB0YXJnZXQuDQoNCkFsbCBMb2dpbiByZXNwb25zZXMgd2l0aGluIHRoZSBMb2dp
biBwaGFzZSBNVVNUIGNhcnJ5IHRoZSBzYW1lIFZlcnNpb24tbWF4Lg0KDQpUaGUgaW5pdGlhdG9y
IE1VU1QgdXNlIHRoZSB2YWx1ZSBwcmVzZW50ZWQgYXMgcmVzcG9uc2UgdG8gdGhlIGxvZ2luIHJl
cXVlc3Qgd2l0aCBDPTAgYW5kIE1BWSBjaGVjayB0aGUgdmFsdWUgb3RoZXJ3aXNlLg0KDQoNCjIu
MTMuMyBWZXJzaW9uLWFjdGl2ZQ0KDQpJbmRpY2F0ZXMgdGhlIHZlcnNpb24gc3VwcG9ydGVkICh0
aGUgaGlnaGVzdCB2ZXJzaW9uIHN1cHBvcnRlZCBieSB0aGUgdGFyZ2V0IGFuZCBpbml0aWF0b3Ip
LiBJZiB0aGUgdGFyZ2V0IGRvZXMgbm90IHN1cHBvcnQgYSB2ZXJzaW9uIHdpdGhpbiB0aGUgcmFu
Z2Ugc3BlY2lmaWVkIGJ5IHRoZSBpbml0aWF0b3IsIHRoZSB0YXJnZXQgcmVqZWN0cyB0aGUgbG9n
aW4gYW5kIHRoaXMgZmllbGQgaW5kaWNhdGVzIHRoZSBsb3dlc3QgdmVyc2lvbiBzdXBwb3J0ZWQg
YnkgdGhlIHRhcmdldC4NCg0KQWxsIExvZ2luIHJlc3BvbnNlcyB3aXRoaW4gdGhlIExvZ2luIHBo
YXNlIE1VU1QgY2FycnkgdGhlIHNhbWUgVmVyc2lvbi1hY3RpdmUuDQoNClRoZSBpbml0aWF0b3Ig
TVVTVCB1c2UgdGhlIHZhbHVlIHByZXNlbnRlZCBhcyByZXNwb25zZSB0byB0aGUgbG9naW4gcmVx
dWVzdCB3aXRoIEM9MCBhbmQgTUFZIGNoZWNrIHRoZSB2YWx1ZSBvdGhlcndpc2UuDQoNCjIuMTMu
NCBUU0lEDQoNClRoZSBUU0lEIGlzIGEgdGFnIHRoYXQgaWRlbnRpZmllcyB0aGUgU0NTSSBpbml0
aWF0b3IgcG9ydC4gVFNJRCBpcyBzZXQgYnkgdGhlIHRhcmdldC4gIEl0IE1VU1QgYmUgdmFsaWQg
b25seSBpbiB0aGUgZmluYWwgbG9naW4gcmVzcG9uc2UgKHRoZSByZXNwb25zZSBoYXZpbmcgRj0x
IGFuZCB0aGUgbmVzdCBwYXJ0IG9mIENOeFNHIGluIGJvdGggcmVxdWVzdCBhbmQgcmVzcG9uc2Ug
aW5kaWNhdGluZyBGdWxsRmVhdHVyZVBoYXNlLg0KIA0KMi4xMy41IFN0YXRTTg0KDQpGb3IgdGhl
IGZpcnN0IExvZ2luIFJlc3BvbnNlICh0aGUgcmVzcG9uc2UgdG8gYSBMb2dpbiBSZXF1ZXN0IHdp
dGggQz0wKSB0aGlzIGlzIHRoZSBzdGFydGluZyBzdGF0dXMgU2VxdWVuY2UgTnVtYmVyIGZvciB0
aGUgY29ubmVjdGlvbiAodGhlIG5leHQgcmVzcG9uc2Ugb2YgYW55IGtpbmQgd2lsbCBjYXJyeSB0
aGlzIG51bWJlciArIDEpLiBUaGlzIGZpZWxkIGlzIHZhbGlkIG9ubHkgaWYgdGhlIFN0YXR1cyBD
bGFzcyBpcyAwLg0KDQoyLjEzLjYgU3RhdHVzLUNsYXNzIGFuZCBTdGF0dXMtRGV0YWlsDQoNClRo
ZSBTdGF0dXMgcmV0dXJuZWQgaW4gYSBMb2dpbiBSZXNwb25zZSBpbmRpY2F0ZXMgdGhlIGV4ZWN1
dGlvbiBzdGF0dXMgb2YgdGhlIGxvZ2luIHBoYXNlLiBUaGUgc3RhdHVzIGluY2x1ZGVzOg0KDQpT
dGF0dXMtQ2xhc3MgDQpTdGF0dXMtRGV0YWlsDQoNClRoZSBTdGF0dXMtQ2xhc3MgaXMgc3VmZmlj
aWVudCBmb3IgYSBzaW1wbGUgaW5pdGlhdG9yIHRvIHVzZSB3aGVuIGhhbmRsaW5nIGVycm9ycywg
d2l0aG91dCBoYXZpbmcgdG8gbG9vayBhdCB0aGUgU3RhdHVzLURldGFpbC4gIFRoZSBTdGF0dXMt
RGV0YWlsIGFsbG93cyBmaW5lci1ncmFpbmVkIGVycm9yIHJlY292ZXJ5IGZvciBtb3JlIHNvcGhp
c3RpY2F0ZWQgaW5pdGlhdG9ycywgYXMgd2VsbCBhcyBiZXR0ZXIgaW5mb3JtYXRpb24gZm9yIGVy
cm9yIGxvZ2dpbmcuDQoNClRoZSBzdGF0dXMgY2xhc3NlcyBhcmUgYXMgZm9sbG93czoNCg0KMCAt
IFN1Y2Nlc3MgLSBpbmRpY2F0ZXMgdGhhdCB0aGUgaVNDU0kgdGFyZ2V0IHN1Y2Nlc3NmdWxseSBy
ZWNlaXZlZCwgdW5kZXJzdG9vZCwgYW5kIGFjY2VwdGVkIHRoZSByZXF1ZXN0LiBUaGUgbnVtYmVy
aW5nIGZpZWxkcyAoU3RhdFNOLCBFeHBDbWRTTiwgTWF4Q21kU04gYXJlIHZhbGlkIG9ubHkgaWYg
U3RhdHVzLUNsYXNzIGlzIDApLg0KDQoxIC0gUmVkaXJlY3Rpb24gLSBpbmRpY2F0ZXMgdGhhdCBm
dXJ0aGVyIGFjdGlvbiBtdXN0IGJlIHRha2VuIGJ5IHRoZSBpbml0aWF0b3IgdG8gY29tcGxldGUg
dGhlIHJlcXVlc3QuIFRoaXMgaXMgdXN1YWxseSBkdWUgdG8gdGhlIHRhcmdldCBtb3ZpbmcgdG8g
YSBkaWZmZXJlbnQgYWRkcmVzcy4gQWxsIG9mIHRoZSByZWRpcmVjdGlvbiBzdGF0dXMgY2xhc3Mg
cmVzcG9uc2VzIE1VU1QgcmV0dXJuIG9uZSBvciBtb3JlIHRleHQga2V5IHBhcmFtZXRlcnMgb2Yg
dGhlIHR5cGUgIlRhcmdldEFkZHJlc3MiLCB3aGljaCBpbmRpY2F0ZXMgdGhlIHRhcmdldCdzIG5l
dyBhZGRyZXNzLg0KDQoyIC0gSW5pdGlhdG9yIEVycm9yIC0gaW5kaWNhdGVzIHRoYXQgdGhlIGlu
aXRpYXRvciBsaWtlbHkgY2F1c2VkIHRoZSBlcnJvci4gVGhpcyBNQVkgYmUgZHVlIHRvIGEgcmVx
dWVzdCBmb3IgYSByZXNvdXJjZSBmb3Igd2hpY2ggdGhlIGluaXRpYXRvciBkb2VzIG5vdCBoYXZl
IHBlcm1pc3Npb24uICBUaGUgcmVxdWVzdCBzaG91bGQgbm90IGJlIHRyaWVkIGFnYWluLg0KDQoz
IC0gVGFyZ2V0IEVycm9yIC0gaW5kaWNhdGVzIHRoYXQgdGhlIHRhcmdldCBzZWVzIG5vIGVycm9y
cyBpbiB0aGUgaW5pdGlhdG9yknMgbG9naW4gcmVxdWVzdCwgYnV0IGlzIGN1cnJlbnRseSBpbmNh
cGFibGUgb2YgZnVsZmlsbGluZyB0aGUgcmVxdWVzdC4gIFRoZSBjbGllbnQgbWF5IHJlLXRyeSB0
aGUgc2FtZSBsb2dpbiByZXF1ZXN0IGxhdGVyLg0KDQpUaGUgdGFibGUgYmVsb3cgc2hvd3MgYWxs
IG9mIHRoZSBjdXJyZW50bHkgYWxsb2NhdGVkIHN0YXR1cyBjb2Rlcy4gIFRoZSBjb2RlcyBhcmUg
aW4gaGV4YWRlY2ltYWw7IHRoZSBmaXJzdCBieXRlIGlzIHRoZSBzdGF0dXMgY2xhc3MgYW5kIHRo
ZSBzZWNvbmQgYnl0ZSBpcyB0aGUgc3RhdHVzIGRldGFpbC4gIFRoZSBhbGxvd2FibGUgc3RhdGUg
b2YgdGhlIEZpbmFsIChGKSBiaXQgaW4gcmVzcG9uc2VzIHdpdGggZWFjaCBvZiB0aGUgY29kZXMg
aXMgYWxzbyBkaXNwbGF5ZWQuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpTdGF0dXMgICAgICAgIHwgQ29kZSB8Rmlu
YWx8ICAgRGVzY3JpcHRpb24NCiAgICAgICAgICAgICAgfChoZXgpIHwgYml0IHwNCi0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
DQpBY2NlcHQgTG9naW4gIHwgMDAwMCB8IDEvMCB8IExvZ2luIGlzIE9LLCBtb3ZpbmcgdG8gRnVs
bCBGZWF0dXJlDQogICAgICAgICAgICAgIHwgICAgICB8ICAgICB8IFBoYXNlIG9yIExvZ2luT3Bl
cmF0aW9uYWxOZWdvdGlhdGlvbiANCiAgICAgICAgICAgICAgfCAgICAgIHwgICAgIHwgc3RhZ2Ug
KCoxKQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0NCkF1dGhlbnRpY2F0ZSAgfCAwMDAxIHwgMCAgIHwgVGhlIGlTQ1NJIFRh
cmdldE5hbWUgKElUTikgZXhpc3RzIGFuZCANCiAgICAgICAgICAgICAgfCAgICAgIHwgICAgIHwg
YXV0aGVudGljYXRpb24gcHJvY2VlZHMuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KaVNDU0kgVGFyZ2V0ICB8IDAwMDIg
fCAwICAgfCBUaGUgSVROIG11c3QgYmUgcHJvdmlkZWQgIA0KTmFtZSByZXF1aXJlZCB8ICAgICAg
fCAgICAgfCBmb3IgYXV0aGVudGljYXRpb24gdG8gcHJvY2VlZC4NCi0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUYXJnZXQg
TW92ZWQgIHwgMDEwMSB8IDEgICB8IFRoZSByZXF1ZXN0ZWQgSVROIGhhcyBtb3ZlZA0KVGVtcG9y
YXJpbHkgICB8ICAgICAgfCAgICAgfCB0ZW1wb3JhcmlseSB0byB0aGUgYWRkcmVzcyBwcm92aWRl
ZC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tDQpUYXJnZXQgTW92ZWQgIHwgMDEwMiB8IDEgICB8IFRoZSByZXF1ZXN0ZWQg
SVROIGhhcyBtb3ZlZA0KUGVybWFuZW50bHkgICB8ICAgICAgfCAgICAgfCBwZXJtYW5lbnRseSB0
byB0aGUgYWRkcmVzcyBwcm92aWRlZC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpJbml0aWF0b3IgICAgIHwgMDIwMCB8
IDEgICB8IE1pc2NlbGxhbmVvdXMgaVNDU0kgaW5pdGlhdG9yIA0KRXJyb3IgICAgICAgICB8ICAg
ICAgfCAgICAgfCBlcnJvcnMNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpBdXRoZW50aWNhdGlvbnwgMDIwMSB8IDEgICB8
IFRoZSBpbml0aWF0b3IgY291bGQgbm90IGJlDQpGYWlsdXJlICAgICAgIHwgICAgICB8ICAgICB8
IHN1Y2Nlc3NmdWxseSBhdXRoZW50aWNhdGVkLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkF1dGhvcml6YXRpb24gfCAw
MjAyIHwgMSAgIHwgVGhlIGluaXRpYXRvciBpcyBub3QgYWxsb3dlZCBhY2Nlc3MNCkZhaWx1cmUg
ICAgICAgfCAgICAgIHwgICAgIHwgdG8gdGhlIGdpdmVuIHRhcmdldC4NCi0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpOb3Qg
Rm91bmQgICAgIHwgMDIwMyB8IDEgICB8IFRoZSByZXF1ZXN0ZWQgSVROIGRvZXMgbm90DQogICAg
ICAgICAgICAgIHwgICAgICB8ICAgICB8IGV4aXN0IGF0IHRoaXMgYWRkcmVzcy4NCi0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
DQpUYXJnZXQgUmVtb3ZlZHwgMDIwNCB8IDEgICB8IFRoZSByZXF1ZXN0ZWQgSVROIGhhcyBiZWVu
DQogICAgICAgICAgICAgIHwgICAgICB8ICAgICB8IHJlbW92ZWQuIE5vIGZvcndhcmRpbmcgYWRk
cmVzcyBpcw0KICAgICAgICAgICAgICB8ICAgICAgfCAgICAgfCBwcm92aWRlZC4NCi0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
DQpVbnN1cHBvcnRlZCAgIHwgMDIwNSB8IDEgICB8IFRoZSByZXF1ZXN0ZWQgaVNDU0kgdmVyc2lv
biByYW5nZSBpcyANClZlcnNpb24gICAgICAgfCAgICAgIHwgICAgIHwgbm90IHN1cHBvcnRlZCBi
eSB0aGUgdGFyZ2V0LiANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpJbml0aWF0b3IgICAgIHwgMDIwNiB8IDEgICB8IElu
dmFsaWQgVFNJRCAtIG5vIG1vcmUgY29ubmVjdGlvbnMgIA0KU0lEIGVycm9yICAgICB8ICAgICAg
fCAgICAgfCBhY2NlcHRlZCANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpNaXNzaW5nICAgICAgIHwgMDIwNyB8IDEgICB8
IE1pc3NpbmcgcGFyYW1ldGVycyAoZS5nLiwgaVNDU0kgDQpwYXJhbWV0ZXIgICAgIHwgICAgICB8
ICAgICB8IEluaXRpYXRvciBhbmQvb3IgVGFyZ2V0IE5hbWUpDQotLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ2FuJ3QgaW5j
bHVkZSB8IDAyMDggfCAxICAgfCBUYXJnZXQgZG9lcyBub3Qgc3VwcG9ydCBzZXNzaW9uICANCmlu
IHNlc3Npb24gICAgfCAgICAgIHwgICAgIHwgc3Bhbm5pbmcgdG8gdGhpcyBjb25uZWN0aW9uIChh
ZGRyZXNzKQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0NClNlc3Npb24gb3BlbiAgfCAwMjA5IHwgMSAgIHwgVGhlIGlTQ1NJ
IEluaXRpYXRvck5hbWUgYW5kIElTSUQgIA0KYWxyZWFkeSB3aXRoICB8ICAgICAgfCAgICAgfCBp
ZGVudGlmeSBhbiBleGlzdGluZyBzZXNzaW9uDQp0aGlzIEluaXRpYXRvcnwgICAgICB8ICAgICB8
IHdpdGggdGhpcyBpbml0aWF0b3INCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpTZXNzaW9uIGRvZXMgIHwgMDIwYSB8IDEg
ICB8IFRoZSBpU0NTSSBJbml0aWF0b3JOYW1lIGFuZCBJU0lEICANCm5vdCBleGlzdCB3aXRofCAg
ICAgIHwgICAgIHwgZG8gbm90IGlkZW50aWZ5IGFuIGV4aXN0aW5nIHNlc3Npb24NCnRoaXMgSW5p
dGlhdG9yfCAgICAgIHwgICAgIHwgd2l0aCB0aGlzIGluaXRpYXRvciAocmVzdGFydCkNCi0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tDQpTZXNzaW9uIHR5cGUgIHwgMDIwYiB8IDEgICB8IFRhcmdldCBkb2VzIG5vdCBzdXBwb3J0
IHRoaXMgdHlwZSBvZiAgDQpOb3Qgc3VwcG9ydGVkIHwgICAgICB8ICAgICB8IG9mIHNlc3Npb24g
KG5vdCBmcm9tIHRoaXMgSW5pdGlhdG9yKQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRhcmdldCBFcnJvciAgfCAwMzAw
IHwgMSAgIHwgVGFyZ2V0IGhhcmR3YXJlIG9yIHNvZnR3YXJlIGVycm9yLg0KICAgICAgICAgICAg
ICB8ICAgICAgfCAgICAgfCANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpTZXJ2aWNlICAgICAgIHwgMDMwMSB8IDEgICB8
IFRoZSBpU0NTSSBzZXJ2aWNlIG9yIHRhcmdldCBpcyBub3QNClVuYXZhaWxhYmxlICAgfCAgICAg
IHwgICAgIHwgY3VycmVudGx5IG9wZXJhdGlvbmFsLiANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpPdXQgb2YgICAgICAg
IHwgMDMwMiB8IDEgICB8IFRoZSB0YXJnZXQgaGFzIGluc3VmZmljaWVudCBzZXNzaW9uLCANClJl
c291cmNlcyAgICAgfCAgICAgIHwgICAgIHwgY29ubmVjdGlvbiwgb3Igb3RoZXIgcmVzb3VyY2Vz
Lg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0NCg0KKCoxKUlmIHRoZSBTdGF0dXMgaXMgImFjY2VwdCBsb2dpbiIgKDB4MDAw
MCkgdGhlIGluaXRpYXRvciBoYXMgc3RhdGVkIHRoZSBjdXJyZW50IHN0YWdlIGFzIExvZ2luT3Bl
cmF0aW9uYWxOZWdvdGlhdGlvbiAoYW5kIGlmIHRoZSBGIGJpdCB3YXMgMSB0aGUgbmV4dCBzdGFn
ZSB0byBGdWxsRmVhdHVyZVBoYXNlKS4gSWYgdGhlIHJlc3BvbnNlIEYgYml0IGlzIDEgKHRoZSBu
ZXh0IHN0YWdlIHBhcnQgaXMgYWxzbyBGdWxsRmVhdHVyZVBoYXNlIGluIGJvdGggdGhlIHJlcXVl
c3QgYW5kIHRoZSByZXNwb25zZSkgdGhlIGxvZ2luIHBoYXNlIGlzIGZpbmlzaGVkIGFuZCB0aGUg
aW5pdGlhdG9yIG1heSBwcm9jZWVkIHRvIGlzc3VlIFNDU0kgY29tbWFuZHMuIElmIHRoZSBTdGF0
dXMgaXMgImFjY2VwdCBsb2dpbiIgKDB4MDAwMCkgYW5kIHRoZSBGIGJpdCBpcyAwLCB0aGUgaW5p
dGlhdG9yIG1heSBwcm9jZWVkIHRvIG5lZ290aWF0ZSBvcGVyYXRpb25hbCBwYXJhbWV0ZXJzLg0K
IA0KSWYgdGhlIFN0YXR1cyBDbGFzcyBpcyBub3QgMCwgdGhlIGluaXRpYXRvciBhbmQgdGFyZ2V0
IE1VU1QgY2xvc2UgdGhlIFRDUCBjb25uZWN0aW9uLiANCg0KSWYgdGhlIHRhcmdldCB3aXNoZXMg
dG8gcmVqZWN0IHRoZSBsb2dpbiByZXF1ZXN0IGZvciBtb3JlIHRoYW4gb25lIHJlYXNvbiwgaXQg
c2hvdWxkIHJldHVybiB0aGUgcHJpbWFyeSByZWFzb24gZm9yIHRoZSByZWplY3Rpb24uDQoNCi0t
LS0tLS0tLS0tLS0tLS0tLS0tLQ0KNC4gTG9naW4gUGhhc2UNCg0KSW4gdGhlIHJlc3Qgb2YgdGhp
cyBjaGFwdGVyLCB3aGVuZXZlciB3ZSBtZW50aW9uIHNlY3VyaXR5IHdlIG1lYW4gc2VjdXJpdHkg
YW5kL29yIGRhdGEgaW50ZWdyaXR5Lg0KDQpUaGUgbG9naW4gcGhhc2UgZXN0YWJsaXNoZXMgYW4g
aVNDU0kgc2Vzc2lvbiBiZXR3ZWVuIGluaXRpYXRvciBhbmQgdGFyZ2V0LiBJdCBzZXRzIHRoZSBp
U0NTSSBwcm90b2NvbCBwYXJhbWV0ZXJzLCBzZWN1cml0eSBwYXJhbWV0ZXJzLCBhbmQgYXV0aGVu
dGljYXRlcyB0aGUgaW5pdGlhdG9yIGFuZCB0YXJnZXQgdG8gZWFjaCBvdGhlci4NCg0KVGhlIGxv
Z2luIHBoYXNlIGlzIGltcGxlbWVudGVkIHZpYSBsb2dpbiByZXF1ZXN0IGFuZCByZXNwb25zZXMg
b25seS4gIFRoZSB3aG9sZSBsb2dpbiBwaGFzZSBpcyBjb25zaWRlcmVkIGFzIGEgc2luZ2xlIHRh
c2sgYW5kIGhhcyBhIHNpbmdsZSBJbml0aWF0b3IgVGFzayBUYWcgKHNpbWlsYXIgdG8gdGhlIGxp
bmtlZCBTQ1NJIGNvbW1hbmRzKS4NCg0KVGhlIGxvZ2luIHBoYXNlIHNlcXVlbmNlIG9mIGNvbW1h
bmRzIGFuZCByZXNwb25zZXMgcHJvY2VlZHMgYXMgZm9sbG93czoNCg0KLSBMb2dpbiBpbml0aWFs
IHJlcXVlc3QgKEMgYml0IHNldCB0byAwKQ0KLSBMb2dpbiBwYXJ0aWFsIHJlc3BvbnNlIChvcHRp
b25hbCkgDQotIE1vcmUgTG9naW4gcmVxdWVzdHMgYW5kIHJlc3BvbnNlcyAob3B0aW9uYWwpDQot
IExvZ2luIEZpbmFsLVJlc3BvbnNlIChtYW5kYXRvcnkpDQoNClRoZSBMb2dpbiBGaW5hbC1yZXNw
b25zZSBhY2NlcHRzIG9yIHJlamVjdHMgdGhlIExvZ2luIENvbW1hbmQuDQoNClRoZSBMb2dpbiBQ
aGFzZSBNQVkgaW5jbHVkZSBhIFNlY3VyaXR5TmVnb3RpYXRpb24gc3RhZ2UgYW5kIGEgTG9naW5P
cGVyYXRpb25hbE5lZ290aWF0aW9uIHN0YWdlIGFuZCBNVVNUIGluY2x1ZGUgYXQgbGVhc3Qgb25l
IG9mIHRoZW0sIGJ1dCB0aGUgaW5jbHVkZWQgc3RhZ2UgTUFZIGJlIGVtcHR5LiANCg0KVGhlIGxv
Z2luIGFuZCB0ZXh0IGNvbW1hbmRzIGFuZCByZXNwb25zZXMgY29udGFpbiBhIGZpZWxkIHRoYXQg
aW5kaWNhdGVzIHRoZSBuZWdvdGlhdGlvbiBzdGFnZSAoU2VjdXJpdHlOZWdvdGlhdGlvbiBvciBM
b2dpbk9wZXJhdGlvbmFsTmVnb3RpYXRpb24pLiAgSWYgYm90aCBzdGFnZXMgYXJlIHVzZWQgdGhl
IFNlY3VyaXR5TmVnb3RpYXRpb24gTVVTVCBwcmVjZWRlIHRoZSBMb2dpbk9wZXJhdGlvbmFsTmVn
b3RpYXRpb24uDQoNClNvbWUgb3BlcmF0aW9uYWwgcGFyYW1ldGVycyBjYW4gYmUgbmVnb3RpYXRl
ZCBvdXRzaWRlIGxvZ2luLCB0aHJvdWdoIHRleHQgY29tbWFuZCByZXNwb25zZS4NCiANClNlY3Vy
aXR5IE1VU1QgYmUgY29tcGxldGVseSBuZWdvdGlhdGVkIHdpdGhpbiB0aGUgTG9naW4gUGhhc2Ug
b3IgcHJvdmlkZWQgYnkgZXh0ZXJuYWwgbWVhbnMgKGUuZy4sIElQU2VjKS4NCg0KSW4gc29tZSBl
bnZpcm9ubWVudHMsIGEgdGFyZ2V0IG9yIGFuIGluaXRpYXRvciBpcyBub3QgaW50ZXJlc3RlZCBp
biBhdXRoZW50aWNhdGluZyBpdHMgY291bnRlcnBhcnQuIEl0IGlzIHBvc3NpYmxlIHRvIGJ5cGFz
cyBhdXRoZW50aWNhdGlvbiB0aHJvdWdoIHRoZSBMb2dpbiByZXF1ZXN0IGFuZCByZXNwb25zZS4N
Cg0KVGhlIGluaXRpYXRvciBhbmQgdGFyZ2V0IE1BWSB3YW50IHRvIG5lZ290aWF0ZSBhdXRoZW50
aWNhdGlvbiBhbmQgZGF0YSBpbnRlZ3JpdHkgcGFyYW1ldGVycy4gT25jZSB0aGlzIG5lZ290aWF0
aW9uIGlzIGNvbXBsZXRlZCwgdGhlIGNoYW5uZWwgaXMgY29uc2lkZXJlZCBzZWN1cmUuDQoNCkF1
dGhlbnRpY2F0aW9uIGFuZCBhIFNlY3VyZSBDaGFubmVsIHNldHVwIE1BWSBiZSBwZXJmb3JtZWQg
aW5kZXBlbmRlbnQgb2YgaVNDU0kgKGFzIHdoZW4gdXNpbmcgdHVubmVsaW5nIElQU2VjIG9yIHNv
bWUgaW1wbGVtZW50YXRpb25zIG9mIHRyYW5zcG9ydCBJUFNlYykgaW4gd2hpY2ggY2FzZSB0aGUg
TG9naW4gcGhhc2UgY2FuIGJlIHJlZHVjZWQgdG8gb3BlcmF0aW9uYWwgcGFyYW1ldGVyIG5lZ290
aWF0aW9ucy4NCiANCk1vc3Qgb2YgdGhlIG5lZ290aWF0aW9uIGtleXMgYXJlIGFsbG93ZWQgb25s
eSBpbiBhIHNwZWNpZmljIHN0YWdlIC0gdGhlIFNlY3VyaXR5TmVnb3RpYXRpb24ga2V5cyBhcHBl
YXIgYWxsIGluIEFwcGVuZGl4IEEgd2hpbGUgdGhlIExvZ2luT3BlcmF0aW9uYWxOZWdvdGlhdGlv
biBrZXlzIGFwcGVhciBpbiBBcHBlbmRpeCBELg0KT25seSBhIGxpbWl0ZWQgc2V0IG9mIGtleXMg
KG1hcmtlZCBhcyBEZWNsYXJhdGl2ZSBpbiBBcHBlbmRpeCBEKSBtYXkgYmUgdXNlZCBpbiBhbnkg
b2YgdGhlIDIgc3RhZ2VzLg0KDQpBbnkgZ2l2ZW4gTG9naW4gcmVxdWVzdCBvciByZXNwb25zZSBi
ZWxvbmdzIHRvIGEgc3BlY2lmaWMgc3RhZ2UgYW5kIHRoaXMgZGV0ZXJtaW5lcyB0aGUgbmVnb3Rp
YXRpb24ga2V5cyBhbGxvd2VkIHdpdGggdGhlIGNvbW1hbmQgb3IgcmVzcG9uc2UuDQoNClN0YWdl
IHRyYW5zaXRpb24gaXMgcGVyZm9ybWVkIHRocm91Z2ggYSBjb21tYW5kIGV4Y2hhbmdlIChyZXF1
ZXN0L3Jlc3BvbnNlKSBjYXJyeWluZyB0aGUgRiBiaXQgYW5kIHRoZSBzYW1lIGN1cnJlbnQgc3Rh
Z2UgY29kZS4gIER1cmluZyB0aGlzIGV4Y2hhbmdlLCB0aGUgbmV4dCBzdGFnZSBzZWxlY3RlZCBp
cyB0aGUgbG93ZXIgb2YgdGhlIHR3byBuZXh0IHN0YWdlIGNvZGVzLiAgVGhlIGluaXRpYXRvciBj
YW4gcmVxdWVzdCBhIHRyYW5zaXRpb24gd2hlbmV2ZXIgaXQgaXMgcmVhZHkgYnV0IGEgdGFyZ2V0
IGNhbiByZXNwb25kIHdpdGggYSB0cmFuc2l0aW9uIG9ubHkgYWZ0ZXIgaXQgaXMgb2ZmZXJlZCBv
bmUgYnkgdGhlIGluaXRpYXRvci4NCg0KSW4gYSBuZWdvdGlhdGlvbiBzZXF1ZW5jZSwgdGhlIEYg
Yml0IHNldHRpbmdzIGluIG9uZSBwYWlyIG9mIGxvZ2luIHJlcXVlc3QtcmVzcG9uc2VzIGhhdmUg
bm8gYmVhcmluZyBvbiB0aGUgRiBiaXQgc2V0dGluZ3Mgb2YgdGhlIG5leHQgcGFpci4gIEFuIGlu
aXRpYXRvciBoYXZpbmcgRiBiaXQgc2V0IHRvIDEgaW4gb25lIHBhaXIgYW5kIGJlaW5nIGFuc3dl
cmVkIHdpdGggYW4gRiBiaXQgc2V0dGluZyBvZiAwIG1heSBpc3N1ZSB0aGUgbmV4dCByZXF1ZXN0
IHdpdGggRiBiaXQgc2V0IHRvIDAuDQoNClN0YWdlIHRyYW5zaXRpb25zIGR1cmluZyBsb2dpbiAo
aW5jbHVkaW5nIGVudGVyaW5nIGFuZCBleGl0KSBhcmUgcG9zc2libGUgb25seSBhcyBvdXRsaW5l
ZCBpbiB0aGUgZm9sbG93aW5nIHRhYmxlOg0KDQorLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQp8RnJvbSAgICAgVG8gLT4gICB8IFNl
Y3VyaXR5ICAgIHwgT3BlcmF0aW9uYWwgfCBGdWxsRmVhdHVyZSB8ICANCnwgIHwgICAgICAgICAg
ICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwgDQp8ICBWICAg
ICAgICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgICB8DQor
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0rDQp8IChzdGFydCkgICAgICAgICB8ICB5ZXMgICAgICAgIHwgIHllcyAgICAgICAgfCAgbm8g
ICAgICAgICB8ICAgDQorLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0rDQp8IFNlY3VyaXR5ICAgICAgICB8ICBubyAgICAgICAgIHwgIHll
cyAgICAgICAgfCAgeWVzICAgICAgICB8DQorLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQp8IE9wZXJhdGlvbmFsICAgICB8ICBubyAg
ICAgICAgIHwgIG5vICAgICAgICAgfCAgeWVzICAgICAgICB8DQorLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQoNClRoZSBMb2dpbiBG
aW5hbC1SZXNwb25zZSB0aGF0IGFjY2VwdHMgYSBMb2dpbiBDb21tYW5kIGNhbiBjb21lIG9ubHkg
YXMgYSByZXNwb25zZSB0byBhIExvZ2luIGNvbW1hbmQgd2l0aCB0aGUgRiBiaXQgc2V0IHRvIDEg
d2l0aCB0aGUgRiBiaXQgc2V0IHRvIDEgYW5kIGJvdGggdGhlIGNvbW1hbmQgYW5kIHJlc3BvbnNl
IE1VU1QgaGF2ZSBGdWxsRmVhdHVyZVBoYXNlIGluIHRoZSBuZXh0IHN0YWdlIHBhcnQgb2YgdGhl
IENOeFNHIGZpZWxkLg0KDQoNCjQuMSBMb2dpbiBQaGFzZSBTdGFydA0KDQpUaGUgbG9naW4gcGhh
c2Ugc3RhcnRzIHdpdGggYSBsb2dpbiByZXF1ZXN0IGZyb20gdGhlIGluaXRpYXRvciB0byB0aGUg
dGFyZ2V0LiBUaGUgaW5pdGlhbCBsb2dpbiByZXF1ZXN0IGluY2x1ZGVzOg0KDQotUHJvdG9jb2wg
dmVyc2lvbiBzdXBwb3J0ZWQgYnkgdGhlIGluaXRpYXRvciAoY3VycmVudGx5IDB4JzAyJykNCi1T
ZXNzaW9uIGFuZCBjb25uZWN0aW9uIElkcw0KLVRoZSBuZWdvdGlhdGlvbiBzdGFnZSB0aGF0IHRo
ZSBpbml0aWF0b3IgaXMgcmVhZHkgdG8gZW50ZXINCi1UaGUgQyBiaXQgc2V0IHRvIDAgKGZpcnN0
IGxvZ2luIHJlcXVlc3Qgb24gYSBjb25uZWN0aW9uKQ0KDQpPcHRpb25hbGx5IHRoZSBsb2dpbiBy
ZXF1ZXN0IG1heSBpbmNsdWRlOg0KDQotU2VjdXJpdHkvSW50ZWdyaXR5IHBhcmFtZXRlcnMgT1IN
Ci1pU0NTSSBvcGVyYXRpb25hbCBwYXJhbWV0ZXJzIEFORC9PUg0KLVRoZSBuZXh0IG5lZ290aWF0
aW9uIHN0YWdlIHRoYXQgdGhlIGluaXRpYXRvciBpcyByZWFkeSB0byBlbnRlcg0KDQpUaGUgdGFy
Z2V0IGNhbiBhbnN3ZXIgdGhlIGxvZ2luIGluIHRoZSBmb2xsb3dpbmcgd2F5czoNCg0KLUxvZ2lu
IFJlc3BvbnNlIHdpdGggTG9naW4gUmVqZWN0LiAgVGhpcyBpcyBhbiBpbW1lZGlhdGUgcmVqZWN0
aW9uIGZyb20gdGhlIHRhcmdldCB0aGF0IGNhdXNlcyB0aGUgc2Vzc2lvbiB0byB0ZXJtaW5hdGUu
IFRoZSBGIGJpdCBvZiB0aGUgcmVzcG9uc2UgTVVTVCBiZSBzZXQgdG8gMSBhbmQgdGhlIENOeFNH
IGlzIHRvIGJlIGlnbm9yZWQNCi1Mb2dpbiBSZXNwb25zZSB3aXRoIExvZ2luIEFjY2VwdCBhcyBh
IGZpbmFsIHJlc3BvbnNlIChGIGJpdCBzZXQgdG8gMSBhbmQgdGhlIG5leHQgcGFydCBvZiBDTnhT
RyBpbiBib3RoIGNvbW1hbmQgYSByZXNwb25zZSBhcmUgc2V0IHRvIEZ1bGxGZWF0dXJlUGhhc2Up
LiBUaGUgcmVzcG9uc2UgaW5jbHVkZXMgdGhlIHByb3RvY29sIHZlcnNpb24gc3VwcG9ydGVkIGJ5
IHRoZSB0YXJnZXQgIGFuZCB0aGUgc2Vzc2lvbiBJRCBhbmQgbWF5ICBpbmNsdWRlIGlTQ1NJIG9w
ZXJhdGlvbmFsIG9yIHNlY3VyaXR5IHBhcmFtZXRlcnMgKGRlcGVuZGluZyBvbiB0aGUgY3VycmVu
dCBzdGFnZSkuDQotTG9naW4gUmVzcG9uc2Ugd2l0aCBMb2dpbiBBY2NlcHQgYXMgYSBwYXJ0aWFs
IHJlc3BvbnNlIGluZGljYXRpbmcgdGhlIHN0YXJ0IG9mIGEgbmVnb3RpYXRpb24gc2VxdWVuY2Uu
ICBUaGUgcmVzcG9uc2UgaW5jbHVkZXMgdGhlIHByb3RvY29sIHZlcnNpb24gc3VwcG9ydGVkIGJ5
IHRoZSB0YXJnZXQgYW5kIGVpdGhlciBzZWN1cml0eS9pbnRlZ3JpdHkgcGFyYW1ldGVycyBvciBp
U0NTSSBwYXJhbWV0ZXJzICh3aGVuIG5vIHNlY3VyaXR5L2ludGVncml0eSBtZWNoYW5pc20gaXMg
Y2hvc2VuKSBzdXBwb3J0ZWQgYnkgdGhlIHRhcmdldC4NCg0KSWYgdGhlIGluaXRpYXRvciBkZWNp
ZGVzIHRvIGZvcmVnbyB0aGUgU2VjdXJpdHlOZWdvdGlhdGlvbiBzdGFnZSBpdCBpc3N1ZXMgdGhl
IExvZ2luIHdpdGggdGhlIENOeFNHIHNldCB0byBMb2dpbk9wZXJhdGlvbmFsTmVnb3RpYXRpb24g
aW4gdGhlIGN1cnJlbnQgc3RhZ2UgYW5kIHRoZSB0YXJnZXQgbWF5IHJlcGx5IHdpdGggYSBMb2dp
biBSZXNwb25zZSBpbmRpY2F0aW5nIHRoYXQgaXQgaXMgdW53aWxsaW5nIHRvIGFjY2VwdCB0aGUg
Y29ubmVjdGlvbiB3aXRob3V0IFNlY3VyaXR5TmVnb3RpYXRpb24gYW5kIHRlcm1pbmF0ZSB0aGUg
Y29ubmVjdGlvbi4NCg0KSWYgdGhlIGluaXRpYXRvciBpcyB3aWxsaW5nIG5vIG5lZ290aWF0ZSBz
ZWN1cml0eSBidXQgaXQgaXMgdW53aWxsaW5nIHRvIG1ha2UgdGhlIGluaXRpYWwgcGFyYW1ldGVy
IG9mZmVyIGFuZCBtYXkgYWNjZXB0IGEgY29ubmVjdGlvbiB3aXRob3V0IHNlY3VyaXR5IGl0IGlz
c3VlcyB0aGUgTG9naW4gd2l0aCB0aGUgRiBiaXQgc2V0IHRvIDEsIHRoZSBDTnhTRyBzZXQgdG8g
U2VjdXJpdHlOZWdvdGlhdGlvbiBpbiB0aGUgY3VycmVudCBzdGFnZSBhbmQgTG9naW5PcGVyYXRp
b25hbE5lZ290aWF0aW9uIGluIHRoZSBuZXh0IHN0YWdlLiBJZiB0aGUgdGFyZ2V0IGlzIGFsc28g
cmVhZHkgdG8gZm9yZWdvIHNlY3VyaXR5IHRoZSBMb2dpbiByZXNwb25zZSBpcyBlbXB0eSBhbmQg
aGFzIEYgYml0IGlzIHNldCB0byAxIGFuZCB0aGUgQ054U0cgc2V0IHRvIFNlY3VyaXR5TmVnb3Rp
YXRpb24gaW4gdGhlIGN1cnJlbnQgc3RhZ2UgYW5kIExvZ2luT3BlcmF0aW9uYWxOZWdvdGlhdGlv
biBpbiB0aGUgbmV4dCBzdGFnZS4NCg0KQW4gaW5pdGlhdG9yIHRoYXQgY2FuIG9wZXJhdGUgd2l0
aG91dCBzZWN1cml0eSBhbmQgd2l0aCBhbGwgdGhlIG9wZXJhdGlvbmFsIHBhcmFtZXRlcnMgdGFr
aW5nIHRoZSBkZWZhdWx0IHZhbHVlcyBpc3N1ZXMgdGhlIExvZ2luIHdpdGggdGhlIEYgYml0IHNl
dCB0byAxLCB0aGUgQ054U0cgc2V0IHRvIExvZ2luT3BlcmF0aW9uYWxOZWdvdGlhdGlvbiBpbiB0
aGUgY3VycmVudCBzdGFnZSBhbmQgRnVsbEZlYXR1cmVQaGFzZSBpbiB0aGUgbmV4dCBzdGFnZS4g
SWYgdGhlIHRhcmdldCBpcyBhbHNvIHJlYWR5IHRvIGZvcmVnbyBzZWN1cml0eSBhbmQgTG9naW5P
cGVyYXRpb25hbE5lZ290aWF0aW9uIHRoZSBMb2dpbiByZXNwb25zZSBpcyBlbXB0eSBhbmQgaGFz
IEYgYml0IGlzIHNldCB0byAxIGFuZCB0aGUgQ054U0cgc2V0IHRvIExvZ2luT3BlcmF0aW9uYWxO
ZWdvdGlhdGlvbiBpbiB0aGUgY3VycmVudCBzdGFnZSBhbmQgRnVsbEZlYXR1cmVQaGFzZSBpbiB0
aGUgbmV4dCBzdGFnZS4NCg0KQSB0YXJnZXQgTUFZIHVzZSB0aGUgaVNDU0kgSW5pdGlhdG9yIE5h
bWUgYXMgcGFydCBvZiBpdHMgYWNjZXNzIGNvbnRyb2wgbWVjaGFuaXNtOyB0aGVyZWZvcmUsIHRo
ZSBpU0NTSSBJbml0aWF0b3IgTmFtZSBNVVNUIGJlIHNlbnQgYmVmb3JlIHRoZSB0YXJnZXQgaXMg
cmVxdWlyZWQgdG8gZGlzY2xvc2UgaXRzIExVcy4NCg0KSWYgdGhlIGlTQ1NJIFRhcmdldCBOYW1l
IGFuZC9vciBpU0NTSSBJbml0aWF0b3IgTmFtZSBpcyBnb2luZyB0byBiZSB1c2VkIGluIGRldGVy
bWluaW5nIHRoZSBzZWN1cml0eSBtb2RlIG9yIGl0IGlzIGltcGxpY2l0IHBhcnQgb2YgYXV0aGVu
dGljYXRpb24sIHRoZW4gdGhlIGlTQ1NJIFRhcmdldCBOYW1lIGFuZC9vciBpU0NTSSBJbml0aWF0
b3IgTmFtZSBNVVNUIGJlIHNlbnQgaW4gdGhlIGxvZ2luIGNvbW1hbmQgZm9yIHRoZSBmaXJzdCBj
b25uZWN0aW9uIG9mIGEgc2Vzc2lvbiB0byBpZGVudGlmeSB0aGUgc3RvcmFnZSBlbmRwb2ludCBv
ZiB0aGUgc2Vzc2lvbi4gSWYgc2VudCBvbiBuZXcgY29ubmVjdGlvbnMgd2l0aGluIGFuIGV4aXN0
aW5nIHNlc3Npb24gaXQgTVVTVCBiZSB0aGUgc2FtZSBhcyB0aGUgb25lIHVzZWQgZm9yIHRoZSBs
ZWFkaW5nIGNvbm5lY3Rpb24uICBJZiB0aGUgaVNDU0kgVGFyZ2V0IE5hbWUgYW5kL29yIGlTQ1NJ
IEluaXRpYXRvciBOYW1lIGlzIGdvaW5nIHRvIGJlIHVzZWQgb25seSBmb3IgYWNjZXNzIGNvbnRy
b2wsIGl0IGNhbiBiZSBzZW50IGFmdGVyIHRoZSBTZWN1cml0eU5lZ290aWF0aW9uIHN0YWdlLiBB
IHRhcmdldCBjYW4gYmUgYWNjZXNzZWQgd2l0aG91dCBhIFRhcmdldCBOYW1lIG9ubHkgaWYgdGhl
IHNlc3Npb24gdHlwZSBpcyBhIGRpc2NvdmVyeSBzZXNzaW9uLg0KIA0KVGhlIGlTQ1NJIE5hbWVz
IE1VU1QgYmUgaW4gdGV4dCBjb21tYW5kIGZvcm1hdC4NCg0KNC4yIGlTQ1NJIFNlY3VyaXR5IGFu
ZCBJbnRlZ3JpdHkgTmVnb3RpYXRpb24NCg0KVGhlIHNlY3VyaXR5IGV4Y2hhbmdlIHNldHMgdGhl
IHNlY3VyaXR5IG1lY2hhbmlzbSBhbmQgYXV0aGVudGljYXRlcyB0aGUgdXNlciBhbmQgdGhlIHRh
cmdldCB0byBlYWNoIG90aGVyLiBUaGUgZXhjaGFuZ2UgcHJvY2VlZHMgYWNjb3JkaW5nIHRvIHRo
ZSBhbGdvcml0aG1zIHRoYXQgd2VyZSBjaG9zZW4gaW4gdGhlIG5lZ290aWF0aW9uIHBoYXNlIGFu
ZCBpcyBjb25kdWN0ZWQgYnkgdGhlIGxvZ2luIGFuZCB0ZXh0IGNvbW1hbmRzIGtleT12YWx1ZSBw
YXJhbWV0ZXJzLg0KDQpUaGUgbmVnb3RpYWJsZSBzZWN1cml0eSBtZWNoYW5pc21zIGluY2x1ZGUg
dGhlIGZvbGxvd2luZyBtb2RlczoNCg0KLUluaXRpYXRvci10YXJnZXQgYXV0aGVudGljYXRpb24g
LSB0aGUgaG9zdCBhbmQgdGhlIHRhcmdldCBhdXRoZW50aWNhdGUgdGhlbXNlbHZlcyB0byBlYWNo
IG90aGVyLiBBIG5lZ290aWFibGUgYWxnb3JpdGhtIHN1Y2ggYXMgS2VyYmVyb3MgcHJvdmlkZXMg
dGhpcyBmZWF0dXJlLg0KLVBEVSBpbnRlZ3JpdHkgLSBhbiBpbnRlZ3JpdHkvYXV0aGVudGljYXRp
b24gZGlnZXN0IGlzIGF0dGFjaGVkIHRvIGVhY2ggcGFja2V0LiAgVGhlIGFsZ29yaXRobSBpcyBu
ZWdvdGlhYmxlLg0KIA0KVXNpbmcgSVBzZWMgZm9yIGVuY3J5cHRpb24gb3IgYXV0aGVudGljYXRp
b24gbWF5IGVsaW1pbmF0ZSBwYXJ0IG9mIHRoZSBzZWN1cml0eSBuZWdvdGlhdGlvbiBhdCB0aGUg
aVNDU0kgbGV2ZWwgYnV0IG5vdCBuZWNlc3NhcmlseSBhbGwuIA0KDQpJZiBzZWN1cml0eSBpcyBl
c3RhYmxpc2hlZCBpbiB0aGUgbG9naW4gcGhhc2UgdGhlbiBhZnRlciB0aGUgc2VjdXJpdHkgbmVn
b3RpYXRpb24gaXMgY29tcGxldGUsIGVhY2ggaVNDU0kgUERVIE1VU1QgaW5jbHVkZSB0aGUgYXBw
cm9wcmlhdGUgZGlnZXN0IGZpZWxkIGlmIGFueS4NCg0KVGhlIG5lZ290aWF0aW9uIHByb2NlZWRz
IGFzIGZvbGxvd3M6DQoNCi1UaGUgaW5pdGlhdG9yIHNlbmRzIGEgbG9naW4gcmVxdWVzdCB3aXRo
IGFuIG9yZGVyZWQgbGlzdCBvZiB0aGUgb3B0aW9ucyBpdCBzdXBwb3J0cyBmb3IgZWFjaCBzdWJq
ZWN0IChhdXRoZW50aWNhdGlvbiBhbGdvcml0aG0sIGlTQ1NJIHBhcmFtZXRlcnMgYW5kIHNvIG9u
KS4gVGhlIG9wdGlvbnMgYXJlIGxpc3RlZCBpbiB0aGUgaW5pdGlhdG9yJ3Mgb3JkZXIgb2YgcHJl
ZmVyZW5jZS4gDQotVGhlIHRhcmdldCBNVVNUIHJlcGx5IHdpdGggdGhlIGZpcnN0IG9wdGlvbiBp
biB0aGUgbGlzdCBpdCBzdXBwb3J0cyBhbmQgaXMgYWxsb3dlZCBmb3IgdGhlIHNwZWNpZmljIGlu
aXRpYXRvci4gIFRoZSBwYXJhbWV0ZXJzIGFyZSBlbmNvZGVkIGluIFVURjggYXMga2V5PXZhbHVl
LiAgVGhlIGluaXRpYXRvciBNQVkgYWxzbyBzZW5kIHByb3ByaWV0YXJ5IG9wdGlvbnMuIFRoZSAi
bm9uZSIgb3B0aW9uLCBpZiBhbGxvd2VkLCBNVVNUIGJlIGluY2x1ZGVkIGluIHRoZSBsaXN0LCB3
aGljaCBpbmRpY2F0ZXMgdGhhdCBubyBhbGdvcml0aG0gaXMgc3VwcG9ydGVkIGJ5IHRoZSB0YXJn
ZXQuIEZvciBhIGxpc3Qgb2Ygc2VjdXJpdHkgcGFyYW1ldGVycyBzZWUgQXBwZW5kaXggQS4NCg0K
LVRoZSBpbml0aWF0b3IgbXVzdCBiZSBhd2FyZSBvZiB0aGUgaW1taW5lbnQgY29tcGxldGlvbiBv
ZiB0aGUgU2VjdXJpdHlOZWdvdGlhdGlvbiBzdGFnZSBhbmQgTVVTVCBzZXQgdGhlIEYgYml0IHRv
IDEgYW5kIHRoZSBuZXh0IHN0YWdlIHBhcnQgb2YgQ054U0cgdG8gd2hhdCBpdCB3b3VsZCBsaWtl
IHRoZSBuZXh0IHN0YWdlIHRvIGJlLiBUaGUgdGFyZ2V0IHdpbGwgYW5zd2VyIHdpdGggYSBMb2dp
biByZXNwb25zZSB3aXRoIHRoZSBGIGJpdCBzZXQgdG8gMSBhbmQgdGhlIG5leHQgc3RhZ2UgcGFy
dCBvZiBDTnhTRyB0byB3aGF0IGl0IHdvdWxkIGxpa2UgdGhlIG5leHQgc3RhZ2UgdG8gYmUuIFRo
ZSBuZXh0IHN0YWdlIHNlbGVjdGVkIHdpbGwgYmUgdGhlICJsb3dlciIgb2YgdGhlIHR3by4gSWYg
dGhlIG5leHQgc3RhZ2UgaXMgRnVsbEZlYXR1cmVQaGFzZSwgdGhlIHRhcmdldCBNVVNUIHJlc3Bv
bmQgd2l0aCBhIExvZ2luIFJlc3BvbnNlIHdpdGggdGhlIFNlc3Npb24gSUQgYW5kIHRoZSBwcm90
b2NvbCB2ZXJzaW9uLiANCg0KDQpBbGwgUERVcyBzZW50IGFmdGVyIHRoZSBzZWN1cml0eSBuZWdv
dGlhdGlvbiBzdGFnZSBNVVNUIGJlIGJ1aWx0IHVzaW5nIHRoZSBhZ3JlZWQgc2VjdXJpdHkuIA0K
DQpJZiB0aGUgc2VjdXJpdHkgbmVnb3RpYXRpb24gZmFpbHMgYXQgdGhlIHRhcmdldCB0aGVuIHRo
ZSB0YXJnZXQgTVVTVCBzZW5kIHRoZSBhcHByb3ByaWF0ZSBMb2dpbiBSZXNwb25zZSBQRFUuICBJ
ZiB0aGUgc2VjdXJpdHkgbmVnb3RpYXRpb24gZmFpbHMgYXQgdGhlIGluaXRpYXRvciwgdGhlIGlu
aXRpYXRvciBzaGFsbCBkcm9wIHRoZSBjb25uZWN0aW9uLiANCg0KNC4zIE9wZXJhdGlvbmFsIFBh
cmFtZXRlciBOZWdvdGlhdGlvbiBEdXJpbmcgdGhlIExvZ2luIFBoYXNlDQoNCk9wZXJhdGlvbmFs
IHBhcmFtZXRlciBuZWdvdGlhdGlvbiBkdXJpbmcgdGhlIGxvZ2luIE1BWSBiZSBkb25lOg0KDQot
IHN0YXJ0aW5nIHdpdGggdGhlIGZpcnN0IExvZ2luIHJlcXVlc3QgaWYgdGhlIGluaXRpYXRvciBk
b2VzIG5vdCBvZmZlciAgYW55IHNlY3VyaXR5LyBpbnRlZ3JpdHkgb3B0aW9uDQotIHN0YXJ0aW5n
IGltbWVkaWF0ZWx5IGFmdGVyIHRoZSBzZWN1cml0eS9pbnRlZ3JpdHkgbmVnb3RpYXRpb24gaWYg
dGhlIGluaXRpYXRvciBhbmQgdGFyZ2V0IHBlcmZvcm0gc3VjaCBhIG5lZ290aWF0aW9uDQoNCkFu
IG9wZXJhdGlvbmFsIHBhcmFtZXRlciBuZWdvdGlhdGlvbiBvbiBhIGNvbm5lY3Rpb24gTVVTVCBO
T1Qgc3RhcnQgYmVmb3JlIHRoZSBzZWN1cml0eSBuZWdvdGlhdGlvbiBpZiBhIHNlY3VyaXR5IG5l
Z290aWF0aW9uIGV4aXN0cy4gIA0KDQpPcGVyYXRpb25hbCBwYXJhbWV0ZXIgbmVnb3RpYXRpb24g
TUFZIGludm9sdmUgc2V2ZXJhbCBMb2dpbiByZXF1ZXN0LXJlc3BvbnNlIGV4Y2hhbmdlcyBzdGFy
dGVkIGFuZCB0ZXJtaW5hdGVkIGJ5IHRoZSBpbml0aWF0b3IuIFRoZSBpbml0aWF0b3IgTVVTVCBp
bmRpY2F0ZSBpdHMgaW50ZW50IHRvIHRlcm1pbmF0ZSB0aGUgbmVnb3RpYXRpb24gYnkgc2V0dGlu
ZyB0aGUgRiBiaXQgdG8gMTsgdGhlIHRhcmdldCBzZXRzIHRoZSBGIGJpdCB0byAxIG9uIHRoZSBs
YXN0IHJlc3BvbnNlLiBUaGUgbGFzdCByZXNwb25zZSBNVVNUIGJlIHRoZSBMb2dpbiBSZXNwb25z
ZS4NCklmIHRoZSB0YXJnZXQgcmVzcG9uZHMgdG8gYSBMb2dpbiByZXF1ZXN0IHdpdGggdGhlIEYg
Yml0IHNldCB0byAxLCB3aXRoIGEgTG9naW4gcmVzcG9uc2Ugd2l0aCB0aGUgRiBiaXQgc2V0IHRv
IDAsIHRoZSBpbml0aWF0b3IgbXVzdCBrZWVwIHNlbmRpbmcgdGhlIExvZ2luIHJlcXVlc3QgKGV2
ZW4gZW1wdHkpIHdpdGggdGhlIEYgYml0IHNldCB0byAxIHVudGlsIGl0IGdldHMgdGhlIExvZ2lu
IFJlc3BvbnNlIHdpdGggdGhlIEYgYml0IHNldCB0byAxLg0KDQpXaGVuZXZlciBwYXJhbWV0ZXIg
YWN0aW9uIG9yIGFjY2VwdGFuY2UgaXMgZGVwZW5kZW50IG9uIG90aGVyIHBhcmFtZXRlcnMgdGhl
IGRlcGVuZGVudCBwYXJhbWV0ZXJzIE1VU1QgYmUgc2VudCBhZnRlciB0aGUgcGFyYW1ldGVycyB0
aGV5IGRlcGVuZCBvbi4gIElmIHRoZXkgYXJlIHNlbnQgd2l0aGluIHRoZSBzYW1lIGNvbW1hbmQg
YSByZXNwb25zZSBmb3IgYSBwYXJhbWV0ZXIgbWlnaHQgaW1wbHkgcmVzcG9uc2VzIGZvciBvdGhl
cnMuDQoNCkFuIGluaXRpYXRvciBNVVNUIHNlbmQgYSBzaW5nbGUgTG9naW4gcmVxdWVzdCB3aXRo
IHRoZSBDIGJpdCBzZXQgdG8gMCBwZXIgY29ubmVjdGlvbiwgcGVyIHNlc3Npb24uIA0KDQpTZXNz
aW9uIHNwZWNpZmljIHBhcmFtZXRlcnMgY2FuIGJlIHNwZWNpZmllZCBvbmx5IGR1cmluZyB0aGUg
bG9naW4gcGhhc2UgICAgIGJlZ3VuIGJ5IGEgbG9naW4gY29tbWFuZCBjb250YWluaW5nIGEgbnVs
bCBUU0lEIChlLmcuLCB0aGUgbWF4aW11bSBudW1iZXIgb2YgY29ubmVjdGlvbnMgdGhhdCBjYW4g
YmUgdXNlZCBmb3IgdGhpcyBzZXNzaW9uKS4gIENvbm5lY3Rpb24gc3BlY2lmaWMgcGFyYW1ldGVy
cywgaWYgYW55LCBjYW4gYmUgc3BlY2lmaWVkIGR1cmluZyB0aGUgbG9naW4gcGhhc2UgYmVndW4g
YnkgYW55IGxvZ2luIGNvbW1hbmQuIFRodXMsIGEgc2Vzc2lvbiBpcyBvcGVyYXRpb25hbCBvbmNl
IGl0IGhhcyBhdCBsZWFzdCBvbmUgY29ubmVjdGlvbi4gDQoNCkZvciBhIGxpc3Qgb2Ygb3BlcmF0
aW9uYWwgcGFyYW1ldGVycywgc2VlIEFwcGVuZGl4IEQuIA0KDQotLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tDQowMyBMb2dpbiBQaGFzZSBFeGFtcGxlcw0KDQpJbiB0aGUgZmlyc3QgZXhhbXBs
ZSwgdGhlIGluaXRpYXRvciBhbmQgdGFyZ2V0IGF1dGhlbnRpY2F0ZSBlYWNoIG90aGVyIHZpYSBL
ZXJiZXJvczoNCg0KSS0+IExvZ2luIChDPTAsIENOeFNHPTAsMSBGPTEpDQogICAgSW5pdGlhdG9y
TmFtZT1pcW4uMTk5OS0wNy5jb20ub3MuaG9zdGlkLjc3DQogICAgVGFyZ2V0TmFtZT1pcW4uMTk5
OS0wNy5jb20uYWNtZS5kaXNrYXJyYXkuc24uODggDQogICAgSGVhZGVyRGlnZXN0PUNSQy0zMkMs
bm9uZSANCiAgICBEYXRhRGlnZXN0PUNSQy0zMkMsbm9uZQ0KICAgIEF1dGhNZXRob2Q9U1JQLEtS
QjUsbm9uZSANCg0KVC0+IExvZ2luIChDTnhTRz0wLDEgRj0wKQ0KICAgIEhlYWRlckRpZ2VzdD1D
UkMtMzJDDQogICAgRGF0YURpZ2VzdD1DUkMtMzJDDQogICAgQXV0aE1ldGhvZD1LUkI1DQoNCg0K
SS0+IExvZ2luIChDPTEsIENOeFNHPTAsMSBGPTEpDQogICAgS1JCX0FQX1JFUT08a3JiX2FwX3Jl
cT4NCg0KKGtyYl9hcF9yZXEgY29udGFpbnMgdGhlIEtlcmJlcm9zIFY1IHRpY2tldCBhbmQgYXV0
aGVudGljYXRvciB3aXRoIE1VVFVBTC1SRVFVSVJFRCBzZXQgaW4gdGhlIGFwLW9wdGlvbnMgZmll
bGQpDQoNCklmIHRoZSBhdXRoZW50aWNhdGlvbiBpcyBzdWNjZXNzZnVsLCB0aGUgdGFyZ2V0IHBy
b2NlZWRzIHdpdGg6DQoNClQtPiBMb2dpbiAoQ054U0c9MCwxIEY9MSkNCiAgICBLUkJfQVBfUkVQ
PTxrcmJfYXBfcmVwPiANCg0KKGtyYl9hcF9yZXAgaXMgdGhlIEtlcmJlcm9zIFY1IG11dHVhbCBh
dXRoZW50aWNhdGlvbiByZXBseSkgDQogDQpJZiB0aGUgYXV0aGVudGljYXRpb24gaXMgc3VjY2Vz
c2Z1bCwgdGhlIGluaXRpYXRvciBwcm9jZWVkcy4NCg0KRnJvbSB0aGlzIHBvaW50IG9uLCBhbnkg
TG9naW4gY29tbWFuZCBhbmQgZWFjaCBQRFUgdGhlcmVhZnRlciBNVVNUIGhhdmUgQ1JDLTMyQyBk
aWdlc3RzIGZvciB0aGUgaGVhZGVyIGFuZCB0aGUgZGF0YS4NCg0KVGhlIGluaXRpYXRvciBtYXkg
cHJvY2VlZDoNCg0KSS0+IExvZ2luIChDPTEsIENOeFNHPTEsMyBGPTApDQogICAgLi4uIGlTQ1NJ
IE9wZXJhdGlvbmFsIFBhcmFtZXRlcnMNCg0KVC0+IExvZ2luIChDTnhTRz0xLDMgRj0wKQ0KICAg
IC4uLiBpU0NTSSBPcGVyYXRpb25hbCBQYXJhbWV0ZXJzIA0KDQpBbmQgYXQgdGhlIGVuZDoNCg0K
SS0+IExvZ2luIChDPTEsIENOeFNHPTEsMyBGPTEpDQogICAgb3B0aW9uYWwgaVNDU0kgcGFyYW1l
dGVycw0KICAgIFRhcmdldE5hbWU9aXFuLjE5OTktMDcuY29tLmFjbWUuZGlza2FycmF5LnNuLjg4
DQoNClQtPiBMb2dpbiAoQ054U0c9MSwzIEY9MSkgImxvZ2luIGFjY2VwdCIgDQoNCklmIHRoZSBp
bml0aWF0b3IgYXV0aGVudGljYXRpb24gYnkgdGhlIHRhcmdldCBpcyBub3Qgc3VjY2Vzc2Z1bCwg
dGhlIHRhcmdldCByZXNwb25kcyB3aXRoOg0KDQpULT4gTG9naW4gImxvZ2luIHJlamVjdCINCg0K
aW5zdGVhZCBvZiB0aGUgTG9naW4gS1JCX0FQX1JFUCBtZXNzYWdlLCBhbmQgdGVybWluYXRlcyB0
aGUgY29ubmVjdGlvbi4NCg0KSWYgdGhlIHRhcmdldCBhdXRoZW50aWNhdGlvbiBieSB0aGUgaW5p
dGlhdG9yIGlzIG5vdCBzdWNjZXNzZnVsLCB0aGUgaW5pdGlhdG9yIHRlcm1pbmF0ZXMgdGhlIGNv
bm5lY3Rpb24gKHdpdGhvdXQgcmVzcG9uZGluZyB0byB0aGUgTG9naW4gS1JCX0FQX1JFUCBtZXNz
YWdlKS4NCg0KSW4gdGhlIG5leHQgZXhhbXBsZSBvbmx5IHRoZSBpbml0aWF0b3IgaXMgYXV0aGVu
dGljYXRlZCBieSB0aGUgdGFyZ2V0IHZpYSBLZXJiZXJvczoNCg0KSS0+IExvZ2luIChDPTAsIENO
eFNHPTAsMSBGPTEpDQogICAgSW5pdGlhdG9yTmFtZT1pcW4uMTk5OS0wNy5jb20ub3MuaG9zdGlk
Ljc3DQogICAgVGFyZ2V0TmFtZT1pcW4uMTk5OS0wNy5jb20uYWNtZS5kaXNrYXJyYXkuc24uODgg
IA0KICAgIEhlYWRlckRpZ2VzdD1DUkMtMzJDLG5vbmUNCiAgICBEYXRhRGlnZXN0PUNSQy0zMkMs
bm9uZQ0KICAgIEF1dGhNZXRob2Q9U1JQLEtSQjUsbm9uZSANCg0KVC0+IExvZ2luLVBSIChDTnhT
Rz0wLDEgRj0wKQ0KICAgIEhlYWRlckRpZ2VzdD1DUkMtMzJDDQogICAgRGF0YURpZ2VzdD1DUkMt
MzJDIA0KICAgIEF1dGhNZXRob2Q9S1JCNSANCg0KSS0+IExvZ2luIChDPTEsIENOeFNHPTAsMSBG
PTEpDQogICAgS1JCX0FQX1JFUT1rcmJfYXBfcmVxIA0KDQooTVVUVUFMLVJFUVVJUkVEIG5vdCBz
ZXQgaW4gdGhlIGFwLW9wdGlvbnMgZmllbGQgb2Yga3JiX2FwX3JlcSkNCg0KSWYgdGhlIGF1dGhl
bnRpY2F0aW9uIGlzIHN1Y2Nlc3NmdWwsIHRoZSB0YXJnZXQgcHJvY2VlZHMgd2l0aDoNCg0KVC0+
IExvZ2luIChDTnhTRz0wLDEgRj0xKQ0KDQpGcm9tIHRoaXMgcG9pbnQgb24sIGFueSBMb2dpbiBj
b21tYW5kIGFuZCBlYWNoIFBEVSB0aGVyZWFmdGVyIE1VU1QgaGF2ZSBDUkMtMzJDIGRpZ2VzdHMg
Zm9yIHRoZSBoZWFkZXIgYW5kIHRoZSBkYXRhLg0KDQpJLT4gTG9naW4gKEM9MSwgQ054U0c9MSwz
IEY9MCkNCiAgICAuLi4gaVNDU0kgcGFyYW1ldGVycw0KDQpULT4gTG9naW4gKEM9MSwgQ054U0c9
MSwzIEY9MCkNCiAgICAuLi4gaVNDU0kgcGFyYW1ldGVycw0KDQouIC4gLg0KDQpULT4gTG9naW4g
KENOeFNHPTEsMyBGPTEpImxvZ2luIGFjY2VwdCINCiAgICBUYXJnZXROYW1lPWlxbi4xOTk5LTA3
LmNvbS5hY21lLmRpc2thcnJheS5zbi44OA0KDQoNCkluIHRoZSBuZXh0IGV4YW1wbGUsIHRoZSBp
bml0aWF0b3IgYW5kIHRhcmdldCBhdXRoZW50aWNhdGUgZWFjaCBvdGhlciB2aWEgU1BLTS0xOg0K
DQpJLT4gTG9naW4gKEM9MCwgQ054U0c9MCwxIEY9MSkNCiAgICBJbml0aWF0b3JOYW1lPWlxbi4x
OTk5LTA3LmNvbS5vcy5ob3N0aWQuNzcNCiAgICBUYXJnZXROYW1lPWlxbi4xOTk5LTA3LmNvbS5h
Y21lLmRpc2thcnJheS5zbi44OA0KICAgIEhlYWRlckRpZ2VzdD1DUkMtMzJDLG5vbmUgDQogICAg
RGF0YURpZ2VzdD1DUkMtMzJDLCBub25lDQogICAgQXV0aE1ldGhvZD1TUEtNLTEsS1JCNSxub25l
IA0KDQpULT4gTG9naW4gKENOeFNHPTAsMSBGPTApDQogICAgSGVhZGVyRGlnZXN0PUNSQy0zMkMN
CiAgICBEYXRhRGlnZXN0PVNQS00NCiAgICBBdXRoTWV0aG9kPVNQS00tMQ0KDQpJLT4gTG9naW4g
KEM9MSwgQ054U0c9MCwxIEY9MCkNCiAgICBTUEtNLVJFUT08c3BrbS1yZXE+DQoNCihzcGttLXJl
cSBpcyB0aGUgU1BLTS1SRVEgdG9rZW4gd2l0aCB0aGUgbXV0dWFsLXN0YXRlIGJpdCBpbiB0aGUg
b3B0aW9ucyBmaWVsZCBvZiB0aGUgUkVRLVRPS0VOIHNldCkNCg0KVC0+IExvZ2luIChDTnhTRz0w
LDEgRj0wKQ0KICAgIFNQS00tUkVQLVRJPTxzcGttLXJlcC10aT4gDQoNCklmIHRoZSBhdXRoZW50
aWNhdGlvbiBpcyBzdWNjZXNzZnVsLCB0aGUgaW5pdGlhdG9yIHByb2NlZWRzOg0KDQpJLT4gTG9n
aW4gKEM9MSwgQ054U0c9MCwxIEY9MSkNCiAgICBTUEtNLVJFUC1JVD08c3BrbS1yZXAtaXQ+DQog
DQpJZiB0aGUgYXV0aGVudGljYXRpb24gaXMgc3VjY2Vzc2Z1bCwgdGhlIHRhcmdldCBwcm9jZWVk
cyB3aXRoOg0KDQpULT4gTG9naW4gKENOeFNHPTAsMSBGPTEpDQoNCkZyb20gdGhpcyBwb2ludCBv
biwgYW55IExvZ2luIGNvbW1hbmQgYW5kIGVhY2ggUERVIHRoZXJlYWZ0ZXIgTVVTVCBoYXZlIENS
Qy0zMkMgZGlnZXN0cyBmb3IgdGhlIGhlYWRlciBhbmQgdGhlIGRhdGEuDQoNClRoZSBpbml0aWF0
b3IgbWF5IHByb2NlZWQ6DQoNCkktPiBMb2dpbiAgKEM9MSwgQ054U0c9MSwzIEY9MCkgLi4uIGlT
Q1NJIHBhcmFtZXRlcnMNClQtPiBMb2dpbiAgKENOeFNHPTEsMyBGPTApIC4uLiBpU0NTSSBwYXJh
bWV0ZXJzDQoNCkFuZCBhdCB0aGUgZW5kOg0KDQpJLT4gTG9naW4gIChDPTEsIENOeFNHPTEsMyBG
PTEpDQogICAgb3B0aW9uYWwgaVNDU0kgcGFyYW1ldGVycyANCg0KVC0+IExvZ2luIChDTnhTRz0x
LDMgRj0xKSAibG9naW4gYWNjZXB0Ig0KICAgIFRhcmdldE5hbWU9aXFuLjE5OTktMDcuY29tLmFj
bWUuZGlza2FycmF5LnNuLjg4DQoNCg0KSWYgdGhlIHRhcmdldCBhdXRoZW50aWNhdGlvbiBieSB0
aGUgaW5pdGlhdG9yIGlzIG5vdCBzdWNjZXNzZnVsLCB0aGUgaW5pdGlhdG9yIHRlcm1pbmF0ZXMg
dGhlIGNvbm5lY3Rpb24gKHdpdGhvdXQgcmVzcG9uZGluZyB0byB0aGUgTG9naW4gU1BLTS1SRVAt
VEkgbWVzc2FnZSkuDQoNCklmIHRoZSBpbml0aWF0b3IgYXV0aGVudGljYXRpb24gYnkgdGhlIHRh
cmdldCBpcyBub3Qgc3VjY2Vzc2Z1bCwgdGhlIHRhcmdldCByZXNwb25kcyB3aXRoOg0KDQpULT4g
TG9naW4gImxvZ2luIHJlamVjdCINCg0KaW5zdGVhZCBvZiB0aGUgTG9naW4gU2VjdXJpdHlDb250
ZXh0Q29tcGxldGU9eWVzIG1lc3NhZ2UsIGFuZCB0ZXJtaW5hdGVzIHRoZSBjb25uZWN0aW9uLg0K
DQoNCkluIHRoZSBuZXh0IGV4YW1wbGUsIHRoZSBpbml0aWF0b3IgYW5kIHRhcmdldCBhdXRoZW50
aWNhdGUgZWFjaCBvdGhlciB2aWEgU1BLTS0yOg0KDQpJLT4gTG9naW4gKEM9MCwgQ054U0c9MCwx
IEY9MCkNCiAgICBJbml0aWF0b3JOYW1lPWlxbi4xOTk5LTA3LmNvbS5vcy5ob3N0aWQuNzcNCiAg
ICBUYXJnZXROYW1lPWlxbi4xOTk5LTA3LmNvbS5hY21lLmRpc2thcnJheS5zbi44OA0KICAgIEhl
YWRlckRpZ2VzdD0gQ1JDLTMyQyxub25lDQogICAgICAgICAgRGF0YURpZ2VzdD1DUkMtMzJDLG5v
bmUNCiAgICAgICAgICBBdXRoTWV0aG9kPVNQS00tMSxTUEtNLTIgDQoNClQtPiBMb2dpbi1QUiAo
Q054U0c9MCwxIEY9MCkNCiAgICBIZWFkZXJEaWdlc3Q9Q1JDLTMyQw0KICAgIERhdGFEaWdlc3Q9
Q1JDLTMyQw0KICAgIEF1dGhNZXRob2Q9U1BLTS0yDQoNCkktPiBMb2dpbiAoQz0xLCBDTnhTRz0w
LDEgRj0xKQ0KICAgIFNQS00tUkVRPTxzcGttLXJlcT4NCg0KKHNwa20tcmVxIGlzIHRoZSBTUEtN
LVJFUSB0b2tlbiB3aXRoIHRoZSBtdXR1YWwtc3RhdGUgYml0IGluIHRoZSBvcHRpb25zIGZpZWxk
IG9mIHRoZSBSRVEtVE9LRU4gbm90IHNldCkNCg0KSWYgdGhlIGF1dGhlbnRpY2F0aW9uIGlzIHN1
Y2Nlc3NmdWwsIHRoZSB0YXJnZXQgcHJvY2VlZHMgd2l0aDoNCg0KVC0+IExvZ2luIChDTnhTRz0w
LDEgRj0xKSANCg0KRnJvbSB0aGlzIHBvaW50IG9uLCBhbnkgTG9naW4gY29tbWFuZCBhbmQgZWFj
aCBQRFUgdGhlcmVhZnRlciBNVVNUIGhhdmUgQ1JDLTMyQyBkaWdlc3RzIGZvciB0aGUgaGVhZGVy
IGFuZCB0aGUgZGF0YS4NCg0KVGhlIGluaXRpYXRvciBtYXkgcHJvY2VlZDoNCg0KSS0+IExvZ2lu
IChDPTEsIENOeFNHPTEsMyBGPTApDQogICAgLi4uIGlTQ1NJIHBhcmFtZXRlcnMNCg0KVC0+IExv
Z2luIChDTnhTRz0xLDMgRj0wKQ0KICAgIC4uLiBpU0NTSSBwYXJhbWV0ZXJzDQoNCkFuZCBhdCB0
aGUgZW5kOg0KDQpJLT4gTG9naW4gIChDPTEsIENOeFNHPTEsMyBGPTEpDQogICAgb3B0aW9uYWwg
aVNDU0kgcGFyYW1ldGVycw0KDQpULT4gTG9naW4gKENOeFNHPTEsMyBGPTEpICJsb2dpbiBhY2Nl
cHQiDQogICAgVGFyZ2V0TmFtZT1pcW4uMTk5OS0wNy5jb20uYWNtZS5kaXNrYXJyYXkuc24uODgN
Cg0KDQpJbiB0aGUgbmV4dCBleGFtcGxlLCB0aGUgaW5pdGlhdG9yIGFuZCB0YXJnZXQgYXV0aGVu
dGljYXRlIGVhY2ggb3RoZXIgdmlhIFNSUDoNCg0KSS0+IExvZ2luIChDPTAsIENOeFNHPTAsMSBG
PTEpDQogICAgSW5pdGlhdG9yTmFtZT1pcW4uMTk5OS0wNy5jb20ub3MuaG9zdGlkLjc3DQogICAg
VGFyZ2V0TmFtZT1pcW4uMTk5OS0wNy5jb20uYWNtZS5kaXNrYXJyYXkuc24uODggDQogICAgSGVh
ZGVyRGlnZXN0PUNSQy0zMkMsbm9uZQ0KICAgIERhdGFEaWdlc3Q9Q1JDLTMyQyxub25lDQogICAg
QXV0aE1ldGhvZD1LUkI1LFNSUCxub25lDQogDQpULT4gTG9naW4tUFIgIChDPTEsIENOeFNHPTAs
MSBGPTApDQogICAgSGVhZGVyRGlnZXN0PUNSQy0zMkMNCiAgICBEYXRhRGlnZXN0PUNSQy0zMkMN
CiAgICBBdXRoTWV0aG9kPVNSUA0KDQpJLT4gTG9naW4gKEM9MSwgQ054U0c9MCwxIEY9MCkNCiAg
ICBVPTx1c2VyPg0KICAgIFRhcmdldEF1dGg9eWVzDQoNClQtPiBMb2dpbiAoQ054U0c9MCwxIEY9
MCkNCiAgICBOPTxOPg0KICAgIGc9PGc+DQogICAgcz08cz4NCg0KSS0+IExvZ2luIChDPTEsIENO
eFNHPTAsMSBGPTApDQogICAgQT08QT4NCg0KVC0+IExvZ2luIChDTnhTRz0wLDEgRj0wKQ0KICAg
IEI9PEI+DQoNCkktPiBMb2dpbiAoQz0xLCBDTnhTRz0wLDEgRj0xKQ0KICAgIE09PE0+DQoNCklm
IHRoZSBpbml0aWF0b3IgYXV0aGVudGljYXRpb24gaXMgc3VjY2Vzc2Z1bCwgdGhlIHRhcmdldCBw
cm9jZWVkczoNCg0KVC0+IExvZ2luIChDTnhTRz0wLDEgRj0xKQ0KICAgIEhNPTxIKEEgfCBNIHwg
Syk+DQoNCiAgIFdoZXJlIE4sIGcsIHMsIEEsIEIsIE0sIGFuZCBIKEEgfCBNIHwgSykgYXJlIGRl
ZmluZWQgaW4gW1JGQzI5NDVdLg0KDQpJZiB0aGUgdGFyZ2V0IGF1dGhlbnRpY2F0aW9uIGlzIG5v
dCBzdWNjZXNzZnVsLCB0aGUgaW5pdGlhdG9yIHRlcm1pbmF0ZXMgdGhlIGNvbm5lY3Rpb24uIE90
aGVyd2lzZSBpdCBwcm9jZWVkcy4NCg0KRnJvbSB0aGlzIHBvaW50IG9uLCBhbnkgTG9naW4gY29t
bWFuZCBhbmQgZWFjaCBQRFUgdGhlcmVhZnRlciBNVVNUIGhhdmUgQ1JDLTMyQyBkaWdlc3RzIGZv
ciB0aGUgaGVhZGVyIGFuZCB0aGUgZGF0YS4NCg0KSS0+IExvZ2luIChDPTEsIENOeFNHPTEsMyBG
PTApDQogICAgLi4uIGlTQ1NJIHBhcmFtZXRlcnMNCg0KVC0+IExvZ2luIChDTnhTRz0xLDMgRj0w
KQ0KICAgIC4uLiBpU0NTSSBwYXJhbWV0ZXJzDQoNCkFuZCBhdCB0aGUgZW5kOg0KDQpJLT4gTG9n
aW4gKEM9MSwgQ054U0c9MSwzIEY9MSkNCiAgICBvcHRpb25hbCBpU0NTSSBwYXJhbWV0ZXJzIA0K
DQpULT4gTG9naW4gIChDTnhTRz0xLDMgRj0xKSAibG9naW4gYWNjZXB0Ig0KICAgIFRhcmdldE5h
bWU9aXFuLjE5OTktMDcuY29tLmFjbWUuZGlza2FycmF5LnNuLjg4DQoNCklmIHRoZSBpbml0aWF0
b3IgYXV0aGVudGljYXRpb24gaXMgbm90IHN1Y2Nlc3NmdWwsIHRoZSB0YXJnZXQgcmVzcG9uZHMg
d2l0aDoNCg0KVC0+IExvZ2luICJsb2dpbiByZWplY3QiDQoNCkluc3RlYWQgb2YgdGhlIFQtPiBM
b2dpbiBITT08SChBIHwgTSB8IEspPiAgbWVzc2FnZSBhbmQgdGVybWluYXRlcyB0aGUgY29ubmVj
dGlvbi4NCg0KSW4gdGhlIG5leHQgZXhhbXBsZSBvbmx5IHRoZSBpbml0aWF0b3IgaXMgYXV0aGVu
dGljYXRlZCBieSB0aGUgdGFyZ2V0IHZpYSBTUlA6DQoNCkktPiBMb2dpbiAoQz0wLCBDTnhTRz0w
LDEgRj0xKQ0KICAgIEluaXRpYXRvck5hbWU9aXFuLjE5OTktMDcuY29tLm9zLmhvc3RpZC43Nw0K
ICAgIFRhcmdldE5hbWU9aXFuLjE5OTktMDcuY29tLmFjbWUuZGlza2FycmF5LnNuLjg4IA0KICAg
IEhlYWRlckRpZ2VzdD1DUkMtMzJDLG5vbmUNCiAgICBEYXRhRGlnZXN0PUNSQy0zMkMsbm9uZQ0K
ICAgIEF1dGhNZXRob2Q9S1JCNSxTUlAsbm9uZSANCg0KVC0+IExvZ2luLVBSIChDTnhTRz0wLDEg
Rj0wKQ0KICAgIEhlYWRlckRpZ2VzdD1DUkMtMzJDDQogICAgRGF0YURpZ2VzdD1DUkMtMzJDDQog
ICAgQXV0aE1ldGhvZD1TUlANCg0KSS0+IExvZ2luIChDPTEsIENOeFNHPTAsMSBGPTApDQogICAg
VT08dXNlcj4NCiAgICBUYXJnZXRBdXRoPW5vDQoNCiAgIFQtPiBMb2dpbiAoQ054U0c9MCwxIEY9
MCkNCiAgICAgICBOPTxOPiANCiAgICAgICBnPTxnPg0KICAgICAgIHM9PHM+DQoNCkktPiBMb2dp
biAoQz0xLCBDTnhTRz0wLDEgRj0wKSANCiAgICBBPTxBPg0KDQpULT4gTG9naW4gKENOeFNHPTAs
MSBGPTApIA0KICAgIEI9PEI+DQoNCkktPiBMb2dpbiAoQz0xLCBDTnhTRz0wLDEgRj0xKSANCiAg
ICBNPTxNPg0KIA0KSWYgdGhlIGluaXRpYXRvciBhdXRoZW50aWNhdGlvbiBpcyBzdWNjZXNzZnVs
LCB0aGUgdGFyZ2V0IHByb2NlZWRzOg0KDQpULT4gTG9naW4gKENOeFNHPTAsMSBGPTEpDQoNCkZy
b20gdGhpcyBwb2ludCBvbiwgYW55IExvZ2luIGNvbW1hbmQgYW5kIGVhY2ggUERVIHRoZXJlYWZ0
ZXIgTVVTVCBoYXZlIENSQy0zMkMgZGlnZXN0cyBmb3IgdGhlIGhlYWRlciBhbmQgdGhlIGRhdGEu
DQoNCkktPiBMb2dpbiAoQz0xLCBDTnhTRz0xLDMgRj0wKSANCiAgICAuLi4gaVNDU0kgcGFyYW1l
dGVycw0KDQpULT4gTG9naW4gKEM9MSwgQ054U0c9MSwzIEY9MCkNCiAgICAuLi4gaVNDU0kgcGFy
YW1ldGVycw0KDQpBbmQgYXQgdGhlIGVuZDoNCg0KSS0+IExvZ2luIChDPTEsIENOeFNHPTEsMyBG
PTEpDQogICAgb3B0aW9uYWwgaVNDU0kgcGFyYW1ldGVycw0KDQpULT4gTG9naW4gKENOeFNHPTEs
MyBGPTEpICJsb2dpbiBhY2NlcHQiDQogICAgVGFyZ2V0TmFtZT1pcW4uMTk5OS0wNy5jb20uYWNt
ZS5kaXNrYXJyYXkuc24uODgNCg0KDQpJbiB0aGUgbmV4dCBleGFtcGxlIHRoZSBpbml0aWF0b3Ig
YW5kIHRhcmdldCBhdXRoZW50aWNhdGUgZWFjaCBvdGhlciB2aWEgQ0hBUDoNCg0KSS0+IExvZ2lu
IChDPTAsIENOeFNHPTAsMSBGPTApIA0KICAgIEluaXRpYXRvck5hbWU9aXFuLjE5OTktMDcuY29t
Lm9zLmhvc3RpZC43Nw0KICAgIFRhcmdldE5hbWU9aXFuLjE5OTktMDcuY29tLmFjbWUuZGlza2Fy
cmF5LnNuLjg4IA0KICAgIEhlYWRlckRpZ2VzdD1DUkMtMzJDLG5vbmUNCiAgICBEYXRhRGlnZXN0
PUNSQy0zMkMsbm9uZQ0KICAgIEF1dGhNZXRob2Q9S1JCNSxDSEFQLG5vbmUgDQoNClQtPiBMb2dp
bi1QUiAoQ054U0c9MCwxIEY9MCkNCiAgICBIZWFkZXJEaWdlc3Q9Q1JDLTMyQw0KICAgIERhdGFE
aWdlc3Q9Q1JDLTMyQw0KICAgIEF1dGhNZXRob2Q9Q0hBUA0KDQpJLT4gTG9naW4gKEM9MSwgQ054
U0c9MCwxIEY9MCkNCiAgICBBPTxBMSxBMj4NCg0KICAgVC0+IExvZ2luIChDTnhTRz0wLDEgRj0w
KSANCiAgICAgICBBPTxBMT4gDQogICAgICAgST08ST4gDQogICAgICAgQz08Qz4NCg0KSS0+IExv
Z2luIChDPTEsIENOeFNHPTAsMSBGPTEpDQogICAgTj08Tj4gDQogICAgUj08Uj4gDQogICAgST08
ST4gDQogICAgQz08Qz4gDQoNCklmIHRoZSBpbml0aWF0b3IgYXV0aGVudGljYXRpb24gaXMgc3Vj
Y2Vzc2Z1bCwgdGhlIHRhcmdldCBwcm9jZWVkczoNCg0KVC0+IExvZ2luIChDTnhTRz0wLDEgRj0x
KSANCiAgICBOPTxOPiANCiAgICBSPTxSPg0KDQpJZiB0aGUgdGFyZ2V0IGF1dGhlbnRpY2F0aW9u
IGlzIG5vdCBzdWNjZXNzZnVsLCB0aGUgaW5pdGlhdG9yIGFib3J0cyB0aGUgY29ubmVjdGlvbi4g
T3RoZXJ3aXNlIGl0IHByb2NlZWRzLg0KDQpGcm9tIHRoaXMgcG9pbnQgb24sIGFueSBMb2dpbiBj
b21tYW5kIGFuZCBlYWNoIFBEVSB0aGVyZWFmdGVyIE1VU1QgaGF2ZSBDUkMtMzJDIGRpZ2VzdHMg
Zm9yIHRoZSBoZWFkZXIgYW5kIHRoZSBkYXRhLg0KDQpJLT4gTG9naW4gKEM9MSwgQ054U0c9MSwz
IEY9MCkgDQogICAgLi4uIGlTQ1NJIHBhcmFtZXRlcnMNClQtPiBMb2dpbiAoQ054U0c9MSwzIEY9
MCkgDQogICAgLi4uIGlTQ1NJIHBhcmFtZXRlcnMNCg0KQW5kIGF0IHRoZSBlbmQ6DQoNCkktPiBM
b2dpbiAoQz0xLCBDTnhTRz0xLDMgRj0xKSANCiAgICBvcHRpb25hbCBpU0NTSSBwYXJhbWV0ZXJz
DQoNClQtPiBMb2dpbiAoQ054U0c9MSwzIEY9MSkgImxvZ2luIGFjY2VwdCIgDQogICAgVGFyZ2V0
TmFtZT1pcW4uMTk5OS0wNy5jb20uYWNtZS5kaXNrYXJyYXkuc24uODgNCg0KSWYgdGhlIGluaXRp
YXRvciBhdXRoZW50aWNhdGlvbiBpcyBub3Qgc3VjY2Vzc2Z1bCwgdGhlIHRhcmdldCByZXNwb25k
cyB3aXRoOg0KDQpULT4gTG9naW4gImxvZ2luIHJlamVjdCINCg0KSW5zdGVhZCBvZiB0aGUgTG9n
aW4gUj08cmVzcG9uc2U+IFNlY3VyaXR5Q29udGV4dENvbXBsZXRlPXllcw0KbWVzc2FnZSBhbmQg
dGVybWluYXRlcyB0aGUgY29ubmVjdGlvbi4NCg0KDQpJbiB0aGUgbmV4dCBleGFtcGxlIG9ubHkg
dGhlIGluaXRpYXRvciBpcyBhdXRoZW50aWNhdGVkIGJ5IHRoZSB0YXJnZXQgdmlhIENIQVA6DQoN
CkktPiBMb2dpbiAoQz0wLCBDTnhTRz0wLDEgRj0wKSANCiAgICBJbml0aWF0b3JOYW1lPWlxbi4x
OTk5LTA3LmNvbS5vcy5ob3N0aWQuNzcNCiAgICBUYXJnZXROYW1lPWlxbi4xOTk5LTA3LmNvbS5h
Y21lLmRpc2thcnJheS5zbi44OCANCiAgICBIZWFkZXJEaWdlc3Q9Q1JDLTMyQyxub25lDQogICAg
RGF0YURpZ2VzdD1DUkMtMzJDLG5vbmUNCiAgICBBdXRoTWV0aG9kPUtSQjUsQ0hBUCxub25lIA0K
DQpULT4gTG9naW4tUFIgKENOeFNHPTAsMSBGPTApDQogICAgSGVhZGVyRGlnZXN0PUNSQy0zMkMN
CiAgICBEYXRhRGlnZXN0PUNSQy0zMkMgDQogICAgQXV0aE1ldGhvZD1DSEFQDQoNCkktPiBMb2dp
biAoQz0xLCBDTnhTRz0wLDEgRj0wKSANCiAgICBBPTxBMSxBMj4NCg0KICAgVC0+IExvZ2luIChD
TnhTRz0wLDEgRj0wKSANCiAgICAgICBBPTxBMT4gDQogICAgICAgST08ST4gDQogICAgICAgQz08
Qz4NCg0KSS0+IExvZ2luIChDPTEsIENOeFNHPTAsMSBGPTEpIA0KICAgIE49PE4+IA0KICAgIFI9
PFI+IA0KDQpJZiB0aGUgaW5pdGlhdG9yIGF1dGhlbnRpY2F0aW9uIGlzIHN1Y2Nlc3NmdWwsIHRo
ZSB0YXJnZXQgcHJvY2VlZHM6DQoNClQtPiBMb2dpbiAoQ054U0c9MCwxIEY9MSkNCg0KSS0+IExv
Z2luIChDPTEsIENOeFNHPTEsMyBGPTApIA0KICAgIC4uLiBpU0NTSSBwYXJhbWV0ZXJzDQoNClQt
PiBMb2dpbiAoQ054U0c9MSwzIEY9MCkgDQogICAgLi4uIGlTQ1NJIHBhcmFtZXRlcnMNCg0KQW5k
IGF0IHRoZSBlbmQ6DQoNCkktPiBMb2dpbiAoQz0xLCBDTnhTRz0xLDMgRj0xKSANCiAgICBvcHRp
b25hbCBpU0NTSSBwYXJhbWV0ZXJzDQoNClQtPiBMb2dpbiAoQ054U0c9MSwzIEY9MSkgImxvZ2lu
IGFjY2VwdCIgDQogICAgVGFyZ2V0TmFtZT1pcW4uMTk5OS0wNy5jb20uYWNtZS5kaXNrYXJyYXku
c24uODgNCg0KDQpJbiB0aGUgbmV4dCBleGFtcGxlLCB0aGUgaW5pdGlhdG9yIGRvZXMgbm90IG9m
ZmVyIGFueSBzZWN1cml0eS9pbnRlZ3JpdHkgcGFyYW1ldGVycywgc28gaXQgbWF5IG9mZmVyIGlT
Q1NJIHBhcmFtZXRlcnMgb24gdGhlIExvZ2luIFBEVSB3aXRoIHRoZSBGIGJpdCBzZXQgdG8gMSwg
YW5kIHRoZSB0YXJnZXQgbWF5IHJlc3BvbmQgd2l0aCBhIGZpbmFsIExvZ2luIFJlc3BvbnNlIFBE
VSBpbW1lZGlhdGVseToNCg0KSS0+IExvZ2luIChDPTAsIENOeFNHPTEsMyBGPTEpIA0KICAgIElu
aXRpYXRvck5hbWU9aXFuLjE5OTktMDcuY29tLm9zLmhvc3RpZC43Nw0KICAgIFRhcmdldE5hbWU9
aXFuLjE5OTktMDcuY29tLmFjbWUuZGlza2FycmF5LnNuLjg4ICANCiAgICAuLi4gaVNDU0kgcGFy
YW1ldGVycw0KDQpULT4gTG9naW4gKENOeFNHPTEsMyBGPTEpICJsb2dpbiBhY2NlcHQiIA0KICAg
IFRhcmdldE5hbWU9aXFuLjE5OTktMDcuY29tLmFjbWUuZGlza2FycmF5LnNuLjg4ICANCiAgICAu
Li4gSVNDU0kgcGFyYW1ldGVycw0KDQpJbiB0aGUgbmV4dCBleGFtcGxlLCB0aGUgaW5pdGlhdG9y
IGRvZXMgb2ZmZXIgc2VjdXJpdHkvaW50ZWdyaXR5IHBhcmFtZXRlcnMgb24gdGhlIExvZ2luIFBE
VSwgYnV0IHRoZSB0YXJnZXQgZG9lcyBub3QgY2hvb3NlIGFueSAoaS5lLiwgY2hvb3NlcyB0aGUg
Im5vbmUiIHZhbHVlcyk6DQoNCkktPiBMb2dpbiAoQz0wLCBDTnhTRz0wLDEgRj0xKSANCiAgICBJ
bml0aWF0b3JOYW1lPWlxbi4xOTk5LTA3LmNvbS5vcy5ob3N0aWQuNzcNCiAgICBUYXJnZXROYW1l
PWlxbi4xOTk5LTA3LmNvbS5hY21lLmRpc2thcnJheS5zbi44OCANCiAgICBIZWFkZXJEaWdlc3Q9
Q1JDLTMyQyxub25lIA0KICAgIERhdGFEaWdlc3Q9Q1JDLTMyQyxub25lIA0KICAgIEF1dGhNZXRo
b2Q6S1JCNSxTUlAsbm9uZQ0KDQpULT4gTG9naW4tUFIgKENOeFNHPTAsMSBGPTEpIA0KICAgIEhl
YWRlckRpZ2VzdD1ub25lIA0KICAgIERhdGFEaWdlc3Q9bm9uZSANCiAgICBBdXRoTWV0aG9kPW5v
bmUNCg0KSS0+IExvZ2luIChDPTEsIENOeFNHPTEsMyBGPTApIA0KICAgIC4uLiBpU0NTSSBwYXJh
bWV0ZXJzDQoNClQtPiBMb2dpbiAoQ054U0c9MSwzIEY9MCkgDQogICAgLi4uIGlTQ1NJIHBhcmFt
ZXRlcnMNCg0KQW5kIGF0IHRoZSBlbmQ6DQoNCkktPiBMb2dpbiAoQz0xLCBDTnhTRz0xLDMgRj0x
KSANCiAgICBvcHRpb25hbCBpU0NTSSBwYXJhbWV0ZXJzDQoNClQtPiBMb2dpbiAoQ054U0c9MSwz
IEY9MSkgImxvZ2luIGFjY2VwdCIgDQogICAgVGFyZ2V0TmFtZT1pcW4uMTk5OS0wNy5jb20uYWNt
ZS5kaXNrYXJyYXkuc24uODgNCg0K

--0__=C2256AB80057B5EA8f9e8a93df938690918cC2256AB80057B5EA--



From owner-ips@ece.cmu.edu  Thu Aug 30 16:02:28 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26746
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 16:02:23 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7UGxKa24420
	for ips-outgoing; Thu, 30 Aug 2001 12:59:20 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7UGx7P24404
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 12:59:07 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id SAA96868
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 18:59:00 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7UGZhX215778
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 18:35:43 +0200
Importance: Normal
Subject: iSCSI - Login proposed change
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF48C22E07.2F07CD1B-ONC2256AB8.005AF60F@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Thu, 30 Aug 2001 19:35:02 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 30/08/2001 19:35:42
MIME-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=C2256AB8005AF60F8f9e8a93df938690918cC2256AB8005AF60F"
Content-Disposition: inline
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

--0__=C2256AB8005AF60F8f9e8a93df938690918cC2256AB8005AF60F
Content-type: text/plain; charset=us-ascii

I am not sure that I sent the right set of proposed changes - here is a
complete one:

Julo

(See attached file: Login-changes.txt)
--0__=C2256AB8005AF60F8f9e8a93df938690918cC2256AB8005AF60F
Content-type: text/plain; 
	name="Login-changes.txt"
Content-Transfer-Encoding: base64

MS4yLjMgaVNDU0kgTG9naW4NCg0KVGhlIHB1cnBvc2Ugb2YgdGhlIGlTQ1NJIGxvZ2luIGlzIHRv
IGVuYWJsZSBhIFRDUCBjb25uZWN0aW9uIGZvciBpU0NTSSB1c2UsIGF1dGhlbnRpY2F0ZSB0aGUg
cGFydGllcywgbmVnb3RpYXRlIHRoZSBzZXNzaW9uJ3MgcGFyYW1ldGVycywgb3BlbiBhIHNlY3Vy
aXR5IGFzc29jaWF0aW9uIHByb3RvY29sLCBhbmQgbWFyayB0aGUgY29ubmVjdGlvbiBhcyBiZWxv
bmdpbmcgdG8gYW4gaVNDU0kgc2Vzc2lvbi4NCiANCkEgc2Vzc2lvbiBpcyB1c2VkIHRvIGlkZW50
aWZ5IHRvIGEgdGFyZ2V0IGFsbCB0aGUgY29ubmVjdGlvbnMgd2l0aCBhIGdpdmVuIGluaXRpYXRv
ciB0aGF0IGJlbG9uZyB0byB0aGUgc2FtZSBJX1QgbmV4dXMgKFNlZSAxLjUuMiBmb3IgbW9yZSBk
ZXRhaWxzIG9uIGhvdyBhIHNlc3Npb24gcmVsYXRlcyB0byBhbiBJX1QgbmV4dXMpLg0KDQpUaGUg
dGFyZ2V0cyBsaXN0ZW4gb24gYSB3ZWxsLWtub3duIFRDUCBwb3J0IG9yIG90aGVyIFRDUCBwb3J0
IGZvciBpbmNvbWluZyBjb25uZWN0aW9ucy4gVGhlIGluaXRpYXRvciBiZWdpbnMgdGhlIGxvZ2lu
IHByb2Nlc3MgYnkgY29ubmVjdGluZyB0byB0aGF0IHdlbGwta25vd24gVENQIHBvcnQuIA0KDQpB
cyBwYXJ0IG9mIHRoZSBsb2dpbiBwcm9jZXNzLCB0aGUgaW5pdGlhdG9yIGFuZCB0YXJnZXQgTUFZ
IHdpc2ggdG8gYXV0aGVudGljYXRlIGVhY2ggb3RoZXIgYW5kIHNldCBhIHNlY3VyaXR5IGFzc29j
aWF0aW9uIHByb3RvY29sIGZvciB0aGUgc2Vzc2lvbi4gVGhpcyBjYW4gb2NjdXIgaW4gbWFueSBk
aWZmZXJlbnQgd2F5cyBhbmQgaXMgc3ViamVjdCB0byBuZWdvdGlhdGlvbi4gDQoNClNlY3VyaXR5
IGFzc29jaWF0aW9ucyBlc3RhYmxpc2hlZCBiZWZvcmUgdGhlIExvZ2luIHJlcXVlc3QgYXJlIG91
dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQgYWx0aG91Z2ggdGhleSBtYXkgcmVhbGl6
ZSBhIHJlbGF0ZWQgZnVuY3Rpb24gKGUuZy4sIGVzdGFibGlzaCBhIElQc2VjIHR1bm5lbCkuIA0K
DQpUaGUgaVNDU0kgTG9naW4gUGhhc2UgaXMgY2FycmllZCB0aHJvdWdoIExvZ2luIHJlcXVlc3Rz
IGFuZCByZXNwb25zZXMuIE9uY2Ugc3VpdGFibGUgYXV0aGVudGljYXRpb24gaGFzIG9jY3VycmVk
IGFuZCBvcGVyYXRpb25hbCBwYXJhbWV0ZXJzIGhhdmUgYmVlbiBzZXQgdGhlIGluaXRpYXRvciBt
YXkgc3RhcnQgdG8gc2VuZCBTQ1NJIGNvbW1hbmRzLiBIb3cgdGhlIHRhcmdldCBjaG9vc2VzIHRv
IGF1dGhvcml6ZSBhbiBpbml0aWF0b3IgaXMgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIGRvY3Vt
ZW50LiBBIG1vcmUgZGV0YWlsZWQgZGVzY3JpcHRpb24gb2YgdGhlIExvZ2luIFBoYXNlIGNhbiBi
ZSBmb3VuZCBpbiBjaGFwdGVyIDQuDQoNCg0KVGhlIGxvZ2luIFBEVSBpbmNsdWRlcyBhIHNlc3Np
b24gSUQgdGhhdCBpcyBjb21wb3NlZCBvZiBhbiBpbml0aWF0b3IgcGFydCBJU0lEIGFuZCBhIHRh
cmdldCBwYXJ0IFRTSUQuIEZvciBhIG5ldyBzZXNzaW9uLCB0aGUgVFNJRCBpcyBudWxsLiBBcyBw
YXJ0IG9mIHRoZSByZXNwb25zZSwgdGhlIHRhcmdldCBnZW5lcmF0ZXMgYSBUU0lELiANCg0KRHVy
aW5nIHNlc3Npb24gZXN0YWJsaXNobWVudCwgdGhlIHRhcmdldCBpZGVudGlmaWVzIHRoZSBTQ1NJ
IGluaXRpYXRvciBwb3J0ICh0aGUgIkkiIGluIHRoZSAiSV9UIG5leHVzIikgdGhyb3VnaCB0aGUg
dmFsdWUgcGFpciBJbml0aWF0b3JOYW1lIGFuZCBJU0lEIChJbml0aWF0b3JOYW1lIGlzIGRlc2Ny
aWJlZCBsYXRlciBpbiB0aGlzIHBhcnQpLiAgQW55IHN0YXRlIGFzc29jaWF0ZWQgd2l0aCB0aGUg
U0NTSSBpbml0aWF0b3IgcG9ydCB0aGF0IGlzIHBlcnNpc3RlbnQgYWNjb3JkaW5nIHRvIHRoZSBT
Q1NJIHN0YW5kYXJkcyAoZS5nLiwgcGVyc2lzdGVudCByZXNlcnZhdGlvbnMpIGlzIGFzc29jaWF0
ZWQgd2l0aCB0aGUgU0NTSSBpbml0aWF0b3IgcG9ydCBiYXNlZCBvbiB0aGlzIGlkZW50aXR5LiAg
QW55IHN0YXRlIGFzc29jaWF0ZWQgd2l0aCB0aGUgU0NTSSB0YXJnZXQgcG9ydCAodGhlICJUIiBp
biB0aGUgIklfVCBuZXh1cyIpIGlzIGlkZW50aWZpZWQgZXh0ZXJuYWxseSBieSB0aGUgVGFyZ2V0
TmFtZSBhbmQgcG9ydGFsIGdyb3VwIHRhZyAoc2VlIDEuNS4xKSBhbmQgaW50ZXJuYWxseSBpbiBh
biBpbXBsZW1lbnRhdGlvbiBkZXBlbmRlbnQgd2F5LiBBcyBJU0lEIGlzIHVzZWQgdG8gaWRlbnRp
ZnkgcGVyc2lzdGVudCBzdGF0ZSBpdCBpcyBzdWJqZWN0IHRvIHJldXNlIHJlc3RyaWN0aW9ucyAo
c2VlIDEuNS4zKS4NCg0KQmVmb3JlIGZ1bGwgZmVhdHVyZSBwaGFzZSBpcyBlc3RhYmxpc2hlZCwg
b25seSBMb2dpbiBQRFVzIGFyZSBhbGxvd2VkLiBBbnkgb3RoZXIgUERVLCB3aGVuIHJlY2VpdmVk
IGF0IGluaXRpYXRvciBvciB0YXJnZXQsIGlzIGEgcHJvdG9jb2wgZXJyb3IgYW5kIE1VU1QgcmVz
dWx0IGluIHRoZSBjb25uZWN0aW9uIGJlaW5nIHRlcm1pbmF0ZWQuDQoNClNvbWUgdGV4dCBjb21t
YW5kIHBhcmFtZXRlcnMgYXJlIGFsc28gYWxsb3dlZCBvbmx5IGluIGZ1bGwgZmVhdHVyZSBwaGFz
ZSAoZS5nLiwgU2VuZFRhcmdldHMpLiANCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoy
LjEyIExvZ2luIFJlcXVlc3QNCg0KQWZ0ZXIgZXN0YWJsaXNoaW5nIGEgVENQIGNvbm5lY3Rpb24g
YmV0d2VlbiBhbiBpbml0aWF0b3IgYW5kIGEgdGFyZ2V0LCB0aGUgaW5pdGlhdG9yIE1VU1Qgc3Rh
cnQgYSBMb2dpbiBwaGFzZSB0byBnYWluIGZ1cnRoZXIgYWNjZXNzIHRvIHRoZSB0YXJnZXQncyBy
ZXNvdXJjZXMuIA0KDQpUaGUgTG9naW4gUGhhc2UgKHNlZSBjaGFwdGVyIDQpIGNvbnNpc3RzIG9m
IGEgc2VxdWVuY2Ugb2YgTG9naW4gcmVxdWVzdHMgYW5kIHJlc3BvbnNlcykgdGhhdCBjYXJyeSB0
aGUgc2FtZSBJbml0aWF0b3IgVGFzayBUYWcuDQoNCg0KDQoNCkJ5dGUgLyAgICAwICAgICAgIHwg
ICAgICAgMSAgICAgICB8ICAgICAgIDIgICAgICAgfCAgICAgICAzICAgICAgIHwNCiAgIC8gICAg
ICAgICAgICAgIHwgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAg
IHwNCiAgfDcgNiA1IDQgMyAyIDEgMHw3IDYgNSA0IDMgMiAxIDB8NyA2IDUgNCAzIDIgMSAwfDcg
NiA1IDQgMyAyIDEgMHwNCiAgKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0t
LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSsNCiAwfFh8SXwgMHgwMyAgICAgIHxGfEMgMCAwfCBD
TnhTRyB8IFZlcnNpb24tbWF4ICAgfCBWZXJzaW9uLW1pbiAgIHwNCiAgKy0tLS0tLS0tLS0tLS0t
LSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSsNCiA0fCBS
ZXNlcnZlZCAgICAgIHwgRGF0YVNlZ21lbnRMZW5ndGggICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIHwNCiAgKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0t
Ky0tLS0tLS0tLS0tLS0tLSsNCiA4fCBDSUQgICAgICAgICAgICAgICAgICAgICAgICAgICB8IFJl
c2VydmVkICAgICAgICAgICAgICAgICAgICAgIHwNCiAgKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0t
LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSsNCjEyfCBJU0lEICAgICAg
ICAgICAgICAgICAgICAgICAgICB8VFNJRCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAg
Ky0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0t
LS0tLS0tLSsNCjE2fCBJbml0aWF0b3IgVGFzayBUYWcgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIHwNCiAgKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0r
LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSsNCjIwfCBSZXNlcnZlZCAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgKy0tLS0tLS0t
LS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSsN
CjI0fCBDbWRTTiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHwNCiAgKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0t
LS0tLS0tKy0tLS0tLS0tLS0tLS0tLSsNCjI4fCBFeHBTdGF0U04gICBvciAgIFJlc2VydmVkICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgKy0tLS0tLS0tLS0tLS0tLSst
LS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSsNCjMyLyBSZXNl
cnZlZCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IC8NCiArLyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIC8NCiAgKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0t
LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSsNCjQ4LyBEYXRhU2VnbWVudCAtIExvZ2luIFBhcmFt
ZXRlcnMgaW4gVGV4dCBDb21tYW5kIEZvcm1hdCAgICAgICAgIC8NCiArLyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC8NCiAgKy0t
LS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t
LS0tLSsNCg0KMi4xMi4xIFggLSBSZXN0YXJ0IENvbm5lY3Rpb24vU2Vzc2lvbg0KDQpJZiB0aGlz
IGJpdCBpcyBzZXQgdG8gMSB0aGVuIHRoaXMgY29tbWFuZCBpcyBhbiBhdHRlbXB0IHRvIHJlaW5z
dGF0ZSBhIGZhaWxlZCBjb25uZWN0aW9uIG9yIGEgZmFpbGVkIHNlc3Npb24uIA0KDQpJZiBUU0lE
IGlzIG5vdCAwIHRoZW4gdGhpcyBpcyBhIGNvbm5lY3Rpb24gcmVzdGFydC4gQ0lEIGRvZXMgbm90
IGNoYW5nZSBhbmQgdGhpcyBjb21tYW5kIHBlcmZvcm1zIGZpcnN0IHRoZSBsb2dvdXQgZnVuY3Rp
b24gb2YgdGhlIG9sZCBjb25uZWN0aW9uIGlmIGFuIGV4cGxpY2l0IGxvZ291dCB3YXMgbm90IHBl
cmZvcm1lZCBlYXJsaWVyLiBJbiBzZXNzaW9ucyB3aXRoIGEgc2luZ2xlIGNvbm5lY3Rpb24sIHRo
aXMgbWF5IGltcGx5IHRoZSBvcGVuaW5nIG9mIGEgc2Vjb25kIGNvbm5lY3Rpb24gd2l0aCB0aGUg
c29sZSBwdXJwb3NlIG9mIGNsZWFuaW5nLXVwIHRoZSBmaXJzdC4gVGFyZ2V0cyBzaG91bGQgc3Vw
cG9ydCBvcGVuaW5nIGEgc2Vjb25kIGNvbm5lY3Rpb24gZXZlbiB3aGVuIG5vdCBzdXBwb3J0aW5n
IG11bHRpcGxlIGNvbm5lY3Rpb25zIGluIGZ1bGwgZmVhdHVyZSBwaGFzZS4gIEEgcmVzdGFydCBs
b2dpbiBpbmRpY2F0ZXMgdG8gdGhlIHRhcmdldCB0aGF0IGNvbW1hbmRzIG1heSBiZSBtaXNzaW5n
IGFuZCB0aGVyZWZvcmUgaXQgTVVTVCBiZSBpc3N1ZWQgYXMgYW4gaW1tZWRpYXRlIGNvbW1hbmQu
DQoNCklmIFRTSUQgaXMgMCB0aGVuIHRoaXMgaXMgYSBzZXNzaW9uIHJlc3RhcnQuIFRoZSBvbGQg
c2Vzc2lvbiB3aXRoIHRoZSBzYW1lIGluaXRpYXRvciBhbmQgSVNJRCBpcyB0ZXJtaW5hdGVkIGFu
ZCBhIG5ldyBzZXNzaW9uIGlzIGNyZWF0ZWQuIA0KDQpBIHNlc3Npb24gcmVzdGFydCBNVVNUIGJl
IGlzc3VlZCBPTkxZIGlmIGFuIG9sZCBzZXNzaW9uIGV4aXN0cy4NCg0KVGhlIFggYml0IE1BWSBi
ZSBzZXQgb25lIE9OTFkgb24gdGhlIGZpcnN0IHJlcXVlc3Qgb2YgdGhlIExvZ2luIHBoYXNlLg0K
DQoyLjEyLjIgSSAtIEltbWVkaWF0ZSANCg0KTG9naW4gU0hPVUxEIGJlIGlzc3VlZCBhcyBhbiBp
bW1lZGlhdGUgcmVxdWVzdCAoST0xKS4NCg0KMi4xMi4zIEYgKEZpbmFsKSBCaXQNCg0KSWYgc2V0
IHRvIDEgaW5kaWNhdGVzIHRoYXQgdGhlIGluaXRpYXRvciBoYXMgbm8gbW9yZSBwYXJhbWV0ZXJz
IHRvIHNldC4NCg0KMi4xMi40IEMgKENvbnRpbnVhdGlvbikgQml0DQoNCklmIHNldCB0byAxIGlu
ZGljYXRlcyB0aGF0IHRoaXMgaXMgbm90IHRoZSBmaXJzdCBMb2dpbiByZXF1ZXN0IGluIHRoZSBM
b2dpbiBQaGFzZQ0KDQoyLjEyLjUgQ054U0cNCg0KVGhyb3VnaCB0aGlzIGZpZWxkLCBjYWxsZWQg
Q3VycmVudC1OZXh0IFN0YWdlIChDTnhTRyksIHRoZSBMb2dpbiBuZWdvdGlhdGlvbiBjb21tYW5k
cyBhbmQgcmVzcG9uc2VzIGFyZSBhc3NvY2lhdGVkIHdpdGggYSBzcGVjaWZpYyBzdGFnZSBpbiB0
aGUgc2Vzc2lvbiAoU2VjdXJpdHlOZWdvdGlhdGlvbiwgTG9naW5PcGVyYXRpb25hbE5lZ290aWF0
aW9uLCBGdWxsUGhhc2VPcGVyYXRpb25hbE5lZ290aWF0aW9ucykgYW5kIG1heSBpbmRpY2F0ZSB0
aGUgbmV4dCBzdGFnZSB0aGV5IHdhbnQgdG8gbW92ZSB0byAoc2VlIGNoYXB0ZXIgNCkuDQogIA0K
VGhlIGN1cnJlbnQgc3RhZ2UgaXMgY29kZWQgaW4gYml0cyAwLTEgYW5kIHRoZSBuZXh0IHN0YWdl
IGluIGJpdHMgMi0zLiBUaGUgbmV4dCBzdGFnZSB2YWx1ZSBpcyB2YWxpZCBvbmx5IHdoZW4gdGhl
IEYgYml0IGlzIDEgYW5kIGNhbiBiZSBpZ25vcmVkIG90aGVyd2lzZS4NCg0KVGhlIHN0YWdlIGNv
ZGVzIGFyZToNCg0KLSAwIC0gU2VjdXJpdHlOZWdvdGlhdGlvbg0KLSAxIC0gTG9naW5PcGVyYXRp
b25hbE5lZ290aWF0aW9uDQotIDMgLSBGdWxsRmVhdHVyZVBoYXNlDQogDQoyLjEyLjYgVmVyc2lv
bi1tYXgNCg0KTWF4aW11bSBWZXJzaW9uIG51bWJlciBzdXBwb3J0ZWQuDQoNCkFsbCBMb2dpbiBy
ZXF1ZXN0cyB3aXRoaW4gdGhlIExvZ2luIHBoYXNlIE1VU1QgY2FycnkgdGhlIHNhbWUgVmVyc2lv
bi1tYXguDQoNClRoZSB0YXJnZXQgTVVTVCB1c2UgdGhlIHZhbHVlIHByZXNlbnRlZCB3aXRoIHRo
ZSBsb2dpbiByZXF1ZXN0IHdpdGggQz0wIGFuZCBNQVkgY2hlY2sgdGhlIHZhbHVlIHdoZW4gQz0x
Lg0KDQoyLjEyLjcgVmVyc2lvbi1taW4NCg0KTWluaW11bSBWZXJzaW9uIHN1cHBvcnRlZA0KVGhl
IHZlcnNpb24gbnVtYmVyIG9mIHRoZSBjdXJyZW50IGRyYWZ0IGlzIDB4Mi4NCg0KQWxsIExvZ2lu
IHJlcXVlc3RzIHdpdGhpbiB0aGUgTG9naW4gcGhhc2UgTVVTVCBjYXJyeSB0aGUgc2FtZSBWZXJz
aW9uLW1pbi4NCg0KVGhlIHRhcmdldCBNVVNUIHVzZSB0aGUgdmFsdWUgcHJlc2VudGVkIHdpdGgg
dGhlIGxvZ2luIHJlcXVlc3Qgd2l0aCBDPTAgYW5kIE1BWSBjaGVjayB0aGUgdmFsdWUgd2hlbiBD
PTEuDQoNCjIuMTIuOCBDb25uZWN0aW9uIElEIC0gQ0lEDQoNClRoaXMgaXMgYSB1bmlxdWUgSUQg
Zm9yIHRoaXMgY29ubmVjdGlvbiB3aXRoaW4gdGhlIHNlc3Npb24uDQoNCkFsbCBMb2dpbiByZXF1
ZXN0cyB3aXRoaW4gdGhlIExvZ2luIHBoYXNlIE1VU1QgY2FycnkgdGhlIHNhbWUgQ0lELg0KDQpU
aGUgdGFyZ2V0IE1VU1QgdXNlIHRoZSB2YWx1ZSBwcmVzZW50ZWQgd2l0aCB0aGUgbG9naW4gcmVx
dWVzdCB3aXRoIEM9MCBhbmQgTUFZIGNoZWNrIHRoZSB2YWx1ZSB3aGVuIEM9MS4NCg0KMi4xMi45
IElTSUQNCg0KVGhpcyBpcyBhbiBpbml0aWF0b3ItZGVmaW5lZCBzZXNzaW9uLWlkZW50aWZpZXIu
ICBJdCBNVVNUIGJlIHRoZSBzYW1lIGZvciBhbGwgY29ubmVjdGlvbnMgd2l0aGluIGEgc2Vzc2lv
bi4gIEEgU0NTSSBpbml0aWF0b3IgcG9ydCBpcyB1bmlxdWVseSBpZGVudGlmaWVkIGJ5IHRoZSB2
YWx1ZSBwYWlyIChJbml0aWF0b3JOYW1lLCBJU0lEKS4NCg0KV2hlbiBhIHRhcmdldCBkZXRlY3Rz
IGFuIGF0dGVtcHQgdG8gb3BlbiBhIG5ldyBzZXNzaW9uIGJ5IHRoZSBzYW1lIFNDU0kgaW5pdGlh
dG9yIHBvcnQgKHNhbWUgSW5pdGlhdG9yTmFtZSBhbmQgSVNJRCkgdG8gdGhlIHNhbWUgdGFyZ2V0
IHBvcnRhbCBncm91cCBpdCBNVVNUIGNoZWNrIGlmIHRoZSBvbGQgc2Vzc2lvbiBpcyBzdGlsbCBh
Y3RpdmUuICBJZiBpdCBpcyBub3QgYWN0aXZlIGFuZCB0aGVuIHRoZSBvbGQtc2Vzc2lvbiBtdXN0
IGJlIHJlc2V0IGJ5IHRoZSB0YXJnZXQgYW5kIGEgbmV3IHNlc3Npb24gaXMgZXN0YWJsaXNoZWQu
IE90aGVyd2lzZSwgdGhlIExvZ2luIE1VU1QgYmUgdGVybWluYXRlZCB3aXRoIGEgTG9naW4gUmVz
cG9uc2Ugb2YgIlNlc3Npb24gYWxyZWFkeSBvcGVuIHdpdGggdGhpcyBpbml0aWF0b3IiLg0KDQpB
bGwgTG9naW4gcmVxdWVzdHMgd2l0aGluIHRoZSBMb2dpbiBwaGFzZSBNVVNUIGNhcnJ5IHRoZSBz
YW1lIElTSUQuDQoNClRoZSB0YXJnZXQgTVVTVCB1c2UgdGhlIHZhbHVlIHByZXNlbnRlZCB3aXRo
IHRoZSBsb2dpbiByZXF1ZXN0IHdpdGggQz0wIGFuZCBNQVkgY2hlY2sgdGhlIHZhbHVlIHdoZW4g
Qz0xLg0KDQoyLjEyLjEwIENtZFNODQoNCkNtZFNOIGlzIGVpdGhlciB0aGUgaW5pdGlhbCBjb21t
YW5kIHNlcXVlbmNlIG51bWJlciBvZiBhIHNlc3Npb24gKGZvciB0aGUgZmlyc3QgTG9naW4gb2Yg
YSBzZXNzaW9uIC0gdGhlICJsZWFkaW5nIiBsb2dpbikgb3IgdGhlIGNvbW1hbmQgc2VxdWVuY2Ug
bnVtYmVyIGluIHRoZSBjb21tYW5kIHN0cmVhbSAoZS5nLiwgaWYgdGhlIGxlYWRpbmcgbG9naW4g
Y2FycmllcyB0aGUgQ21kU04gMTIzIHRoZSBuZXh0IGNvbW1hbmQgY2FycmllcyB0aGUgbnVtYmVy
IDEyNCBldGMuKS4gDQoNCjIuMTIuMTEgRXhwU3RhdFNODQoNClRoaXMgaXMgRXhwU3RhdFNOIGZv
ciB0aGUgb2xkIGNvbm5lY3Rpb24uDQoNClRoaXMgZmllbGQgaXMgdmFsaWQgb25seSBpZiB0aGUg
TG9naW4gcmVxdWVzdCByZXN0YXJ0cyBhIGNvbm5lY3Rpb24gKGkuZS4sIFggYml0IGlzIDEgYW5k
IFRTSUQgaXMgbm90IHplcm8pLg0KDQoNCjIuMTIuMTIgTG9naW4gUGFyYW1ldGVycw0KDQpUaGUg
aW5pdGlhdG9yIE1BWSBwcm92aWRlIHNvbWUgYmFzaWMgcGFyYW1ldGVycyBpbiBvcmRlciB0byBl
bmFibGUgdGhlIHRhcmdldCB0byBkZXRlcm1pbmUgaWYgdGhlIGluaXRpYXRvciBtYXkgdXNlIHRo
ZSB0YXJnZXQncyByZXNvdXJjZXMgYW5kIHRoZSBpbml0aWFsIHRleHQgcGFyYW1ldGVycyBmb3Ig
dGhlIHNlY3VyaXR5IGV4Y2hhbmdlLiAgVGhlIGZvcm1hdCBvZiB0aGUgcGFyYW1ldGVycyBpcyBh
cyBzcGVjaWZpZWQgZm9yIHRoZSBUZXh0IENvbW1hbmQuICAgIEtleXMgYW5kIHRoZWlyIGV4cGxh
bmF0aW9ucyBhcmUgbGlzdGVkIGluIHRoZSBBcHBlbmRpeGVzLg0KDQoNCiANCg0KMi4xMyBMb2dp
biBSZXNwb25zZQ0KDQpUaGUgTG9naW4gUmVzcG9uc2UgaW5kaWNhdGVzIHRoZSBwcm9ncmVzcyBh
bmQvb3IgZW5kIG9mIHRoZSBsb2dpbiBwaGFzZS4gIE5vdGUgdGhhdCBhZnRlciBzZWN1cml0eSBp
cyBlc3RhYmxpc2hlZCwgdGhlIGxvZ2luIHJlc3BvbnNlIGlzIGF1dGhlbnRpY2F0ZWQuDQoNCg0K
Qnl0ZSAvICAgIDAgICAgICAgfCAgICAgICAxICAgICAgIHwgICAgICAgMiAgICAgICB8ICAgICAg
IDMgICAgICAgfA0KICAgLyAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAgICAg
ICAgICB8ICAgICAgICAgICAgICAgfA0KICB8NyA2IDUgNCAzIDIgMSAwfDcgNiA1IDQgMyAyIDEg
MHw3IDYgNSA0IDMgMiAxIDB8NyA2IDUgNCAzIDIgMSAwfA0KICArLS0tLS0tLS0tLS0tLS0tKy0t
LS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KIDB8MXwxfCAw
eDIzICAgICAgfEZ8MCAwIDB8IENOeFNHIHwgVmVyc2lvbi1tYXggICB8IFZlcnNpb24tYWN0aXZl
fA0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0t
LS0tLS0tLS0tLS0tKw0KIDR8IFJlc2VydmVkICAgICAgfCBEYXRhU2VnbWVudExlbmd0aCAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgfA0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t
LS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KIDh8IFJlc2VydmVkICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICArLS0t
LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t
LS0tKw0KMTJ8IElTSUQgICAgICAgICAgICAgICAgICAgICAgICAgIHxUU0lEICAgICAgICAgICAg
ICAgICAgICAgICAgICAgfA0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0t
LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KMTZ8IEluaXRpYXRvciBUYXNrIFRhZyAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICArLS0tLS0tLS0tLS0t
LS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KMjB8
IFJlc2VydmVkICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgfA0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t
LS0rLS0tLS0tLS0tLS0tLS0tKw0KMjR8IFN0YXRTTiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0t
LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KMjh8IEV4cENtZFNO
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0K
ICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0t
LS0tLS0tLS0tKw0KMzJ8IE1heENtZFNOICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgfA0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t
LSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KMzZ8IFN0YXR1cy1DbGFzcyAgfCBT
dGF0dXMtRGV0YWlsIHwgUmVzZXJ2ZWQgICAgICAgICAgICAgICAgICAgICAgfA0KICArLS0tLS0t
LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0t
Kw0KNDAvIFJlc2VydmVkICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgLw0KICsvICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgLw0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t
LS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KNDh8IERpZ2VzdHMgaWYgYW55
Li4uICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICArLS0t
LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t
LS0tKw0KICAvIERhdGFTZWdtZW50IC0gTG9naW4gUGFyYW1ldGVycyBpbiBUZXh0IENvbW1hbmQg
Rm9ybWF0ICAgICAgICAgLw0KICsvICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgLw0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0t
LS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KDQoyLjEzLjEgRiAoRmlu
YWwpIGJpdA0KDQpGaW5hbCBiaXQgaXMgc2V0IHRvIDEgYXMgYW4gaW5kaWNhdG9yIG9mIGVuZCBv
ZiBzdGFnZS4gSWYgdGhlIG5leHQgc3RhZ2UgcGFydCBpbiBDTnhTRyBpcyBGdWxsRmVhdHVyZVBo
YXNlIGFuZCB0aGUgRiBiaXQgaXMgc2V0IHRvIDEgdGhlbiB0aGlzIGlzIGFsc28gdGhlIEZpbmFs
IExvZ2luIFJlc3BvbnNlIChzZWUgY2hhcHRlciA0KS4gQSBGaW5hbCBiaXQgb2YgMCBpbmRpY2F0
ZXMgYSAicGFydGlhbCIgcmVzcG9uc2UsIHdoaWNoIG1lYW5zICJtb3JlIG5lZ290aWF0aW9uIG5l
ZWRlZCIuDQoNCkEgbG9naW4gcmVzcG9uc2Ugd2l0aCBhIEYgYml0IHNldCB0byAxIE1VU1QgTk9U
IGNvbnRhaW4ga2V5PXZhbHVlIHBhaXJzIHRoYXQgbWF5IHJlcXVpcmUgYWRkaXRpb25hbCBhbnN3
ZXJzIGZyb20gdGhlIGluaXRpYXRvciB3aXRoaW4gdGhlIHNhbWUgc3RhZ2UuDQoNCg0KMi4xMy4y
IFZlcnNpb24tbWF4DQoNClRoaXMgaXMgdGhlIGhpZ2hlc3QgdmVyc2lvbiBudW1iZXIgc3VwcG9y
dGVkIGJ5IHRoZSB0YXJnZXQuDQoNCkFsbCBMb2dpbiByZXNwb25zZXMgd2l0aGluIHRoZSBMb2dp
biBwaGFzZSBNVVNUIGNhcnJ5IHRoZSBzYW1lIFZlcnNpb24tbWF4Lg0KDQpUaGUgaW5pdGlhdG9y
IE1VU1QgdXNlIHRoZSB2YWx1ZSBwcmVzZW50ZWQgYXMgcmVzcG9uc2UgdG8gdGhlIGxvZ2luIHJl
cXVlc3Qgd2l0aCBDPTAgYW5kIE1BWSBjaGVjayB0aGUgdmFsdWUgb3RoZXJ3aXNlLg0KDQoNCjIu
MTMuMyBWZXJzaW9uLWFjdGl2ZQ0KDQpJbmRpY2F0ZXMgdGhlIHZlcnNpb24gc3VwcG9ydGVkICh0
aGUgaGlnaGVzdCB2ZXJzaW9uIHN1cHBvcnRlZCBieSB0aGUgdGFyZ2V0IGFuZCBpbml0aWF0b3Ip
LiBJZiB0aGUgdGFyZ2V0IGRvZXMgbm90IHN1cHBvcnQgYSB2ZXJzaW9uIHdpdGhpbiB0aGUgcmFu
Z2Ugc3BlY2lmaWVkIGJ5IHRoZSBpbml0aWF0b3IsIHRoZSB0YXJnZXQgcmVqZWN0cyB0aGUgbG9n
aW4gYW5kIHRoaXMgZmllbGQgaW5kaWNhdGVzIHRoZSBsb3dlc3QgdmVyc2lvbiBzdXBwb3J0ZWQg
YnkgdGhlIHRhcmdldC4NCg0KQWxsIExvZ2luIHJlc3BvbnNlcyB3aXRoaW4gdGhlIExvZ2luIHBo
YXNlIE1VU1QgY2FycnkgdGhlIHNhbWUgVmVyc2lvbi1hY3RpdmUuDQoNClRoZSBpbml0aWF0b3Ig
TVVTVCB1c2UgdGhlIHZhbHVlIHByZXNlbnRlZCBhcyByZXNwb25zZSB0byB0aGUgbG9naW4gcmVx
dWVzdCB3aXRoIEM9MCBhbmQgTUFZIGNoZWNrIHRoZSB2YWx1ZSBvdGhlcndpc2UuDQoNCjIuMTMu
NCBUU0lEDQoNClRoZSBUU0lEIGlzIGEgdGFnIHRoYXQgaWRlbnRpZmllcyB0aGUgU0NTSSBpbml0
aWF0b3IgcG9ydC4gVFNJRCBpcyBzZXQgYnkgdGhlIHRhcmdldC4gIEl0IE1VU1QgYmUgdmFsaWQg
b25seSBpbiB0aGUgZmluYWwgbG9naW4gcmVzcG9uc2UgKHRoZSByZXNwb25zZSBoYXZpbmcgRj0x
IGFuZCB0aGUgbmVzdCBwYXJ0IG9mIENOeFNHIGluIGJvdGggcmVxdWVzdCBhbmQgcmVzcG9uc2Ug
aW5kaWNhdGluZyBGdWxsRmVhdHVyZVBoYXNlLg0KIA0KMi4xMy41IFN0YXRTTg0KDQpGb3IgdGhl
IGZpcnN0IExvZ2luIFJlc3BvbnNlICh0aGUgcmVzcG9uc2UgdG8gYSBMb2dpbiBSZXF1ZXN0IHdp
dGggQz0wKSB0aGlzIGlzIHRoZSBzdGFydGluZyBzdGF0dXMgU2VxdWVuY2UgTnVtYmVyIGZvciB0
aGUgY29ubmVjdGlvbiAodGhlIG5leHQgcmVzcG9uc2Ugb2YgYW55IGtpbmQgd2lsbCBjYXJyeSB0
aGlzIG51bWJlciArIDEpLiBUaGlzIGZpZWxkIGlzIHZhbGlkIG9ubHkgaWYgdGhlIFN0YXR1cyBD
bGFzcyBpcyAwLg0KDQoyLjEzLjYgU3RhdHVzLUNsYXNzIGFuZCBTdGF0dXMtRGV0YWlsDQoNClRo
ZSBTdGF0dXMgcmV0dXJuZWQgaW4gYSBMb2dpbiBSZXNwb25zZSBpbmRpY2F0ZXMgdGhlIGV4ZWN1
dGlvbiBzdGF0dXMgb2YgdGhlIGxvZ2luIHBoYXNlLiBUaGUgc3RhdHVzIGluY2x1ZGVzOg0KDQpT
dGF0dXMtQ2xhc3MgDQpTdGF0dXMtRGV0YWlsDQoNClRoZSBTdGF0dXMtQ2xhc3MgaXMgc3VmZmlj
aWVudCBmb3IgYSBzaW1wbGUgaW5pdGlhdG9yIHRvIHVzZSB3aGVuIGhhbmRsaW5nIGVycm9ycywg
d2l0aG91dCBoYXZpbmcgdG8gbG9vayBhdCB0aGUgU3RhdHVzLURldGFpbC4gIFRoZSBTdGF0dXMt
RGV0YWlsIGFsbG93cyBmaW5lci1ncmFpbmVkIGVycm9yIHJlY292ZXJ5IGZvciBtb3JlIHNvcGhp
c3RpY2F0ZWQgaW5pdGlhdG9ycywgYXMgd2VsbCBhcyBiZXR0ZXIgaW5mb3JtYXRpb24gZm9yIGVy
cm9yIGxvZ2dpbmcuDQoNClRoZSBzdGF0dXMgY2xhc3NlcyBhcmUgYXMgZm9sbG93czoNCg0KMCAt
IFN1Y2Nlc3MgLSBpbmRpY2F0ZXMgdGhhdCB0aGUgaVNDU0kgdGFyZ2V0IHN1Y2Nlc3NmdWxseSBy
ZWNlaXZlZCwgdW5kZXJzdG9vZCwgYW5kIGFjY2VwdGVkIHRoZSByZXF1ZXN0LiBUaGUgbnVtYmVy
aW5nIGZpZWxkcyAoU3RhdFNOLCBFeHBDbWRTTiwgTWF4Q21kU04gYXJlIHZhbGlkIG9ubHkgaWYg
U3RhdHVzLUNsYXNzIGlzIDApLg0KDQoxIC0gUmVkaXJlY3Rpb24gLSBpbmRpY2F0ZXMgdGhhdCBm
dXJ0aGVyIGFjdGlvbiBtdXN0IGJlIHRha2VuIGJ5IHRoZSBpbml0aWF0b3IgdG8gY29tcGxldGUg
dGhlIHJlcXVlc3QuIFRoaXMgaXMgdXN1YWxseSBkdWUgdG8gdGhlIHRhcmdldCBtb3ZpbmcgdG8g
YSBkaWZmZXJlbnQgYWRkcmVzcy4gQWxsIG9mIHRoZSByZWRpcmVjdGlvbiBzdGF0dXMgY2xhc3Mg
cmVzcG9uc2VzIE1VU1QgcmV0dXJuIG9uZSBvciBtb3JlIHRleHQga2V5IHBhcmFtZXRlcnMgb2Yg
dGhlIHR5cGUgIlRhcmdldEFkZHJlc3MiLCB3aGljaCBpbmRpY2F0ZXMgdGhlIHRhcmdldCdzIG5l
dyBhZGRyZXNzLg0KDQoyIC0gSW5pdGlhdG9yIEVycm9yIC0gaW5kaWNhdGVzIHRoYXQgdGhlIGlu
aXRpYXRvciBsaWtlbHkgY2F1c2VkIHRoZSBlcnJvci4gVGhpcyBNQVkgYmUgZHVlIHRvIGEgcmVx
dWVzdCBmb3IgYSByZXNvdXJjZSBmb3Igd2hpY2ggdGhlIGluaXRpYXRvciBkb2VzIG5vdCBoYXZl
IHBlcm1pc3Npb24uICBUaGUgcmVxdWVzdCBzaG91bGQgbm90IGJlIHRyaWVkIGFnYWluLg0KDQoz
IC0gVGFyZ2V0IEVycm9yIC0gaW5kaWNhdGVzIHRoYXQgdGhlIHRhcmdldCBzZWVzIG5vIGVycm9y
cyBpbiB0aGUgaW5pdGlhdG9yknMgbG9naW4gcmVxdWVzdCwgYnV0IGlzIGN1cnJlbnRseSBpbmNh
cGFibGUgb2YgZnVsZmlsbGluZyB0aGUgcmVxdWVzdC4gIFRoZSBjbGllbnQgbWF5IHJlLXRyeSB0
aGUgc2FtZSBsb2dpbiByZXF1ZXN0IGxhdGVyLg0KDQpUaGUgdGFibGUgYmVsb3cgc2hvd3MgYWxs
IG9mIHRoZSBjdXJyZW50bHkgYWxsb2NhdGVkIHN0YXR1cyBjb2Rlcy4gIFRoZSBjb2RlcyBhcmUg
aW4gaGV4YWRlY2ltYWw7IHRoZSBmaXJzdCBieXRlIGlzIHRoZSBzdGF0dXMgY2xhc3MgYW5kIHRo
ZSBzZWNvbmQgYnl0ZSBpcyB0aGUgc3RhdHVzIGRldGFpbC4gIFRoZSBhbGxvd2FibGUgc3RhdGUg
b2YgdGhlIEZpbmFsIChGKSBiaXQgaW4gcmVzcG9uc2VzIHdpdGggZWFjaCBvZiB0aGUgY29kZXMg
aXMgYWxzbyBkaXNwbGF5ZWQuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpTdGF0dXMgICAgICAgIHwgQ29kZSB8Rmlu
YWx8ICAgRGVzY3JpcHRpb24NCiAgICAgICAgICAgICAgfChoZXgpIHwgYml0IHwNCi0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
DQpBY2NlcHQgTG9naW4gIHwgMDAwMCB8IDEvMCB8IExvZ2luIGlzIE9LLCBtb3ZpbmcgdG8gRnVs
bCBGZWF0dXJlDQogICAgICAgICAgICAgIHwgICAgICB8ICAgICB8IFBoYXNlIG9yIExvZ2luT3Bl
cmF0aW9uYWxOZWdvdGlhdGlvbiANCiAgICAgICAgICAgICAgfCAgICAgIHwgICAgIHwgc3RhZ2Ug
KCoxKQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0NCkF1dGhlbnRpY2F0ZSAgfCAwMDAxIHwgMCAgIHwgVGhlIGlTQ1NJIFRh
cmdldE5hbWUgKElUTikgZXhpc3RzIGFuZCANCiAgICAgICAgICAgICAgfCAgICAgIHwgICAgIHwg
YXV0aGVudGljYXRpb24gcHJvY2VlZHMuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KaVNDU0kgVGFyZ2V0ICB8IDAwMDIg
fCAwICAgfCBUaGUgSVROIG11c3QgYmUgcHJvdmlkZWQgIA0KTmFtZSByZXF1aXJlZCB8ICAgICAg
fCAgICAgfCBmb3IgYXV0aGVudGljYXRpb24gdG8gcHJvY2VlZC4NCi0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUYXJnZXQg
TW92ZWQgIHwgMDEwMSB8IDEgICB8IFRoZSByZXF1ZXN0ZWQgSVROIGhhcyBtb3ZlZA0KVGVtcG9y
YXJpbHkgICB8ICAgICAgfCAgICAgfCB0ZW1wb3JhcmlseSB0byB0aGUgYWRkcmVzcyBwcm92aWRl
ZC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tDQpUYXJnZXQgTW92ZWQgIHwgMDEwMiB8IDEgICB8IFRoZSByZXF1ZXN0ZWQg
SVROIGhhcyBtb3ZlZA0KUGVybWFuZW50bHkgICB8ICAgICAgfCAgICAgfCBwZXJtYW5lbnRseSB0
byB0aGUgYWRkcmVzcyBwcm92aWRlZC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpJbml0aWF0b3IgICAgIHwgMDIwMCB8
IDEgICB8IE1pc2NlbGxhbmVvdXMgaVNDU0kgaW5pdGlhdG9yIA0KRXJyb3IgICAgICAgICB8ICAg
ICAgfCAgICAgfCBlcnJvcnMNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpBdXRoZW50aWNhdGlvbnwgMDIwMSB8IDEgICB8
IFRoZSBpbml0aWF0b3IgY291bGQgbm90IGJlDQpGYWlsdXJlICAgICAgIHwgICAgICB8ICAgICB8
IHN1Y2Nlc3NmdWxseSBhdXRoZW50aWNhdGVkLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkF1dGhvcml6YXRpb24gfCAw
MjAyIHwgMSAgIHwgVGhlIGluaXRpYXRvciBpcyBub3QgYWxsb3dlZCBhY2Nlc3MNCkZhaWx1cmUg
ICAgICAgfCAgICAgIHwgICAgIHwgdG8gdGhlIGdpdmVuIHRhcmdldC4NCi0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpOb3Qg
Rm91bmQgICAgIHwgMDIwMyB8IDEgICB8IFRoZSByZXF1ZXN0ZWQgSVROIGRvZXMgbm90DQogICAg
ICAgICAgICAgIHwgICAgICB8ICAgICB8IGV4aXN0IGF0IHRoaXMgYWRkcmVzcy4NCi0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
DQpUYXJnZXQgUmVtb3ZlZHwgMDIwNCB8IDEgICB8IFRoZSByZXF1ZXN0ZWQgSVROIGhhcyBiZWVu
DQogICAgICAgICAgICAgIHwgICAgICB8ICAgICB8IHJlbW92ZWQuIE5vIGZvcndhcmRpbmcgYWRk
cmVzcyBpcw0KICAgICAgICAgICAgICB8ICAgICAgfCAgICAgfCBwcm92aWRlZC4NCi0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
DQpVbnN1cHBvcnRlZCAgIHwgMDIwNSB8IDEgICB8IFRoZSByZXF1ZXN0ZWQgaVNDU0kgdmVyc2lv
biByYW5nZSBpcyANClZlcnNpb24gICAgICAgfCAgICAgIHwgICAgIHwgbm90IHN1cHBvcnRlZCBi
eSB0aGUgdGFyZ2V0LiANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpJbml0aWF0b3IgICAgIHwgMDIwNiB8IDEgICB8IElu
dmFsaWQgVFNJRCAtIG5vIG1vcmUgY29ubmVjdGlvbnMgIA0KU0lEIGVycm9yICAgICB8ICAgICAg
fCAgICAgfCBhY2NlcHRlZCANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpNaXNzaW5nICAgICAgIHwgMDIwNyB8IDEgICB8
IE1pc3NpbmcgcGFyYW1ldGVycyAoZS5nLiwgaVNDU0kgDQpwYXJhbWV0ZXIgICAgIHwgICAgICB8
ICAgICB8IEluaXRpYXRvciBhbmQvb3IgVGFyZ2V0IE5hbWUpDQotLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ2FuJ3QgaW5j
bHVkZSB8IDAyMDggfCAxICAgfCBUYXJnZXQgZG9lcyBub3Qgc3VwcG9ydCBzZXNzaW9uICANCmlu
IHNlc3Npb24gICAgfCAgICAgIHwgICAgIHwgc3Bhbm5pbmcgdG8gdGhpcyBjb25uZWN0aW9uIChh
ZGRyZXNzKQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0NClNlc3Npb24gb3BlbiAgfCAwMjA5IHwgMSAgIHwgVGhlIGlTQ1NJ
IEluaXRpYXRvck5hbWUgYW5kIElTSUQgIA0KYWxyZWFkeSB3aXRoICB8ICAgICAgfCAgICAgfCBp
ZGVudGlmeSBhbiBleGlzdGluZyBzZXNzaW9uDQp0aGlzIEluaXRpYXRvcnwgICAgICB8ICAgICB8
IHdpdGggdGhpcyBpbml0aWF0b3INCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpTZXNzaW9uIGRvZXMgIHwgMDIwYSB8IDEg
ICB8IFRoZSBpU0NTSSBJbml0aWF0b3JOYW1lIGFuZCBJU0lEICANCm5vdCBleGlzdCB3aXRofCAg
ICAgIHwgICAgIHwgZG8gbm90IGlkZW50aWZ5IGFuIGV4aXN0aW5nIHNlc3Npb24NCnRoaXMgSW5p
dGlhdG9yfCAgICAgIHwgICAgIHwgd2l0aCB0aGlzIGluaXRpYXRvciAocmVzdGFydCkNCi0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tDQpTZXNzaW9uIHR5cGUgIHwgMDIwYiB8IDEgICB8IFRhcmdldCBkb2VzIG5vdCBzdXBwb3J0
IHRoaXMgdHlwZSBvZiAgDQpOb3Qgc3VwcG9ydGVkIHwgICAgICB8ICAgICB8IG9mIHNlc3Npb24g
KG5vdCBmcm9tIHRoaXMgSW5pdGlhdG9yKQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRhcmdldCBFcnJvciAgfCAwMzAw
IHwgMSAgIHwgVGFyZ2V0IGhhcmR3YXJlIG9yIHNvZnR3YXJlIGVycm9yLg0KICAgICAgICAgICAg
ICB8ICAgICAgfCAgICAgfCANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpTZXJ2aWNlICAgICAgIHwgMDMwMSB8IDEgICB8
IFRoZSBpU0NTSSBzZXJ2aWNlIG9yIHRhcmdldCBpcyBub3QNClVuYXZhaWxhYmxlICAgfCAgICAg
IHwgICAgIHwgY3VycmVudGx5IG9wZXJhdGlvbmFsLiANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpPdXQgb2YgICAgICAg
IHwgMDMwMiB8IDEgICB8IFRoZSB0YXJnZXQgaGFzIGluc3VmZmljaWVudCBzZXNzaW9uLCANClJl
c291cmNlcyAgICAgfCAgICAgIHwgICAgIHwgY29ubmVjdGlvbiwgb3Igb3RoZXIgcmVzb3VyY2Vz
Lg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0NCg0KKCoxKUlmIHRoZSBTdGF0dXMgaXMgImFjY2VwdCBsb2dpbiIgKDB4MDAw
MCkgdGhlIGluaXRpYXRvciBoYXMgc3RhdGVkIHRoZSBjdXJyZW50IHN0YWdlIGFzIExvZ2luT3Bl
cmF0aW9uYWxOZWdvdGlhdGlvbiAoYW5kIGlmIHRoZSBGIGJpdCB3YXMgMSB0aGUgbmV4dCBzdGFn
ZSB0byBGdWxsRmVhdHVyZVBoYXNlKS4gSWYgdGhlIHJlc3BvbnNlIEYgYml0IGlzIDEgKHRoZSBu
ZXh0IHN0YWdlIHBhcnQgaXMgYWxzbyBGdWxsRmVhdHVyZVBoYXNlIGluIGJvdGggdGhlIHJlcXVl
c3QgYW5kIHRoZSByZXNwb25zZSkgdGhlIGxvZ2luIHBoYXNlIGlzIGZpbmlzaGVkIGFuZCB0aGUg
aW5pdGlhdG9yIG1heSBwcm9jZWVkIHRvIGlzc3VlIFNDU0kgY29tbWFuZHMuIElmIHRoZSBTdGF0
dXMgaXMgImFjY2VwdCBsb2dpbiIgKDB4MDAwMCkgYW5kIHRoZSBGIGJpdCBpcyAwLCB0aGUgaW5p
dGlhdG9yIG1heSBwcm9jZWVkIHRvIG5lZ290aWF0ZSBvcGVyYXRpb25hbCBwYXJhbWV0ZXJzLg0K
IA0KSWYgdGhlIFN0YXR1cyBDbGFzcyBpcyBub3QgMCwgdGhlIGluaXRpYXRvciBhbmQgdGFyZ2V0
IE1VU1QgY2xvc2UgdGhlIFRDUCBjb25uZWN0aW9uLiANCg0KSWYgdGhlIHRhcmdldCB3aXNoZXMg
dG8gcmVqZWN0IHRoZSBsb2dpbiByZXF1ZXN0IGZvciBtb3JlIHRoYW4gb25lIHJlYXNvbiwgaXQg
c2hvdWxkIHJldHVybiB0aGUgcHJpbWFyeSByZWFzb24gZm9yIHRoZSByZWplY3Rpb24uDQoNCi0t
LS0tLS0tLS0tLS0tLS0tLS0tLQ0KNC4gTG9naW4gUGhhc2UNCg0KSW4gdGhlIHJlc3Qgb2YgdGhp
cyBjaGFwdGVyLCB3aGVuZXZlciB3ZSBtZW50aW9uIHNlY3VyaXR5IHdlIG1lYW4gc2VjdXJpdHkg
YW5kL29yIGRhdGEgaW50ZWdyaXR5Lg0KDQpUaGUgbG9naW4gcGhhc2UgZXN0YWJsaXNoZXMgYW4g
aVNDU0kgc2Vzc2lvbiBiZXR3ZWVuIGluaXRpYXRvciBhbmQgdGFyZ2V0LiBJdCBzZXRzIHRoZSBp
U0NTSSBwcm90b2NvbCBwYXJhbWV0ZXJzLCBzZWN1cml0eSBwYXJhbWV0ZXJzLCBhbmQgYXV0aGVu
dGljYXRlcyB0aGUgaW5pdGlhdG9yIGFuZCB0YXJnZXQgdG8gZWFjaCBvdGhlci4NCg0KVGhlIGxv
Z2luIHBoYXNlIGlzIGltcGxlbWVudGVkIHZpYSBsb2dpbiByZXF1ZXN0IGFuZCByZXNwb25zZXMg
b25seS4gIFRoZSB3aG9sZSBsb2dpbiBwaGFzZSBpcyBjb25zaWRlcmVkIGFzIGEgc2luZ2xlIHRh
c2sgYW5kIGhhcyBhIHNpbmdsZSBJbml0aWF0b3IgVGFzayBUYWcgKHNpbWlsYXIgdG8gdGhlIGxp
bmtlZCBTQ1NJIGNvbW1hbmRzKS4NCg0KVGhlIGxvZ2luIHBoYXNlIHNlcXVlbmNlIG9mIGNvbW1h
bmRzIGFuZCByZXNwb25zZXMgcHJvY2VlZHMgYXMgZm9sbG93czoNCg0KLSBMb2dpbiBpbml0aWFs
IHJlcXVlc3QgKEMgYml0IHNldCB0byAwKQ0KLSBMb2dpbiBwYXJ0aWFsIHJlc3BvbnNlIChvcHRp
b25hbCkgDQotIE1vcmUgTG9naW4gcmVxdWVzdHMgYW5kIHJlc3BvbnNlcyAob3B0aW9uYWwpDQot
IExvZ2luIEZpbmFsLVJlc3BvbnNlIChtYW5kYXRvcnkpDQoNClRoZSBMb2dpbiBGaW5hbC1yZXNw
b25zZSBhY2NlcHRzIG9yIHJlamVjdHMgdGhlIExvZ2luIENvbW1hbmQuDQoNClRoZSBMb2dpbiBQ
aGFzZSBNQVkgaW5jbHVkZSBhIFNlY3VyaXR5TmVnb3RpYXRpb24gc3RhZ2UgYW5kIGEgTG9naW5P
cGVyYXRpb25hbE5lZ290aWF0aW9uIHN0YWdlIGFuZCBNVVNUIGluY2x1ZGUgYXQgbGVhc3Qgb25l
IG9mIHRoZW0sIGJ1dCB0aGUgaW5jbHVkZWQgc3RhZ2UgTUFZIGJlIGVtcHR5LiANCg0KVGhlIGxv
Z2luIGFuZCB0ZXh0IGNvbW1hbmRzIGFuZCByZXNwb25zZXMgY29udGFpbiBhIGZpZWxkIHRoYXQg
aW5kaWNhdGVzIHRoZSBuZWdvdGlhdGlvbiBzdGFnZSAoU2VjdXJpdHlOZWdvdGlhdGlvbiBvciBM
b2dpbk9wZXJhdGlvbmFsTmVnb3RpYXRpb24pLiAgSWYgYm90aCBzdGFnZXMgYXJlIHVzZWQgdGhl
IFNlY3VyaXR5TmVnb3RpYXRpb24gTVVTVCBwcmVjZWRlIHRoZSBMb2dpbk9wZXJhdGlvbmFsTmVn
b3RpYXRpb24uDQoNClNvbWUgb3BlcmF0aW9uYWwgcGFyYW1ldGVycyBjYW4gYmUgbmVnb3RpYXRl
ZCBvdXRzaWRlIGxvZ2luLCB0aHJvdWdoIHRleHQgY29tbWFuZCByZXNwb25zZS4NCiANClNlY3Vy
aXR5IE1VU1QgYmUgY29tcGxldGVseSBuZWdvdGlhdGVkIHdpdGhpbiB0aGUgTG9naW4gUGhhc2Ug
b3IgcHJvdmlkZWQgYnkgZXh0ZXJuYWwgbWVhbnMgKGUuZy4sIElQU2VjKS4NCg0KSW4gc29tZSBl
bnZpcm9ubWVudHMsIGEgdGFyZ2V0IG9yIGFuIGluaXRpYXRvciBpcyBub3QgaW50ZXJlc3RlZCBp
biBhdXRoZW50aWNhdGluZyBpdHMgY291bnRlcnBhcnQuIEl0IGlzIHBvc3NpYmxlIHRvIGJ5cGFz
cyBhdXRoZW50aWNhdGlvbiB0aHJvdWdoIHRoZSBMb2dpbiByZXF1ZXN0IGFuZCByZXNwb25zZS4N
Cg0KVGhlIGluaXRpYXRvciBhbmQgdGFyZ2V0IE1BWSB3YW50IHRvIG5lZ290aWF0ZSBhdXRoZW50
aWNhdGlvbiBhbmQgZGF0YSBpbnRlZ3JpdHkgcGFyYW1ldGVycy4gT25jZSB0aGlzIG5lZ290aWF0
aW9uIGlzIGNvbXBsZXRlZCwgdGhlIGNoYW5uZWwgaXMgY29uc2lkZXJlZCBzZWN1cmUuDQoNCkF1
dGhlbnRpY2F0aW9uIGFuZCBhIFNlY3VyZSBDaGFubmVsIHNldHVwIE1BWSBiZSBwZXJmb3JtZWQg
aW5kZXBlbmRlbnQgb2YgaVNDU0kgKGFzIHdoZW4gdXNpbmcgdHVubmVsaW5nIElQU2VjIG9yIHNv
bWUgaW1wbGVtZW50YXRpb25zIG9mIHRyYW5zcG9ydCBJUFNlYykgaW4gd2hpY2ggY2FzZSB0aGUg
TG9naW4gcGhhc2UgY2FuIGJlIHJlZHVjZWQgdG8gb3BlcmF0aW9uYWwgcGFyYW1ldGVyIG5lZ290
aWF0aW9ucy4NCiANCk1vc3Qgb2YgdGhlIG5lZ290aWF0aW9uIGtleXMgYXJlIGFsbG93ZWQgb25s
eSBpbiBhIHNwZWNpZmljIHN0YWdlIC0gdGhlIFNlY3VyaXR5TmVnb3RpYXRpb24ga2V5cyBhcHBl
YXIgYWxsIGluIEFwcGVuZGl4IEEgd2hpbGUgdGhlIExvZ2luT3BlcmF0aW9uYWxOZWdvdGlhdGlv
biBrZXlzIGFwcGVhciBpbiBBcHBlbmRpeCBELg0KT25seSBhIGxpbWl0ZWQgc2V0IG9mIGtleXMg
KG1hcmtlZCBhcyBEZWNsYXJhdGl2ZSBpbiBBcHBlbmRpeCBEKSBtYXkgYmUgdXNlZCBpbiBhbnkg
b2YgdGhlIDIgc3RhZ2VzLg0KDQpBbnkgZ2l2ZW4gTG9naW4gcmVxdWVzdCBvciByZXNwb25zZSBi
ZWxvbmdzIHRvIGEgc3BlY2lmaWMgc3RhZ2UgYW5kIHRoaXMgZGV0ZXJtaW5lcyB0aGUgbmVnb3Rp
YXRpb24ga2V5cyBhbGxvd2VkIHdpdGggdGhlIGNvbW1hbmQgb3IgcmVzcG9uc2UuDQoNClN0YWdl
IHRyYW5zaXRpb24gaXMgcGVyZm9ybWVkIHRocm91Z2ggYSBjb21tYW5kIGV4Y2hhbmdlIChyZXF1
ZXN0L3Jlc3BvbnNlKSBjYXJyeWluZyB0aGUgRiBiaXQgYW5kIHRoZSBzYW1lIGN1cnJlbnQgc3Rh
Z2UgY29kZS4gIER1cmluZyB0aGlzIGV4Y2hhbmdlLCB0aGUgbmV4dCBzdGFnZSBzZWxlY3RlZCBp
cyB0aGUgbG93ZXIgb2YgdGhlIHR3byBuZXh0IHN0YWdlIGNvZGVzLiAgVGhlIGluaXRpYXRvciBj
YW4gcmVxdWVzdCBhIHRyYW5zaXRpb24gd2hlbmV2ZXIgaXQgaXMgcmVhZHkgYnV0IGEgdGFyZ2V0
IGNhbiByZXNwb25kIHdpdGggYSB0cmFuc2l0aW9uIG9ubHkgYWZ0ZXIgaXQgaXMgb2ZmZXJlZCBv
bmUgYnkgdGhlIGluaXRpYXRvci4NCg0KSW4gYSBuZWdvdGlhdGlvbiBzZXF1ZW5jZSwgdGhlIEYg
Yml0IHNldHRpbmdzIGluIG9uZSBwYWlyIG9mIGxvZ2luIHJlcXVlc3QtcmVzcG9uc2VzIGhhdmUg
bm8gYmVhcmluZyBvbiB0aGUgRiBiaXQgc2V0dGluZ3Mgb2YgdGhlIG5leHQgcGFpci4gIEFuIGlu
aXRpYXRvciBoYXZpbmcgRiBiaXQgc2V0IHRvIDEgaW4gb25lIHBhaXIgYW5kIGJlaW5nIGFuc3dl
cmVkIHdpdGggYW4gRiBiaXQgc2V0dGluZyBvZiAwIG1heSBpc3N1ZSB0aGUgbmV4dCByZXF1ZXN0
IHdpdGggRiBiaXQgc2V0IHRvIDAuDQoNClN0YWdlIHRyYW5zaXRpb25zIGR1cmluZyBsb2dpbiAo
aW5jbHVkaW5nIGVudGVyaW5nIGFuZCBleGl0KSBhcmUgcG9zc2libGUgb25seSBhcyBvdXRsaW5l
ZCBpbiB0aGUgZm9sbG93aW5nIHRhYmxlOg0KDQorLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQp8RnJvbSAgICAgVG8gLT4gICB8IFNl
Y3VyaXR5ICAgIHwgT3BlcmF0aW9uYWwgfCBGdWxsRmVhdHVyZSB8ICANCnwgIHwgICAgICAgICAg
ICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwgDQp8ICBWICAg
ICAgICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgICB8DQor
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0rDQp8IChzdGFydCkgICAgICAgICB8ICB5ZXMgICAgICAgIHwgIHllcyAgICAgICAgfCAgbm8g
ICAgICAgICB8ICAgDQorLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0rDQp8IFNlY3VyaXR5ICAgICAgICB8ICBubyAgICAgICAgIHwgIHll
cyAgICAgICAgfCAgeWVzICAgICAgICB8DQorLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQp8IE9wZXJhdGlvbmFsICAgICB8ICBubyAg
ICAgICAgIHwgIG5vICAgICAgICAgfCAgeWVzICAgICAgICB8DQorLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQoNClRoZSBMb2dpbiBG
aW5hbC1SZXNwb25zZSB0aGF0IGFjY2VwdHMgYSBMb2dpbiBDb21tYW5kIGNhbiBjb21lIG9ubHkg
YXMgYSByZXNwb25zZSB0byBhIExvZ2luIGNvbW1hbmQgd2l0aCB0aGUgRiBiaXQgc2V0IHRvIDEg
d2l0aCB0aGUgRiBiaXQgc2V0IHRvIDEgYW5kIGJvdGggdGhlIGNvbW1hbmQgYW5kIHJlc3BvbnNl
IE1VU1QgaGF2ZSBGdWxsRmVhdHVyZVBoYXNlIGluIHRoZSBuZXh0IHN0YWdlIHBhcnQgb2YgdGhl
IENOeFNHIGZpZWxkLg0KDQoNCjQuMSBMb2dpbiBQaGFzZSBTdGFydA0KDQpUaGUgbG9naW4gcGhh
c2Ugc3RhcnRzIHdpdGggYSBsb2dpbiByZXF1ZXN0IGZyb20gdGhlIGluaXRpYXRvciB0byB0aGUg
dGFyZ2V0LiBUaGUgaW5pdGlhbCBsb2dpbiByZXF1ZXN0IGluY2x1ZGVzOg0KDQotUHJvdG9jb2wg
dmVyc2lvbiBzdXBwb3J0ZWQgYnkgdGhlIGluaXRpYXRvciAoY3VycmVudGx5IDB4JzAyJykNCi1T
ZXNzaW9uIGFuZCBjb25uZWN0aW9uIElkcw0KLVRoZSBuZWdvdGlhdGlvbiBzdGFnZSB0aGF0IHRo
ZSBpbml0aWF0b3IgaXMgcmVhZHkgdG8gZW50ZXINCi1UaGUgQyBiaXQgc2V0IHRvIDAgKGZpcnN0
IGxvZ2luIHJlcXVlc3Qgb24gYSBjb25uZWN0aW9uKQ0KDQpPcHRpb25hbGx5IHRoZSBsb2dpbiBy
ZXF1ZXN0IG1heSBpbmNsdWRlOg0KDQotU2VjdXJpdHkvSW50ZWdyaXR5IHBhcmFtZXRlcnMgT1IN
Ci1pU0NTSSBvcGVyYXRpb25hbCBwYXJhbWV0ZXJzIEFORC9PUg0KLVRoZSBuZXh0IG5lZ290aWF0
aW9uIHN0YWdlIHRoYXQgdGhlIGluaXRpYXRvciBpcyByZWFkeSB0byBlbnRlcg0KDQpUaGUgdGFy
Z2V0IGNhbiBhbnN3ZXIgdGhlIGxvZ2luIGluIHRoZSBmb2xsb3dpbmcgd2F5czoNCg0KLUxvZ2lu
IFJlc3BvbnNlIHdpdGggTG9naW4gUmVqZWN0LiAgVGhpcyBpcyBhbiBpbW1lZGlhdGUgcmVqZWN0
aW9uIGZyb20gdGhlIHRhcmdldCB0aGF0IGNhdXNlcyB0aGUgc2Vzc2lvbiB0byB0ZXJtaW5hdGUu
IFRoZSBGIGJpdCBvZiB0aGUgcmVzcG9uc2UgTVVTVCBiZSBzZXQgdG8gMSBhbmQgdGhlIENOeFNH
IGlzIHRvIGJlIGlnbm9yZWQNCi1Mb2dpbiBSZXNwb25zZSB3aXRoIExvZ2luIEFjY2VwdCBhcyBh
IGZpbmFsIHJlc3BvbnNlIChGIGJpdCBzZXQgdG8gMSBhbmQgdGhlIG5leHQgcGFydCBvZiBDTnhT
RyBpbiBib3RoIGNvbW1hbmQgYSByZXNwb25zZSBhcmUgc2V0IHRvIEZ1bGxGZWF0dXJlUGhhc2Up
LiBUaGUgcmVzcG9uc2UgaW5jbHVkZXMgdGhlIHByb3RvY29sIHZlcnNpb24gc3VwcG9ydGVkIGJ5
IHRoZSB0YXJnZXQgIGFuZCB0aGUgc2Vzc2lvbiBJRCBhbmQgbWF5ICBpbmNsdWRlIGlTQ1NJIG9w
ZXJhdGlvbmFsIG9yIHNlY3VyaXR5IHBhcmFtZXRlcnMgKGRlcGVuZGluZyBvbiB0aGUgY3VycmVu
dCBzdGFnZSkuDQotTG9naW4gUmVzcG9uc2Ugd2l0aCBMb2dpbiBBY2NlcHQgYXMgYSBwYXJ0aWFs
IHJlc3BvbnNlIGluZGljYXRpbmcgdGhlIHN0YXJ0IG9mIGEgbmVnb3RpYXRpb24gc2VxdWVuY2Uu
ICBUaGUgcmVzcG9uc2UgaW5jbHVkZXMgdGhlIHByb3RvY29sIHZlcnNpb24gc3VwcG9ydGVkIGJ5
IHRoZSB0YXJnZXQgYW5kIGVpdGhlciBzZWN1cml0eS9pbnRlZ3JpdHkgcGFyYW1ldGVycyBvciBp
U0NTSSBwYXJhbWV0ZXJzICh3aGVuIG5vIHNlY3VyaXR5L2ludGVncml0eSBtZWNoYW5pc20gaXMg
Y2hvc2VuKSBzdXBwb3J0ZWQgYnkgdGhlIHRhcmdldC4NCg0KSWYgdGhlIGluaXRpYXRvciBkZWNp
ZGVzIHRvIGZvcmVnbyB0aGUgU2VjdXJpdHlOZWdvdGlhdGlvbiBzdGFnZSBpdCBpc3N1ZXMgdGhl
IExvZ2luIHdpdGggdGhlIENOeFNHIHNldCB0byBMb2dpbk9wZXJhdGlvbmFsTmVnb3RpYXRpb24g
aW4gdGhlIGN1cnJlbnQgc3RhZ2UgYW5kIHRoZSB0YXJnZXQgbWF5IHJlcGx5IHdpdGggYSBMb2dp
biBSZXNwb25zZSBpbmRpY2F0aW5nIHRoYXQgaXQgaXMgdW53aWxsaW5nIHRvIGFjY2VwdCB0aGUg
Y29ubmVjdGlvbiB3aXRob3V0IFNlY3VyaXR5TmVnb3RpYXRpb24gYW5kIHRlcm1pbmF0ZSB0aGUg
Y29ubmVjdGlvbi4NCg0KSWYgdGhlIGluaXRpYXRvciBpcyB3aWxsaW5nIG5vIG5lZ290aWF0ZSBz
ZWN1cml0eSBidXQgaXQgaXMgdW53aWxsaW5nIHRvIG1ha2UgdGhlIGluaXRpYWwgcGFyYW1ldGVy
IG9mZmVyIGFuZCBtYXkgYWNjZXB0IGEgY29ubmVjdGlvbiB3aXRob3V0IHNlY3VyaXR5IGl0IGlz
c3VlcyB0aGUgTG9naW4gd2l0aCB0aGUgRiBiaXQgc2V0IHRvIDEsIHRoZSBDTnhTRyBzZXQgdG8g
U2VjdXJpdHlOZWdvdGlhdGlvbiBpbiB0aGUgY3VycmVudCBzdGFnZSBhbmQgTG9naW5PcGVyYXRp
b25hbE5lZ290aWF0aW9uIGluIHRoZSBuZXh0IHN0YWdlLiBJZiB0aGUgdGFyZ2V0IGlzIGFsc28g
cmVhZHkgdG8gZm9yZWdvIHNlY3VyaXR5IHRoZSBMb2dpbiByZXNwb25zZSBpcyBlbXB0eSBhbmQg
aGFzIEYgYml0IGlzIHNldCB0byAxIGFuZCB0aGUgQ054U0cgc2V0IHRvIFNlY3VyaXR5TmVnb3Rp
YXRpb24gaW4gdGhlIGN1cnJlbnQgc3RhZ2UgYW5kIExvZ2luT3BlcmF0aW9uYWxOZWdvdGlhdGlv
biBpbiB0aGUgbmV4dCBzdGFnZS4NCg0KQW4gaW5pdGlhdG9yIHRoYXQgY2FuIG9wZXJhdGUgd2l0
aG91dCBzZWN1cml0eSBhbmQgd2l0aCBhbGwgdGhlIG9wZXJhdGlvbmFsIHBhcmFtZXRlcnMgdGFr
aW5nIHRoZSBkZWZhdWx0IHZhbHVlcyBpc3N1ZXMgdGhlIExvZ2luIHdpdGggdGhlIEYgYml0IHNl
dCB0byAxLCB0aGUgQ054U0cgc2V0IHRvIExvZ2luT3BlcmF0aW9uYWxOZWdvdGlhdGlvbiBpbiB0
aGUgY3VycmVudCBzdGFnZSBhbmQgRnVsbEZlYXR1cmVQaGFzZSBpbiB0aGUgbmV4dCBzdGFnZS4g
SWYgdGhlIHRhcmdldCBpcyBhbHNvIHJlYWR5IHRvIGZvcmVnbyBzZWN1cml0eSBhbmQgTG9naW5P
cGVyYXRpb25hbE5lZ290aWF0aW9uIHRoZSBMb2dpbiByZXNwb25zZSBpcyBlbXB0eSBhbmQgaGFz
IEYgYml0IGlzIHNldCB0byAxIGFuZCB0aGUgQ054U0cgc2V0IHRvIExvZ2luT3BlcmF0aW9uYWxO
ZWdvdGlhdGlvbiBpbiB0aGUgY3VycmVudCBzdGFnZSBhbmQgRnVsbEZlYXR1cmVQaGFzZSBpbiB0
aGUgbmV4dCBzdGFnZS4NCg0KQSB0YXJnZXQgTUFZIHVzZSB0aGUgaVNDU0kgSW5pdGlhdG9yIE5h
bWUgYXMgcGFydCBvZiBpdHMgYWNjZXNzIGNvbnRyb2wgbWVjaGFuaXNtOyB0aGVyZWZvcmUsIHRo
ZSBpU0NTSSBJbml0aWF0b3IgTmFtZSBNVVNUIGJlIHNlbnQgYmVmb3JlIHRoZSB0YXJnZXQgaXMg
cmVxdWlyZWQgdG8gZGlzY2xvc2UgaXRzIExVcy4NCg0KSWYgdGhlIGlTQ1NJIFRhcmdldCBOYW1l
IGFuZC9vciBpU0NTSSBJbml0aWF0b3IgTmFtZSBpcyBnb2luZyB0byBiZSB1c2VkIGluIGRldGVy
bWluaW5nIHRoZSBzZWN1cml0eSBtb2RlIG9yIGl0IGlzIGltcGxpY2l0IHBhcnQgb2YgYXV0aGVu
dGljYXRpb24sIHRoZW4gdGhlIGlTQ1NJIFRhcmdldCBOYW1lIGFuZC9vciBpU0NTSSBJbml0aWF0
b3IgTmFtZSBNVVNUIGJlIHNlbnQgaW4gdGhlIGxvZ2luIGNvbW1hbmQgZm9yIHRoZSBmaXJzdCBj
b25uZWN0aW9uIG9mIGEgc2Vzc2lvbiB0byBpZGVudGlmeSB0aGUgc3RvcmFnZSBlbmRwb2ludCBv
ZiB0aGUgc2Vzc2lvbi4gSWYgc2VudCBvbiBuZXcgY29ubmVjdGlvbnMgd2l0aGluIGFuIGV4aXN0
aW5nIHNlc3Npb24gaXQgTVVTVCBiZSB0aGUgc2FtZSBhcyB0aGUgb25lIHVzZWQgZm9yIHRoZSBs
ZWFkaW5nIGNvbm5lY3Rpb24uICBJZiB0aGUgaVNDU0kgVGFyZ2V0IE5hbWUgYW5kL29yIGlTQ1NJ
IEluaXRpYXRvciBOYW1lIGlzIGdvaW5nIHRvIGJlIHVzZWQgb25seSBmb3IgYWNjZXNzIGNvbnRy
b2wsIGl0IGNhbiBiZSBzZW50IGFmdGVyIHRoZSBTZWN1cml0eU5lZ290aWF0aW9uIHN0YWdlLiBB
IHRhcmdldCBjYW4gYmUgYWNjZXNzZWQgd2l0aG91dCBhIFRhcmdldCBOYW1lIG9ubHkgaWYgdGhl
IHNlc3Npb24gdHlwZSBpcyBhIGRpc2NvdmVyeSBzZXNzaW9uLg0KIA0KVGhlIGlTQ1NJIE5hbWVz
IE1VU1QgYmUgaW4gdGV4dCBjb21tYW5kIGZvcm1hdC4NCg0KNC4yIGlTQ1NJIFNlY3VyaXR5IGFu
ZCBJbnRlZ3JpdHkgTmVnb3RpYXRpb24NCg0KVGhlIHNlY3VyaXR5IGV4Y2hhbmdlIHNldHMgdGhl
IHNlY3VyaXR5IG1lY2hhbmlzbSBhbmQgYXV0aGVudGljYXRlcyB0aGUgdXNlciBhbmQgdGhlIHRh
cmdldCB0byBlYWNoIG90aGVyLiBUaGUgZXhjaGFuZ2UgcHJvY2VlZHMgYWNjb3JkaW5nIHRvIHRo
ZSBhbGdvcml0aG1zIHRoYXQgd2VyZSBjaG9zZW4gaW4gdGhlIG5lZ290aWF0aW9uIHBoYXNlIGFu
ZCBpcyBjb25kdWN0ZWQgYnkgdGhlIGxvZ2luIGFuZCB0ZXh0IGNvbW1hbmRzIGtleT12YWx1ZSBw
YXJhbWV0ZXJzLg0KDQpUaGUgbmVnb3RpYWJsZSBzZWN1cml0eSBtZWNoYW5pc21zIGluY2x1ZGUg
dGhlIGZvbGxvd2luZyBtb2RlczoNCg0KLUluaXRpYXRvci10YXJnZXQgYXV0aGVudGljYXRpb24g
LSB0aGUgaG9zdCBhbmQgdGhlIHRhcmdldCBhdXRoZW50aWNhdGUgdGhlbXNlbHZlcyB0byBlYWNo
IG90aGVyLiBBIG5lZ290aWFibGUgYWxnb3JpdGhtIHN1Y2ggYXMgS2VyYmVyb3MgcHJvdmlkZXMg
dGhpcyBmZWF0dXJlLg0KLVBEVSBpbnRlZ3JpdHkgLSBhbiBpbnRlZ3JpdHkvYXV0aGVudGljYXRp
b24gZGlnZXN0IGlzIGF0dGFjaGVkIHRvIGVhY2ggcGFja2V0LiAgVGhlIGFsZ29yaXRobSBpcyBu
ZWdvdGlhYmxlLg0KIA0KVXNpbmcgSVBzZWMgZm9yIGVuY3J5cHRpb24gb3IgYXV0aGVudGljYXRp
b24gbWF5IGVsaW1pbmF0ZSBwYXJ0IG9mIHRoZSBzZWN1cml0eSBuZWdvdGlhdGlvbiBhdCB0aGUg
aVNDU0kgbGV2ZWwgYnV0IG5vdCBuZWNlc3NhcmlseSBhbGwuIA0KDQpJZiBzZWN1cml0eSBpcyBl
c3RhYmxpc2hlZCBpbiB0aGUgbG9naW4gcGhhc2UgdGhlbiBhZnRlciB0aGUgc2VjdXJpdHkgbmVn
b3RpYXRpb24gaXMgY29tcGxldGUsIGVhY2ggaVNDU0kgUERVIE1VU1QgaW5jbHVkZSB0aGUgYXBw
cm9wcmlhdGUgZGlnZXN0IGZpZWxkIGlmIGFueS4NCg0KVGhlIG5lZ290aWF0aW9uIHByb2NlZWRz
IGFzIGZvbGxvd3M6DQoNCi1UaGUgaW5pdGlhdG9yIHNlbmRzIGEgbG9naW4gcmVxdWVzdCB3aXRo
IGFuIG9yZGVyZWQgbGlzdCBvZiB0aGUgb3B0aW9ucyBpdCBzdXBwb3J0cyBmb3IgZWFjaCBzdWJq
ZWN0IChhdXRoZW50aWNhdGlvbiBhbGdvcml0aG0sIGlTQ1NJIHBhcmFtZXRlcnMgYW5kIHNvIG9u
KS4gVGhlIG9wdGlvbnMgYXJlIGxpc3RlZCBpbiB0aGUgaW5pdGlhdG9yJ3Mgb3JkZXIgb2YgcHJl
ZmVyZW5jZS4gDQotVGhlIHRhcmdldCBNVVNUIHJlcGx5IHdpdGggdGhlIGZpcnN0IG9wdGlvbiBp
biB0aGUgbGlzdCBpdCBzdXBwb3J0cyBhbmQgaXMgYWxsb3dlZCBmb3IgdGhlIHNwZWNpZmljIGlu
aXRpYXRvci4gIFRoZSBwYXJhbWV0ZXJzIGFyZSBlbmNvZGVkIGluIFVURjggYXMga2V5PXZhbHVl
LiAgVGhlIGluaXRpYXRvciBNQVkgYWxzbyBzZW5kIHByb3ByaWV0YXJ5IG9wdGlvbnMuIFRoZSAi
bm9uZSIgb3B0aW9uLCBpZiBhbGxvd2VkLCBNVVNUIGJlIGluY2x1ZGVkIGluIHRoZSBsaXN0LCB3
aGljaCBpbmRpY2F0ZXMgdGhhdCBubyBhbGdvcml0aG0gaXMgc3VwcG9ydGVkIGJ5IHRoZSB0YXJn
ZXQuIEZvciBhIGxpc3Qgb2Ygc2VjdXJpdHkgcGFyYW1ldGVycyBzZWUgQXBwZW5kaXggQS4NCg0K
LVRoZSBpbml0aWF0b3IgbXVzdCBiZSBhd2FyZSBvZiB0aGUgaW1taW5lbnQgY29tcGxldGlvbiBv
ZiB0aGUgU2VjdXJpdHlOZWdvdGlhdGlvbiBzdGFnZSBhbmQgTVVTVCBzZXQgdGhlIEYgYml0IHRv
IDEgYW5kIHRoZSBuZXh0IHN0YWdlIHBhcnQgb2YgQ054U0cgdG8gd2hhdCBpdCB3b3VsZCBsaWtl
IHRoZSBuZXh0IHN0YWdlIHRvIGJlLiBUaGUgdGFyZ2V0IHdpbGwgYW5zd2VyIHdpdGggYSBMb2dp
biByZXNwb25zZSB3aXRoIHRoZSBGIGJpdCBzZXQgdG8gMSBhbmQgdGhlIG5leHQgc3RhZ2UgcGFy
dCBvZiBDTnhTRyB0byB3aGF0IGl0IHdvdWxkIGxpa2UgdGhlIG5leHQgc3RhZ2UgdG8gYmUuIFRo
ZSBuZXh0IHN0YWdlIHNlbGVjdGVkIHdpbGwgYmUgdGhlICJsb3dlciIgb2YgdGhlIHR3by4gSWYg
dGhlIG5leHQgc3RhZ2UgaXMgRnVsbEZlYXR1cmVQaGFzZSwgdGhlIHRhcmdldCBNVVNUIHJlc3Bv
bmQgd2l0aCBhIExvZ2luIFJlc3BvbnNlIHdpdGggdGhlIFNlc3Npb24gSUQgYW5kIHRoZSBwcm90
b2NvbCB2ZXJzaW9uLiANCg0KDQpBbGwgUERVcyBzZW50IGFmdGVyIHRoZSBzZWN1cml0eSBuZWdv
dGlhdGlvbiBzdGFnZSBNVVNUIGJlIGJ1aWx0IHVzaW5nIHRoZSBhZ3JlZWQgc2VjdXJpdHkuIA0K
DQpJZiB0aGUgc2VjdXJpdHkgbmVnb3RpYXRpb24gZmFpbHMgYXQgdGhlIHRhcmdldCB0aGVuIHRo
ZSB0YXJnZXQgTVVTVCBzZW5kIHRoZSBhcHByb3ByaWF0ZSBMb2dpbiBSZXNwb25zZSBQRFUuICBJ
ZiB0aGUgc2VjdXJpdHkgbmVnb3RpYXRpb24gZmFpbHMgYXQgdGhlIGluaXRpYXRvciwgdGhlIGlu
aXRpYXRvciBzaGFsbCBkcm9wIHRoZSBjb25uZWN0aW9uLiANCg0KNC4zIE9wZXJhdGlvbmFsIFBh
cmFtZXRlciBOZWdvdGlhdGlvbiBEdXJpbmcgdGhlIExvZ2luIFBoYXNlDQoNCk9wZXJhdGlvbmFs
IHBhcmFtZXRlciBuZWdvdGlhdGlvbiBkdXJpbmcgdGhlIGxvZ2luIE1BWSBiZSBkb25lOg0KDQot
IHN0YXJ0aW5nIHdpdGggdGhlIGZpcnN0IExvZ2luIHJlcXVlc3QgaWYgdGhlIGluaXRpYXRvciBk
b2VzIG5vdCBvZmZlciAgYW55IHNlY3VyaXR5LyBpbnRlZ3JpdHkgb3B0aW9uDQotIHN0YXJ0aW5n
IGltbWVkaWF0ZWx5IGFmdGVyIHRoZSBzZWN1cml0eS9pbnRlZ3JpdHkgbmVnb3RpYXRpb24gaWYg
dGhlIGluaXRpYXRvciBhbmQgdGFyZ2V0IHBlcmZvcm0gc3VjaCBhIG5lZ290aWF0aW9uDQoNCkFu
IG9wZXJhdGlvbmFsIHBhcmFtZXRlciBuZWdvdGlhdGlvbiBvbiBhIGNvbm5lY3Rpb24gTVVTVCBO
T1Qgc3RhcnQgYmVmb3JlIHRoZSBzZWN1cml0eSBuZWdvdGlhdGlvbiBpZiBhIHNlY3VyaXR5IG5l
Z290aWF0aW9uIGV4aXN0cy4gIA0KDQpPcGVyYXRpb25hbCBwYXJhbWV0ZXIgbmVnb3RpYXRpb24g
TUFZIGludm9sdmUgc2V2ZXJhbCBMb2dpbiByZXF1ZXN0LXJlc3BvbnNlIGV4Y2hhbmdlcyBzdGFy
dGVkIGFuZCB0ZXJtaW5hdGVkIGJ5IHRoZSBpbml0aWF0b3IuIFRoZSBpbml0aWF0b3IgTVVTVCBp
bmRpY2F0ZSBpdHMgaW50ZW50IHRvIHRlcm1pbmF0ZSB0aGUgbmVnb3RpYXRpb24gYnkgc2V0dGlu
ZyB0aGUgRiBiaXQgdG8gMTsgdGhlIHRhcmdldCBzZXRzIHRoZSBGIGJpdCB0byAxIG9uIHRoZSBs
YXN0IHJlc3BvbnNlLiBUaGUgbGFzdCByZXNwb25zZSBNVVNUIGJlIHRoZSBMb2dpbiBSZXNwb25z
ZS4NCklmIHRoZSB0YXJnZXQgcmVzcG9uZHMgdG8gYSBMb2dpbiByZXF1ZXN0IHdpdGggdGhlIEYg
Yml0IHNldCB0byAxLCB3aXRoIGEgTG9naW4gcmVzcG9uc2Ugd2l0aCB0aGUgRiBiaXQgc2V0IHRv
IDAsIHRoZSBpbml0aWF0b3IgbXVzdCBrZWVwIHNlbmRpbmcgdGhlIExvZ2luIHJlcXVlc3QgKGV2
ZW4gZW1wdHkpIHdpdGggdGhlIEYgYml0IHNldCB0byAxIHVudGlsIGl0IGdldHMgdGhlIExvZ2lu
IFJlc3BvbnNlIHdpdGggdGhlIEYgYml0IHNldCB0byAxLg0KDQpXaGVuZXZlciBwYXJhbWV0ZXIg
YWN0aW9uIG9yIGFjY2VwdGFuY2UgaXMgZGVwZW5kZW50IG9uIG90aGVyIHBhcmFtZXRlcnMgdGhl
IGRlcGVuZGVudCBwYXJhbWV0ZXJzIE1VU1QgYmUgc2VudCBhZnRlciB0aGUgcGFyYW1ldGVycyB0
aGV5IGRlcGVuZCBvbi4gIElmIHRoZXkgYXJlIHNlbnQgd2l0aGluIHRoZSBzYW1lIGNvbW1hbmQg
YSByZXNwb25zZSBmb3IgYSBwYXJhbWV0ZXIgbWlnaHQgaW1wbHkgcmVzcG9uc2VzIGZvciBvdGhl
cnMuDQoNCkFuIGluaXRpYXRvciBNVVNUIHNlbmQgYSBzaW5nbGUgTG9naW4gcmVxdWVzdCB3aXRo
IHRoZSBDIGJpdCBzZXQgdG8gMCBwZXIgY29ubmVjdGlvbiwgcGVyIHNlc3Npb24uIA0KDQpTZXNz
aW9uIHNwZWNpZmljIHBhcmFtZXRlcnMgY2FuIGJlIHNwZWNpZmllZCBvbmx5IGR1cmluZyB0aGUg
bG9naW4gcGhhc2UgICAgIGJlZ3VuIGJ5IGEgbG9naW4gY29tbWFuZCBjb250YWluaW5nIGEgbnVs
bCBUU0lEIChlLmcuLCB0aGUgbWF4aW11bSBudW1iZXIgb2YgY29ubmVjdGlvbnMgdGhhdCBjYW4g
YmUgdXNlZCBmb3IgdGhpcyBzZXNzaW9uKS4gIENvbm5lY3Rpb24gc3BlY2lmaWMgcGFyYW1ldGVy
cywgaWYgYW55LCBjYW4gYmUgc3BlY2lmaWVkIGR1cmluZyB0aGUgbG9naW4gcGhhc2UgYmVndW4g
YnkgYW55IGxvZ2luIGNvbW1hbmQuIFRodXMsIGEgc2Vzc2lvbiBpcyBvcGVyYXRpb25hbCBvbmNl
IGl0IGhhcyBhdCBsZWFzdCBvbmUgY29ubmVjdGlvbi4gDQoNCkZvciBhIGxpc3Qgb2Ygb3BlcmF0
aW9uYWwgcGFyYW1ldGVycywgc2VlIEFwcGVuZGl4IEQuIA0KDQotLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tDQowMyBMb2dpbiBQaGFzZSBFeGFtcGxlcw0KDQpJbiB0aGUgZmlyc3QgZXhhbXBs
ZSwgdGhlIGluaXRpYXRvciBhbmQgdGFyZ2V0IGF1dGhlbnRpY2F0ZSBlYWNoIG90aGVyIHZpYSBL
ZXJiZXJvczoNCg0KSS0+IExvZ2luIChDPTAsIENOeFNHPTAsMSBGPTEpDQogICAgSW5pdGlhdG9y
TmFtZT1pcW4uMTk5OS0wNy5jb20ub3MuaG9zdGlkLjc3DQogICAgVGFyZ2V0TmFtZT1pcW4uMTk5
OS0wNy5jb20uYWNtZS5kaXNrYXJyYXkuc24uODggDQogICAgSGVhZGVyRGlnZXN0PUNSQy0zMkMs
bm9uZSANCiAgICBEYXRhRGlnZXN0PUNSQy0zMkMsbm9uZQ0KICAgIEF1dGhNZXRob2Q9U1JQLEtS
QjUsbm9uZSANCg0KVC0+IExvZ2luIChDTnhTRz0wLDEgRj0wKQ0KICAgIEhlYWRlckRpZ2VzdD1D
UkMtMzJDDQogICAgRGF0YURpZ2VzdD1DUkMtMzJDDQogICAgQXV0aE1ldGhvZD1LUkI1DQoNCg0K
SS0+IExvZ2luIChDPTEsIENOeFNHPTAsMSBGPTEpDQogICAgS1JCX0FQX1JFUT08a3JiX2FwX3Jl
cT4NCg0KKGtyYl9hcF9yZXEgY29udGFpbnMgdGhlIEtlcmJlcm9zIFY1IHRpY2tldCBhbmQgYXV0
aGVudGljYXRvciB3aXRoIE1VVFVBTC1SRVFVSVJFRCBzZXQgaW4gdGhlIGFwLW9wdGlvbnMgZmll
bGQpDQoNCklmIHRoZSBhdXRoZW50aWNhdGlvbiBpcyBzdWNjZXNzZnVsLCB0aGUgdGFyZ2V0IHBy
b2NlZWRzIHdpdGg6DQoNClQtPiBMb2dpbiAoQ054U0c9MCwxIEY9MSkNCiAgICBLUkJfQVBfUkVQ
PTxrcmJfYXBfcmVwPiANCg0KKGtyYl9hcF9yZXAgaXMgdGhlIEtlcmJlcm9zIFY1IG11dHVhbCBh
dXRoZW50aWNhdGlvbiByZXBseSkgDQogDQpJZiB0aGUgYXV0aGVudGljYXRpb24gaXMgc3VjY2Vz
c2Z1bCwgdGhlIGluaXRpYXRvciBwcm9jZWVkcy4NCg0KRnJvbSB0aGlzIHBvaW50IG9uLCBhbnkg
TG9naW4gY29tbWFuZCBhbmQgZWFjaCBQRFUgdGhlcmVhZnRlciBNVVNUIGhhdmUgQ1JDLTMyQyBk
aWdlc3RzIGZvciB0aGUgaGVhZGVyIGFuZCB0aGUgZGF0YS4NCg0KVGhlIGluaXRpYXRvciBtYXkg
cHJvY2VlZDoNCg0KSS0+IExvZ2luIChDPTEsIENOeFNHPTEsMyBGPTApDQogICAgLi4uIGlTQ1NJ
IE9wZXJhdGlvbmFsIFBhcmFtZXRlcnMNCg0KVC0+IExvZ2luIChDTnhTRz0xLDMgRj0wKQ0KICAg
IC4uLiBpU0NTSSBPcGVyYXRpb25hbCBQYXJhbWV0ZXJzIA0KDQpBbmQgYXQgdGhlIGVuZDoNCg0K
SS0+IExvZ2luIChDPTEsIENOeFNHPTEsMyBGPTEpDQogICAgb3B0aW9uYWwgaVNDU0kgcGFyYW1l
dGVycw0KICAgIFRhcmdldE5hbWU9aXFuLjE5OTktMDcuY29tLmFjbWUuZGlza2FycmF5LnNuLjg4
DQoNClQtPiBMb2dpbiAoQ054U0c9MSwzIEY9MSkgImxvZ2luIGFjY2VwdCIgDQoNCklmIHRoZSBp
bml0aWF0b3IgYXV0aGVudGljYXRpb24gYnkgdGhlIHRhcmdldCBpcyBub3Qgc3VjY2Vzc2Z1bCwg
dGhlIHRhcmdldCByZXNwb25kcyB3aXRoOg0KDQpULT4gTG9naW4gImxvZ2luIHJlamVjdCINCg0K
aW5zdGVhZCBvZiB0aGUgTG9naW4gS1JCX0FQX1JFUCBtZXNzYWdlLCBhbmQgdGVybWluYXRlcyB0
aGUgY29ubmVjdGlvbi4NCg0KSWYgdGhlIHRhcmdldCBhdXRoZW50aWNhdGlvbiBieSB0aGUgaW5p
dGlhdG9yIGlzIG5vdCBzdWNjZXNzZnVsLCB0aGUgaW5pdGlhdG9yIHRlcm1pbmF0ZXMgdGhlIGNv
bm5lY3Rpb24gKHdpdGhvdXQgcmVzcG9uZGluZyB0byB0aGUgTG9naW4gS1JCX0FQX1JFUCBtZXNz
YWdlKS4NCg0KSW4gdGhlIG5leHQgZXhhbXBsZSBvbmx5IHRoZSBpbml0aWF0b3IgaXMgYXV0aGVu
dGljYXRlZCBieSB0aGUgdGFyZ2V0IHZpYSBLZXJiZXJvczoNCg0KSS0+IExvZ2luIChDPTAsIENO
eFNHPTAsMSBGPTEpDQogICAgSW5pdGlhdG9yTmFtZT1pcW4uMTk5OS0wNy5jb20ub3MuaG9zdGlk
Ljc3DQogICAgVGFyZ2V0TmFtZT1pcW4uMTk5OS0wNy5jb20uYWNtZS5kaXNrYXJyYXkuc24uODgg
IA0KICAgIEhlYWRlckRpZ2VzdD1DUkMtMzJDLG5vbmUNCiAgICBEYXRhRGlnZXN0PUNSQy0zMkMs
bm9uZQ0KICAgIEF1dGhNZXRob2Q9U1JQLEtSQjUsbm9uZSANCg0KVC0+IExvZ2luLVBSIChDTnhT
Rz0wLDEgRj0wKQ0KICAgIEhlYWRlckRpZ2VzdD1DUkMtMzJDDQogICAgRGF0YURpZ2VzdD1DUkMt
MzJDIA0KICAgIEF1dGhNZXRob2Q9S1JCNSANCg0KSS0+IExvZ2luIChDPTEsIENOeFNHPTAsMSBG
PTEpDQogICAgS1JCX0FQX1JFUT1rcmJfYXBfcmVxIA0KDQooTVVUVUFMLVJFUVVJUkVEIG5vdCBz
ZXQgaW4gdGhlIGFwLW9wdGlvbnMgZmllbGQgb2Yga3JiX2FwX3JlcSkNCg0KSWYgdGhlIGF1dGhl
bnRpY2F0aW9uIGlzIHN1Y2Nlc3NmdWwsIHRoZSB0YXJnZXQgcHJvY2VlZHMgd2l0aDoNCg0KVC0+
IExvZ2luIChDTnhTRz0wLDEgRj0xKQ0KDQpGcm9tIHRoaXMgcG9pbnQgb24sIGFueSBMb2dpbiBj
b21tYW5kIGFuZCBlYWNoIFBEVSB0aGVyZWFmdGVyIE1VU1QgaGF2ZSBDUkMtMzJDIGRpZ2VzdHMg
Zm9yIHRoZSBoZWFkZXIgYW5kIHRoZSBkYXRhLg0KDQpJLT4gTG9naW4gKEM9MSwgQ054U0c9MSwz
IEY9MCkNCiAgICAuLi4gaVNDU0kgcGFyYW1ldGVycw0KDQpULT4gTG9naW4gKEM9MSwgQ054U0c9
MSwzIEY9MCkNCiAgICAuLi4gaVNDU0kgcGFyYW1ldGVycw0KDQouIC4gLg0KDQpULT4gTG9naW4g
KENOeFNHPTEsMyBGPTEpImxvZ2luIGFjY2VwdCINCiAgICBUYXJnZXROYW1lPWlxbi4xOTk5LTA3
LmNvbS5hY21lLmRpc2thcnJheS5zbi44OA0KDQoNCkluIHRoZSBuZXh0IGV4YW1wbGUsIHRoZSBp
bml0aWF0b3IgYW5kIHRhcmdldCBhdXRoZW50aWNhdGUgZWFjaCBvdGhlciB2aWEgU1BLTS0xOg0K
DQpJLT4gTG9naW4gKEM9MCwgQ054U0c9MCwxIEY9MSkNCiAgICBJbml0aWF0b3JOYW1lPWlxbi4x
OTk5LTA3LmNvbS5vcy5ob3N0aWQuNzcNCiAgICBUYXJnZXROYW1lPWlxbi4xOTk5LTA3LmNvbS5h
Y21lLmRpc2thcnJheS5zbi44OA0KICAgIEhlYWRlckRpZ2VzdD1DUkMtMzJDLG5vbmUgDQogICAg
RGF0YURpZ2VzdD1DUkMtMzJDLCBub25lDQogICAgQXV0aE1ldGhvZD1TUEtNLTEsS1JCNSxub25l
IA0KDQpULT4gTG9naW4gKENOeFNHPTAsMSBGPTApDQogICAgSGVhZGVyRGlnZXN0PUNSQy0zMkMN
CiAgICBEYXRhRGlnZXN0PVNQS00NCiAgICBBdXRoTWV0aG9kPVNQS00tMQ0KDQpJLT4gTG9naW4g
KEM9MSwgQ054U0c9MCwxIEY9MCkNCiAgICBTUEtNLVJFUT08c3BrbS1yZXE+DQoNCihzcGttLXJl
cSBpcyB0aGUgU1BLTS1SRVEgdG9rZW4gd2l0aCB0aGUgbXV0dWFsLXN0YXRlIGJpdCBpbiB0aGUg
b3B0aW9ucyBmaWVsZCBvZiB0aGUgUkVRLVRPS0VOIHNldCkNCg0KVC0+IExvZ2luIChDTnhTRz0w
LDEgRj0wKQ0KICAgIFNQS00tUkVQLVRJPTxzcGttLXJlcC10aT4gDQoNCklmIHRoZSBhdXRoZW50
aWNhdGlvbiBpcyBzdWNjZXNzZnVsLCB0aGUgaW5pdGlhdG9yIHByb2NlZWRzOg0KDQpJLT4gTG9n
aW4gKEM9MSwgQ054U0c9MCwxIEY9MSkNCiAgICBTUEtNLVJFUC1JVD08c3BrbS1yZXAtaXQ+DQog
DQpJZiB0aGUgYXV0aGVudGljYXRpb24gaXMgc3VjY2Vzc2Z1bCwgdGhlIHRhcmdldCBwcm9jZWVk
cyB3aXRoOg0KDQpULT4gTG9naW4gKENOeFNHPTAsMSBGPTEpDQoNCkZyb20gdGhpcyBwb2ludCBv
biwgYW55IExvZ2luIGNvbW1hbmQgYW5kIGVhY2ggUERVIHRoZXJlYWZ0ZXIgTVVTVCBoYXZlIENS
Qy0zMkMgZGlnZXN0cyBmb3IgdGhlIGhlYWRlciBhbmQgdGhlIGRhdGEuDQoNClRoZSBpbml0aWF0
b3IgbWF5IHByb2NlZWQ6DQoNCkktPiBMb2dpbiAgKEM9MSwgQ054U0c9MSwzIEY9MCkgLi4uIGlT
Q1NJIHBhcmFtZXRlcnMNClQtPiBMb2dpbiAgKENOeFNHPTEsMyBGPTApIC4uLiBpU0NTSSBwYXJh
bWV0ZXJzDQoNCkFuZCBhdCB0aGUgZW5kOg0KDQpJLT4gTG9naW4gIChDPTEsIENOeFNHPTEsMyBG
PTEpDQogICAgb3B0aW9uYWwgaVNDU0kgcGFyYW1ldGVycyANCg0KVC0+IExvZ2luIChDTnhTRz0x
LDMgRj0xKSAibG9naW4gYWNjZXB0Ig0KICAgIFRhcmdldE5hbWU9aXFuLjE5OTktMDcuY29tLmFj
bWUuZGlza2FycmF5LnNuLjg4DQoNCg0KSWYgdGhlIHRhcmdldCBhdXRoZW50aWNhdGlvbiBieSB0
aGUgaW5pdGlhdG9yIGlzIG5vdCBzdWNjZXNzZnVsLCB0aGUgaW5pdGlhdG9yIHRlcm1pbmF0ZXMg
dGhlIGNvbm5lY3Rpb24gKHdpdGhvdXQgcmVzcG9uZGluZyB0byB0aGUgTG9naW4gU1BLTS1SRVAt
VEkgbWVzc2FnZSkuDQoNCklmIHRoZSBpbml0aWF0b3IgYXV0aGVudGljYXRpb24gYnkgdGhlIHRh
cmdldCBpcyBub3Qgc3VjY2Vzc2Z1bCwgdGhlIHRhcmdldCByZXNwb25kcyB3aXRoOg0KDQpULT4g
TG9naW4gImxvZ2luIHJlamVjdCINCg0KaW5zdGVhZCBvZiB0aGUgTG9naW4gU2VjdXJpdHlDb250
ZXh0Q29tcGxldGU9eWVzIG1lc3NhZ2UsIGFuZCB0ZXJtaW5hdGVzIHRoZSBjb25uZWN0aW9uLg0K
DQoNCkluIHRoZSBuZXh0IGV4YW1wbGUsIHRoZSBpbml0aWF0b3IgYW5kIHRhcmdldCBhdXRoZW50
aWNhdGUgZWFjaCBvdGhlciB2aWEgU1BLTS0yOg0KDQpJLT4gTG9naW4gKEM9MCwgQ054U0c9MCwx
IEY9MCkNCiAgICBJbml0aWF0b3JOYW1lPWlxbi4xOTk5LTA3LmNvbS5vcy5ob3N0aWQuNzcNCiAg
ICBUYXJnZXROYW1lPWlxbi4xOTk5LTA3LmNvbS5hY21lLmRpc2thcnJheS5zbi44OA0KICAgIEhl
YWRlckRpZ2VzdD0gQ1JDLTMyQyxub25lDQogICAgICAgICAgRGF0YURpZ2VzdD1DUkMtMzJDLG5v
bmUNCiAgICAgICAgICBBdXRoTWV0aG9kPVNQS00tMSxTUEtNLTIgDQoNClQtPiBMb2dpbi1QUiAo
Q054U0c9MCwxIEY9MCkNCiAgICBIZWFkZXJEaWdlc3Q9Q1JDLTMyQw0KICAgIERhdGFEaWdlc3Q9
Q1JDLTMyQw0KICAgIEF1dGhNZXRob2Q9U1BLTS0yDQoNCkktPiBMb2dpbiAoQz0xLCBDTnhTRz0w
LDEgRj0xKQ0KICAgIFNQS00tUkVRPTxzcGttLXJlcT4NCg0KKHNwa20tcmVxIGlzIHRoZSBTUEtN
LVJFUSB0b2tlbiB3aXRoIHRoZSBtdXR1YWwtc3RhdGUgYml0IGluIHRoZSBvcHRpb25zIGZpZWxk
IG9mIHRoZSBSRVEtVE9LRU4gbm90IHNldCkNCg0KSWYgdGhlIGF1dGhlbnRpY2F0aW9uIGlzIHN1
Y2Nlc3NmdWwsIHRoZSB0YXJnZXQgcHJvY2VlZHMgd2l0aDoNCg0KVC0+IExvZ2luIChDTnhTRz0w
LDEgRj0xKSANCg0KRnJvbSB0aGlzIHBvaW50IG9uLCBhbnkgTG9naW4gY29tbWFuZCBhbmQgZWFj
aCBQRFUgdGhlcmVhZnRlciBNVVNUIGhhdmUgQ1JDLTMyQyBkaWdlc3RzIGZvciB0aGUgaGVhZGVy
IGFuZCB0aGUgZGF0YS4NCg0KVGhlIGluaXRpYXRvciBtYXkgcHJvY2VlZDoNCg0KSS0+IExvZ2lu
IChDPTEsIENOeFNHPTEsMyBGPTApDQogICAgLi4uIGlTQ1NJIHBhcmFtZXRlcnMNCg0KVC0+IExv
Z2luIChDTnhTRz0xLDMgRj0wKQ0KICAgIC4uLiBpU0NTSSBwYXJhbWV0ZXJzDQoNCkFuZCBhdCB0
aGUgZW5kOg0KDQpJLT4gTG9naW4gIChDPTEsIENOeFNHPTEsMyBGPTEpDQogICAgb3B0aW9uYWwg
aVNDU0kgcGFyYW1ldGVycw0KDQpULT4gTG9naW4gKENOeFNHPTEsMyBGPTEpICJsb2dpbiBhY2Nl
cHQiDQogICAgVGFyZ2V0TmFtZT1pcW4uMTk5OS0wNy5jb20uYWNtZS5kaXNrYXJyYXkuc24uODgN
Cg0KDQpJbiB0aGUgbmV4dCBleGFtcGxlLCB0aGUgaW5pdGlhdG9yIGFuZCB0YXJnZXQgYXV0aGVu
dGljYXRlIGVhY2ggb3RoZXIgdmlhIFNSUDoNCg0KSS0+IExvZ2luIChDPTAsIENOeFNHPTAsMSBG
PTEpDQogICAgSW5pdGlhdG9yTmFtZT1pcW4uMTk5OS0wNy5jb20ub3MuaG9zdGlkLjc3DQogICAg
VGFyZ2V0TmFtZT1pcW4uMTk5OS0wNy5jb20uYWNtZS5kaXNrYXJyYXkuc24uODggDQogICAgSGVh
ZGVyRGlnZXN0PUNSQy0zMkMsbm9uZQ0KICAgIERhdGFEaWdlc3Q9Q1JDLTMyQyxub25lDQogICAg
QXV0aE1ldGhvZD1LUkI1LFNSUCxub25lDQogDQpULT4gTG9naW4tUFIgIChDPTEsIENOeFNHPTAs
MSBGPTApDQogICAgSGVhZGVyRGlnZXN0PUNSQy0zMkMNCiAgICBEYXRhRGlnZXN0PUNSQy0zMkMN
CiAgICBBdXRoTWV0aG9kPVNSUA0KDQpJLT4gTG9naW4gKEM9MSwgQ054U0c9MCwxIEY9MCkNCiAg
ICBVPTx1c2VyPg0KICAgIFRhcmdldEF1dGg9eWVzDQoNClQtPiBMb2dpbiAoQ054U0c9MCwxIEY9
MCkNCiAgICBOPTxOPg0KICAgIGc9PGc+DQogICAgcz08cz4NCg0KSS0+IExvZ2luIChDPTEsIENO
eFNHPTAsMSBGPTApDQogICAgQT08QT4NCg0KVC0+IExvZ2luIChDTnhTRz0wLDEgRj0wKQ0KICAg
IEI9PEI+DQoNCkktPiBMb2dpbiAoQz0xLCBDTnhTRz0wLDEgRj0xKQ0KICAgIE09PE0+DQoNCklm
IHRoZSBpbml0aWF0b3IgYXV0aGVudGljYXRpb24gaXMgc3VjY2Vzc2Z1bCwgdGhlIHRhcmdldCBw
cm9jZWVkczoNCg0KVC0+IExvZ2luIChDTnhTRz0wLDEgRj0xKQ0KICAgIEhNPTxIKEEgfCBNIHwg
Syk+DQoNCiAgIFdoZXJlIE4sIGcsIHMsIEEsIEIsIE0sIGFuZCBIKEEgfCBNIHwgSykgYXJlIGRl
ZmluZWQgaW4gW1JGQzI5NDVdLg0KDQpJZiB0aGUgdGFyZ2V0IGF1dGhlbnRpY2F0aW9uIGlzIG5v
dCBzdWNjZXNzZnVsLCB0aGUgaW5pdGlhdG9yIHRlcm1pbmF0ZXMgdGhlIGNvbm5lY3Rpb24uIE90
aGVyd2lzZSBpdCBwcm9jZWVkcy4NCg0KRnJvbSB0aGlzIHBvaW50IG9uLCBhbnkgTG9naW4gY29t
bWFuZCBhbmQgZWFjaCBQRFUgdGhlcmVhZnRlciBNVVNUIGhhdmUgQ1JDLTMyQyBkaWdlc3RzIGZv
ciB0aGUgaGVhZGVyIGFuZCB0aGUgZGF0YS4NCg0KSS0+IExvZ2luIChDPTEsIENOeFNHPTEsMyBG
PTApDQogICAgLi4uIGlTQ1NJIHBhcmFtZXRlcnMNCg0KVC0+IExvZ2luIChDTnhTRz0xLDMgRj0w
KQ0KICAgIC4uLiBpU0NTSSBwYXJhbWV0ZXJzDQoNCkFuZCBhdCB0aGUgZW5kOg0KDQpJLT4gTG9n
aW4gKEM9MSwgQ054U0c9MSwzIEY9MSkNCiAgICBvcHRpb25hbCBpU0NTSSBwYXJhbWV0ZXJzIA0K
DQpULT4gTG9naW4gIChDTnhTRz0xLDMgRj0xKSAibG9naW4gYWNjZXB0Ig0KICAgIFRhcmdldE5h
bWU9aXFuLjE5OTktMDcuY29tLmFjbWUuZGlza2FycmF5LnNuLjg4DQoNCklmIHRoZSBpbml0aWF0
b3IgYXV0aGVudGljYXRpb24gaXMgbm90IHN1Y2Nlc3NmdWwsIHRoZSB0YXJnZXQgcmVzcG9uZHMg
d2l0aDoNCg0KVC0+IExvZ2luICJsb2dpbiByZWplY3QiDQoNCkluc3RlYWQgb2YgdGhlIFQtPiBM
b2dpbiBITT08SChBIHwgTSB8IEspPiAgbWVzc2FnZSBhbmQgdGVybWluYXRlcyB0aGUgY29ubmVj
dGlvbi4NCg0KSW4gdGhlIG5leHQgZXhhbXBsZSBvbmx5IHRoZSBpbml0aWF0b3IgaXMgYXV0aGVu
dGljYXRlZCBieSB0aGUgdGFyZ2V0IHZpYSBTUlA6DQoNCkktPiBMb2dpbiAoQz0wLCBDTnhTRz0w
LDEgRj0xKQ0KICAgIEluaXRpYXRvck5hbWU9aXFuLjE5OTktMDcuY29tLm9zLmhvc3RpZC43Nw0K
ICAgIFRhcmdldE5hbWU9aXFuLjE5OTktMDcuY29tLmFjbWUuZGlza2FycmF5LnNuLjg4IA0KICAg
IEhlYWRlckRpZ2VzdD1DUkMtMzJDLG5vbmUNCiAgICBEYXRhRGlnZXN0PUNSQy0zMkMsbm9uZQ0K
ICAgIEF1dGhNZXRob2Q9S1JCNSxTUlAsbm9uZSANCg0KVC0+IExvZ2luLVBSIChDTnhTRz0wLDEg
Rj0wKQ0KICAgIEhlYWRlckRpZ2VzdD1DUkMtMzJDDQogICAgRGF0YURpZ2VzdD1DUkMtMzJDDQog
ICAgQXV0aE1ldGhvZD1TUlANCg0KSS0+IExvZ2luIChDPTEsIENOeFNHPTAsMSBGPTApDQogICAg
VT08dXNlcj4NCiAgICBUYXJnZXRBdXRoPW5vDQoNCiAgIFQtPiBMb2dpbiAoQ054U0c9MCwxIEY9
MCkNCiAgICAgICBOPTxOPiANCiAgICAgICBnPTxnPg0KICAgICAgIHM9PHM+DQoNCkktPiBMb2dp
biAoQz0xLCBDTnhTRz0wLDEgRj0wKSANCiAgICBBPTxBPg0KDQpULT4gTG9naW4gKENOeFNHPTAs
MSBGPTApIA0KICAgIEI9PEI+DQoNCkktPiBMb2dpbiAoQz0xLCBDTnhTRz0wLDEgRj0xKSANCiAg
ICBNPTxNPg0KIA0KSWYgdGhlIGluaXRpYXRvciBhdXRoZW50aWNhdGlvbiBpcyBzdWNjZXNzZnVs
LCB0aGUgdGFyZ2V0IHByb2NlZWRzOg0KDQpULT4gTG9naW4gKENOeFNHPTAsMSBGPTEpDQoNCkZy
b20gdGhpcyBwb2ludCBvbiwgYW55IExvZ2luIGNvbW1hbmQgYW5kIGVhY2ggUERVIHRoZXJlYWZ0
ZXIgTVVTVCBoYXZlIENSQy0zMkMgZGlnZXN0cyBmb3IgdGhlIGhlYWRlciBhbmQgdGhlIGRhdGEu
DQoNCkktPiBMb2dpbiAoQz0xLCBDTnhTRz0xLDMgRj0wKSANCiAgICAuLi4gaVNDU0kgcGFyYW1l
dGVycw0KDQpULT4gTG9naW4gKEM9MSwgQ054U0c9MSwzIEY9MCkNCiAgICAuLi4gaVNDU0kgcGFy
YW1ldGVycw0KDQpBbmQgYXQgdGhlIGVuZDoNCg0KSS0+IExvZ2luIChDPTEsIENOeFNHPTEsMyBG
PTEpDQogICAgb3B0aW9uYWwgaVNDU0kgcGFyYW1ldGVycw0KDQpULT4gTG9naW4gKENOeFNHPTEs
MyBGPTEpICJsb2dpbiBhY2NlcHQiDQogICAgVGFyZ2V0TmFtZT1pcW4uMTk5OS0wNy5jb20uYWNt
ZS5kaXNrYXJyYXkuc24uODgNCg0KDQpJbiB0aGUgbmV4dCBleGFtcGxlIHRoZSBpbml0aWF0b3Ig
YW5kIHRhcmdldCBhdXRoZW50aWNhdGUgZWFjaCBvdGhlciB2aWEgQ0hBUDoNCg0KSS0+IExvZ2lu
IChDPTAsIENOeFNHPTAsMSBGPTApIA0KICAgIEluaXRpYXRvck5hbWU9aXFuLjE5OTktMDcuY29t
Lm9zLmhvc3RpZC43Nw0KICAgIFRhcmdldE5hbWU9aXFuLjE5OTktMDcuY29tLmFjbWUuZGlza2Fy
cmF5LnNuLjg4IA0KICAgIEhlYWRlckRpZ2VzdD1DUkMtMzJDLG5vbmUNCiAgICBEYXRhRGlnZXN0
PUNSQy0zMkMsbm9uZQ0KICAgIEF1dGhNZXRob2Q9S1JCNSxDSEFQLG5vbmUgDQoNClQtPiBMb2dp
bi1QUiAoQ054U0c9MCwxIEY9MCkNCiAgICBIZWFkZXJEaWdlc3Q9Q1JDLTMyQw0KICAgIERhdGFE
aWdlc3Q9Q1JDLTMyQw0KICAgIEF1dGhNZXRob2Q9Q0hBUA0KDQpJLT4gTG9naW4gKEM9MSwgQ054
U0c9MCwxIEY9MCkNCiAgICBBPTxBMSxBMj4NCg0KICAgVC0+IExvZ2luIChDTnhTRz0wLDEgRj0w
KSANCiAgICAgICBBPTxBMT4gDQogICAgICAgST08ST4gDQogICAgICAgQz08Qz4NCg0KSS0+IExv
Z2luIChDPTEsIENOeFNHPTAsMSBGPTEpDQogICAgTj08Tj4gDQogICAgUj08Uj4gDQogICAgST08
ST4gDQogICAgQz08Qz4gDQoNCklmIHRoZSBpbml0aWF0b3IgYXV0aGVudGljYXRpb24gaXMgc3Vj
Y2Vzc2Z1bCwgdGhlIHRhcmdldCBwcm9jZWVkczoNCg0KVC0+IExvZ2luIChDTnhTRz0wLDEgRj0x
KSANCiAgICBOPTxOPiANCiAgICBSPTxSPg0KDQpJZiB0aGUgdGFyZ2V0IGF1dGhlbnRpY2F0aW9u
IGlzIG5vdCBzdWNjZXNzZnVsLCB0aGUgaW5pdGlhdG9yIGFib3J0cyB0aGUgY29ubmVjdGlvbi4g
T3RoZXJ3aXNlIGl0IHByb2NlZWRzLg0KDQpGcm9tIHRoaXMgcG9pbnQgb24sIGFueSBMb2dpbiBj
b21tYW5kIGFuZCBlYWNoIFBEVSB0aGVyZWFmdGVyIE1VU1QgaGF2ZSBDUkMtMzJDIGRpZ2VzdHMg
Zm9yIHRoZSBoZWFkZXIgYW5kIHRoZSBkYXRhLg0KDQpJLT4gTG9naW4gKEM9MSwgQ054U0c9MSwz
IEY9MCkgDQogICAgLi4uIGlTQ1NJIHBhcmFtZXRlcnMNClQtPiBMb2dpbiAoQ054U0c9MSwzIEY9
MCkgDQogICAgLi4uIGlTQ1NJIHBhcmFtZXRlcnMNCg0KQW5kIGF0IHRoZSBlbmQ6DQoNCkktPiBM
b2dpbiAoQz0xLCBDTnhTRz0xLDMgRj0xKSANCiAgICBvcHRpb25hbCBpU0NTSSBwYXJhbWV0ZXJz
DQoNClQtPiBMb2dpbiAoQ054U0c9MSwzIEY9MSkgImxvZ2luIGFjY2VwdCIgDQogICAgVGFyZ2V0
TmFtZT1pcW4uMTk5OS0wNy5jb20uYWNtZS5kaXNrYXJyYXkuc24uODgNCg0KSWYgdGhlIGluaXRp
YXRvciBhdXRoZW50aWNhdGlvbiBpcyBub3Qgc3VjY2Vzc2Z1bCwgdGhlIHRhcmdldCByZXNwb25k
cyB3aXRoOg0KDQpULT4gTG9naW4gImxvZ2luIHJlamVjdCINCg0KSW5zdGVhZCBvZiB0aGUgTG9n
aW4gUj08cmVzcG9uc2U+IFNlY3VyaXR5Q29udGV4dENvbXBsZXRlPXllcw0KbWVzc2FnZSBhbmQg
dGVybWluYXRlcyB0aGUgY29ubmVjdGlvbi4NCg0KDQpJbiB0aGUgbmV4dCBleGFtcGxlIG9ubHkg
dGhlIGluaXRpYXRvciBpcyBhdXRoZW50aWNhdGVkIGJ5IHRoZSB0YXJnZXQgdmlhIENIQVA6DQoN
CkktPiBMb2dpbiAoQz0wLCBDTnhTRz0wLDEgRj0wKSANCiAgICBJbml0aWF0b3JOYW1lPWlxbi4x
OTk5LTA3LmNvbS5vcy5ob3N0aWQuNzcNCiAgICBUYXJnZXROYW1lPWlxbi4xOTk5LTA3LmNvbS5h
Y21lLmRpc2thcnJheS5zbi44OCANCiAgICBIZWFkZXJEaWdlc3Q9Q1JDLTMyQyxub25lDQogICAg
RGF0YURpZ2VzdD1DUkMtMzJDLG5vbmUNCiAgICBBdXRoTWV0aG9kPUtSQjUsQ0hBUCxub25lIA0K
DQpULT4gTG9naW4tUFIgKENOeFNHPTAsMSBGPTApDQogICAgSGVhZGVyRGlnZXN0PUNSQy0zMkMN
CiAgICBEYXRhRGlnZXN0PUNSQy0zMkMgDQogICAgQXV0aE1ldGhvZD1DSEFQDQoNCkktPiBMb2dp
biAoQz0xLCBDTnhTRz0wLDEgRj0wKSANCiAgICBBPTxBMSxBMj4NCg0KICAgVC0+IExvZ2luIChD
TnhTRz0wLDEgRj0wKSANCiAgICAgICBBPTxBMT4gDQogICAgICAgST08ST4gDQogICAgICAgQz08
Qz4NCg0KSS0+IExvZ2luIChDPTEsIENOeFNHPTAsMSBGPTEpIA0KICAgIE49PE4+IA0KICAgIFI9
PFI+IA0KDQpJZiB0aGUgaW5pdGlhdG9yIGF1dGhlbnRpY2F0aW9uIGlzIHN1Y2Nlc3NmdWwsIHRo
ZSB0YXJnZXQgcHJvY2VlZHM6DQoNClQtPiBMb2dpbiAoQ054U0c9MCwxIEY9MSkNCg0KSS0+IExv
Z2luIChDPTEsIENOeFNHPTEsMyBGPTApIA0KICAgIC4uLiBpU0NTSSBwYXJhbWV0ZXJzDQoNClQt
PiBMb2dpbiAoQ054U0c9MSwzIEY9MCkgDQogICAgLi4uIGlTQ1NJIHBhcmFtZXRlcnMNCg0KQW5k
IGF0IHRoZSBlbmQ6DQoNCkktPiBMb2dpbiAoQz0xLCBDTnhTRz0xLDMgRj0xKSANCiAgICBvcHRp
b25hbCBpU0NTSSBwYXJhbWV0ZXJzDQoNClQtPiBMb2dpbiAoQ054U0c9MSwzIEY9MSkgImxvZ2lu
IGFjY2VwdCIgDQogICAgVGFyZ2V0TmFtZT1pcW4uMTk5OS0wNy5jb20uYWNtZS5kaXNrYXJyYXku
c24uODgNCg0KDQpJbiB0aGUgbmV4dCBleGFtcGxlLCB0aGUgaW5pdGlhdG9yIGRvZXMgbm90IG9m
ZmVyIGFueSBzZWN1cml0eS9pbnRlZ3JpdHkgcGFyYW1ldGVycywgc28gaXQgbWF5IG9mZmVyIGlT
Q1NJIHBhcmFtZXRlcnMgb24gdGhlIExvZ2luIFBEVSB3aXRoIHRoZSBGIGJpdCBzZXQgdG8gMSwg
YW5kIHRoZSB0YXJnZXQgbWF5IHJlc3BvbmQgd2l0aCBhIGZpbmFsIExvZ2luIFJlc3BvbnNlIFBE
VSBpbW1lZGlhdGVseToNCg0KSS0+IExvZ2luIChDPTAsIENOeFNHPTEsMyBGPTEpIA0KICAgIElu
aXRpYXRvck5hbWU9aXFuLjE5OTktMDcuY29tLm9zLmhvc3RpZC43Nw0KICAgIFRhcmdldE5hbWU9
aXFuLjE5OTktMDcuY29tLmFjbWUuZGlza2FycmF5LnNuLjg4ICANCiAgICAuLi4gaVNDU0kgcGFy
YW1ldGVycw0KDQpULT4gTG9naW4gKENOeFNHPTEsMyBGPTEpICJsb2dpbiBhY2NlcHQiIA0KICAg
IFRhcmdldE5hbWU9aXFuLjE5OTktMDcuY29tLmFjbWUuZGlza2FycmF5LnNuLjg4ICANCiAgICAu
Li4gSVNDU0kgcGFyYW1ldGVycw0KDQpJbiB0aGUgbmV4dCBleGFtcGxlLCB0aGUgaW5pdGlhdG9y
IGRvZXMgb2ZmZXIgc2VjdXJpdHkvaW50ZWdyaXR5IHBhcmFtZXRlcnMgb24gdGhlIExvZ2luIFBE
VSwgYnV0IHRoZSB0YXJnZXQgZG9lcyBub3QgY2hvb3NlIGFueSAoaS5lLiwgY2hvb3NlcyB0aGUg
Im5vbmUiIHZhbHVlcyk6DQoNCkktPiBMb2dpbiAoQz0wLCBDTnhTRz0wLDEgRj0xKSANCiAgICBJ
bml0aWF0b3JOYW1lPWlxbi4xOTk5LTA3LmNvbS5vcy5ob3N0aWQuNzcNCiAgICBUYXJnZXROYW1l
PWlxbi4xOTk5LTA3LmNvbS5hY21lLmRpc2thcnJheS5zbi44OCANCiAgICBIZWFkZXJEaWdlc3Q9
Q1JDLTMyQyxub25lIA0KICAgIERhdGFEaWdlc3Q9Q1JDLTMyQyxub25lIA0KICAgIEF1dGhNZXRo
b2Q6S1JCNSxTUlAsbm9uZQ0KDQpULT4gTG9naW4tUFIgKENOeFNHPTAsMSBGPTEpIA0KICAgIEhl
YWRlckRpZ2VzdD1ub25lIA0KICAgIERhdGFEaWdlc3Q9bm9uZSANCiAgICBBdXRoTWV0aG9kPW5v
bmUNCg0KSS0+IExvZ2luIChDPTEsIENOeFNHPTEsMyBGPTApIA0KICAgIC4uLiBpU0NTSSBwYXJh
bWV0ZXJzDQoNClQtPiBMb2dpbiAoQ054U0c9MSwzIEY9MCkgDQogICAgLi4uIGlTQ1NJIHBhcmFt
ZXRlcnMNCg0KQW5kIGF0IHRoZSBlbmQ6DQoNCkktPiBMb2dpbiAoQz0xLCBDTnhTRz0xLDMgRj0x
KSANCiAgICBvcHRpb25hbCBpU0NTSSBwYXJhbWV0ZXJzDQoNClQtPiBMb2dpbiAoQ054U0c9MSwz
IEY9MSkgImxvZ2luIGFjY2VwdCIgDQogICAgVGFyZ2V0TmFtZT1pcW4uMTk5OS0wNy5jb20uYWNt
ZS5kaXNrYXJyYXkuc24uODgNCg0K

--0__=C2256AB8005AF60F8f9e8a93df938690918cC2256AB8005AF60F--



From owner-ips@ece.cmu.edu  Thu Aug 30 16:36:24 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27441
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 16:36:24 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7UIkQ200857
	for ips-outgoing; Thu, 30 Aug 2001 14:46:26 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7UIkNP00847
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 14:46:23 -0400 (EDT)
Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77])
	by msgbas2.cos.agilent.com (Postfix) with ESMTP
	id 166ED1550; Thu, 30 Aug 2001 12:46:16 -0600 (MDT)
Received: from axcsbh2.cos.agilent.com (axcsbh2.cos.agilent.com [130.29.152.144])
	by msgrel1.cos.agilent.com (Postfix) with SMTP
	id BC3E3913; Thu, 30 Aug 2001 12:46:15 -0600 (MDT)
Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Thu, 30 Aug 2001 12:46:14 -0600 (Mountain Daylight Time)
Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19)
	id <Q9QT951N>; Thu, 30 Aug 2001 12:46:13 -0600
Message-ID: <5708CCE35B15D41188300090278CB06C02A84452@axcs10.cos.agilent.com>
From: "CLEMENT,ERIC L (A-Roseville,ex1)" <eric_l_clement@agilent.com>
To: "'Black_David@emc.com'" <Black_David@emc.com>
Cc: "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
Subject: iSCSI-08 Draft Availability?
Date: Thu, 30 Aug 2001 12:46:12 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Hi David,

Do you know what timeframe the iSCSI-08 draft will be available?

Regards,
Eric
__________________________________

Eric Clement
Agilent Technologies, Inc.
1101 Creekside Ridge Drive
Suite 100, MS RH-21
Roseville, California 95661

Phone: 916.788.6211
Fax: 916.788.6134
Email: Eric_L_Clement@Agilent.com
___________________________________ 



To: ips@ece.cmu.edu 
Subject: IPS Draft Status and Schedule 
From: Black_David@emc.com 
Date: Wed, 22 Aug 2001 17:24:11 -0400 
Content-Type: text/plain;charset="iso-8859-1" 
Sender: owner-ips@ece.cmu.edu 

----------------------------------------------------------------------------
----

Here's what the WG chairs think the current status and schedule
is for the drafts that the IP Storage WG is working on (including
three individual submissions that have agenda time in Orange
County).  This is probably not 100% accurate, but should be
close.  Draft authors - please send any corrections to me.

Apologies for being tardy on this - this should have been done
about a month ago, but I have negative "copious spare time".
Going forward, the intent is to produce an updated version of
this prior to each WG meeting.  Proposed revised charter will
be coming in the near future, with milestones based on the
completion guesstimates below.

Thanks,
--David

-- iSCSI

draft-ietf-ips-iscsi-07.txt
	To be a proposed standard RFC.
	Large portions are stable, major open security and login issues.
	-08 will be a functional/technical revision, document restructure/
		reorganization expected in -09 version.
	Hope to close all major issues by December 2001 IETF meeting

draft-ietf-ips-iscsi-boot-02.txt
	No major open issues, possible minor issues in DHCP usage.
		DHCP material to be extracted into a separate
standards-track draft.	
	Remainder to become an informational RFC, after the main iSCSI
document.

draft-ietf-ips-iscsi-reqmts-05.txt
	To be an informational RFC.
	Has completed WG Last Call, currently being considered by the IESG,
		IETF Last Call has not been issued.

draft-ietf-ips-iscsi-name-disc-02.txt
	To be an informational RFC.
	Specification portions that must be standards track are being added
		to the main iSCSI specification.
	No major open issues, hope to close any other issues by December
2001 IETF
		meeting.  Plan to issue WG Last Call for this with main
iSCSI draft.

draft-ietf-ips-iscsi-slp-01.txt
	To be a proposed standard RFC.
	Close to done.  Issues in this general area seem to come up in the
		context of the naming and discovery draft (name-disc-02)
rather
		than this draft.
	WG Last Call will be after the naming and discovery draft.

draft-ietf-ips-iscsi-mib-02.txt
	To be a proposed standard RFC.
	Next (-03) version expected in September, should be close to done.
	WG Last Call will follow main iSCSI draft.
	
draft-black-ips-iscsi-security-01.txt
draft-aboba-ips-iscsi-security-00.txt
	Unlikely to become RFCs in their current forms.
	New drafts on iSCSI Security for discussion at Orange County
meeting.
		Security requirements will be specified in the main iSCSI
document.
	Some remaining portions of one or both drafts may become an
		informational RFC.  Whether to do this and what portions to
use
		are subject to discussion.

-- FC Common Encapsulation

draft-ietf-ips-fcencapsulation-02.txt
	To be a proposed standard RFC.
	No major open issues.
	Will accompany FCIP and/or iFCP drafts in Last Call, probably after
		December 2001 IETF.

-- FCIP

draft-ietf-ips-fcovertcpip-05.txt
	To be a proposed standard RFC.
	Large portions are stable, major open security issues.
	Hope to close all major issues by December 2001 IETF meeting.

draft-ietf-ips-fcip-slp-00.txt
	To be a proposed standard RFC.
	New draft for discussion in Orange County.
	Hope to close all major issues by December 2001 IETF meeting.

draft-ietf-ips-fcip-mib-00.txt
	To be a proposed standard RFC.
	New draft for discussion in Orange County.
	Likely timeframe for closing final issues is March 2002 IETF
meeting.

-- iFCP

draft-ietf-ips-ifcp-04.txt
	To be a proposed standard RFC.
	Large portions are stable, major open security issues.
	Hope to close all major issues by December 2001 IETF meeting.

draft-tseng-ifcp-mib-00.txt
	To be a proposed standard RFC.
	New draft for consideration in Orange County, will be proposed for
		approval as an official WG draft.
	Likely timeframe for closing final issues is March 2002 IETF
meeting.

-- iSNS

draft-ietf-ips-isns-04.txt
	To be a proposed standard RFC.
	Relationship to SLP for use with iSCSI seems to be settled, no
		other major open issues.
	WG Last Call to follow iSCSI and iFCP drafts.
	Hope to close any remaining issues by December 2001 IETF meeting.

draft-gibbons-isnsmib-00.txt
	To be a proposed standard RFC.
	Relatively new draft, London meeting approved it as an official
		IPS WG work item, next version will be draft-ietf-ips-...
	Likely timeframe for closing final issues is March 2002 IETF
meeting.

-- Framework

draft-ietf-ips-framework-00.txt
	Has not been updated by author team since original revision.
	Likely to be abandoned in the absence of renewed interest.

-- SCSI MIB

There's been talk about working on this, but no draft has appeared, yet.


----- Document Completion Guesstimates ------

A rough guess is 3 waves of documents:

(1) Main protocol standards.  Close technical issues at December 2001 IETF
	(or before), WG Last Call in early 2002, submit to IESG before
	March 2002 IETF Meeting.
	- iSCSI
	- iSCSI Naming/Discovery
	- FC Encapsulation
	- FCIP
	- iFCP
	Last Call scheduling will be an issue, as there are at least two,
	and possibly more 4 week (or longer) WG Last Calls required for
	the above that probably should not overlap with each other.

(2) Supporting Protocol Documents.  Close technical issues at December
	IETF if possible (but above documents have priority).  WG Last
	Call to follow above, probably in March-April 2002.
	- iSCSI Boot
	- iSCSI SLP
	- FCIP SLP
	- iSNS
	iSNS Last Call should not overlap iSCSI Last Calls, hence at least
	two will be needed, but 2 week WG Last Call periods should suffice
	for these documents.

(3) MIBs.  To follow supporting documents.  Final opportunity to discuss
	at March 2002 IETF Meeting, with WG Last Call to follow shortly
	thereafter.
	- iSCSI MIB
	- FCIP MIB
	- iFCP MIB
	- iSNS MIB
	Probably need two Last Call periods, but again, 2 weeks each
	should be sufficient.  May move Last Call schedule up if
	MIBs are ready to go earlier (e.g., after December 2001 IETF
	meeting).

The waves will overlap in practice, but each main protocol document
needs to make it through WG Last Call before any WG Last Calls are
issued for documents that depend on it.  So for any protocol, wave
(1) has to come before (2) and (3), but (2) and (3) can run in
parallel, and the different protocols may run on different schedules.

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


From owner-ips@ece.cmu.edu  Thu Aug 30 16:39:52 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27518
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 16:39:52 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7UJL6M03097
	for ips-outgoing; Thu, 30 Aug 2001 15:21:06 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7UJL4P03092
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 15:21:04 -0400 (EDT)
Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA19664; Thu, 30 Aug 2001 15:20:48 -0400 (EDT)
Message-ID: <3B8E905E.DDEBFD85@cisco.com>
Date: Thu, 30 Aug 2001 14:13:34 -0500
From: Mark Bakke <mbakke@cisco.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686)
X-Accept-Language: en, de
MIME-Version: 1.0
To: Bill Strahm <bill@sanera.net>
CC: Julian Satran <Julian_Satran@il.ibm.com>,
        "Ips@Ece. Cmu. Edu" <ips@ece.cmu.edu>
Subject: Re: iSCSI - Change - Login/Text commands with the binary stage code
References: <HDECJFNIFJBIAINDCFOMGELDCAAA.bill@sanera.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Bill-

In Irvine, we agreed that when IPsec is enabled, IKE will be used
to do key exchange.  We also agreed on which transforms to use when
IPsec is enabled.

The key word is "enabled".  Keep in mind that there will probably
be three classes of iSCSI implementations "out there":

1. iSCSI implementations without security.  These won't be able to
   say they are "compliant", but are likely to be the majority of
   implementations, at least for a little while.  At any rate, we
   all pay our marketing folks to get us around this one.

2. iSCSI implementations with software security.  These will add
   IPsec in software for one of two reasons: either high performance
   is not required (perhaps it's designed to go over a T1 or something),
   or just so the "RFC-xxxx-compliant" bullet can be checked off on
   the list.  If it's for the first reason, IPsec will be used by
   some customers; if it's for the second reason, it will likely
   never be enabled.

3. iSCSI implementations with hardware security.  These will be
   serious implementations that include IPsec, and can perform
   well enough that a customer will want to use IPsec.  These
   implementations will enable IPsec if the customer needs it, but
   again, might not enable it if this is not a concern.

Your assumption seems to be that because we chose IPsec/IKE, that
it will always be used.  Given the implementations 1 and 2, and
some of 3, that is not always the case.

As you mentioned, when your assumptions are correct, the login
phase only has to exchange initiator and target names, and can
use AuthMethod=none if it likes.  However, those assumptions
will not always hold.

--
Mark

Bill Strahm wrote:
> 
> Ok,
> 
> I am confused here (or maybe it is just a lag effect for me)
> 
> I thought we had decided in Irvine to use IPsec/IKE to negotiate security.
> So basically the process is this
> 
> 1) Administrator makes several entries into a Security Policy Database
> 2) An iSCSI initiator attempts to send a TCP-SYN packet to a target machine
> 3) The IPsec packet filter detects this packet, realized there isn't a
> security association for it, and asks the Security Policy Database what to
> do about it
> 4) The security Policy Database may determine that an IPsec SA needs to be
> established so tells IKE to negotiate with the remote peer
> 5) An IKE negotiation proceeds until either it succeeds or fails
> 6) If it fails, packets are dropped
> 7) If it succeeds, the negotiated SAs are pushed to the IPsec packet filters
> 8) The origional TCP-SYN packet is now sent out under the IPsec SA that was
> negotiated.
> 
> Now under this scenario there is no need for iSCSI to negotiate security at
> all.  I DO now see the need to include an iSCSI Login phase that includes
> passing user identities across so targets and initiators can identify
> themselves, but this is over a secure link (see the above discussion) so I
> can just put ID= Bills-iSCSI-Initiator PW=BetYouCantGuessIt and the link
> will secure it for me...
> 
> Bill
> Sanera Systems Inc.
> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Julian Satran
> Sent: Wednesday, August 29, 2001 2:40 PM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI - Change - Login/Text commands with the binary stage
> code
> 
> Steve,
> 
> Implement and use are different terms. An administrator might set it up not
> to use security under specific conditions.
> 
> Julo
> 
> Steve Senum <ssenum@cisco.com>@ece.cmu.edu on 30-08-2001 00:12:28
> 
> Please respond to Steve Senum <ssenum@cisco.com>
> 
> Sent by:  owner-ips@ece.cmu.edu
> 
> To:   ietf-ips <ips@ece.cmu.edu>
> cc:
> Subject:  Re: iSCSI - Change - Login/Text commands with the binary stage
>       code
> 
> Julian,
> 
> In the following section:
> 
>    If the initiator decides to forego the SecurityNegotiation stage it
>    issues the Login with the CNxSG set to LoginOperationalNegotiation in
>    the current stage and the target may replay with a Login Response
>    indicating that it is unwilling to accept the connection without
>    SecurityNegotiation and terminate the connection.
> 
> This seems contrary to the requirement to implement
> authentication (at least AuthMethod=SRP).  I realize
> this could also be a configuration issue, but I wonder
> if the spec should at least strongly recommend starting
> with phase SecurityNegotiation, or better yet, make it
> a SHOULD?
> 
> Regards,
> Steve Senum

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054


From owner-ips@ece.cmu.edu  Thu Aug 30 16:43:39 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27589
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 16:43:37 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7UJE6102596
	for ips-outgoing; Thu, 30 Aug 2001 15:14:06 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from sandmail.sandburst.com (sandmail.sandburst.com [216.57.132.42])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7UJE5P02592
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 15:14:05 -0400 (EDT)
To: ips@ece.cmu.edu
Cc: "John Hufferd" <hufferd@us.ibm.com>
Subject: Re: ISCSI: User authentication vs. Machine Authentication for iSC SI 
In-Reply-To: Message from "John Hufferd" <hufferd@us.ibm.com> 
   of "Thu, 30 Aug 2001 09:43:19 PDT." <OF761F95F7.844FE06F-ON88256AB8.00574D6B@boulder.ibm.com> 
References: <OF761F95F7.844FE06F-ON88256AB8.00574D6B@boulder.ibm.com> 
Date: Thu, 30 Aug 2001 15:13:33 -0400
From: Stephen Bailey <steph@cs.uchicago.edu>
Message-Id: <20010830191403.A0DE24E95@sandmail.sandburst.com>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

> The new Name (UserID) is exactly what was implied at the meeting in
> Irvine.

Oh.  How horrible.

> A number of us, I am sure, think this is a very poor direction for an
> implementation.

Agreed.  I just wanted to walk the space a little bit.  My point is
that while traditional SCSI passthru does confer control privs (and is
protected as such), it doesn't need to.  Specifically, a client using
SCSI passthru is not actually given the identity of the host OS, per
se.

> So I believe we must consider such a potential application as
> probably a rouge application and do nothing to help this, and work
> to prevent it.

I understand what you're saying, but I'm not sure it confers much
architectural direction.  There already must be a concept of identity
which is independent of anything bound to a particular system (e.g. IP
address, hardware network port etc.), so there's no way to exclude
that.

> The important issue is, can we make the iSCSI Initiator Node Name be
> used as the UserID.

Agreed.  Are there minutes to the meeting?

Thanks,
  Steph


From owner-ips@ece.cmu.edu  Thu Aug 30 16:44:18 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27622
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 16:44:18 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7UInFW01007
	for ips-outgoing; Thu, 30 Aug 2001 14:49:15 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from sentinel.sanera.net (ns1.sanera.net [208.253.254.10] (may be forged))
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7UInDP01003
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 14:49:13 -0400 (EDT)
Received: from newton.sanera.net (newton [192.168.254.11])
	by sentinel.sanera.net (8.11.2/8.11.2) with ESMTP id f7UIn7225901;
	Thu, 30 Aug 2001 11:49:07 -0700
Received: from strahmw2k (dhcp-pc-100-165.sanera.net [192.168.100.165])
	by newton.sanera.net (8.11.4/8.11.4) with SMTP id f7UIn2U00854;
	Thu, 30 Aug 2001 11:49:02 -0700 (PDT)
From: "Bill Strahm" <bill@sanera.net>
To: "Julian Satran" <Julian_Satran@il.ibm.com>
Cc: "Ips@Ece. Cmu. Edu" <ips@ece.cmu.edu>
Subject: RE: iSCSI - Change - Login/Text commands with the binary stage code
Date: Thu, 30 Aug 2001 11:49:01 -0700
Message-ID: <HDECJFNIFJBIAINDCFOMGELDCAAA.bill@sanera.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <OFCDF400C1.1FFD51D6-ONC2256AB7.0076E777@telaviv.ibm.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Ok,

I am confused here (or maybe it is just a lag effect for me)

I thought we had decided in Irvine to use IPsec/IKE to negotiate security.
So basically the process is this

1) Administrator makes several entries into a Security Policy Database
2) An iSCSI initiator attempts to send a TCP-SYN packet to a target machine
3) The IPsec packet filter detects this packet, realized there isn't a
security association for it, and asks the Security Policy Database what to
do about it
4) The security Policy Database may determine that an IPsec SA needs to be
established so tells IKE to negotiate with the remote peer
5) An IKE negotiation proceeds until either it succeeds or fails
6) If it fails, packets are dropped
7) If it succeeds, the negotiated SAs are pushed to the IPsec packet filters
8) The origional TCP-SYN packet is now sent out under the IPsec SA that was
negotiated.

Now under this scenario there is no need for iSCSI to negotiate security at
all.  I DO now see the need to include an iSCSI Login phase that includes
passing user identities across so targets and initiators can identify
themselves, but this is over a secure link (see the above discussion) so I
can just put ID= Bills-iSCSI-Initiator PW=BetYouCantGuessIt and the link
will secure it for me...

Bill
Sanera Systems Inc.
-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Julian Satran
Sent: Wednesday, August 29, 2001 2:40 PM
To: ips@ece.cmu.edu
Subject: Re: iSCSI - Change - Login/Text commands with the binary stage
code



Steve,

Implement and use are different terms. An administrator might set it up not
to use security under specific conditions.

Julo

Steve Senum <ssenum@cisco.com>@ece.cmu.edu on 30-08-2001 00:12:28

Please respond to Steve Senum <ssenum@cisco.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ietf-ips <ips@ece.cmu.edu>
cc:
Subject:  Re: iSCSI - Change - Login/Text commands with the binary stage
      code



Julian,

In the following section:

   If the initiator decides to forego the SecurityNegotiation stage it
   issues the Login with the CNxSG set to LoginOperationalNegotiation in
   the current stage and the target may replay with a Login Response
   indicating that it is unwilling to accept the connection without
   SecurityNegotiation and terminate the connection.

This seems contrary to the requirement to implement
authentication (at least AuthMethod=SRP).  I realize
this could also be a configuration issue, but I wonder
if the spec should at least strongly recommend starting
with phase SecurityNegotiation, or better yet, make it
a SHOULD?

Regards,
Steve Senum






From owner-ips@ece.cmu.edu  Thu Aug 30 17:32:58 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28498
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 17:32:57 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7UKF3m06542
	for ips-outgoing; Thu, 30 Aug 2001 16:15:03 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7UKF1P06533
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 16:15:01 -0400 (EDT)
Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA24162; Thu, 30 Aug 2001 16:14:49 -0400 (EDT)
Message-ID: <3B8E9D07.720E107B@cisco.com>
Date: Thu, 30 Aug 2001 15:07:35 -0500
From: Mark Bakke <mbakke@cisco.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686)
X-Accept-Language: en, de
MIME-Version: 1.0
To: Stephen Bailey <steph@cs.uchicago.edu>
CC: ips@ece.cmu.edu, John Hufferd <hufferd@us.ibm.com>
Subject: Re: ISCSI: User authentication vs. Machine Authentication for iSC SI
References: <OF761F95F7.844FE06F-ON88256AB8.00574D6B@boulder.ibm.com> <20010830191403.A0DE24E95@sandmail.sandburst.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Stephen Bailey wrote:
> 
> > The new Name (UserID) is exactly what was implied at the meeting in
> > Irvine.
> 
> Oh.  How horrible.

Ideally, you're right.  For instance, if iSCSI was using AuthMethod=CHAP,
then it would be great if the CHAP username (N) specified was identical
to the InitiatorName.

In the draft, that's not how it is.  The user names for CHAP and SRP
(I'm not sure about the others) are specified separately from the
InitiatorName, so there's currently nothing in the protocol to prevent
them from being different.

In practise, there might be times when having them be different
makes the "fit in" better with whatever administration scheme is
out there.  For instance, if my desktop was assigned some iSCSI
storage, and my username and password were kept on a RADIUS server
somewhere, for use by file servers, web servers, and iSCSI servers
or devices, my user name is likely to be a non-globally-unique
string, probably "mbakke".  However, that's not likely to be
my InitiatorName.  To make them the same, I would either have to
change my InitiatorName on my desktop to "mbakke", to fit in with
my login on all of our web and file servers, or the admin would
have to create a new login for my iSCSI stuff on the RADIUS server,
and maintain two of them.  Changing my login on everything to
match an iSCSI name is likely not an option.

Another possible place this could happen is if I am obtaining
iSCSI "services" from more than one administratively-separate
environment.  Each of these environments may prefer to assign
me a user name for login that matches their own internal scheme.
I may have some control over this, but in the end, it has to be
unique within the service-provider's scheme.  This is very
similar to setting up a user-name for your ISP at home; you
may request a particular name, but if the ISP already has one,
you have to pick again.

The point is that if one had two of these environments providing
services, they may each need a separate user name.

Of course, the latter example could be solved by having the
admins accept the initiator name that's already on my iSCSI
client as the user name; these are supposed to be unique
anyway.  The only trouble then is the same as before; if I am
getting more than just iSCSI services from this provider, they
would then have to maintain two user names for me.

A third reason this might happen is that some centralized
password authenticated services such as RADIUS may have
length restrictions on their user names that are shorter than
what is allowed in an iSCSI initiator name.

Anyway, implementations have the most flexibility the way
these protocols (SRP, CHAP) are currently documented.  I think
that we could recommend that the iSCSI initiator name be the
same wherever possible, but I don't see how we can require it.

> 
> > A number of us, I am sure, think this is a very poor direction for an
> > implementation.
> 
> Agreed.  I just wanted to walk the space a little bit.  My point is
> that while traditional SCSI passthru does confer control privs (and is
> protected as such), it doesn't need to.  Specifically, a client using
> SCSI passthru is not actually given the identity of the host OS, per
> se.
> 
> > So I believe we must consider such a potential application as
> > probably a rouge application and do nothing to help this, and work
> > to prevent it.
> 
> I understand what you're saying, but I'm not sure it confers much
> architectural direction.  There already must be a concept of identity
> which is independent of anything bound to a particular system (e.g. IP
> address, hardware network port etc.), so there's no way to exclude
> that.
> 
> > The important issue is, can we make the iSCSI Initiator Node Name be
> > used as the UserID.


Again, I think that the best we can do is recommend that they
be the same, but I don't think we can take the step of requiring
it.


> Agreed.  Are there minutes to the meeting?
> 
> Thanks,
>   Steph

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054


From owner-ips@ece.cmu.edu  Thu Aug 30 17:35:38 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28524
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 17:35:37 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7UK7sm06090
	for ips-outgoing; Thu, 30 Aug 2001 16:07:54 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from sentinel.sanera.net (ns1.sanera.net [208.253.254.10] (may be forged))
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7UK7qP06086
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 16:07:52 -0400 (EDT)
Received: from newton.sanera.net (newton [192.168.254.11])
	by sentinel.sanera.net (8.11.2/8.11.2) with ESMTP id f7UK3i226176;
	Thu, 30 Aug 2001 13:03:44 -0700
Received: from strahmw2k (dhcp-pc-100-165.sanera.net [192.168.100.165])
	by newton.sanera.net (8.11.4/8.11.4) with SMTP id f7UK3bU05646;
	Thu, 30 Aug 2001 13:03:37 -0700 (PDT)
From: "Bill Strahm" <bill@sanera.net>
To: <mbakke@cisco.com>
Cc: "Julian Satran" <Julian_Satran@il.ibm.com>,
        "Ips@Ece. Cmu. Edu" <ips@ece.cmu.edu>
Subject: RE: iSCSI - Change - Login/Text commands with the binary stage code
Date: Thu, 30 Aug 2001 13:03:36 -0700
Message-ID: <HDECJFNIFJBIAINDCFOMGELECAAA.bill@sanera.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <3B8E905E.DDEBFD85@cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

So you are saying that there will be a second layer of security that we will
build on top of TCP to secure the iSCSI traffic above and beyond the
security available at layer 3 IPsec ???

I agree with your deployment strategies.  It will be up to custommers to
determine what is important, and how much to pay for security.  If the
custommer determines that the price that they are willing to pay for
security is 0, then you get products of type 1 maybe 2.  If the custommer is
willing to pay for the cost of security you will end up with products like 2
and 3.

What I don't like is that if a custommer only wants to pay for 1, he has to
pick up 2 & 3 as well, and also if a custommer only wants to pay for 1,
having any illusions that there is security.

I am concerned that there will be layer 7 authentication/encryption methods,
on top of layer 4 authentication/encryption methods, on top of layer 3
authentication/encryption methods on top of layer 2
authentication/encryption methods...  I want a security method specified,
and either it is implemented or not, if it is not - you don't get security.
Why is specifying another layer of security that I don't have to implement
going to lead to anything other than interoperablility problems

Bill
Sanera Systems Inc.

-----Original Message-----
From: mbakke@cisco.com [mailto:mbakke@cisco.com]
Sent: Thursday, August 30, 2001 12:14 PM
To: Bill Strahm
Cc: Julian Satran; Ips@Ece. Cmu. Edu
Subject: Re: iSCSI - Change - Login/Text commands with the binary stage
code


Bill-

In Irvine, we agreed that when IPsec is enabled, IKE will be used
to do key exchange.  We also agreed on which transforms to use when
IPsec is enabled.

The key word is "enabled".  Keep in mind that there will probably
be three classes of iSCSI implementations "out there":

1. iSCSI implementations without security.  These won't be able to
   say they are "compliant", but are likely to be the majority of
   implementations, at least for a little while.  At any rate, we
   all pay our marketing folks to get us around this one.

2. iSCSI implementations with software security.  These will add
   IPsec in software for one of two reasons: either high performance
   is not required (perhaps it's designed to go over a T1 or something),
   or just so the "RFC-xxxx-compliant" bullet can be checked off on
   the list.  If it's for the first reason, IPsec will be used by
   some customers; if it's for the second reason, it will likely
   never be enabled.

3. iSCSI implementations with hardware security.  These will be
   serious implementations that include IPsec, and can perform
   well enough that a customer will want to use IPsec.  These
   implementations will enable IPsec if the customer needs it, but
   again, might not enable it if this is not a concern.

Your assumption seems to be that because we chose IPsec/IKE, that
it will always be used.  Given the implementations 1 and 2, and
some of 3, that is not always the case.

As you mentioned, when your assumptions are correct, the login
phase only has to exchange initiator and target names, and can
use AuthMethod=none if it likes.  However, those assumptions
will not always hold.

--
Mark

Bill Strahm wrote:
>
> Ok,
>
> I am confused here (or maybe it is just a lag effect for me)
>
> I thought we had decided in Irvine to use IPsec/IKE to negotiate security.
> So basically the process is this
>
> 1) Administrator makes several entries into a Security Policy Database
> 2) An iSCSI initiator attempts to send a TCP-SYN packet to a target
machine
> 3) The IPsec packet filter detects this packet, realized there isn't a
> security association for it, and asks the Security Policy Database what to
> do about it
> 4) The security Policy Database may determine that an IPsec SA needs to be
> established so tells IKE to negotiate with the remote peer
> 5) An IKE negotiation proceeds until either it succeeds or fails
> 6) If it fails, packets are dropped
> 7) If it succeeds, the negotiated SAs are pushed to the IPsec packet
filters
> 8) The origional TCP-SYN packet is now sent out under the IPsec SA that
was
> negotiated.
>
> Now under this scenario there is no need for iSCSI to negotiate security
at
> all.  I DO now see the need to include an iSCSI Login phase that includes
> passing user identities across so targets and initiators can identify
> themselves, but this is over a secure link (see the above discussion) so I
> can just put ID= Bills-iSCSI-Initiator PW=BetYouCantGuessIt and the link
> will secure it for me...
>
> Bill
> Sanera Systems Inc.
> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Julian Satran
> Sent: Wednesday, August 29, 2001 2:40 PM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI - Change - Login/Text commands with the binary stage
> code
>
> Steve,
>
> Implement and use are different terms. An administrator might set it up
not
> to use security under specific conditions.
>
> Julo
>
> Steve Senum <ssenum@cisco.com>@ece.cmu.edu on 30-08-2001 00:12:28
>
> Please respond to Steve Senum <ssenum@cisco.com>
>
> Sent by:  owner-ips@ece.cmu.edu
>
> To:   ietf-ips <ips@ece.cmu.edu>
> cc:
> Subject:  Re: iSCSI - Change - Login/Text commands with the binary stage
>       code
>
> Julian,
>
> In the following section:
>
>    If the initiator decides to forego the SecurityNegotiation stage it
>    issues the Login with the CNxSG set to LoginOperationalNegotiation in
>    the current stage and the target may replay with a Login Response
>    indicating that it is unwilling to accept the connection without
>    SecurityNegotiation and terminate the connection.
>
> This seems contrary to the requirement to implement
> authentication (at least AuthMethod=SRP).  I realize
> this could also be a configuration issue, but I wonder
> if the spec should at least strongly recommend starting
> with phase SecurityNegotiation, or better yet, make it
> a SHOULD?
>
> Regards,
> Steve Senum

--
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054



From owner-ips@ece.cmu.edu  Thu Aug 30 17:36:15 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28539
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 17:36:14 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7UJpJO04950
	for ips-outgoing; Thu, 30 Aug 2001 15:51:19 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e34.bld.us.ibm.com (e34.co.us.ibm.com [32.97.110.132])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7UJpGP04944
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 15:51:16 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e34.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA18344
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 15:48:58 -0400
Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7UJnrD185782
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 13:49:53 -0600
X-Priority: 1 (High)
Importance: Normal
Subject: RE: iSCSI: reusing ISID for recovery
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OFA26A9057.3751B6B8-ON88256AB8.0064D8C0@boulder.ibm.com>
From: "John Hufferd" <hufferd@us.ibm.com>
Date: Thu, 30 Aug 2001 12:47:31 -0700
X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at
 08/30/2001 01:49:53 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Folks,
Following your notes, I think  that if an initiator does not know what it
is doing, rather then having a new semantic on Login, why not just Logout,
then re-Login.
Since this should only happen like "Never", if you have coded things well,
and the infrequency should mean that the extra hand shake is not a problem.

However,  if you do not know what your session's TSID is, you probably are
two screwed up to make even the above Logout work, so I think this is what
you are all trying to address.  That is,  we  need to have a method to blow
everything away and start again when the initiator has lost the TSID of its
Session.  This is why we have option A, and Option B.

So I think the issue here is do we add additional responses at boot up
time, or not.  (Quit frankly I do not think this is an important issue,
either way.) However, it is a consideration.  If mode B is used, the clean
up bit is available, and initiators that use it all the time, will usually
cause the Extra interaction to occur at boot, because the normal case would
be that things come up clean.  (Since I think we said that if things are
clean, an error response would be issued. Therefore, most of the time, the
extra response is going to happen).  If, as some have suggested, the right
way to code this is to use  the Clean up bit only when there is a rejection
of the Login, because of existing sessions, and require that the initiator
should come back with the Login again but this time with the Clean up bit
set. The argument is made that there will not normally  be any extra
interaction.  Just extra interactions when clean-up is needed. (This
approach has been called Option B.)  The other approach is known as Option
A.  It will implicitly start the Login and clear out any existing session
when the Login is issued.   There will never be extra responses with Option
A, and there will only be extra responses in option B when the Target
rejects the Login because of a existing session. The Option B clean-up
action will not happen often, and the code is not hard, but there is more
code, perhaps 100 lines.

Now the folks that support option A say that they will not have to do
anything special since they want the Login to always succeed and blow away
any other thing that might be going on.  It is clear that this has less
code and interaction at boot/Startup. (However 100 lines of code is not a
big deal anyway.)
It also seem to me that there is probably less code on the target since
they do not have to do inspection of whether or not sessions are active or
not, etc. They just blow them away if they exist.

So all this flapping has to do with whether we need to add (on either side)
some (perhaps small) amount of code so that we use to protect from a buggy
Initiator.

I think this is a Nit in the Draft and is needlessly divisive, over a small
amount of code.

There has also been stated the opinion that option B is needed when their
is more then one OS sharing the Link.  I do not think this applies since
there should be another iSCSI Initiator Name for each OS, and therefore it
is a different session and has nothing to do with the discussion at hand.

Therefore, since the simplification (less code) is on the side of option A,
and since this is really not important anyway, I suggest that all the B
folks roll over since you will not be able to convince the A folks anyway,
and since they do have a valid (small) argument that Option B requires more
complexity and lines of code.

So I recommend Option A, and lets move on.  This does not deserver the list
space, or the emotion  it has been given.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com



From owner-ips@ece.cmu.edu  Thu Aug 30 17:37:28 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28557
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 17:37:28 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7UJhiX04428
	for ips-outgoing; Thu, 30 Aug 2001 15:43:44 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7UJhbP04421
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 15:43:37 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id VAA74672
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 21:43:24 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7UJhNp89348
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 21:43:24 +0200
Importance: Normal
Subject: Re: iSCSI-08 Draft Availability?
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFD262D3D5.219680EC-ONC2256AB8.006C351B@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Thu, 30 Aug 2001 22:42:45 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 30/08/2001 22:43:23
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Next week - provided we get some things cooling down. Julo

"CLEMENT,ERIC L (A-Roseville,ex1)" <eric_l_clement@agilent.com>@ece.cmu.edu
on 30-08-2001 21:46:12

Please respond to "CLEMENT,ERIC L (A-Roseville,ex1)"
      <eric_l_clement@agilent.com>

Sent by:  owner-ips@ece.cmu.edu


To:   "'Black_David@emc.com'" <Black_David@emc.com>
cc:   "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
Subject:  iSCSI-08 Draft Availability?



Hi David,

Do you know what timeframe the iSCSI-08 draft will be available?

Regards,
Eric
__________________________________

Eric Clement
Agilent Technologies, Inc.
1101 Creekside Ridge Drive
Suite 100, MS RH-21
Roseville, California 95661

Phone: 916.788.6211
Fax: 916.788.6134
Email: Eric_L_Clement@Agilent.com
___________________________________



To: ips@ece.cmu.edu
Subject: IPS Draft Status and Schedule
From: Black_David@emc.com
Date: Wed, 22 Aug 2001 17:24:11 -0400
Content-Type: text/plain;charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu

----------------------------------------------------------------------------

----

Here's what the WG chairs think the current status and schedule
is for the drafts that the IP Storage WG is working on (including
three individual submissions that have agenda time in Orange
County).  This is probably not 100% accurate, but should be
close.  Draft authors - please send any corrections to me.

Apologies for being tardy on this - this should have been done
about a month ago, but I have negative "copious spare time".
Going forward, the intent is to produce an updated version of
this prior to each WG meeting.  Proposed revised charter will
be coming in the near future, with milestones based on the
completion guesstimates below.

Thanks,
--David

-- iSCSI

draft-ietf-ips-iscsi-07.txt
     To be a proposed standard RFC.
     Large portions are stable, major open security and login issues.
     -08 will be a functional/technical revision, document restructure/
          reorganization expected in -09 version.
     Hope to close all major issues by December 2001 IETF meeting

draft-ietf-ips-iscsi-boot-02.txt
     No major open issues, possible minor issues in DHCP usage.
          DHCP material to be extracted into a separate
standards-track draft.
     Remainder to become an informational RFC, after the main iSCSI
document.

draft-ietf-ips-iscsi-reqmts-05.txt
     To be an informational RFC.
     Has completed WG Last Call, currently being considered by the IESG,
          IETF Last Call has not been issued.

draft-ietf-ips-iscsi-name-disc-02.txt
     To be an informational RFC.
     Specification portions that must be standards track are being added
          to the main iSCSI specification.
     No major open issues, hope to close any other issues by December
2001 IETF
          meeting.  Plan to issue WG Last Call for this with main
iSCSI draft.

draft-ietf-ips-iscsi-slp-01.txt
     To be a proposed standard RFC.
     Close to done.  Issues in this general area seem to come up in the
          context of the naming and discovery draft (name-disc-02)
rather
          than this draft.
     WG Last Call will be after the naming and discovery draft.

draft-ietf-ips-iscsi-mib-02.txt
     To be a proposed standard RFC.
     Next (-03) version expected in September, should be close to done.
     WG Last Call will follow main iSCSI draft.

draft-black-ips-iscsi-security-01.txt
draft-aboba-ips-iscsi-security-00.txt
     Unlikely to become RFCs in their current forms.
     New drafts on iSCSI Security for discussion at Orange County
meeting.
          Security requirements will be specified in the main iSCSI
document.
     Some remaining portions of one or both drafts may become an
          informational RFC.  Whether to do this and what portions to
use
          are subject to discussion.

-- FC Common Encapsulation

draft-ietf-ips-fcencapsulation-02.txt
     To be a proposed standard RFC.
     No major open issues.
     Will accompany FCIP and/or iFCP drafts in Last Call, probably after
          December 2001 IETF.

-- FCIP

draft-ietf-ips-fcovertcpip-05.txt
     To be a proposed standard RFC.
     Large portions are stable, major open security issues.
     Hope to close all major issues by December 2001 IETF meeting.

draft-ietf-ips-fcip-slp-00.txt
     To be a proposed standard RFC.
     New draft for discussion in Orange County.
     Hope to close all major issues by December 2001 IETF meeting.

draft-ietf-ips-fcip-mib-00.txt
     To be a proposed standard RFC.
     New draft for discussion in Orange County.
     Likely timeframe for closing final issues is March 2002 IETF
meeting.

-- iFCP

draft-ietf-ips-ifcp-04.txt
     To be a proposed standard RFC.
     Large portions are stable, major open security issues.
     Hope to close all major issues by December 2001 IETF meeting.

draft-tseng-ifcp-mib-00.txt
     To be a proposed standard RFC.
     New draft for consideration in Orange County, will be proposed for
          approval as an official WG draft.
     Likely timeframe for closing final issues is March 2002 IETF
meeting.

-- iSNS

draft-ietf-ips-isns-04.txt
     To be a proposed standard RFC.
     Relationship to SLP for use with iSCSI seems to be settled, no
          other major open issues.
     WG Last Call to follow iSCSI and iFCP drafts.
     Hope to close any remaining issues by December 2001 IETF meeting.

draft-gibbons-isnsmib-00.txt
     To be a proposed standard RFC.
     Relatively new draft, London meeting approved it as an official
          IPS WG work item, next version will be draft-ietf-ips-...
     Likely timeframe for closing final issues is March 2002 IETF
meeting.

-- Framework

draft-ietf-ips-framework-00.txt
     Has not been updated by author team since original revision.
     Likely to be abandoned in the absence of renewed interest.

-- SCSI MIB

There's been talk about working on this, but no draft has appeared, yet.


----- Document Completion Guesstimates ------

A rough guess is 3 waves of documents:

(1) Main protocol standards.  Close technical issues at December 2001 IETF
     (or before), WG Last Call in early 2002, submit to IESG before
     March 2002 IETF Meeting.
     - iSCSI
     - iSCSI Naming/Discovery
     - FC Encapsulation
     - FCIP
     - iFCP
     Last Call scheduling will be an issue, as there are at least two,
     and possibly more 4 week (or longer) WG Last Calls required for
     the above that probably should not overlap with each other.

(2) Supporting Protocol Documents.  Close technical issues at December
     IETF if possible (but above documents have priority).  WG Last
     Call to follow above, probably in March-April 2002.
     - iSCSI Boot
     - iSCSI SLP
     - FCIP SLP
     - iSNS
     iSNS Last Call should not overlap iSCSI Last Calls, hence at least
     two will be needed, but 2 week WG Last Call periods should suffice
     for these documents.

(3) MIBs.  To follow supporting documents.  Final opportunity to discuss
     at March 2002 IETF Meeting, with WG Last Call to follow shortly
     thereafter.
     - iSCSI MIB
     - FCIP MIB
     - iFCP MIB
     - iSNS MIB
     Probably need two Last Call periods, but again, 2 weeks each
     should be sufficient.  May move Last Call schedule up if
     MIBs are ready to go earlier (e.g., after December 2001 IETF
     meeting).

The waves will overlap in practice, but each main protocol document
needs to make it through WG Last Call before any WG Last Calls are
issued for documents that depend on it.  So for any protocol, wave
(1) has to come before (2) and (3), but (2) and (3) can run in
parallel, and the different protocols may run on different schedules.

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------





From owner-ips@ece.cmu.edu  Thu Aug 30 17:39:18 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28599
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 17:39:17 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7UJlGD04645
	for ips-outgoing; Thu, 30 Aug 2001 15:47:16 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7UJlDP04639
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 15:47:13 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id VAA53090
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 21:46:57 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7UJkuR203810
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 21:46:56 +0200
Importance: Normal
Subject: RE: iSCSI - Change - Login/Text commands with the binary stage code
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFDBC8B68E.38061E7B-ONC2256AB8.006C711B@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Thu, 30 Aug 2001 22:46:19 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 30/08/2001 22:46:56
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

It may decide to authenticate. This is an end-to-end authentication between
two iSCSI entities
not necesarily equivalent to the IPSec end-point.

Julo

"Bill Strahm" <bill@Sanera.net> on 30-08-2001 21:49:01

Please respond to "Bill Strahm" <bill@Sanera.net>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   "Ips@Ece. Cmu. Edu" <ips@ece.cmu.edu>
Subject:  RE: iSCSI - Change - Login/Text commands with the binary stage
      code



Ok,

I am confused here (or maybe it is just a lag effect for me)

I thought we had decided in Irvine to use IPsec/IKE to negotiate security.
So basically the process is this

1) Administrator makes several entries into a Security Policy Database
2) An iSCSI initiator attempts to send a TCP-SYN packet to a target machine
3) The IPsec packet filter detects this packet, realized there isn't a
security association for it, and asks the Security Policy Database what to
do about it
4) The security Policy Database may determine that an IPsec SA needs to be
established so tells IKE to negotiate with the remote peer
5) An IKE negotiation proceeds until either it succeeds or fails
6) If it fails, packets are dropped
7) If it succeeds, the negotiated SAs are pushed to the IPsec packet
filters
8) The origional TCP-SYN packet is now sent out under the IPsec SA that was
negotiated.

Now under this scenario there is no need for iSCSI to negotiate security at
all.  I DO now see the need to include an iSCSI Login phase that includes
passing user identities across so targets and initiators can identify
themselves, but this is over a secure link (see the above discussion) so I
can just put ID= Bills-iSCSI-Initiator PW=BetYouCantGuessIt and the link
will secure it for me...

Bill
Sanera Systems Inc.
-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Julian Satran
Sent: Wednesday, August 29, 2001 2:40 PM
To: ips@ece.cmu.edu
Subject: Re: iSCSI - Change - Login/Text commands with the binary stage
code



Steve,

Implement and use are different terms. An administrator might set it up not
to use security under specific conditions.

Julo

Steve Senum <ssenum@cisco.com>@ece.cmu.edu on 30-08-2001 00:12:28

Please respond to Steve Senum <ssenum@cisco.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ietf-ips <ips@ece.cmu.edu>
cc:
Subject:  Re: iSCSI - Change - Login/Text commands with the binary stage
      code



Julian,

In the following section:

   If the initiator decides to forego the SecurityNegotiation stage it
   issues the Login with the CNxSG set to LoginOperationalNegotiation in
   the current stage and the target may replay with a Login Response
   indicating that it is unwilling to accept the connection without
   SecurityNegotiation and terminate the connection.

This seems contrary to the requirement to implement
authentication (at least AuthMethod=SRP).  I realize
this could also be a configuration issue, but I wonder
if the spec should at least strongly recommend starting
with phase SecurityNegotiation, or better yet, make it
a SHOULD?

Regards,
Steve Senum









From owner-ips@ece.cmu.edu  Thu Aug 30 17:39:33 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28611
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 17:39:33 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7UKCnL06404
	for ips-outgoing; Thu, 30 Aug 2001 16:12:49 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7UKCjP06399
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 16:12:47 -0400 (EDT)
Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203])
	by palrel1.hp.com (Postfix) with ESMTP id 629681B23
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 13:12:38 -0700 (PDT)
Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197])
	by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id NAA11999
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 13:12:36 -0700 (PDT)
Message-ID: <3B8E9F79.962CF8B2@cup.hp.com>
Date: Thu, 30 Aug 2001 13:18:01 -0700
From: Santosh Rao <santoshr@cup.hp.com>
Organization: Hewlett Packard, Cupertino.
X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778)
X-Accept-Language: en
MIME-Version: 1.0
To: ips@ece.cmu.edu
Subject: Re: iSCSI: reusing ISID for recovery
References: <45BEF1D68145D51186C100B0D0AABE6503D6C3@med.corp.rhapsodynetworks.com>
Content-Type: multipart/mixed;
 boundary="------------55E793E601D955DA48C74E8E"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

This is a multi-part message in MIME format.
--------------55E793E601D955DA48C74E8E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Venkat Rangan wrote:

>  One aspect from the
> other thread that may not have been mentioned is the fact that you could
> have a situation where a rogue software on the initiator running in user
> mode which simply issues ISID=existing, TSID=0 to the target. (This may be
> what was meant by "wild closing of connections" in this thread.) Choosing
> option A) would destroy an otherwise well protected ISID managed in the
> kernel space. This could also occur when you accidentally start another
> application that does not coordinate its ISID selection.

Another parallel iscsi application running in user space should use a different
iscsi initiator name than the iscsi kernel driver. If it does use the same
iscsi initiator name, it must co-ordinate its usage of ISID, cmdsn, exp_statsn,
initiator task tag with the kernel iscsi driver.

Failure to do either can and should result in the pre-existing session being
logged out, since this is a coding error in the initiator application. However,
prior to taking any such action, the login request must first be authenticated
to protect against malicious logouts from spurious initiators.


> The earlier thread was leaning towards "Reject the second login attempt with
> In-Use error code" but the issue of targets cleaning up inactive and failed
> sessions still lingers on.
>
> Some observations:
>
> 1. There is no way to protect against rogue software at the intiator; even
> the best IPSec policies and key management can not prevent such software
> from disturbing other well-behaved components. So trying to design
> mechanisms to prevent this at the target would be fruitless.

Agreed. That is the philosophy of option (A).


>
> 2. There is some value in protecting an accidental use of an existing ISID
> by a second client (ISID=<existing>, TSID=0). This can be done with a Reject
> of the login attempt, even without verification of login credentials - (less
> of a DOS attack). You also do not need to analyze connection states in this
> case.

A second client should create its own iscsi initiator name or partition the
(ISID, cmdsn, init task tag) resources into pools that can be shared b/n the 2
clients. Even then, there exist issues in sending exp_statsn values. The
easiest partition is to use different names for different clients.

If multiple clients on a host do not follow the above precautions, they are
faulty in their iscsi session resource management and there is little sense in
designing targets to protect against such behaviour.


>
> 3. From the perspective of the Target, case 2) above is no different from an
> initiator rebooting and accidentally choosing an existing ISID with TSID=0.
> To distinguish 2) from 3), we can make use of the Clear bit (or the C-bit)
> and avoid many unnecessary trips at reboot time, trying to probe for an
> unused ISID. The usage is that if C-bit is present, any previous sessions
> are also closed by the target. I think this was Option B) in the original
> email.

There is nothing to prevent multiple concurrent clients from logging in with
"C" bit set, and use the same ISID + 0 TSID.

The simplest approach is for the targets to authenticate the initiators and
once authentication has passed, to trust the initiator's requests. The target
should not be in the business of second-guessing the initiator's intentions by
testing connections, etc.

The "C" bit is of little or no use, since the initiator does not know reliably
in which cases its usage is required. [It may have lost prior state and has no
knowledge that it had a pre-existing session].  It would end up using this bit
in all logins.

Regards,
Santosh

--------------55E793E601D955DA48C74E8E
Content-Type: text/x-vcard; charset=us-ascii;
 name="santoshr.vcf"
Content-Description: Card for Santosh Rao
Content-Disposition: attachment;
 filename="santoshr.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Rao;Santosh 
tel;work:408-447-3751
x-mozilla-html:FALSE
org:Hewlett Packard, Cupertino.;SISL
adr:;;19420, Homestead Road, M\S 43LN,	;Cupertino.;CA.;95014.;USA.
version:2.1
email;internet:santoshr@cup.hp.com
title:Software Design Engineer
x-mozilla-cpt:;21088
fn:Santosh Rao
end:vcard

--------------55E793E601D955DA48C74E8E--



From owner-ips@ece.cmu.edu  Thu Aug 30 18:13:03 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29062
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 18:13:03 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7UL7N309631
	for ips-outgoing; Thu, 30 Aug 2001 17:07:23 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7UL7GP09625
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 17:07:16 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id XAA18010
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 23:07:06 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7UL75R248214
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 23:07:05 +0200
Importance: Normal
Subject: Re: iSCSI - Change - Login/Text commands with the binary stage code
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF8109894C.945C276E-ONC2256AB8.0072B830@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Fri, 31 Aug 2001 00:06:27 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 31/08/2001 00:07:04
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Sandeep,

Comments in text.  Julo

Sandeep Joshi <sandeepj@research.bell-labs.com>@ece.cmu.edu on 30-08-2001
19:11:53

Please respond to Sandeep Joshi <sandeepj@research.bell-labs.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  Re: iSCSI - Change - Login/Text commands with the binary stage
      code




Julian,

> > As for the names - I though that security people might object having
the
> > name in clear if the security phase does not make use of the name.
> > Otherwise we can mandate them on the login but I wonder if that is a
real
> > improvement or we are getting carelles.
> >
> > Julo

The problem with these names (and hence the request from Steve and
others
earlier) is that it is not possible to know when the target wants them.

Consider the following excerpts from your latest login proposal..
+++ The initiator know if the authentication method selected needs the name
and will offer it if so (that is mostly context information not related to
the wire protocol +++
> A target MAY use the iSCSI Initiator Name as part of its access control
> mechanism; therefore, the iSCSI Initiator Name MUST be sent before the
> target is required to disclose its LUs.

The above is _very_ confusing..how can the initiator know if the
 the target is doing access control ?
+++ It really is not. LU names can be obtaine only in FFP. The statement
says that you have to disclose them before reaching FFP and explains why
+++
> If the iSCSI Target Name and/or iSCSI Initiator Name is going to be used
> in determining the security mode or it is implicit part of
> authentication, then the iSCSI Target Name and/or iSCSI Initiator Name
> MUST be sent in the login command for the first connection of a session
> to identify the storage endpoint of the session

In both the above cases, how does the initiator know when the target
requires these names?  The partial login response occurs *only* once.
So when going from the security->operational phase, there is no
indication that the target would like these names sent.
+++ the security negotiation is not ended with partial response
but through a complete handshake in the old and new schemes.
The initiator will know before by the selection made if he has to give its
name or not.
The whole point was for us to mandate what is mandatory for iSCSI in
general
and let all the other choices open.
With IPSec it is less of an issue as the name can be presented on an
encrypted although not fully authenticated channel+++

There are 3 options here :
(A) ALways send the names in the login command.  Simplify target
   and initiator and eliminate a few of those partial login
   response codes.
(B) Maintain a configuration database (per-target) of when names
   must be sent - adds an administration burden.
(C) Change the wire protocol to allow the target to indicate when
   the names must be sent - again more complications.
+++ please read and react to the new proposals +++
To round up, I prefer Option (A).  These are just names and not
passwords, so the security risks are minimal.  Are we trying to
protect against traffic analysis ?
+++ I agree that it is simpler to think about it this way. I do not agree
that it is more difficult to implement.
If you need the name in the security negotiation it is just another
parameter of the
method and you will know when to present it.
If you don't need it you will present it on the last Login request (or text
in the old version) - the one that holds the F bit set.
IAgain I hold no strong opinion for or against what you suggest.
I simply don't want us to make a decision based on convenience. It is a bad
guide.
+++
-Sandeep

> >
> > Steve Senum <ssenum@cisco.com>@ece.cmu.edu on 29-08-2001 23:59:36
> >
> > Please respond to Steve Senum <ssenum@cisco.com>
> >
> > Sent by:  owner-ips@ece.cmu.edu
> >
> >
> > To:   ietf-ips <ips@ece.cmu.edu>
> > cc:
> > Subject:  Re: iSCSI - Change - Login/Text commands with the binary
stage
> >       code
> >
> >
> >
> > Julian,
> >
> > A couple of ideas from Matthew Burbridge & Co.'s
> > login proposal that has generated some interest here:
> >
> > 1. Removal of partial login response.  Is it still needed?
> >
> > 2. Requiring Initiator and (if not a discovery session)
> >    Target names on login command, so they are always
> >    available if needed by the initial phase.
> >
> > Comments?
> >
> > Regards,
> > Steve Senum
> >
> >
> >
> >





From owner-ips@ece.cmu.edu  Thu Aug 30 18:13:25 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29074
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 18:13:25 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7UL0U309253
	for ips-outgoing; Thu, 30 Aug 2001 17:00:30 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from atlrel6.hp.com (atlrel6.hp.com [192.151.27.8])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7UL0SP09249
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 17:00:28 -0400 (EDT)
Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190])
	by atlrel6.hp.com (Postfix) with ESMTP
	id 35B211F928; Thu, 30 Aug 2001 17:00:15 -0400 (EDT)
Received: from xatlbh4.atl.hp.com (xatlbh4.atl.hp.com [15.45.89.189])
	by xatlrelay1.atl.hp.com (Postfix) with ESMTP
	id 365731F53A; Thu, 30 Aug 2001 17:00:14 -0400 (EDT)
Received: by xatlbh4.atl.hp.com with Internet Mail Service (5.5.2653.19)
	id <RTX576JK>; Thu, 30 Aug 2001 17:00:14 -0400
Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF09C@xrose06.rose.hp.com>
From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
To: "'John Hufferd'" <hufferd@us.ibm.com>, ips@ece.cmu.edu
Subject: RE: iSCSI: reusing ISID for recovery
Date: Thu, 30 Aug 2001 17:00:10 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Thanks John.  I'm not concerned about the amount of code.  The sticking
point for option B is the delay in initiator boot time for what I feel is
unnecessary protection against software defects (IOTW, adds delay to boot to
inform initiator of existing session, which initiator wants cleaned up
anyway).  I recall very ugly boot times in FC testing because of delay in
target response to initiator login that would cause some OS (MS!) to give up
and time out the target device at great expense to total SAN recovery times.

Marj 

> -----Original Message-----
> From: John Hufferd [mailto:hufferd@us.ibm.com]
> Sent: Thursday, August 30, 2001 12:48 PM
> To: ips@ece.cmu.edu
> Subject: RE: iSCSI: reusing ISID for recovery
> 
> 
> 
> Folks,
> Following your notes, I think  that if an initiator does not 
> know what it
> is doing, rather then having a new semantic on Login, why not 
> just Logout,
> then re-Login.
> Since this should only happen like "Never", if you have coded 
> things well,
> and the infrequency should mean that the extra hand shake is 
> not a problem.
> 
> However,  if you do not know what your session's TSID is, you 
> probably are
> two screwed up to make even the above Logout work, so I think 
> this is what
> you are all trying to address.  That is,  we  need to have a 
> method to blow
> everything away and start again when the initiator has lost 
> the TSID of its
> Session.  This is why we have option A, and Option B.
> 
> So I think the issue here is do we add additional responses at boot up
> time, or not.  (Quit frankly I do not think this is an 
> important issue,
> either way.) However, it is a consideration.  If mode B is 
> used, the clean
> up bit is available, and initiators that use it all the time, 
> will usually
> cause the Extra interaction to occur at boot, because the 
> normal case would
> be that things come up clean.  (Since I think we said that if 
> things are
> clean, an error response would be issued. Therefore, most of 
> the time, the
> extra response is going to happen).  If, as some have 
> suggested, the right
> way to code this is to use  the Clean up bit only when there 
> is a rejection
> of the Login, because of existing sessions, and require that 
> the initiator
> should come back with the Login again but this time with the 
> Clean up bit
> set. The argument is made that there will not normally  be any extra
> interaction.  Just extra interactions when clean-up is needed. (This
> approach has been called Option B.)  The other approach is 
> known as Option
> A.  It will implicitly start the Login and clear out any 
> existing session
> when the Login is issued.   There will never be extra 
> responses with Option
> A, and there will only be extra responses in option B when the Target
> rejects the Login because of a existing session. The Option B clean-up
> action will not happen often, and the code is not hard, but 
> there is more
> code, perhaps 100 lines.
> 
> Now the folks that support option A say that they will not have to do
> anything special since they want the Login to always succeed 
> and blow away
> any other thing that might be going on.  It is clear that 
> this has less
> code and interaction at boot/Startup. (However 100 lines of 
> code is not a
> big deal anyway.)
> It also seem to me that there is probably less code on the 
> target since
> they do not have to do inspection of whether or not sessions 
> are active or
> not, etc. They just blow them away if they exist.
> 
> So all this flapping has to do with whether we need to add 
> (on either side)
> some (perhaps small) amount of code so that we use to protect 
> from a buggy
> Initiator.
> 
> I think this is a Nit in the Draft and is needlessly 
> divisive, over a small
> amount of code.
> 
> There has also been stated the opinion that option B is 
> needed when their
> is more then one OS sharing the Link.  I do not think this 
> applies since
> there should be another iSCSI Initiator Name for each OS, and 
> therefore it
> is a different session and has nothing to do with the 
> discussion at hand.
> 
> Therefore, since the simplification (less code) is on the 
> side of option A,
> and since this is really not important anyway, I suggest that 
> all the B
> folks roll over since you will not be able to convince the A 
> folks anyway,
> and since they do have a valid (small) argument that Option B 
> requires more
> complexity and lines of code.
> 
> So I recommend Option A, and lets move on.  This does not 
> deserver the list
> space, or the emotion  it has been given.
> 
> .
> .
> .
> John L. Hufferd
> Senior Technical Staff Member (STSM)
> IBM/SSG San Jose Ca
> Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
> Home Office (408) 997-6136
> Internet address: hufferd@us.ibm.com
> 


From owner-ips@ece.cmu.edu  Thu Aug 30 18:19:06 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29199
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 18:19:05 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7UKc6i07940
	for ips-outgoing; Thu, 30 Aug 2001 16:38:06 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7UKc3P07935
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 16:38:03 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id WAA21632
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 22:37:55 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7UKbtp119482
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 22:37:55 +0200
Importance: Normal
Subject: Re: iSCSI: reusing ISID for recovery
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OFC5493A64.2E88E329-ONC2256AB8.00712E00@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Thu, 30 Aug 2001 23:37:18 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 30/08/2001 23:37:54
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

My major objection is that we make it to easy to err.  Even
not-malicious/just mistaken code can blow up a session.

Julo

Santosh Rao <santoshr@cup.hp.com>@ece.cmu.edu on 30-08-2001 23:18:01

Please respond to Santosh Rao <santoshr@cup.hp.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  Re: iSCSI: reusing ISID for recovery



Venkat Rangan wrote:

>  One aspect from the
> other thread that may not have been mentioned is the fact that you could
> have a situation where a rogue software on the initiator running in user
> mode which simply issues ISID=existing, TSID=0 to the target. (This may
be
> what was meant by "wild closing of connections" in this thread.) Choosing
> option A) would destroy an otherwise well protected ISID managed in the
> kernel space. This could also occur when you accidentally start another
> application that does not coordinate its ISID selection.

Another parallel iscsi application running in user space should use a
different
iscsi initiator name than the iscsi kernel driver. If it does use the same
iscsi initiator name, it must co-ordinate its usage of ISID, cmdsn,
exp_statsn,
initiator task tag with the kernel iscsi driver.

Failure to do either can and should result in the pre-existing session
being
logged out, since this is a coding error in the initiator application.
However,
prior to taking any such action, the login request must first be
authenticated
to protect against malicious logouts from spurious initiators.


> The earlier thread was leaning towards "Reject the second login attempt
with
> In-Use error code" but the issue of targets cleaning up inactive and
failed
> sessions still lingers on.
>
> Some observations:
>
> 1. There is no way to protect against rogue software at the intiator;
even
> the best IPSec policies and key management can not prevent such software
> from disturbing other well-behaved components. So trying to design
> mechanisms to prevent this at the target would be fruitless.

Agreed. That is the philosophy of option (A).


>
> 2. There is some value in protecting an accidental use of an existing
ISID
> by a second client (ISID=<existing>, TSID=0). This can be done with a
Reject
> of the login attempt, even without verification of login credentials -
(less
> of a DOS attack). You also do not need to analyze connection states in
this
> case.

A second client should create its own iscsi initiator name or partition the
(ISID, cmdsn, init task tag) resources into pools that can be shared b/n
the 2
clients. Even then, there exist issues in sending exp_statsn values. The
easiest partition is to use different names for different clients.

If multiple clients on a host do not follow the above precautions, they are
faulty in their iscsi session resource management and there is little sense
in
designing targets to protect against such behaviour.


>
> 3. From the perspective of the Target, case 2) above is no different from
an
> initiator rebooting and accidentally choosing an existing ISID with
TSID=0.
> To distinguish 2) from 3), we can make use of the Clear bit (or the
C-bit)
> and avoid many unnecessary trips at reboot time, trying to probe for an
> unused ISID. The usage is that if C-bit is present, any previous sessions
> are also closed by the target. I think this was Option B) in the original
> email.

There is nothing to prevent multiple concurrent clients from logging in
with
"C" bit set, and use the same ISID + 0 TSID.

The simplest approach is for the targets to authenticate the initiators and
once authentication has passed, to trust the initiator's requests. The
target
should not be in the business of second-guessing the initiator's intentions
by
testing connections, etc.

The "C" bit is of little or no use, since the initiator does not know
reliably
in which cases its usage is required. [It may have lost prior state and has
no
knowledge that it had a pre-existing session].  It would end up using this
bit
in all logins.

Regards,
Santosh

 - santoshr.vcf





From owner-ips@ece.cmu.edu  Thu Aug 30 18:25:12 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29295
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 18:25:12 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7UKa9307811
	for ips-outgoing; Thu, 30 Aug 2001 16:36:09 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7UKZvP07789
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 16:35:57 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id WAA96410
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 22:35:47 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7UKZkp201124
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 22:35:46 +0200
Importance: Normal
Subject: RE: iSCSI - Change - Login/Text commands with the binary stage code
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF3EF39701.94AB6C6B-ONC2256AB8.00709882@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Thu, 30 Aug 2001 23:35:07 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 30/08/2001 23:35:46
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

 If IPsec secures only the connection between
an initiator and a piece of hardware+code that sits in foront of several
initiator (an example of a configuration)
and this piece is the endpoint of the IP connection as seen by the
initiator) a login authenticantion (or none) may be requested by one or
both parties.

Julo



"Bill Strahm" <bill@Sanera.net> on 30-08-2001 23:03:36

Please respond to "Bill Strahm" <bill@Sanera.net>

To:   <mbakke@cisco.com>
cc:   Julian Satran/Haifa/IBM@IBMIL, "Ips@Ece. Cmu. Edu" <ips@ece.cmu.edu>
Subject:  RE: iSCSI - Change - Login/Text commands with the binary stage
      code



So you are saying that there will be a second layer of security that we
will
build on top of TCP to secure the iSCSI traffic above and beyond the
security available at layer 3 IPsec ???

I agree with your deployment strategies.  It will be up to custommers to
determine what is important, and how much to pay for security.  If the
custommer determines that the price that they are willing to pay for
security is 0, then you get products of type 1 maybe 2.  If the custommer
is
willing to pay for the cost of security you will end up with products like
2
and 3.

What I don't like is that if a custommer only wants to pay for 1, he has to
pick up 2 & 3 as well, and also if a custommer only wants to pay for 1,
having any illusions that there is security.

I am concerned that there will be layer 7 authentication/encryption
methods,
on top of layer 4 authentication/encryption methods, on top of layer 3
authentication/encryption methods on top of layer 2
authentication/encryption methods...  I want a security method specified,
and either it is implemented or not, if it is not - you don't get security.
Why is specifying another layer of security that I don't have to implement
going to lead to anything other than interoperablility problems

Bill
Sanera Systems Inc.

-----Original Message-----
From: mbakke@cisco.com [mailto:mbakke@cisco.com]
Sent: Thursday, August 30, 2001 12:14 PM
To: Bill Strahm
Cc: Julian Satran; Ips@Ece. Cmu. Edu
Subject: Re: iSCSI - Change - Login/Text commands with the binary stage
code


Bill-

In Irvine, we agreed that when IPsec is enabled, IKE will be used
to do key exchange.  We also agreed on which transforms to use when
IPsec is enabled.

The key word is "enabled".  Keep in mind that there will probably
be three classes of iSCSI implementations "out there":

1. iSCSI implementations without security.  These won't be able to
   say they are "compliant", but are likely to be the majority of
   implementations, at least for a little while.  At any rate, we
   all pay our marketing folks to get us around this one.

2. iSCSI implementations with software security.  These will add
   IPsec in software for one of two reasons: either high performance
   is not required (perhaps it's designed to go over a T1 or something),
   or just so the "RFC-xxxx-compliant" bullet can be checked off on
   the list.  If it's for the first reason, IPsec will be used by
   some customers; if it's for the second reason, it will likely
   never be enabled.

3. iSCSI implementations with hardware security.  These will be
   serious implementations that include IPsec, and can perform
   well enough that a customer will want to use IPsec.  These
   implementations will enable IPsec if the customer needs it, but
   again, might not enable it if this is not a concern.

Your assumption seems to be that because we chose IPsec/IKE, that
it will always be used.  Given the implementations 1 and 2, and
some of 3, that is not always the case.

As you mentioned, when your assumptions are correct, the login
phase only has to exchange initiator and target names, and can
use AuthMethod=none if it likes.  However, those assumptions
will not always hold.

--
Mark

Bill Strahm wrote:
>
> Ok,
>
> I am confused here (or maybe it is just a lag effect for me)
>
> I thought we had decided in Irvine to use IPsec/IKE to negotiate
security.
> So basically the process is this
>
> 1) Administrator makes several entries into a Security Policy Database
> 2) An iSCSI initiator attempts to send a TCP-SYN packet to a target
machine
> 3) The IPsec packet filter detects this packet, realized there isn't a
> security association for it, and asks the Security Policy Database what
to
> do about it
> 4) The security Policy Database may determine that an IPsec SA needs to
be
> established so tells IKE to negotiate with the remote peer
> 5) An IKE negotiation proceeds until either it succeeds or fails
> 6) If it fails, packets are dropped
> 7) If it succeeds, the negotiated SAs are pushed to the IPsec packet
filters
> 8) The origional TCP-SYN packet is now sent out under the IPsec SA that
was
> negotiated.
>
> Now under this scenario there is no need for iSCSI to negotiate security
at
> all.  I DO now see the need to include an iSCSI Login phase that includes
> passing user identities across so targets and initiators can identify
> themselves, but this is over a secure link (see the above discussion) so
I
> can just put ID= Bills-iSCSI-Initiator PW=BetYouCantGuessIt and the link
> will secure it for me...
>
> Bill
> Sanera Systems Inc.
> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Julian Satran
> Sent: Wednesday, August 29, 2001 2:40 PM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI - Change - Login/Text commands with the binary stage
> code
>
> Steve,
>
> Implement and use are different terms. An administrator might set it up
not
> to use security under specific conditions.
>
> Julo
>
> Steve Senum <ssenum@cisco.com>@ece.cmu.edu on 30-08-2001 00:12:28
>
> Please respond to Steve Senum <ssenum@cisco.com>
>
> Sent by:  owner-ips@ece.cmu.edu
>
> To:   ietf-ips <ips@ece.cmu.edu>
> cc:
> Subject:  Re: iSCSI - Change - Login/Text commands with the binary stage
>       code
>
> Julian,
>
> In the following section:
>
>    If the initiator decides to forego the SecurityNegotiation stage it
>    issues the Login with the CNxSG set to LoginOperationalNegotiation in
>    the current stage and the target may replay with a Login Response
>    indicating that it is unwilling to accept the connection without
>    SecurityNegotiation and terminate the connection.
>
> This seems contrary to the requirement to implement
> authentication (at least AuthMethod=SRP).  I realize
> this could also be a configuration issue, but I wonder
> if the spec should at least strongly recommend starting
> with phase SecurityNegotiation, or better yet, make it
> a SHOULD?
>
> Regards,
> Steve Senum

--
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054






From owner-ips@ece.cmu.edu  Thu Aug 30 19:10:35 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29826
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 19:10:33 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7ULl6511802
	for ips-outgoing; Thu, 30 Aug 2001 17:47:06 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7ULkqP11785
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 17:46:52 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id XAA22340
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 23:46:40 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7ULkeR203382
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 23:46:40 +0200
Importance: Normal
Subject: Re: iSCSI - Change - Login/Text commands with the binary stage code
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF57939113.CB2DE94C-ONC2256AB8.007724F2@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Fri, 31 Aug 2001 00:43:15 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 31/08/2001 00:46:39
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Or it may skip the Security Stage at all (e.g., when it uses IPSEc and it
is satisfied with whatever IPSec gives him).

Julo

Steve Senum <ssenum@cisco.com>@ece.cmu.edu on 30-08-2001 19:48:04

Please respond to Steve Senum <ssenum@cisco.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ietf-ips <ips@ece.cmu.edu>
cc:
Subject:  Re: iSCSI - Change - Login/Text commands with the binary stage
      code



Julian,

> Implement and use are different terms. An administrator might set it up
not
> to use security under specific conditions.

I understand that.  Still, the only situation I would
consider it valid for the initiator to skip the
SecurityNegotiation stage is if it intended to send out:

I-> AuthMethod:none
    HeaderDigest:none
    DataDigest:none

Otherwise it should give the target the chance to
negotiate these options.

Regards,
Steve Senum





From owner-ips@ece.cmu.edu  Thu Aug 30 19:10:55 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29866
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 19:10:55 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7UM3pd12646
	for ips-outgoing; Thu, 30 Aug 2001 18:03:51 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from smtp012.mail.yahoo.com (smtp012.mail.yahoo.com [216.136.173.32])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f7UM3iP12639
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 18:03:44 -0400 (EDT)
Received: from sdsl-216-36-75-164.dsl.sjc.megapath.net (HELO somesh) (216.36.75.164)
  by smtp.mail.vip.sc5.yahoo.com with SMTP; 30 Aug 2001 22:03:42 -0000
X-Apparently-From: <someshg@yahoo.com>
Reply-To: <someshg@yahoo.com>
From: "Somesh Gupta" <someshg@yahoo.com>
To: "Julian Satran" <Julian_Satran@il.ibm.com>, <ips@ece.cmu.edu>
Subject: RE: iSCSI: reusing ISID for recovery
Date: Thu, 30 Aug 2001 14:52:01 -0700
Message-ID: <NMEALCLOIBCHBDHLCMIJAEPCCGAA.someshg@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <OFC5493A64.2E88E329-ONC2256AB8.00712E00@telaviv.ibm.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Julian,

I final comment on this issue from me. I think the point
is that the code is either broke or not, and there is no
way to help code that has bugs.

On the other hand, the more complexity, the higher
the probability of bugs. For this, one does not
have to look at the incremental effort for one
feature or another (because that always ends up in a
debate of whether I can program another 100 lines
of code correctly or not), but rather in gross terms.
And to use another hyperbole, the forest is finally
made up of trees.

Somesh

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Julian Satran
> Sent: Thursday, August 30, 2001 1:37 PM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI: reusing ISID for recovery
>
>
> My major objection is that we make it to easy to err.  Even
> not-malicious/just mistaken code can blow up a session.
>
> Julo
>
> Santosh Rao <santoshr@cup.hp.com>@ece.cmu.edu on 30-08-2001 23:18:01
>
> Please respond to Santosh Rao <santoshr@cup.hp.com>
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   ips@ece.cmu.edu
> cc:
> Subject:  Re: iSCSI: reusing ISID for recovery
>
>
>
> Venkat Rangan wrote:
>
> >  One aspect from the
> > other thread that may not have been mentioned is the fact that you could
> > have a situation where a rogue software on the initiator running in user
> > mode which simply issues ISID=existing, TSID=0 to the target. (This may
> be
> > what was meant by "wild closing of connections" in this
> thread.) Choosing
> > option A) would destroy an otherwise well protected ISID managed in the
> > kernel space. This could also occur when you accidentally start another
> > application that does not coordinate its ISID selection.
>
> Another parallel iscsi application running in user space should use a
> different
> iscsi initiator name than the iscsi kernel driver. If it does use the same
> iscsi initiator name, it must co-ordinate its usage of ISID, cmdsn,
> exp_statsn,
> initiator task tag with the kernel iscsi driver.
>
> Failure to do either can and should result in the pre-existing session
> being
> logged out, since this is a coding error in the initiator application.
> However,
> prior to taking any such action, the login request must first be
> authenticated
> to protect against malicious logouts from spurious initiators.
>
>
> > The earlier thread was leaning towards "Reject the second login attempt
> with
> > In-Use error code" but the issue of targets cleaning up inactive and
> failed
> > sessions still lingers on.
> >
> > Some observations:
> >
> > 1. There is no way to protect against rogue software at the intiator;
> even
> > the best IPSec policies and key management can not prevent such software
> > from disturbing other well-behaved components. So trying to design
> > mechanisms to prevent this at the target would be fruitless.
>
> Agreed. That is the philosophy of option (A).
>
>
> >
> > 2. There is some value in protecting an accidental use of an existing
> ISID
> > by a second client (ISID=<existing>, TSID=0). This can be done with a
> Reject
> > of the login attempt, even without verification of login credentials -
> (less
> > of a DOS attack). You also do not need to analyze connection states in
> this
> > case.
>
> A second client should create its own iscsi initiator name or
> partition the
> (ISID, cmdsn, init task tag) resources into pools that can be shared b/n
> the 2
> clients. Even then, there exist issues in sending exp_statsn values. The
> easiest partition is to use different names for different clients.
>
> If multiple clients on a host do not follow the above
> precautions, they are
> faulty in their iscsi session resource management and there is
> little sense
> in
> designing targets to protect against such behaviour.
>
>
> >
> > 3. From the perspective of the Target, case 2) above is no
> different from
> an
> > initiator rebooting and accidentally choosing an existing ISID with
> TSID=0.
> > To distinguish 2) from 3), we can make use of the Clear bit (or the
> C-bit)
> > and avoid many unnecessary trips at reboot time, trying to probe for an
> > unused ISID. The usage is that if C-bit is present, any
> previous sessions
> > are also closed by the target. I think this was Option B) in
> the original
> > email.
>
> There is nothing to prevent multiple concurrent clients from logging in
> with
> "C" bit set, and use the same ISID + 0 TSID.
>
> The simplest approach is for the targets to authenticate the
> initiators and
> once authentication has passed, to trust the initiator's requests. The
> target
> should not be in the business of second-guessing the initiator's
> intentions
> by
> testing connections, etc.
>
> The "C" bit is of little or no use, since the initiator does not know
> reliably
> in which cases its usage is required. [It may have lost prior
> state and has
> no
> knowledge that it had a pre-existing session].  It would end up using this
> bit
> in all logins.
>
> Regards,
> Santosh
>
>  - santoshr.vcf
>
>


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com



From owner-ips@ece.cmu.edu  Thu Aug 30 19:11:12 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29886
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 19:11:11 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7ULkmf11779
	for ips-outgoing; Thu, 30 Aug 2001 17:46:48 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7ULkkP11773
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 17:46:46 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id XAA05020
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 23:46:38 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7ULkcR157760
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 23:46:38 +0200
Importance: Normal
Subject: RE: iSCSI - Login proposed change
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF809F0494.72C363A9-ONC2256AB8.00767FB9@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Fri, 31 Aug 2001 00:38:31 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 31/08/2001 00:46:37
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Thanks Bill,  Your point about leaking is well taken - I hope it will
resonate with those that favor as much debugging information as possible.

As for checking the target may do 1 in 2 things:

   really check with a nop
   just tell the initiator that a session is there and wait for him to come
   bake asking to blow it away (the X bit)

Julo

"Bill Strahm" <bill@Sanera.net> on 31-08-2001 00:09:32

Please respond to "Bill Strahm" <bill@Sanera.net>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   "Ips@Ece. Cmu. Edu" <ips@ece.cmu.edu>
Subject:  RE: iSCSI - Login proposed change



I'll make some comments on the text... I'll copy the current text from your
.txt file then a comment denoted by [bills][\bills]


Security associations established before the Login request are outside the
scope of this document although they may realize a related function (e.g.,
establish a IPsec tunnel).
[bill]
Establish IPsec SAs using IKE or other methods.  I do not see a need to
specify tunnel/transport modes etc.
[\bills]


When a target detects an attempt to open a new session by the same SCSI
initiator port (same InitiatorName and ISID) to the same target portal
group
it MUST check if the old session is still active.  If it is not active and
then the old-session must be reset by the target and a new session is
established. Otherwise, the Login MUST be terminated with a Login Response
of "Session already open with this initiator".
[bills]
How are we to determine that a TCP connection is active.  Do we send data
on
it and wait for a timeout (3 minutes ???) before we can continue.  If the
TCP connection is not active, and the TCP connection is shutdown, what do
you mean by reset by the target ?
[\bills]



Indicates the version supported (the highest version supported by the
target
and initiator). If the target does not support a version within the range
specified by the initiator, the target rejects the login and this field
indicates the lowest version supported by the target.
[bill]
I would rather see a failed login result in the socket closing, and not
leaking implementation details to the client.  Ok maybe I am a little
paranoid.
[\bills]


-----------------------------------------------------------------
Authentication| 0201 | 1   | The initiator could not be
Failure       |      |     | successfully authenticated.
-----------------------------------------------------------------
Authorization | 0202 | 1   | The initiator is not allowed access
Failure       |      |     | to the given target.
-----------------------------------------------------------------
[bills]
This is leaking interesting information.  Kind of like an operating system
telling you that it can't log you in (wrong password) vs. Unknown user...
This is information that doesn't need to be passed to the initiator that
can't authenticate.
[\bills]

If the Status Class is not 0, the initiator and target MUST close the TCP
connection.
[bills]
NO... The TARGET WILL close the connection.  Think about a DOS attack, I
just attempt a login, then leave my session open.  The TARGET MUST close
the
socket
[\bills]


Security MUST be completely negotiated within the Login Phase or provided
by
external means (e.g., IPSec).
[bills]
I thought we were providing security with IPsec...
[\bills]

Bill Strahm
Sanera Systems Inc.

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Julian Satran
Sent: Thursday, August 30, 2001 9:35 AM
To: ips@ece.cmu.edu
Subject: iSCSI - Login proposed change


I am not sure that I sent the right set of proposed changes - here is a
complete one:

Julo

(See attached file: Login-changes.txt)






From owner-ips@ece.cmu.edu  Thu Aug 30 19:11:42 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29909
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 19:11:42 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7ULauw11282
	for ips-outgoing; Thu, 30 Aug 2001 17:36:56 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7ULarP11274
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 17:36:53 -0400 (EDT)
Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203])
	by palrel1.hp.com (Postfix) with ESMTP
	id 5E4FA21B8; Thu, 30 Aug 2001 14:36:52 -0700 (PDT)
Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197])
	by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id OAA18858;
	Thu, 30 Aug 2001 14:36:51 -0700 (PDT)
Message-ID: <3B8EB337.1C3DC3E5@cup.hp.com>
Date: Thu, 30 Aug 2001 14:42:15 -0700
From: Santosh Rao <santoshr@cup.hp.com>
Organization: Hewlett Packard, Cupertino.
X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778)
X-Accept-Language: en
MIME-Version: 1.0
To: Julian Satran <Julian_Satran@il.ibm.com>
Cc: ips@ece.cmu.edu
Subject: Re: iSCSI: reusing ISID for recovery
References: <OFC5493A64.2E88E329-ONC2256AB8.00712E00@telaviv.ibm.com>
Content-Type: multipart/mixed;
 boundary="------------3A1EE5DB7E79C2D0821AC3EF"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

This is a multi-part message in MIME format.
--------------3A1EE5DB7E79C2D0821AC3EF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Julian Satran wrote:

> My major objection is that we make it to easy to err.  Even
> not-malicious/just mistaken code can blow up a session.

Code that is not written to manage session resources correctly across multiple
iscsi clients [if someone would  try to do that !!] is'nt going to go too far
anyway ! The session would blow up sooner rather than later and that system
is'nt going to have too much forward progress with its iscsi sessions.

I don't think complexity should be introduced into the draft to protect
against simple coding errors.  I have'nt yet seen a valid scenario, other than
a coding error, which would result in a session being blown away. There are
other precedents to the mechanism being asked for here [ex :FC] and it has
been well used without any complaints in those cases.

- Santosh


> Santosh Rao <santoshr@cup.hp.com>@ece.cmu.edu on 30-08-2001 23:18:01
>
> Please respond to Santosh Rao <santoshr@cup.hp.com>
>
> Sent by:  owner-ips@ece.cmu.edu
>
> To:   ips@ece.cmu.edu
> cc:
> Subject:  Re: iSCSI: reusing ISID for recovery
>
> Venkat Rangan wrote:
>
> >  One aspect from the
> > other thread that may not have been mentioned is the fact that you could
> > have a situation where a rogue software on the initiator running in user
> > mode which simply issues ISID=existing, TSID=0 to the target. (This may
> be
> > what was meant by "wild closing of connections" in this thread.) Choosing
> > option A) would destroy an otherwise well protected ISID managed in the
> > kernel space. This could also occur when you accidentally start another
> > application that does not coordinate its ISID selection.
>
> Another parallel iscsi application running in user space should use a
> different
> iscsi initiator name than the iscsi kernel driver. If it does use the same
> iscsi initiator name, it must co-ordinate its usage of ISID, cmdsn,
> exp_statsn,
> initiator task tag with the kernel iscsi driver.
>
> Failure to do either can and should result in the pre-existing session
> being
> logged out, since this is a coding error in the initiator application.
> However,
> prior to taking any such action, the login request must first be
> authenticated
> to protect against malicious logouts from spurious initiators.
>
> > The earlier thread was leaning towards "Reject the second login attempt
> with
> > In-Use error code" but the issue of targets cleaning up inactive and
> failed
> > sessions still lingers on.
> >
> > Some observations:
> >
> > 1. There is no way to protect against rogue software at the intiator;
> even
> > the best IPSec policies and key management can not prevent such software
> > from disturbing other well-behaved components. So trying to design
> > mechanisms to prevent this at the target would be fruitless.
>
> Agreed. That is the philosophy of option (A).
>
> >
> > 2. There is some value in protecting an accidental use of an existing
> ISID
> > by a second client (ISID=<existing>, TSID=0). This can be done with a
> Reject
> > of the login attempt, even without verification of login credentials -
> (less
> > of a DOS attack). You also do not need to analyze connection states in
> this
> > case.
>
> A second client should create its own iscsi initiator name or partition the
> (ISID, cmdsn, init task tag) resources into pools that can be shared b/n
> the 2
> clients. Even then, there exist issues in sending exp_statsn values. The
> easiest partition is to use different names for different clients.
>
> If multiple clients on a host do not follow the above precautions, they are
> faulty in their iscsi session resource management and there is little sense
> in
> designing targets to protect against such behaviour.
>
> >
> > 3. From the perspective of the Target, case 2) above is no different from
> an
> > initiator rebooting and accidentally choosing an existing ISID with
> TSID=0.
> > To distinguish 2) from 3), we can make use of the Clear bit (or the
> C-bit)
> > and avoid many unnecessary trips at reboot time, trying to probe for an
> > unused ISID. The usage is that if C-bit is present, any previous sessions
> > are also closed by the target. I think this was Option B) in the original
> > email.
>
> There is nothing to prevent multiple concurrent clients from logging in
> with
> "C" bit set, and use the same ISID + 0 TSID.
>
> The simplest approach is for the targets to authenticate the initiators and
> once authentication has passed, to trust the initiator's requests. The
> target
> should not be in the business of second-guessing the initiator's intentions
> by
> testing connections, etc.
>
> The "C" bit is of little or no use, since the initiator does not know
> reliably
> in which cases its usage is required. [It may have lost prior state and has
> no
> knowledge that it had a pre-existing session].  It would end up using this
> bit
> in all logins.
>

--------------3A1EE5DB7E79C2D0821AC3EF
Content-Type: text/x-vcard; charset=us-ascii;
 name="santoshr.vcf"
Content-Description: Card for Santosh Rao
Content-Disposition: attachment;
 filename="santoshr.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Rao;Santosh 
tel;work:408-447-3751
x-mozilla-html:FALSE
org:Hewlett Packard, Cupertino.;SISL
adr:;;19420, Homestead Road, M\S 43LN,	;Cupertino.;CA.;95014.;USA.
version:2.1
email;internet:santoshr@cup.hp.com
title:Software Design Engineer
x-mozilla-cpt:;21088
fn:Santosh Rao
end:vcard

--------------3A1EE5DB7E79C2D0821AC3EF--



From owner-ips@ece.cmu.edu  Thu Aug 30 19:11:58 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29922
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 19:11:58 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7UM2hY12578
	for ips-outgoing; Thu, 30 Aug 2001 18:02:43 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from sentinel.sanera.net (ns1.sanera.net [208.253.254.10] (may be forged))
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7UM2eP12570
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 18:02:40 -0400 (EDT)
Received: from newton.sanera.net (newton [192.168.254.11])
	by sentinel.sanera.net (8.11.2/8.11.2) with ESMTP id f7UM2Y226820;
	Thu, 30 Aug 2001 15:02:34 -0700
Received: from strahmw2k (dhcp-pc-100-165.sanera.net [192.168.100.165])
	by newton.sanera.net (8.11.4/8.11.4) with SMTP id f7UM2TU14979;
	Thu, 30 Aug 2001 15:02:29 -0700 (PDT)
From: "Bill Strahm" <bill@sanera.net>
To: "Julian Satran" <Julian_Satran@il.ibm.com>, <ips@ece.cmu.edu>
Subject: RE: iSCSI - Change - Login/Text commands with the binary stage code
Date: Thu, 30 Aug 2001 15:02:27 -0700
Message-ID: <HDECJFNIFJBIAINDCFOMGELJCAAA.bill@sanera.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <OFDBC8B68E.38061E7B-ONC2256AB8.006C711B@telaviv.ibm.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Ok, I did get confused.  I was thinking about packet authentication (ie
HMAC-SHA1) not authentication methods (ie CHAP)

Thank you for the clarification

Bill

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Julian Satran
Sent: Thursday, August 30, 2001 12:46 PM
To: ips@ece.cmu.edu
Subject: RE: iSCSI - Change - Login/Text commands with the binary stage
code


It may decide to authenticate. This is an end-to-end authentication between
two iSCSI entities
not necesarily equivalent to the IPSec end-point.

Julo

"Bill Strahm" <bill@Sanera.net> on 30-08-2001 21:49:01

Please respond to "Bill Strahm" <bill@Sanera.net>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   "Ips@Ece. Cmu. Edu" <ips@ece.cmu.edu>
Subject:  RE: iSCSI - Change - Login/Text commands with the binary stage
      code



Ok,

I am confused here (or maybe it is just a lag effect for me)

I thought we had decided in Irvine to use IPsec/IKE to negotiate security.
So basically the process is this

1) Administrator makes several entries into a Security Policy Database
2) An iSCSI initiator attempts to send a TCP-SYN packet to a target machine
3) The IPsec packet filter detects this packet, realized there isn't a
security association for it, and asks the Security Policy Database what to
do about it
4) The security Policy Database may determine that an IPsec SA needs to be
established so tells IKE to negotiate with the remote peer
5) An IKE negotiation proceeds until either it succeeds or fails
6) If it fails, packets are dropped
7) If it succeeds, the negotiated SAs are pushed to the IPsec packet
filters
8) The origional TCP-SYN packet is now sent out under the IPsec SA that was
negotiated.

Now under this scenario there is no need for iSCSI to negotiate security at
all.  I DO now see the need to include an iSCSI Login phase that includes
passing user identities across so targets and initiators can identify
themselves, but this is over a secure link (see the above discussion) so I
can just put ID= Bills-iSCSI-Initiator PW=BetYouCantGuessIt and the link
will secure it for me...

Bill
Sanera Systems Inc.
-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Julian Satran
Sent: Wednesday, August 29, 2001 2:40 PM
To: ips@ece.cmu.edu
Subject: Re: iSCSI - Change - Login/Text commands with the binary stage
code



Steve,

Implement and use are different terms. An administrator might set it up not
to use security under specific conditions.

Julo

Steve Senum <ssenum@cisco.com>@ece.cmu.edu on 30-08-2001 00:12:28

Please respond to Steve Senum <ssenum@cisco.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ietf-ips <ips@ece.cmu.edu>
cc:
Subject:  Re: iSCSI - Change - Login/Text commands with the binary stage
      code



Julian,

In the following section:

   If the initiator decides to forego the SecurityNegotiation stage it
   issues the Login with the CNxSG set to LoginOperationalNegotiation in
   the current stage and the target may replay with a Login Response
   indicating that it is unwilling to accept the connection without
   SecurityNegotiation and terminate the connection.

This seems contrary to the requirement to implement
authentication (at least AuthMethod=SRP).  I realize
this could also be a configuration issue, but I wonder
if the spec should at least strongly recommend starting
with phase SecurityNegotiation, or better yet, make it
a SHOULD?

Regards,
Steve Senum










From owner-ips@ece.cmu.edu  Thu Aug 30 19:14:26 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00024
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 19:14:24 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7ULlUK11827
	for ips-outgoing; Thu, 30 Aug 2001 17:47:30 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7ULl1P11797
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 17:47:09 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id XAA15186
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 23:46:39 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7ULkdR203380
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 23:46:39 +0200
Importance: Normal
Subject: RE: iSCSI - Change - Login/Text commands with the binary stage co	de
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF4A0E37C7.788DAC2C-ONC2256AB8.0076FC51@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Fri, 31 Aug 2001 00:40:11 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 31/08/2001 00:46:39
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Correct - at the cost of a round-trip. Julo

Michael Schoberg <michael_schoberg@cnt.com>@ece.cmu.edu on 30-08-2001
19:47:54

Please respond to Michael Schoberg <michael_schoberg@cnt.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI - Change - Login/Text commands with the binary stage co
      de



I'm not sure if this has been suggested, but one possible solution to the
login state confusion could be to eliminate this dual master relationship
between the iSCSI initiator logging in and the iSCSI target.  When the
iSCSI
initiator attempts login, it could send an empty (no text options) message
and let the iSCSI Target send back the options it supports as either empty
(InitiatorName=) or with the default (MaxConnections=8).  The login would
proceed until the iSCSI target sends a completion message.  This would
remove the ambiguity of the order in which login variables are presented.





From owner-ips@ece.cmu.edu  Thu Aug 30 19:15:06 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00040
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 19:15:05 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7UM86i12867
	for ips-outgoing; Thu, 30 Aug 2001 18:08:06 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from sentinel.sanera.net (ns1.sanera.net [208.253.254.10] (may be forged))
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7UM82P12860
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 18:08:04 -0400 (EDT)
Received: from newton.sanera.net (newton [192.168.254.11])
	by sentinel.sanera.net (8.11.2/8.11.2) with ESMTP id f7UL9d226525;
	Thu, 30 Aug 2001 14:09:39 -0700
Received: from strahmw2k (dhcp-pc-100-165.sanera.net [192.168.100.165])
	by newton.sanera.net (8.11.4/8.11.4) with SMTP id f7UL9XU10749;
	Thu, 30 Aug 2001 14:09:33 -0700 (PDT)
From: "Bill Strahm" <bill@sanera.net>
To: "Julian Satran" <Julian_Satran@il.ibm.com>
Cc: "Ips@Ece. Cmu. Edu" <ips@ece.cmu.edu>
Subject: RE: iSCSI - Login proposed change
Date: Thu, 30 Aug 2001 14:09:32 -0700
Message-ID: <HDECJFNIFJBIAINDCFOMCELHCAAA.bill@sanera.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <OF48C22E07.2F07CD1B-ONC2256AB8.005AF60F@telaviv.ibm.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

I'll make some comments on the text... I'll copy the current text from your
.txt file then a comment denoted by [bills][\bills]


Security associations established before the Login request are outside the
scope of this document although they may realize a related function (e.g.,
establish a IPsec tunnel).
[bill]
Establish IPsec SAs using IKE or other methods.  I do not see a need to
specify tunnel/transport modes etc.
[\bills]


When a target detects an attempt to open a new session by the same SCSI
initiator port (same InitiatorName and ISID) to the same target portal group
it MUST check if the old session is still active.  If it is not active and
then the old-session must be reset by the target and a new session is
established. Otherwise, the Login MUST be terminated with a Login Response
of "Session already open with this initiator".
[bills]
How are we to determine that a TCP connection is active.  Do we send data on
it and wait for a timeout (3 minutes ???) before we can continue.  If the
TCP connection is not active, and the TCP connection is shutdown, what do
you mean by reset by the target ?
[\bills]



Indicates the version supported (the highest version supported by the target
and initiator). If the target does not support a version within the range
specified by the initiator, the target rejects the login and this field
indicates the lowest version supported by the target.
[bill]
I would rather see a failed login result in the socket closing, and not
leaking implementation details to the client.  Ok maybe I am a little
paranoid.
[\bills]


-----------------------------------------------------------------
Authentication| 0201 | 1   | The initiator could not be
Failure       |      |     | successfully authenticated.
-----------------------------------------------------------------
Authorization | 0202 | 1   | The initiator is not allowed access
Failure       |      |     | to the given target.
-----------------------------------------------------------------
[bills]
This is leaking interesting information.  Kind of like an operating system
telling you that it can't log you in (wrong password) vs. Unknown user...
This is information that doesn't need to be passed to the initiator that
can't authenticate.
[\bills]

If the Status Class is not 0, the initiator and target MUST close the TCP
connection.
[bills]
NO... The TARGET WILL close the connection.  Think about a DOS attack, I
just attempt a login, then leave my session open.  The TARGET MUST close the
socket
[\bills]


Security MUST be completely negotiated within the Login Phase or provided by
external means (e.g., IPSec).
[bills]
I thought we were providing security with IPsec...
[\bills]

Bill Strahm
Sanera Systems Inc.

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Julian Satran
Sent: Thursday, August 30, 2001 9:35 AM
To: ips@ece.cmu.edu
Subject: iSCSI - Login proposed change


I am not sure that I sent the right set of proposed changes - here is a
complete one:

Julo

(See attached file: Login-changes.txt)



From owner-ips@ece.cmu.edu  Thu Aug 30 20:05:57 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00777
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 20:05:57 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7UNNJb16237
	for ips-outgoing; Thu, 30 Aug 2001 19:23:19 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from sentinel.sanera.net (ns1.sanera.net [208.253.254.10] (may be forged))
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7UNNHP16230
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 19:23:17 -0400 (EDT)
Received: from newton.sanera.net (newton [192.168.254.11])
	by sentinel.sanera.net (8.11.2/8.11.2) with ESMTP id f7UNN8227186;
	Thu, 30 Aug 2001 16:23:08 -0700
Received: from strahmw2k (dhcp-pc-100-165.sanera.net [192.168.100.165])
	by newton.sanera.net (8.11.4/8.11.4) with SMTP id f7UNN2U20431;
	Thu, 30 Aug 2001 16:23:02 -0700 (PDT)
From: "Bill Strahm" <bill@sanera.net>
To: "Julian Satran" <Julian_Satran@il.ibm.com>, <ips@ece.cmu.edu>
Subject: RE: iSCSI - Login proposed change
Date: Thu, 30 Aug 2001 16:23:00 -0700
Message-ID: <HDECJFNIFJBIAINDCFOMKELMCAAA.bill@sanera.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <OF809F0494.72C363A9-ONC2256AB8.00767FB9@telaviv.ibm.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


Thanks Bill,  Your point about leaking is well taken - I hope it will
resonate with those that favor as much debugging information as possible.

Yes the joys of security vs. convienience.  I have heard may people saying
that as soon as I turn on security I can not debug my network any more...
However I think this is rather important.  By leaking versions, reasons for
denial, etc. my Target is giving away information that may make a future
attack more likely to succeed.

Bill



From owner-ips@ece.cmu.edu  Thu Aug 30 20:10:31 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00852
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 20:10:30 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7UMZx314166
	for ips-outgoing; Thu, 30 Aug 2001 18:35:59 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail4.tor.primus.ca (mx-backup.primus.ca [216.254.136.135])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7UMZuP14160
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 18:35:56 -0400 (EDT)
Received: from dsl-216-254-190-93.tor.primus.ca ([216.254.190.93] helo=perfisan4)
	by mail4.tor.primus.ca with smtp (Exim 2.11 #1)
	id 15caPJ-0005yP-07; Thu, 30 Aug 2001 18:35:29 -0400
Reply-To: <tnguyen@perfisans.com>
From: "Trang Nguyen" <tnguyen@perfisans.com>
To: "Julian Satran" <Julian_Satran@il.ibm.com>, <ips@ece.cmu.edu>
Subject: RE: iSCSI-08 Draft Availability?
Date: Thu, 30 Aug 2001 18:39:53 -0400
Message-ID: <BNEALKHNNHCOIGPENKKMEEFJCBAA.tnguyen@perfisans.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
In-Reply-To: <OFD262D3D5.219680EC-ONC2256AB8.006C351B@telaviv.ibm.com>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Julian,

Do you have a schedule of when iSCSI protocol will be finalized?

Thanks,

*********************************
 Trang Nguyen
 tnguyen@perfisans.com
*********************************


-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Julian Satran
Sent: August 30, 2001 3:43 PM
To: ips@ece.cmu.edu
Subject: Re: iSCSI-08 Draft Availability?



Next week - provided we get some things cooling down. Julo

"CLEMENT,ERIC L (A-Roseville,ex1)" <eric_l_clement@agilent.com>@ece.cmu.edu
on 30-08-2001 21:46:12

Please respond to "CLEMENT,ERIC L (A-Roseville,ex1)"
      <eric_l_clement@agilent.com>

Sent by:  owner-ips@ece.cmu.edu


To:   "'Black_David@emc.com'" <Black_David@emc.com>
cc:   "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
Subject:  iSCSI-08 Draft Availability?



Hi David,

Do you know what timeframe the iSCSI-08 draft will be available?

Regards,
Eric
__________________________________

Eric Clement
Agilent Technologies, Inc.
1101 Creekside Ridge Drive
Suite 100, MS RH-21
Roseville, California 95661

Phone: 916.788.6211
Fax: 916.788.6134
Email: Eric_L_Clement@Agilent.com
___________________________________



To: ips@ece.cmu.edu
Subject: IPS Draft Status and Schedule
From: Black_David@emc.com
Date: Wed, 22 Aug 2001 17:24:11 -0400
Content-Type: text/plain;charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu

----------------------------------------------------------------------------

----

Here's what the WG chairs think the current status and schedule
is for the drafts that the IP Storage WG is working on (including
three individual submissions that have agenda time in Orange
County).  This is probably not 100% accurate, but should be
close.  Draft authors - please send any corrections to me.

Apologies for being tardy on this - this should have been done
about a month ago, but I have negative "copious spare time".
Going forward, the intent is to produce an updated version of
this prior to each WG meeting.  Proposed revised charter will
be coming in the near future, with milestones based on the
completion guesstimates below.

Thanks,
--David

-- iSCSI

draft-ietf-ips-iscsi-07.txt
     To be a proposed standard RFC.
     Large portions are stable, major open security and login issues.
     -08 will be a functional/technical revision, document restructure/
          reorganization expected in -09 version.
     Hope to close all major issues by December 2001 IETF meeting

draft-ietf-ips-iscsi-boot-02.txt
     No major open issues, possible minor issues in DHCP usage.
          DHCP material to be extracted into a separate
standards-track draft.
     Remainder to become an informational RFC, after the main iSCSI
document.

draft-ietf-ips-iscsi-reqmts-05.txt
     To be an informational RFC.
     Has completed WG Last Call, currently being considered by the IESG,
          IETF Last Call has not been issued.

draft-ietf-ips-iscsi-name-disc-02.txt
     To be an informational RFC.
     Specification portions that must be standards track are being added
          to the main iSCSI specification.
     No major open issues, hope to close any other issues by December
2001 IETF
          meeting.  Plan to issue WG Last Call for this with main
iSCSI draft.

draft-ietf-ips-iscsi-slp-01.txt
     To be a proposed standard RFC.
     Close to done.  Issues in this general area seem to come up in the
          context of the naming and discovery draft (name-disc-02)
rather
          than this draft.
     WG Last Call will be after the naming and discovery draft.

draft-ietf-ips-iscsi-mib-02.txt
     To be a proposed standard RFC.
     Next (-03) version expected in September, should be close to done.
     WG Last Call will follow main iSCSI draft.

draft-black-ips-iscsi-security-01.txt
draft-aboba-ips-iscsi-security-00.txt
     Unlikely to become RFCs in their current forms.
     New drafts on iSCSI Security for discussion at Orange County
meeting.
          Security requirements will be specified in the main iSCSI
document.
     Some remaining portions of one or both drafts may become an
          informational RFC.  Whether to do this and what portions to
use
          are subject to discussion.

-- FC Common Encapsulation

draft-ietf-ips-fcencapsulation-02.txt
     To be a proposed standard RFC.
     No major open issues.
     Will accompany FCIP and/or iFCP drafts in Last Call, probably after
          December 2001 IETF.

-- FCIP

draft-ietf-ips-fcovertcpip-05.txt
     To be a proposed standard RFC.
     Large portions are stable, major open security issues.
     Hope to close all major issues by December 2001 IETF meeting.

draft-ietf-ips-fcip-slp-00.txt
     To be a proposed standard RFC.
     New draft for discussion in Orange County.
     Hope to close all major issues by December 2001 IETF meeting.

draft-ietf-ips-fcip-mib-00.txt
     To be a proposed standard RFC.
     New draft for discussion in Orange County.
     Likely timeframe for closing final issues is March 2002 IETF
meeting.

-- iFCP

draft-ietf-ips-ifcp-04.txt
     To be a proposed standard RFC.
     Large portions are stable, major open security issues.
     Hope to close all major issues by December 2001 IETF meeting.

draft-tseng-ifcp-mib-00.txt
     To be a proposed standard RFC.
     New draft for consideration in Orange County, will be proposed for
          approval as an official WG draft.
     Likely timeframe for closing final issues is March 2002 IETF
meeting.

-- iSNS

draft-ietf-ips-isns-04.txt
     To be a proposed standard RFC.
     Relationship to SLP for use with iSCSI seems to be settled, no
          other major open issues.
     WG Last Call to follow iSCSI and iFCP drafts.
     Hope to close any remaining issues by December 2001 IETF meeting.

draft-gibbons-isnsmib-00.txt
     To be a proposed standard RFC.
     Relatively new draft, London meeting approved it as an official
          IPS WG work item, next version will be draft-ietf-ips-...
     Likely timeframe for closing final issues is March 2002 IETF
meeting.

-- Framework

draft-ietf-ips-framework-00.txt
     Has not been updated by author team since original revision.
     Likely to be abandoned in the absence of renewed interest.

-- SCSI MIB

There's been talk about working on this, but no draft has appeared, yet.


----- Document Completion Guesstimates ------

A rough guess is 3 waves of documents:

(1) Main protocol standards.  Close technical issues at December 2001 IETF
     (or before), WG Last Call in early 2002, submit to IESG before
     March 2002 IETF Meeting.
     - iSCSI
     - iSCSI Naming/Discovery
     - FC Encapsulation
     - FCIP
     - iFCP
     Last Call scheduling will be an issue, as there are at least two,
     and possibly more 4 week (or longer) WG Last Calls required for
     the above that probably should not overlap with each other.

(2) Supporting Protocol Documents.  Close technical issues at December
     IETF if possible (but above documents have priority).  WG Last
     Call to follow above, probably in March-April 2002.
     - iSCSI Boot
     - iSCSI SLP
     - FCIP SLP
     - iSNS
     iSNS Last Call should not overlap iSCSI Last Calls, hence at least
     two will be needed, but 2 week WG Last Call periods should suffice
     for these documents.

(3) MIBs.  To follow supporting documents.  Final opportunity to discuss
     at March 2002 IETF Meeting, with WG Last Call to follow shortly
     thereafter.
     - iSCSI MIB
     - FCIP MIB
     - iFCP MIB
     - iSNS MIB
     Probably need two Last Call periods, but again, 2 weeks each
     should be sufficient.  May move Last Call schedule up if
     MIBs are ready to go earlier (e.g., after December 2001 IETF
     meeting).

The waves will overlap in practice, but each main protocol document
needs to make it through WG Last Call before any WG Last Calls are
issued for documents that depend on it.  So for any protocol, wave
(1) has to come before (2) and (3), but (2) and (3) can run in
parallel, and the different protocols may run on different schedules.

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------





From owner-ips@ece.cmu.edu  Thu Aug 30 20:10:44 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00864
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 20:10:44 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7UN7Zw15585
	for ips-outgoing; Thu, 30 Aug 2001 19:07:35 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e33.bld.us.ibm.com (e33.co.us.ibm.com [32.97.110.131])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7UN7XP15580
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 19:07:33 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e33.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA74494;
	Thu, 30 Aug 2001 18:05:20 -0500
Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7UN6GD195606;
	Thu, 30 Aug 2001 17:06:16 -0600
X-Priority: 1 (High)
Importance: Normal
Subject: Re: ISCSI: User authentication vs. Machine Authentication for iSCSI
To: Pierre Labat <pierre_labat@hp.com>
Cc: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OF02417126.D6443558-ON88256AB8.007C4E2A@boulder.ibm.com>
From: "John Hufferd" <hufferd@us.ibm.com>
Date: Thu, 30 Aug 2001 16:05:42 -0700
X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at
 08/30/2001 05:06:16 PM
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f7UN7YP15581
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit


Pierre asks the following question.

"John,

Do i miss something? Why not use Certificate where
the subjectname is the iSCSI name (iqn or eui)?.
So as soon as the IPSEC SA are established each side
knows what intitiator/target is the other side.
There no need for extra password or alias.
The only problem with that is that some directory
as you mentionned below wouldn't support subjectname
as long as an iqn? "

I would like to see more discussion on the feasibility of this approach,
especially
since iSCSI and IKE/IPSec are disjoint processes.  Please, anyone, that
understands
how these different layers would communicate with each other (using
Standard IKE/IPSec
implementations) please help.  For instance how does the IKE get the iSCSI
name of the
system on which it is running, and how does the iSCSI layer find out the
"Subjectname"
the remote system used to establish the connection, since it must be check
that it is the
same name sent on the iSCSI Login."  (Otherwise any valid Certificate owner
could still
masquerade as any other iSCSI Initiator Node.)

Also, if we can figure out how the above works, we need to understand how,
in an SRP environment,
the iqn or eui type name can be used.  (Environment 3).

Further, following Mark's Environment 2, we still need to find a way to use
the iSCSI initiator Node
Name, or understand the ramifications of establishing and using a related
Alias for the
iSCSI initiator node name.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com


Pierre Labat <pierre_labat@hp.com>@cup.hp.com on 08/30/2001 08:37:46 AM

Sent by:  plabat@cup.hp.com


To:   John Hufferd/San Jose/IBM@IBMUS
cc:   ips@ece.cmu.edu
Subject:  Re: ISCSI: User authentication vs. Machine Authentication for
      iSCSI




John Hufferd wrote: Bill,
You are correct, in my opinion, on the problem statement, but not  on the
solution.

The IKE stuff will Get a system identified, and perhaps ensure that a
encrypted connection is put in place.  This then give the Source and Target
the Freedom to exchange stuff that would otherwise be in the clear, such as
iSCSI Node Names etc.  But after the iSCSI session is established, it is
between an OS and a target.  The OS, is the thing that actually owns the
resource, it only loans the resources, in some manor, to applications.

I was having a similar problem to what you stated, at the Irvine meeting,
and kept digging and objecting (off-stage) until I got the following more
acceptable response.

Environment 1: (Use of IKE with complete Certificates processing ( or
pre-Shared password), with ESP equal to something other then Null)
1. We use IKE to get a mutually authenticated and Encrypted communication
link.  This means that the Target knows that (at the IKE/TCP Layer) there
is, at the other end, an authorized thing.  (What or who that thing is,
relative to iSCSI is not really known).  This secure link can be
established either via Certificates or via a pre-Shared password.
2. An iSCSI Login can now be done, over a secure link, so the iSCSI
Initiator Name, and iSCSI Target Name etc can be exchanged securely.
Please note, just because you passed the IKE certificate gate does not mean
you are the iSCSI Initiator that you claim to be.John,

Do i miss something? Why not use Certificate where
the subjectname is the iSCSI name (iqn or eui)?.
So as soon as the IPSEC SA are established each side
knows what intitiator/target is the other side.
There no need for extra password or alias.
The only problem with that is that some directory
as you mentionned below wouldn't support subjectname
as long as an iqn?

Regards,

Pierre Therefore, a password,
for example, that is associated with the iSCSI Initiator Name can now be
used to perform an iSCSI validation of the Initiator.  (Please note, this
could, instead of a password,  be a Kerberos type Validation etc.)
3. David, and perhaps other used the words "User" or "Application" name to
address what was being addressed in 2 above.  But there was more to this
then just assuming that the iSCSI Initiator Name was the User name.  Since
folks may actually want to use existing infrastructure, to handle the
password management and authentication process, they will need to assign
what I might call an "Alias for the iSCSI Initiator" which can actually be
saved in the existing infrastructure user authentication repository.  The
point that was made to me, is that iSCSI Initiator Name (iqn or eui) will
not "fit" into things that contain "User Names" so we need to have a
corresponding "User Name" that we can actually authenticate using, for
example Microsoft Active Directory etc. Hence the need for a "Alias for the
iSCSI initiator.  (I really hate this, and wish there was something else we
could do.)






From owner-ips@ece.cmu.edu  Thu Aug 30 20:12:29 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00890
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 20:12:29 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7UMfiD14438
	for ips-outgoing; Thu, 30 Aug 2001 18:41:44 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7UMfhP14434
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 18:41:43 -0400 (EDT)
Received: from xparelay2.corp.hp.com (unknown [15.58.137.112])
	by palrel2.hp.com (Postfix) with ESMTP
	id 703083139; Thu, 30 Aug 2001 15:41:42 -0700 (PDT)
Received: from xpabh4.corp.hp.com (xpabh4.corp.hp.com [15.58.136.1])
	by xparelay2.corp.hp.com (Postfix) with ESMTP
	id 6B4A01F53D; Thu, 30 Aug 2001 15:41:41 -0700 (PDT)
Received: by xpabh4.corp.hp.com with Internet Mail Service (5.5.2653.19)
	id <RTZXDZJ6>; Thu, 30 Aug 2001 15:41:41 -0700
Message-ID: <499DC368E25AD411B3F100902740AD6507778FD4@xrose03.rose.hp.com>
From: "CONGDON,PAUL (HP-Roseville,ex1)" <paul_congdon@hp.com>
To: "'John Hufferd'" <hufferd@us.ibm.com>, Bill Strahm <bill@sanera.net>
Cc: "Ips@Ece. Cmu. Edu" <ips@ece.cmu.edu>
Subject: RE: ISCSI: User authentication vs. Machine Authentication for iSC
	SI
Date: Thu, 30 Aug 2001 15:41:39 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Just one clarification on John's response (which I agree with, by the way,
as well as Charles and Mark's comments).  John stated.

>Note: Mark pointed out that this was the way Web servers worked.
>3. Chap can  be used in this environment since the Link is already secure
>and encrypted, and sending the password in what otherwise would have been
>in the clear, is protected by the link encryption.

CHAP does not send passwords in the clear.  It may send user identities in
the clear, and it requires a shared secret to be stored in multiple
locations, but the password is hashed using MD5 or other similar algorithm.
MD5 may not be considered the tightest hash algorithm, but it produces stuff
far from clear text.

Paul



From owner-ips@ece.cmu.edu  Thu Aug 30 21:00:49 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01374
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 21:00:48 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7UNaSL16832
	for ips-outgoing; Thu, 30 Aug 2001 19:36:28 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e32.bld.us.ibm.com (e32.co.us.ibm.com [32.97.110.130])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7UNaQP16826
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 19:36:26 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e32.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id TAA97268;
	Thu, 30 Aug 2001 19:34:13 -0400
Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7UNZ9D24292;
	Thu, 30 Aug 2001 17:35:09 -0600
X-Priority: 1 (High)
Importance: Normal
Subject: Re: ISCSI: User authentication vs. Machine Authentication for iSC SI
To: Mark Bakke <mbakke@cisco.com>
Cc: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OF83252697.E9778045-ON88256AB8.007ED3B7@boulder.ibm.com>
From: "John Hufferd" <hufferd@us.ibm.com>
Date: Thu, 30 Aug 2001 16:34:36 -0700
X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at
 08/30/2001 05:35:08 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Mark,
You clearly understand part of the problem well.  You need to step a bit
further.
Just recommending the names be the same, does not address what happens
when they are not.  So let me take you a bit further.

A system that has an iSCSI Initiator Node Name "iqn.com.mother.jump"
is given the UserID of "Wonder".
Now assume that "Wonder" is Authenticated. Now the iSCSI client system with
UserID
of "Wonder" can now masquerade as any other Authorized iSCSI Initiator
Node, by putting that name on its Login.

This seems like it is not a real good idea, so the target system needs to
prevent this.  That means that the Target System needs to bind together
in some way the UserID and the approprate iSCSI Initiator Node Name.

So only recommending that the UserID and iSCSI Initiator NodeName
be the same means that everyone MUST implement a relationship
binding Database that can be used to ensure that no one can masquerade
as some other iSCSI Initiator Node.

This also means that it needs to be tied into the UserID authorization
Database/Directory such that when name etc. are change (which
often they do), the iSCSI Target Device relationship/Binding Database
is also updated.  If this is a manual process, it will get out on hand
very quickly.

For those of you that think this is a very simple one to one table, you
might want to read Marks note again, he said that he could have
a different UserID for each network he logs into.  If there is any
cross connect to a specific iSCSI Target this means that the
iSCSI Target Device needs to perhaps carry more then one
UserID for each iSCSI Initiator Node Name.

That may not be a significant problem since the networks
may never interconnect.  Opinions would be useful here.

Is their any other reason that an iSCSI Initiator Node would  have
more then one UserID?

Does anyone have a technique to ensure that only the iSCSI
Initiator Node Name need be managed?



.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com


Mark Bakke <mbakke@cisco.com>@cisco.com on 08/30/2001 01:07:35 PM

Sent by:  mbakke@cisco.com


To:   Stephen Bailey <steph@cs.uchicago.edu>
cc:   ips@ece.cmu.edu, John Hufferd/San Jose/IBM@IBMUS
Subject:  Re: ISCSI: User authentication vs. Machine Authentication for iSC
      SI



Stephen Bailey wrote:
>
> > The new Name (UserID) is exactly what was implied at the meeting in
> > Irvine.
>
> Oh.  How horrible.

Ideally, you're right.  For instance, if iSCSI was using AuthMethod=CHAP,
then it would be great if the CHAP username (N) specified was identical
to the InitiatorName.

In the draft, that's not how it is.  The user names for CHAP and SRP
(I'm not sure about the others) are specified separately from the
InitiatorName, so there's currently nothing in the protocol to prevent
them from being different.

In practise, there might be times when having them be different
makes the "fit in" better with whatever administration scheme is
out there.  For instance, if my desktop was assigned some iSCSI
storage, and my username and password were kept on a RADIUS server
somewhere, for use by file servers, web servers, and iSCSI servers
or devices, my user name is likely to be a non-globally-unique
string, probably "mbakke".  However, that's not likely to be
my InitiatorName.  To make them the same, I would either have to
change my InitiatorName on my desktop to "mbakke", to fit in with
my login on all of our web and file servers, or the admin would
have to create a new login for my iSCSI stuff on the RADIUS server,
and maintain two of them.  Changing my login on everything to
match an iSCSI name is likely not an option.

Another possible place this could happen is if I am obtaining
iSCSI "services" from more than one administratively-separate
environment.  Each of these environments may prefer to assign
me a user name for login that matches their own internal scheme.
I may have some control over this, but in the end, it has to be
unique within the service-provider's scheme.  This is very
similar to setting up a user-name for your ISP at home; you
may request a particular name, but if the ISP already has one,
you have to pick again.

The point is that if one had two of these environments providing
services, they may each need a separate user name.

Of course, the latter example could be solved by having the
admins accept the initiator name that's already on my iSCSI
client as the user name; these are supposed to be unique
anyway.  The only trouble then is the same as before; if I am
getting more than just iSCSI services from this provider, they
would then have to maintain two user names for me.

A third reason this might happen is that some centralized
password authenticated services such as RADIUS may have
length restrictions on their user names that are shorter than
what is allowed in an iSCSI initiator name.

Anyway, implementations have the most flexibility the way
these protocols (SRP, CHAP) are currently documented.  I think
that we could recommend that the iSCSI initiator name be the
same wherever possible, but I don't see how we can require it.

>
> > A number of us, I am sure, think this is a very poor direction for an
> > implementation.
>
> Agreed.  I just wanted to walk the space a little bit.  My point is
> that while traditional SCSI passthru does confer control privs (and is
> protected as such), it doesn't need to.  Specifically, a client using
> SCSI passthru is not actually given the identity of the host OS, per
> se.
>
> > So I believe we must consider such a potential application as
> > probably a rouge application and do nothing to help this, and work
> > to prevent it.
>
> I understand what you're saying, but I'm not sure it confers much
> architectural direction.  There already must be a concept of identity
> which is independent of anything bound to a particular system (e.g. IP
> address, hardware network port etc.), so there's no way to exclude
> that.
>
> > The important issue is, can we make the iSCSI Initiator Node Name be
> > used as the UserID.


Again, I think that the best we can do is recommend that they
be the same, but I don't think we can take the step of requiring
it.


> Agreed.  Are there minutes to the meeting?
>
> Thanks,
>   Steph

--
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054





From owner-ips@ece.cmu.edu  Thu Aug 30 21:42:39 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02769
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 21:42:38 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7V0atQ19439
	for ips-outgoing; Thu, 30 Aug 2001 20:36:55 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mxic1.isus.emc.com ([168.159.129.100])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7V0anP19428
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 20:36:49 -0400 (EDT)
Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <RRQ3LH3L>; Thu, 30 Aug 2001 20:38:50 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD694@CORPMX14>
From: Black_David@emc.com
To: ips@ece.cmu.edu
Subject: IKE Subsetting Comments
Date: Thu, 30 Aug 2001 20:30:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Although not discussed in detail at the interim meeting, I offer
the following comments on IKE subsetting:

[A] Authentication algorithms.  IKE contains four authentication
	algorithms:
	- Signature authentication, usually based on certificates
		binding identities to signature keys [RFC 2409, Section
		5.1].
	- Public key encryption authentication (2 algorithms), usually
		based on certificates binding identities to encryption
		keys [RFC 2409, Sections 5.2 and 5.3]
	- Pre-shared key authentication, based on demonstrating
		possession of the pre-shared key.  There is an
		administrative responsibility to only provide that key
		to appropriate systems, as there is no other IKE
		identity check performed [RFC 2409, Section 5.4].
As William Dixon indicated in his presentation, the public key
encryption algorithms are good candidates for deletion, and the
improveike draft (draft-ietf-ipsec-improveike-00.txt) also
recommends dropping them.  I would recommend that they at least
be "NOT REQUIRED to implement".  Going further (e.g., to "SHOULD
NOT use") takes a risk on the direction of the ipsec WG that
I don't see as necessary.

Pre-shared key authentication is the simplest, and hence a good
selection for "MUST implement".  To make signature authentication
a "SHOULD implement" or "MUST implement", I would want to see
additional text about certificate usage and validation including
topics such as single certificate vs. chain, certificate authorities
(esp. issues arising when multiple authorities are possible),
certificate revocation, and use of self-signed certificates. 
The goal would be to limit the complexity of recommended or
required certificate processing.  The Aboba draft contains a
start on this, and I would ask the authors of that draft to
come back with a more complete and concrete set of recommendations
in this area.  Can we wait for such a set of recommendations
before embarking on further discussion of certificate usage
restrictions?  There are potentially huge gains in reduction
of IKE code and complexity from restrictions in this area, but
we need to start with recommendations from experts.

[B] Operating modes.  The fundamental issue here is whether to
require Main Mode and/or Aggressive Mode for IKE Phase 1.  Main
Mode hides identities at the cost of an extra round trip in the
IKE Phase 1 protocol.  Also, as described in both the Aboba draft
(draft-aboba-ips-iscsi-security-00.txt) and the improveike draft
(draft-ietf-ipsec-improveike-00.txt), Main Mode is not secure
against man-in-the-middle attacks when used with dynamically
assigned IP addresses (e.g., from DHCP).  IMHO, this makes
Aggressive Mode a "MUST implement", as I would expect at least
iSCSI initiators to be deployed in environments where DHCP
is used for IP address assignment.  This problem with Main
Mode is arguably an oversight in its specification, but it's
a specified, deployed, interoperable, and REQUIRED oversight,
and one that we don't have the ability to change.  The change
recommended in the improveike draft is for IKEv2 (aka son-of-IKE),
which is off in the future somewhere.

In addition, I suggest also making Main Mode a MUST, as it
has advantages in some situations (identity hiding), it is a
MUST in RFC 2409 and it is present in essentially all
implementations of IPsec.  This will avoid a potentially
deep and unproductive rathole discussion on Main Mode vs.
Aggressive Mode. 

Thanks,
--David
 
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


From owner-ips@ece.cmu.edu  Thu Aug 30 21:42:56 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02783
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 21:42:56 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7V0qif20102
	for ips-outgoing; Thu, 30 Aug 2001 20:52:44 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e33.bld.us.ibm.com (e33.co.us.ibm.com [32.97.110.131])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7V0qhP20098
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 20:52:43 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e33.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id TAA93034;
	Thu, 30 Aug 2001 19:50:25 -0500
Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7V0pLD38632;
	Thu, 30 Aug 2001 18:51:21 -0600
X-Priority: 1 (High)
Importance: Normal
Subject: RE: iSCSI - Change - Login/Text commands with the binary stage code
To: "Bill Strahm" <bill@sanera.net>
Cc: <ips@ece.cmu.edu>
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OFCC8FC58F.F243B213-ON88256AB9.0004305B@boulder.ibm.com>
From: "John Hufferd" <hufferd@us.ibm.com>
Date: Thu, 30 Aug 2001 17:50:42 -0700
X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at
 08/30/2001 06:51:20 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Bill,
This IPSec is not enough, you need to ensure that the initiator you are
connected too, is who it claims to be in the eui, or iqn iSCSI Initiator
Names.  It could lie and get at LUNs that he is not authorized to get at.
Subsequent iSCSI Authentication must be done to prevent this masquerade.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com


"Bill Strahm" <bill@sanera.net>@ece.cmu.edu on 08/30/2001 11:49:01 AM

Sent by:  owner-ips@ece.cmu.edu


To:   Julian Satran/Haifa/IBM@IBMIL
cc:   "Ips@Ece. Cmu. Edu" <ips@ece.cmu.edu>
Subject:  RE: iSCSI - Change - Login/Text commands with the binary stage
      code



Ok,

I am confused here (or maybe it is just a lag effect for me)

I thought we had decided in Irvine to use IPsec/IKE to negotiate security.
So basically the process is this

1) Administrator makes several entries into a Security Policy Database
2) An iSCSI initiator attempts to send a TCP-SYN packet to a target machine
3) The IPsec packet filter detects this packet, realized there isn't a
security association for it, and asks the Security Policy Database what to
do about it
4) The security Policy Database may determine that an IPsec SA needs to be
established so tells IKE to negotiate with the remote peer
5) An IKE negotiation proceeds until either it succeeds or fails
6) If it fails, packets are dropped
7) If it succeeds, the negotiated SAs are pushed to the IPsec packet
filters
8) The origional TCP-SYN packet is now sent out under the IPsec SA that was
negotiated.

Now under this scenario there is no need for iSCSI to negotiate security at
all.  I DO now see the need to include an iSCSI Login phase that includes
passing user identities across so targets and initiators can identify
themselves, but this is over a secure link (see the above discussion) so I
can just put ID= Bills-iSCSI-Initiator PW=BetYouCantGuessIt and the link
will secure it for me...

Bill
Sanera Systems Inc.
-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Julian Satran
Sent: Wednesday, August 29, 2001 2:40 PM
To: ips@ece.cmu.edu
Subject: Re: iSCSI - Change - Login/Text commands with the binary stage
code



Steve,

Implement and use are different terms. An administrator might set it up not
to use security under specific conditions.

Julo

Steve Senum <ssenum@cisco.com>@ece.cmu.edu on 30-08-2001 00:12:28

Please respond to Steve Senum <ssenum@cisco.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ietf-ips <ips@ece.cmu.edu>
cc:
Subject:  Re: iSCSI - Change - Login/Text commands with the binary stage
      code



Julian,

In the following section:

   If the initiator decides to forego the SecurityNegotiation stage it
   issues the Login with the CNxSG set to LoginOperationalNegotiation in
   the current stage and the target may replay with a Login Response
   indicating that it is unwilling to accept the connection without
   SecurityNegotiation and terminate the connection.

This seems contrary to the requirement to implement
authentication (at least AuthMethod=SRP).  I realize
this could also be a configuration issue, but I wonder
if the spec should at least strongly recommend starting
with phase SecurityNegotiation, or better yet, make it
a SHOULD?

Regards,
Steve Senum









From owner-ips@ece.cmu.edu  Thu Aug 30 21:45:05 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02811
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 21:45:03 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7V0vmo20309
	for ips-outgoing; Thu, 30 Aug 2001 20:57:48 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e33.bld.us.ibm.com (e33.co.us.ibm.com [32.97.110.131])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7V0vkP20301
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 20:57:46 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e33.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id TAA16574;
	Thu, 30 Aug 2001 19:55:33 -0500
Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7V0uTD166780;
	Thu, 30 Aug 2001 18:56:29 -0600
X-Priority: 1 (High)
Importance: Normal
Subject: Re: iSCSI - Change - Login/Text commands with the binary stage code
To: Mark Bakke <mbakke@cisco.com>
Cc: <ips@ece.cmu.edu>
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OFF40AF60E.25A659EB-ON88256AB9.0004EE4F@boulder.ibm.com>
From: "John Hufferd" <hufferd@us.ibm.com>
Date: Thu, 30 Aug 2001 17:55:55 -0700
X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at
 08/30/2001 06:56:28 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Mark, (I attached this note to the wrong message from you previously, so
here it is attached to the approprate message)

Regardless of whether IKE and IPSec is used, you Still need iSCSI
Authentication to prevent Masquerading as various different iSCSI Initiator
Nodes.

.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com


Mark Bakke <mbakke@cisco.com>@ece.cmu.edu on 08/30/2001 12:13:34 PM

Sent by:  owner-ips@ece.cmu.edu


To:   Bill Strahm <bill@sanera.net>
cc:   Julian Satran/Haifa/IBM@IBMIL, "Ips@Ece. Cmu. Edu" <ips@ece.cmu.edu>
Subject:  Re: iSCSI - Change - Login/Text commands with the binary stage
      code



Bill-

In Irvine, we agreed that when IPsec is enabled, IKE will be used
to do key exchange.  We also agreed on which transforms to use when
IPsec is enabled.

The key word is "enabled".  Keep in mind that there will probably
be three classes of iSCSI implementations "out there":

1. iSCSI implementations without security.  These won't be able to
   say they are "compliant", but are likely to be the majority of
   implementations, at least for a little while.  At any rate, we
   all pay our marketing folks to get us around this one.

2. iSCSI implementations with software security.  These will add
   IPsec in software for one of two reasons: either high performance
   is not required (perhaps it's designed to go over a T1 or something),
   or just so the "RFC-xxxx-compliant" bullet can be checked off on
   the list.  If it's for the first reason, IPsec will be used by
   some customers; if it's for the second reason, it will likely
   never be enabled.

3. iSCSI implementations with hardware security.  These will be
   serious implementations that include IPsec, and can perform
   well enough that a customer will want to use IPsec.  These
   implementations will enable IPsec if the customer needs it, but
   again, might not enable it if this is not a concern.

Your assumption seems to be that because we chose IPsec/IKE, that
it will always be used.  Given the implementations 1 and 2, and
some of 3, that is not always the case.

As you mentioned, when your assumptions are correct, the login
phase only has to exchange initiator and target names, and can
use AuthMethod=none if it likes.  However, those assumptions
will not always hold.

--
Mark

Bill Strahm wrote:
>
> Ok,
>
> I am confused here (or maybe it is just a lag effect for me)
>
> I thought we had decided in Irvine to use IPsec/IKE to negotiate
security.
> So basically the process is this
>
> 1) Administrator makes several entries into a Security Policy Database
> 2) An iSCSI initiator attempts to send a TCP-SYN packet to a target
machine
> 3) The IPsec packet filter detects this packet, realized there isn't a
> security association for it, and asks the Security Policy Database what
to
> do about it
> 4) The security Policy Database may determine that an IPsec SA needs to
be
> established so tells IKE to negotiate with the remote peer
> 5) An IKE negotiation proceeds until either it succeeds or fails
> 6) If it fails, packets are dropped
> 7) If it succeeds, the negotiated SAs are pushed to the IPsec packet
filters
> 8) The origional TCP-SYN packet is now sent out under the IPsec SA that
was
> negotiated.
>
> Now under this scenario there is no need for iSCSI to negotiate security
at
> all.  I DO now see the need to include an iSCSI Login phase that includes
> passing user identities across so targets and initiators can identify
> themselves, but this is over a secure link (see the above discussion) so
I
> can just put ID= Bills-iSCSI-Initiator PW=BetYouCantGuessIt and the link
> will secure it for me...
>
> Bill
> Sanera Systems Inc.
> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Julian Satran
> Sent: Wednesday, August 29, 2001 2:40 PM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI - Change - Login/Text commands with the binary stage
> code
>
> Steve,
>
> Implement and use are different terms. An administrator might set it up
not
> to use security under specific conditions.
>
> Julo
>
> Steve Senum <ssenum@cisco.com>@ece.cmu.edu on 30-08-2001 00:12:28
>
> Please respond to Steve Senum <ssenum@cisco.com>
>
> Sent by:  owner-ips@ece.cmu.edu
>
> To:   ietf-ips <ips@ece.cmu.edu>
> cc:
> Subject:  Re: iSCSI - Change - Login/Text commands with the binary stage
>       code
>
> Julian,
>
> In the following section:
>
>    If the initiator decides to forego the SecurityNegotiation stage it
>    issues the Login with the CNxSG set to LoginOperationalNegotiation in
>    the current stage and the target may replay with a Login Response
>    indicating that it is unwilling to accept the connection without
>    SecurityNegotiation and terminate the connection.
>
> This seems contrary to the requirement to implement
> authentication (at least AuthMethod=SRP).  I realize
> this could also be a configuration issue, but I wonder
> if the spec should at least strongly recommend starting
> with phase SecurityNegotiation, or better yet, make it
> a SHOULD?
>
> Regards,
> Steve Senum

--
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054





From owner-ips@ece.cmu.edu  Thu Aug 30 21:53:29 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02888
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 21:53:28 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7V0YQ219305
	for ips-outgoing; Thu, 30 Aug 2001 20:34:26 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from chmls05.mediaone.net (chmls05.mediaone.net [24.147.1.143])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7V0YBP19296
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 20:34:11 -0400 (EDT)
Received: from cs.uchicago.edu (h005018030f43.ne.mediaone.net [24.91.87.144])
	by chmls05.mediaone.net (8.11.1/8.11.1) with ESMTP id f7V0Y5Z13463
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 20:34:05 -0400 (EDT)
Message-Id: <200108310034.f7V0Y5Z13463@chmls05.mediaone.net>
To: ips@ece.cmu.edu
Subject: Re: ISCSI: User authentication vs. Machine Authentication for iSC SI 
In-Reply-To: Message from Mark Bakke <mbakke@cisco.com> 
   of "Thu, 30 Aug 2001 15:07:35 CDT." <3B8E9D07.720E107B@cisco.com> 
References: <OF761F95F7.844FE06F-ON88256AB8.00574D6B@boulder.ibm.com> <20010830191403.A0DE24E95@sandmail.sandburst.com>  <3B8E9D07.720E107B@cisco.com> 
Date: Thu, 30 Aug 2001 20:33:34 -0400
From: Stephen Bailey <steph@cs.uchicago.edu>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

> In practise, there might be times when having them be different
> makes the "fit in" better with whatever administration scheme is
> out there.

Oh, right.

Impedance-matching existing authentication architectures is fast
becoming the oldest profession.  There is no really good solution,
because people keep hacking together patchwork because there is no
really good solution.  Look no further than authentication for
commercial databases if you want a good cry.

Thanks for putting me in the picture.

Steph


From owner-ips@ece.cmu.edu  Thu Aug 30 21:53:51 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02906
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 21:53:51 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7V0LgO18751
	for ips-outgoing; Thu, 30 Aug 2001 20:21:42 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mxic2.us.dg.com (mxic2.us.dg.com [128.221.31.40])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7V0LfP18747
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 20:21:42 -0400 (EDT)
Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19)
	id <RX0AB0MZ>; Thu, 30 Aug 2001 20:19:19 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD693@CORPMX14>
From: Black_David@emc.com
To: ips@ece.cmu.edu
Subject: iSCSI Security directions and rationale
Date: Thu, 30 Aug 2001 20:15:22 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

The purpose of this message is to state the recommended
security directions for iSCSI from the interim meeting and
describe the rationale for them.  Objections to these
decisions may be made on the list, but they need to have
*good* technical reasons.  I apologize for the length of
this message, but we spent a while on this in the meeting,
and I wanted to get all the considerations into this message.

First, an important piece of procedural context.  In order to
specify a security algorithm (cipher and mode, or integrity MAC),
we need a separate RFC to cite.  For algorithms without RFCs,
the work to create such an RFC occurs in the ipsec WG, not here.
Given the anticipated timetable for iSCSI, any new RFC for such
an algorithm needs to be in ipsec WG Last Call and ideally
submitted to the IESG by early next year, otherwise approval
of the iSCSI RFC gets held up until that algorithm RFC is ready.
The proposed charter revision for the ipsec WG (posted for
comments on August 9) anticipates the following work on
algorithms between now and the end of the year:

3)  New cipher documents to support AES-CBC, AES-MAC, SHA-2, and 
	a fast AES mode suitable for use in hardware encryptors

The "fast AES mode suitable for use in hardware encryptors" is
likely to be counter mode.  In practice, NIST is functioning
as a gateway to the ipsec WG in this area, in that if NIST is not
prepared to recommend a cipher/mode or MAC algorithm, the ipsec
WG is unlikely to work on it seriously in the next few months.
Hence as a practical matter "NIST is not prepared to recommend"
is fatal to the inclusion of an algorithm in the current iSCSI
specification.

There were four major security issues considered at the interim
meeting.  Here's a summary of the issues and recommendations:
(1) Keying - inband (SRP/ESP) or IKE subset
	Recommendation: IKE subset.  No further work to be done
		on inband keying and it will not be specified.
(2) Integrity MAC - many possibilities
	Recommendation: HMAC-SHA1 as "MUST implement", AES CBC MAC
		with XCBC extensions as "SHOULD implement", subject
		to verification that this is consistent with the
		ipsec WG's standardization plans.
(3) Encryption algorithm and operating mode - many possibilities
	Recommendation: 3DES in CBC mode as "MUST implement", AES
		in counter mode or whatever "fast AES mode suitable
		for use in hardware encryptors" is standardized by the
		ipsec WG as "SHOULD implement".  As previously noted
		on the list, NULL encryption is "MUST implement".
(4) Encapsulation mode - transport vs. tunnel
	Recommendation: Unable to reach reasonable consensus.  This
		is wrapped up in external gateway and end-to-end
		security issues as will be explained below.
These recommendations are subject to further comment on the list,
but I would ask that anyone who comments make sure that they
understand the rationale described below.  In the absence of 
serious objections, I intend to call consensus on the first
three items above in the near future.

Let me also note that nothing in this message excludes any
algorithm from implementation  - this is entirely about what
algorithms to REQUIRE (MUST implement) or RECOMMEND (SHOULD
implement).  The one exception is DES, which is sufficiently
weak to justify "SHOULD NOT implement" wording (IMHO).  Usage
is negotiable in all cases.  We may want or need to revisit
these recommendations in the future when the iSCSI specification
is closer to being issued as an RFC in light of developments
between now and then.

- Keying Rationale

Inband keying has negotiation and startup weaknesses.  The best
that can be done with negotiation for the inband keying approach
detects tampering with security negotiation after the fact (at
which point one has to abandon the connection and start over),
whereas IKE can prevent tampering.  There is no good solution for
starting ESP underneath an existing TCP connection.  IKE can be
implemented within memory requirements that are reasonable for
embedded devices (see draft-aboba-ips-iscsi-security-00.txt),
and IKE implementations are readily available in contrast to new
work that would be required for inband keying.  IKE can also be
judiciously subsetted to cut down on the complexity objections
to it (more on this in a separate thread).  In addition, there is
some desire for FCIP and iFCP to follow iSCSI's security direction,
and inband keying is a poor fit to these protocols, especially
FCIP.

- Integrity MAC Rationale

There are three classes of candidate MAC algorithms:
(1) New MACs (e.g., UMAC, PMAC) and new encryption operating
	modes that incorporate MAC functionality.  NIST is not
	prepared to recommend any of these at this time, and hence
	they have to be ruled out for iSCSI.  Unfortunately, all
	of the MAC algorithms likely to have high performance in
	hardware fall into this category.  In addition, with the
	exception of UMAC, all of these sorts of algorithms considered
	at the Modes workshop have serious intellectual property (i.e.,
	patent) issues.  Since UMAC has been of particular interest
	in the past, I should note that the developer of UMAC asked
	NIST not to consider it (and to consider PMAC instead) because
	UMAC is a poor fit to hardware implementations.  NIST will
	be considering algorithms of both sorts (including PMAC)
	for possible future recommendation.  
(2) AES CBC MAC.  NIST was initially prepared to recommend this,
	but it was modified at the Modes workshop to include the XCBC
	extension to improve security for variable size messages.
	NIST is prepared to recommend the result, but we need to check
	that the ipsec WG will proceed to standardize AES CBC MAC as
	modified in this fashion.  Between this and the newness of
	the modification, AES CBC MAC is most appropriate as a
	backup (in case a serious security flaw is discovered in our
	primary algorithm) and hence is recommended as "SHOULD
	implement" subject to verification with the ipsec WG
	(Howard Herbert is working on that verification).
(3) HMAC-SHA1 and HMAC-MD5.  This is what's left.  They're stable,
	well-known, widely implemented, but not exactly fast.  Of the
	two, HMAC-SHA1 is the better choice, as a security issue has
	been discovered with MD5 (as pointed out in the meeting, the
	issue doesn't compromise HMAC-MD5, but the "where there's smoke"
	principle suggests that HMAC-SHA1 is the better choice).  SHA2
	was felt to be more of a performance improvement for SHA1 and
	not sufficiently different from SHA1 to provide meaningful
	protection if a security flaw is found in SHA1, motivating
	the choice of AES CBC MAC as modified by XCBC as the second
	MAC algorithm.
 
- Encryption Algorithm and Mode Rationale

After the WG chair exercised his prerogative to exclude DES from
consideration, four algorithm/mode possibilities were considered:
	- AES in Counter and CBC Modes
	- 3DES in Counter and CBC Modes
3DES Counter Mode is a new mode for 3DES; the ipsec WG does
not appear to have any current plans to standardize it, and
that eliminates 3DES in Counter Mode from consideration.
The point of choosing AES would be to get an algorithm/mode
combination with high performance in hardware and software.
There's unlikely to be a significant difference between CBC
Mode and Counter Mode in software, but Counter Mode can be 
much faster than CBC in hardware, hence Counter Mode makes
a lot more sense for AES than CBC Mode.

Between 3DES in CBC Mode and AES in Counter Mode (or possibly
some other fast mode for hardware encryptors selected by the
ipsec WG), 3DES/CBC is specified, stable, and deployed (and
implementations are available).  Counter Mode for AES is not
completely specified yet, and AES implementations are not
currently widely available.  Hence 3DES in CBC Mode was
recommended as "MUST implement" and AES in Counter Mode or
whatever fast mode for hardware encryptors the ipsec WG
selects as "SHOULD implement" (e.g., inability to get
high performance hardware can be part of a valid reason
to ignore a "SHOULD").  NULL encryption needs to be "MUST
implement" in order to allow ESP to be used for keyed
cryptographic integrity without encryptions.  
 
- Encapsulation Mode

Given the decision to use IKE, a decision to use tunnel mode
encapsulation would result in iSCSI security *exactly matching*
the functionality of an IPsec security gateway (Bump In The
Wire).  Security gateways can be deployed anywhere, and as a
result, it's quite easy for the security obtained from gateways
to be other than end-to-end.  Based on discussions with ADs and
other knowledgeable folks in London, I believe that the IETF
Security Area and the IESG have a preference for end-to-end
security solutions.

Since most security gateways do not support transport mode
(there are a few that do, but they are the exception, not
the rule), REQUIRING transport mode would bias the iSCSI
specification towards end-to-end security in a fashion that
should make it easier to gain IESG approval.  OTOH,
REQUIRING transport mode would make it considerably more
difficult to use external security gateways to provide the
mandatory to implement iSCSI security, which seems to be of
interest to a significant portion of the WG.  On the third
hand, as was made clear at the IESG Open Plenary in London,
the IESG has little sympathy for a desire to use external
security gateways when the result leads to standardization
of other than the "best security available" (see Section 6 of
draft-ietf-saag-whyenc-00.txt).  On the fourth hand, there
may be ways to specify/recommend/require usage of IKE
authentication in a fashion that creates a bias towards
end-to-end security of similar strength to requiring transport
mode.

And that's about where things stand.  I apologize for being
unable to provide clearer guidance, but the situation is what
it is.  From a purely specification and process viewpoint,
REQUIRING transport mode will hasten completion of the iSCSI
spec and its approval by the IESG, but process should not
take precedence over making the proverbial "right" or "best"
technical and engineering decisions.

Please do not quote this entire message when responding.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


From owner-ips@ece.cmu.edu  Thu Aug 30 22:38:39 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04321
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 22:38:39 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7V1dKB22034
	for ips-outgoing; Thu, 30 Aug 2001 21:39:20 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mxic2.us.dg.com (mxic2.us.dg.com [128.221.31.40])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7V1dIP22029
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 21:39:19 -0400 (EDT)
Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19)
	id <RX0ACA6Z>; Thu, 30 Aug 2001 21:36:56 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD696@CORPMX14>
From: Black_David@emc.com
To: tnguyen@perfisans.com, ips@ece.cmu.edu
Subject: RE: iSCSI-08 Draft Availability?
Date: Thu, 30 Aug 2001 21:32:59 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Since Julian answered the question addressed to me (and properly so),
I'll answer the one addressed to him.  I'd hope to see all major technical
issues closed by the end of the year (the December IETF meeting in Salt
Lake City will be the place to close issues not already closed on the
list).  A new version of the draft would be prepared and WG Last Called
sometime in early 2002 - WG Last Call will run for at least 4 weeks,
and it may take more than one attempt to complete WG Last Call.
At that point the draft will be submitted to the IESG - between their
review and IETF Last Call, I'm going to guess middle of next year
as the earliest that iSCSI will get approved as an RFC.  This is a
longer version of (1) in the message forwarded below.

WARNING: Substantial technical changes can occur as a consequence of
comments made during both WG Last Call and IETF Last Call, as well as
concerns the IESG has in reviewing the document.  It will be risky to
assume that completion of WG Last Call implies no further substantial
technical changes.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------

> -----Original Message-----
> From: Trang Nguyen [mailto:tnguyen@perfisans.com]
> Sent: Thursday, August 30, 2001 6:40 PM
> To: Julian Satran; ips@ece.cmu.edu
> Subject: RE: iSCSI-08 Draft Availability?
> 
> 
> Hi Julian,
> 
> Do you have a schedule of when iSCSI protocol will be finalized?
> 
> Thanks,
> 
> *********************************
>  Trang Nguyen
>  tnguyen@perfisans.com
> *********************************
> 
> 
> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Julian Satran
> Sent: August 30, 2001 3:43 PM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI-08 Draft Availability?
> 
> 
> 
> Next week - provided we get some things cooling down. Julo
> 
> "CLEMENT,ERIC L (A-Roseville,ex1)" 
> <eric_l_clement@agilent.com>@ece.cmu.edu
> on 30-08-2001 21:46:12
> 
> Please respond to "CLEMENT,ERIC L (A-Roseville,ex1)"
>       <eric_l_clement@agilent.com>
> 
> Sent by:  owner-ips@ece.cmu.edu
> 
> 
> To:   "'Black_David@emc.com'" <Black_David@emc.com>
> cc:   "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
> Subject:  iSCSI-08 Draft Availability?
> 
> 
> 
> Hi David,
> 
> Do you know what timeframe the iSCSI-08 draft will be available?
> 
> Regards,
> Eric
> __________________________________
> 
> Eric Clement
> Agilent Technologies, Inc.
> 1101 Creekside Ridge Drive
> Suite 100, MS RH-21
> Roseville, California 95661
> 
> Phone: 916.788.6211
> Fax: 916.788.6134
> Email: Eric_L_Clement@Agilent.com
> ___________________________________
> 
> 
> 
> To: ips@ece.cmu.edu
> Subject: IPS Draft Status and Schedule
> From: Black_David@emc.com
> Date: Wed, 22 Aug 2001 17:24:11 -0400
> Content-Type: text/plain;charset="iso-8859-1"
> Sender: owner-ips@ece.cmu.edu
> 
> --------------------------------------------------------------
> --------------
> 
> ----
> 
> Here's what the WG chairs think the current status and schedule
> is for the drafts that the IP Storage WG is working on (including
> three individual submissions that have agenda time in Orange
> County).  This is probably not 100% accurate, but should be
> close.  Draft authors - please send any corrections to me.
> 
> Apologies for being tardy on this - this should have been done
> about a month ago, but I have negative "copious spare time".
> Going forward, the intent is to produce an updated version of
> this prior to each WG meeting.  Proposed revised charter will
> be coming in the near future, with milestones based on the
> completion guesstimates below.
> 
> Thanks,
> --David
> 
> -- iSCSI
> 
> draft-ietf-ips-iscsi-07.txt
>      To be a proposed standard RFC.
>      Large portions are stable, major open security and login issues.
>      -08 will be a functional/technical revision, document 
> restructure/
>           reorganization expected in -09 version.
>      Hope to close all major issues by December 2001 IETF meeting
> 
> draft-ietf-ips-iscsi-boot-02.txt
>      No major open issues, possible minor issues in DHCP usage.
>           DHCP material to be extracted into a separate
> standards-track draft.
>      Remainder to become an informational RFC, after the main iSCSI
> document.
> 
> draft-ietf-ips-iscsi-reqmts-05.txt
>      To be an informational RFC.
>      Has completed WG Last Call, currently being considered 
> by the IESG,
>           IETF Last Call has not been issued.
> 
> draft-ietf-ips-iscsi-name-disc-02.txt
>      To be an informational RFC.
>      Specification portions that must be standards track are 
> being added
>           to the main iSCSI specification.
>      No major open issues, hope to close any other issues by December
> 2001 IETF
>           meeting.  Plan to issue WG Last Call for this with main
> iSCSI draft.
> 
> draft-ietf-ips-iscsi-slp-01.txt
>      To be a proposed standard RFC.
>      Close to done.  Issues in this general area seem to come 
> up in the
>           context of the naming and discovery draft (name-disc-02)
> rather
>           than this draft.
>      WG Last Call will be after the naming and discovery draft.
> 
> draft-ietf-ips-iscsi-mib-02.txt
>      To be a proposed standard RFC.
>      Next (-03) version expected in September, should be 
> close to done.
>      WG Last Call will follow main iSCSI draft.
> 
> draft-black-ips-iscsi-security-01.txt
> draft-aboba-ips-iscsi-security-00.txt
>      Unlikely to become RFCs in their current forms.
>      New drafts on iSCSI Security for discussion at Orange County
> meeting.
>           Security requirements will be specified in the main iSCSI
> document.
>      Some remaining portions of one or both drafts may become an
>           informational RFC.  Whether to do this and what portions to
> use
>           are subject to discussion.
> 
> -- FC Common Encapsulation
> 
> draft-ietf-ips-fcencapsulation-02.txt
>      To be a proposed standard RFC.
>      No major open issues.
>      Will accompany FCIP and/or iFCP drafts in Last Call, 
> probably after
>           December 2001 IETF.
> 
> -- FCIP
> 
> draft-ietf-ips-fcovertcpip-05.txt
>      To be a proposed standard RFC.
>      Large portions are stable, major open security issues.
>      Hope to close all major issues by December 2001 IETF meeting.
> 
> draft-ietf-ips-fcip-slp-00.txt
>      To be a proposed standard RFC.
>      New draft for discussion in Orange County.
>      Hope to close all major issues by December 2001 IETF meeting.
> 
> draft-ietf-ips-fcip-mib-00.txt
>      To be a proposed standard RFC.
>      New draft for discussion in Orange County.
>      Likely timeframe for closing final issues is March 2002 IETF
> meeting.
> 
> -- iFCP
> 
> draft-ietf-ips-ifcp-04.txt
>      To be a proposed standard RFC.
>      Large portions are stable, major open security issues.
>      Hope to close all major issues by December 2001 IETF meeting.
> 
> draft-tseng-ifcp-mib-00.txt
>      To be a proposed standard RFC.
>      New draft for consideration in Orange County, will be 
> proposed for
>           approval as an official WG draft.
>      Likely timeframe for closing final issues is March 2002 IETF
> meeting.
> 
> -- iSNS
> 
> draft-ietf-ips-isns-04.txt
>      To be a proposed standard RFC.
>      Relationship to SLP for use with iSCSI seems to be settled, no
>           other major open issues.
>      WG Last Call to follow iSCSI and iFCP drafts.
>      Hope to close any remaining issues by December 2001 IETF meeting.
> 
> draft-gibbons-isnsmib-00.txt
>      To be a proposed standard RFC.
>      Relatively new draft, London meeting approved it as an official
>           IPS WG work item, next version will be draft-ietf-ips-...
>      Likely timeframe for closing final issues is March 2002 IETF
> meeting.
> 
> -- Framework
> 
> draft-ietf-ips-framework-00.txt
>      Has not been updated by author team since original revision.
>      Likely to be abandoned in the absence of renewed interest.
> 
> -- SCSI MIB
> 
> There's been talk about working on this, but no draft has 
> appeared, yet.
> 
> 
> ----- Document Completion Guesstimates ------
> 
> A rough guess is 3 waves of documents:
> 
> (1) Main protocol standards.  Close technical issues at 
> December 2001 IETF
>      (or before), WG Last Call in early 2002, submit to IESG before
>      March 2002 IETF Meeting.
>      - iSCSI
>      - iSCSI Naming/Discovery
>      - FC Encapsulation
>      - FCIP
>      - iFCP
>      Last Call scheduling will be an issue, as there are at least two,
>      and possibly more 4 week (or longer) WG Last Calls required for
>      the above that probably should not overlap with each other.
> 
> (2) Supporting Protocol Documents.  Close technical issues at December
>      IETF if possible (but above documents have priority).  WG Last
>      Call to follow above, probably in March-April 2002.
>      - iSCSI Boot
>      - iSCSI SLP
>      - FCIP SLP
>      - iSNS
>      iSNS Last Call should not overlap iSCSI Last Calls, 
> hence at least
>      two will be needed, but 2 week WG Last Call periods 
> should suffice
>      for these documents.
> 
> (3) MIBs.  To follow supporting documents.  Final opportunity 
> to discuss
>      at March 2002 IETF Meeting, with WG Last Call to follow shortly
>      thereafter.
>      - iSCSI MIB
>      - FCIP MIB
>      - iFCP MIB
>      - iSNS MIB
>      Probably need two Last Call periods, but again, 2 weeks each
>      should be sufficient.  May move Last Call schedule up if
>      MIBs are ready to go earlier (e.g., after December 2001 IETF
>      meeting).
> 
> The waves will overlap in practice, but each main protocol document
> needs to make it through WG Last Call before any WG Last Calls are
> issued for documents that depend on it.  So for any protocol, wave
> (1) has to come before (2) and (3), but (2) and (3) can run in
> parallel, and the different protocols may run on different schedules.
> 
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------
> 
> 
> 


From owner-ips@ece.cmu.edu  Thu Aug 30 22:39:28 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04333
	for <ips-archive@odin.ietf.org>; Thu, 30 Aug 2001 22:39:28 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7V1IX221182
	for ips-outgoing; Thu, 30 Aug 2001 21:18:33 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mxic1.isus.emc.com ([168.159.129.100])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7V1IWP21177
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 21:18:32 -0400 (EDT)
Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <RRQ3L22G>; Thu, 30 Aug 2001 21:20:33 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD695@CORPMX14>
From: Black_David@emc.com
To: cmonia@NishanSystems.com, ips@ece.cmu.edu
Subject: RE: iFCP:PDF's with markup
Date: Thu, 30 Aug 2001 21:12:11 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Only "as well as", not "in lieu of", as Ralph said.  --David

> -----Original Message-----
> From: Charles Monia [mailto:cmonia@NishanSystems.com]
> Sent: Wednesday, August 29, 2001 6:19 PM
> To: Ips (E-mail)
> Subject: iFCP:PDF's with markup
> 
> 
> Hi:
> 
> Sorry if this has been asked before.  For a rev of an 
> evolving draft, is it
> ok to submit a PDF file with change bars to the archive as 
> well as (or in
> lieu of) the txt file?
> 
> Charles
> Charles Monia
> Senior Technology Consultant
> Nishan Systems
> email: cmonia@nishansystems.com
> voice: (408) 519-3986
> fax:   (408) 435-8385
>  
> 


From owner-ips@ece.cmu.edu  Fri Aug 31 00:30:19 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08066
	for <ips-archive@odin.ietf.org>; Fri, 31 Aug 2001 00:30:19 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7V2v2I25526
	for ips-outgoing; Thu, 30 Aug 2001 22:57:02 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mxic2.us.dg.com (mxic2.us.dg.com [128.221.31.40])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7V2v0P25521
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 22:57:00 -0400 (EDT)
Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19)
	id <RX0ACCH1>; Thu, 30 Aug 2001 22:54:37 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD698@CORPMX14>
From: Black_David@emc.com
To: ips@ece.cmu.edu
Subject: IKE and iSCSI Authentication
Date: Thu, 30 Aug 2001 22:50:40 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Starting a new thread to try to roll up a number of related
issues from the User vs. Machine Authentication thread and
a few others.

-- Concept of "user".

This has been confusing due in part to lazy/sloppy use of
terminology by yours truly.  The term "machine"
has been used to refer to IKE authentication that has a single
identity associated with the network interface (i.e., IP address).
Finer grain authentication at a higher level has been referred
to as "user" authentication by analogy to remote access via
ppp/l2tp/ipsec, where a "machine" is authenticated by IKE
and a "user" is authenticated by ppp.  For iSCSI, we do have
a need to authenticate at a finer grain than one entity per
network interface, but "user" is a poor choice of word for
that.

-- Need for finer grain authentication than "machine"

As noted earlier, IKE starts up in response to the TCP SYN
packet being queued for transmission to set up a TCP connection
for iSCSI.  IKE intercepts that packet and completes its
its authentication and SA setup before allowing that packet
to continue on its way (over the SA that was just set up).
Hence IKE can't know what the iSCSI Initiator and
Target names are.  The usual result is that the IPsec
implementation behind a single network interface has a
single identity.  We went to great efforts in iSCSI to allow
multiple Initiators and Targets to share IP addresses, and
hence if there's any authentication associated with those
names, some other authentication mechanism is required that
occurs at a later stage and higher level than IKE (i.e.,
iSCSI inband authentication).

-- Need for authentication management

A careful reader of RFC 2401 will note the ability to inject
Name information into an IPsec SPD, and if one is careful about
having Initiators or Targets that one wants to distinguish be
associated with different OS user identities, this can be made
to work when IPsec is on the same system as the Initiator or
Target (it won't work with an outboard security gateway).  This
is not the best approach in many cases because it requires IKE
keying material (a certificate or pre-shared key) per identity
and these things are at best clumsy to administer.

Due to the complexities involved in administering even the best
IPsec systems, I expect to see deployments in which IPsec and IKE
are simply not used, or the authentication is very coarse.  One
could load the same pre-shared key or certificate into multiple
systems so that the IKE authentication only establishes that both
systems are members of some "ok" group, and then another mechanism
is used to determine who can actually access what - inband
authentication provides that mechanism.  The SRP mechanism is easy
to set up in situations where one does not want to run IKE, and
the other mechanisms are motivated by integration into existing
scalable centrally managed authentication systems - Kerberos,
CHAP (RADIUS), SPKM* (PKI).

-- That "tape" example

Obviously, I didn't explain this well, because nobody seems to
understand it.  Consider a SAN-accessible tape drive that is
sequentially shared by multiple hosts for backup.  To claim
that the operating systems own the tape drive misses the point
here - the multiple OSs will allow multiple backups from different
systems to the same drive to start at the same time, and the result
will be chaos.  One plausible alternative view is that the SAN
owns the tape drive, in which case authentication to the drive
can be used to control who can access it when, and the backup
application is the obvious entity to authenticate.  Some backup
applications have application-specific solutions to this problem
that work among cooperating entities (i.e., each instance of the backup
app knows that it has to ask permission) - requiring authentication
can keep out the uncooperative entities that won't bother asking
for permission.

-- iSCSI names and authentication identities

One could certainly use the same string as the iSCSI Initiator or
Target name and the userid used to do inband authentication, but
requiring that forces those strings into the existing authentication
systems that we'd like to live with.  The alternative of associating
userids from those systems with iSCSI authentication information
should be allowed to avoid forcing this.  John complains mightily
about the required translation, forgetting that there already has
to be a table indicating which Initiators are allowed to access
each Target; adding a userid column (or even a list) to this table
is a minor addition for the benefit of being able to reuse the
existing authentication infrastructure.  Pierre's suggestion of
issuing a certificate for every iSCSI initiator and target seems
to prevent reuse of existing certificates that were already issued
for some other reason, and that seems very wrong given the administrative
difficulties already posed by certificate issuance and management.
Mark's example of wanting to reuse his login ID on a local RADIUS
server (which is highly unlikely to meet the uniqueness requirements
of iSCSI Initiator and Target names) is a related situation in which
this forcing causes problems.

I'll stop here - I think I've caught most of the major points.
Comments?

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


From owner-ips@ece.cmu.edu  Fri Aug 31 00:34:19 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08119
	for <ips-archive@odin.ietf.org>; Fri, 31 Aug 2001 00:34:18 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7V38S926167
	for ips-outgoing; Thu, 30 Aug 2001 23:08:28 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mxic1.isus.emc.com ([168.159.129.100])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7V38LP26160
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 23:08:21 -0400 (EDT)
Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <RRQ3LKG4>; Thu, 30 Aug 2001 23:10:23 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD699@CORPMX14>
From: Black_David@emc.com
To: ssenum@cisco.com, ips@ece.cmu.edu
Subject: iSCSI names on login - consensus call
Date: Thu, 30 Aug 2001 23:02:00 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Yesterday, Steve Senum suggested:

> 2. Requiring Initiator and (if not a discovery session)
>    Target names on login command, so they are always
>    available if needed by the initial phase.

This definitely simplifies login, as the target no longer
has to check for the absence of the names and ask for them
if they are necessary.  Given the selection of IKE for
keying, the security concerns about always sending
the names are no longer valid - if the names need to
be hidden, an encrypted IPsec SA should be set
up by IKE (and Main Mode should be used if the IKE
identities also need to be hidden).

Based on discussion since Steve's post, I believe the
rough consensus of the IPS WG is to require the names on
the login command.  Julian Satran's disagreement with this
is noted - anyone else who objects should post to the
list and include a cogent technical rationale for the
objection.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


From owner-ips@ece.cmu.edu  Fri Aug 31 00:34:40 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08130
	for <ips-archive@odin.ietf.org>; Fri, 31 Aug 2001 00:34:40 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7V3CL026322
	for ips-outgoing; Thu, 30 Aug 2001 23:12:21 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7V3CKP26318
	for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 23:12:20 -0400 (EDT)
Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <RNJ8958P>; Thu, 30 Aug 2001 23:12:15 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD69A@CORPMX14>
From: Black_David@emc.com
To: ips@ece.cmu.edu
Subject:  iSCSI: Proxies - Consensus Call
Date: Thu, 30 Aug 2001 23:06:01 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Sitting on my to-do list from before the interim meeting
was the following consensus call.

Based on discussion on the list since my post on iSCSI Proxies
last week, I believe the rough consensus of the IPS WG is that
the iSCSI protocol should not include any support for proxies
beyond the calculation of separate CRCs on header and data.
Anyone who objects should post to the list with a cogent
technical rationale for the objection.

A consequence of this consensus call is that status code
0103 - Proxy Required will be removed if this consensus call
stands.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


From owner-ips@ece.cmu.edu  Fri Aug 31 01:49:49 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14047
	for <ips-archive@odin.ietf.org>; Fri, 31 Aug 2001 01:49:49 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7V4Ofs29472
	for ips-outgoing; Fri, 31 Aug 2001 00:24:41 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e34.bld.us.ibm.com (e34.co.us.ibm.com [32.97.110.132])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7V4OeP29466
	for <ips@ece.cmu.edu>; Fri, 31 Aug 2001 00:24:40 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e34.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id AAA28302;
	Fri, 31 Aug 2001 00:22:27 -0400
Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7V4NMD93268;
	Thu, 30 Aug 2001 22:23:22 -0600
X-Priority: 1 (High)
Importance: Normal
Subject: Re: IKE and iSCSI Authentication
To: Black_David@emc.com
Cc: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OFD74AAE34.3C792950-ON88256AB9.0016C17B@boulder.ibm.com>
From: "John Hufferd" <hufferd@us.ibm.com>
Date: Thu, 30 Aug 2001 21:22:41 -0700
X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at
 08/30/2001 10:23:22 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


David,
I agree with most of what you said, but not comfortable with the Tape
Application that you address,  but it is NOT important that we agree on
this at this time.

I really did understand what it take to associate the iSCSI Initiator Name
with the UserID.  I said that an tight binding table was needed.  I also
said that you have to be sure that it is kept in sync with the
Installations User/Password Database/Directory.  You did not refute that,
just attempted to trivialize the relationship table that needs to be built.

We have never address this Table as part of iSCSI before, and it is
important that everyone understands this, and that we understand how it is
to be kept in sync with the installations User/Password Directory.  As part
of doing this, we need to really understand what directories prevent our
use of iSCSI Node Names, and which permit it.  We need to understand if it
is possible to have more then one UserID associated with a single iSCSI
Node Name, etc.

The point is, this is all new information and has not been discussed, and
no expert in UserID Directories have had a chance to tell us their
thoughts.  This needs to be completely understood (especially since it is
not documented anywhere in our iSCSI Documents), and most folks on this
Reflector did not have a clue about it.

Discussions and thoughts about this is what I have been trying to get
going.  I would not like this to fade into the background until it is fully
reviewed and commented upon.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com


Black_David@emc.com@ece.cmu.edu on 08/30/2001 07:50:40 PM

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  IKE and iSCSI Authentication



Starting a new thread to try to roll up a number of related
issues from the User vs. Machine Authentication thread and
a few others.

-- Concept of "user".

This has been confusing due in part to lazy/sloppy use of
terminology by yours truly.  The term "machine"
has been used to refer to IKE authentication that has a single
identity associated with the network interface (i.e., IP address).
Finer grain authentication at a higher level has been referred
to as "user" authentication by analogy to remote access via
ppp/l2tp/ipsec, where a "machine" is authenticated by IKE
and a "user" is authenticated by ppp.  For iSCSI, we do have
a need to authenticate at a finer grain than one entity per
network interface, but "user" is a poor choice of word for
that.

-- Need for finer grain authentication than "machine"

As noted earlier, IKE starts up in response to the TCP SYN
packet being queued for transmission to set up a TCP connection
for iSCSI.  IKE intercepts that packet and completes its
its authentication and SA setup before allowing that packet
to continue on its way (over the SA that was just set up).
Hence IKE can't know what the iSCSI Initiator and
Target names are.  The usual result is that the IPsec
implementation behind a single network interface has a
single identity.  We went to great efforts in iSCSI to allow
multiple Initiators and Targets to share IP addresses, and
hence if there's any authentication associated with those
names, some other authentication mechanism is required that
occurs at a later stage and higher level than IKE (i.e.,
iSCSI inband authentication).

-- Need for authentication management

A careful reader of RFC 2401 will note the ability to inject
Name information into an IPsec SPD, and if one is careful about
having Initiators or Targets that one wants to distinguish be
associated with different OS user identities, this can be made
to work when IPsec is on the same system as the Initiator or
Target (it won't work with an outboard security gateway).  This
is not the best approach in many cases because it requires IKE
keying material (a certificate or pre-shared key) per identity
and these things are at best clumsy to administer.

Due to the complexities involved in administering even the best
IPsec systems, I expect to see deployments in which IPsec and IKE
are simply not used, or the authentication is very coarse.  One
could load the same pre-shared key or certificate into multiple
systems so that the IKE authentication only establishes that both
systems are members of some "ok" group, and then another mechanism
is used to determine who can actually access what - inband
authentication provides that mechanism.  The SRP mechanism is easy
to set up in situations where one does not want to run IKE, and
the other mechanisms are motivated by integration into existing
scalable centrally managed authentication systems - Kerberos,
CHAP (RADIUS), SPKM* (PKI).

-- That "tape" example

Obviously, I didn't explain this well, because nobody seems to
understand it.  Consider a SAN-accessible tape drive that is
sequentially shared by multiple hosts for backup.  To claim
that the operating systems own the tape drive misses the point
here - the multiple OSs will allow multiple backups from different
systems to the same drive to start at the same time, and the result
will be chaos.  One plausible alternative view is that the SAN
owns the tape drive, in which case authentication to the drive
can be used to control who can access it when, and the backup
application is the obvious entity to authenticate.  Some backup
applications have application-specific solutions to this problem
that work among cooperating entities (i.e., each instance of the backup
app knows that it has to ask permission) - requiring authentication
can keep out the uncooperative entities that won't bother asking
for permission.

-- iSCSI names and authentication identities

One could certainly use the same string as the iSCSI Initiator or
Target name and the userid used to do inband authentication, but
requiring that forces those strings into the existing authentication
systems that we'd like to live with.  The alternative of associating
userids from those systems with iSCSI authentication information
should be allowed to avoid forcing this.  John complains mightily
about the required translation, forgetting that there already has
to be a table indicating which Initiators are allowed to access
each Target; adding a userid column (or even a list) to this table
is a minor addition for the benefit of being able to reuse the
existing authentication infrastructure.  Pierre's suggestion of
issuing a certificate for every iSCSI initiator and target seems
to prevent reuse of existing certificates that were already issued
for some other reason, and that seems very wrong given the administrative
difficulties already posed by certificate issuance and management.
Mark's example of wanting to reuse his login ID on a local RADIUS
server (which is highly unlikely to meet the uniqueness requirements
of iSCSI Initiator and Target names) is a related situation in which
this forcing causes problems.

I'll stop here - I think I've caught most of the major points.
Comments?

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------





From owner-ips@ece.cmu.edu  Fri Aug 31 01:50:47 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14192
	for <ips-archive@odin.ietf.org>; Fri, 31 Aug 2001 01:50:47 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7V4Sjk29680
	for ips-outgoing; Fri, 31 Aug 2001 00:28:45 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7V4SfP29675
	for <ips@ece.cmu.edu>; Fri, 31 Aug 2001 00:28:41 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id GAA54468
	for <ips@ece.cmu.edu>; Fri, 31 Aug 2001 06:28:34 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7V4SX5138242
	for <ips@ece.cmu.edu>; Fri, 31 Aug 2001 06:28:33 +0200
Importance: Normal
Subject: Re: iSCSI names on login - consensus call
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF379C2608.CBC0DCF3-ONC2256AB9.0017E95C@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Fri, 31 Aug 2001 07:27:01 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 31/08/2001 07:28:33
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

David,

You might as well call a consensus "blowing away an old session when asked
to do so".
I think that it is a bad decision but I failed to convince the list that it
is so.  Please note for the record
my strong opposition.

Julo



Black_David@emc.com@ece.cmu.edu on 31-08-2001 06:02:00

Please respond to Black_David@emc.com

Sent by:  owner-ips@ece.cmu.edu


To:   ssenum@cisco.com, ips@ece.cmu.edu
cc:
Subject:  iSCSI names on login - consensus call



Yesterday, Steve Senum suggested:

> 2. Requiring Initiator and (if not a discovery session)
>    Target names on login command, so they are always
>    available if needed by the initial phase.

This definitely simplifies login, as the target no longer
has to check for the absence of the names and ask for them
if they are necessary.  Given the selection of IKE for
keying, the security concerns about always sending
the names are no longer valid - if the names need to
be hidden, an encrypted IPsec SA should be set
up by IKE (and Main Mode should be used if the IKE
identities also need to be hidden).

Based on discussion since Steve's post, I believe the
rough consensus of the IPS WG is to require the names on
the login command.  Julian Satran's disagreement with this
is noted - anyone else who objects should post to the
list and include a cogent technical rationale for the
objection.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------





From owner-ips@ece.cmu.edu  Fri Aug 31 01:51:31 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14292
	for <ips-archive@odin.ietf.org>; Fri, 31 Aug 2001 01:51:31 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7V4qQM00585
	for ips-outgoing; Fri, 31 Aug 2001 00:52:26 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7V4qPP00581
	for <ips@ece.cmu.edu>; Fri, 31 Aug 2001 00:52:25 -0400 (EDT)
Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100])
	by atlrel1.hp.com (Postfix) with ESMTP id 6BA8D534
	for <ips@ece.cmu.edu>; Fri, 31 Aug 2001 00:52:21 -0400 (EDT)
Received: from rose.hp.com (pal1nai160128.nsr.hp.com [15.244.160.128]) by core.rose.hp.com with ESMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id VAA18541 for <ips@ece.cmu.edu>; Thu, 30 Aug 2001 21:53:34 -0700 (PDT)
Message-ID: <3B8F1925.DA641AA6@rose.hp.com>
Date: Thu, 30 Aug 2001 21:57:09 -0700
From: "Mallikarjun C." <cbm@rose.hp.com>
Reply-To: cbm@rose.hp.com
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: ips@ece.cmu.edu
Subject: Re: iSCSI: definition of TSID (2.11.4 of draft 07)
References: <OF1F698899.0CFFEBFA-ON88256AB7.005139BA@boulder.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Jim,

Sorry, I was travelling, so couldn't get back sooner.  Let me say first 
off that I am not disagreeing with you, only suggesting more explicit
wording.

I see that the text you sent offline does contain "assumption A" stated
explicitly - thanks.  I believe that's necessary since one could very
well
attach new connections to an existing SSID when its uniqueness is
maintained
between just the target portal group and the initiator. 

I am still though missing the rationale for mandating uniqueness of SSID
between the target (across all portals) and initiator.  I assume target 
knows the portal group based on which IP address the login arrives on - 
eventhough not explicitly carried in the payload.

Coming to my harping on the nexus identifier, there are two reasons -
    -  It seems to provide a nice rationale for the above issue (refer
       to my previous mail at the bottom on how).  Please set me
straight
       if I am totally ignoring something I shouldn't.
    -  You stated that iSCSI is the first transport which opens the 
       possibility of "parallel nexus" and so iSCSI mandates
implementations
       not to allow it - but appears to stop short of specifying an
       identifier/means to enforce this mandatory requirement.  May be
       it's just me who is troubled by this...

Regards.
-- 
Mallikarjun 

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

       
Jim Hafner wrote:
> 
> Mallikarjun,
> 
> There are two assumptions that go into the model and requirements (as I see
> it).  One is currently implicit in draft-07 and is an iSCSI issue, the
> other is a bit more explicit and is a SCSI issue with iSCSI implications.
> These are
> 
> A) (Uniqueness of SIDs) Between a given iSCSI Initiator Node and iSCSI
> Target Node there can be only one session with a given SID.  [This is
> implied by the language that says that a login attempt that uses an
> existing SID=ISID||TSID is an attempt to *add* a connection to the existing
> session. (This is the response I got from Julian when I suggested making
> this explicit.)
> 
> B) (No parallel I_T nexus) Between a given SCSI Initiator Port and SCSI
> Target Port there can be only one nexus.  [With the definition of SCSI
> Initiator Port as the endpoint of a session identified by iSCSI Initiator
> Name + ISID, and with the definition of the SCSI Target Port as the target
> portal group identified by the iSCSI Target Name + portal group tag, we get
> the ISID RULE as stated (or intended) in the draft.]
> 
> The minimalist requirement is to meet the these two rules (assumptions).
> 
> There is a typo in the text you quote.  It should read "The TSID name space
> of the iSCSI Target should be partitioned among the target portal groups".
> But as we've discussed this really less of a requirement than it is a
> desirable "note to implementers" (and I'm going to propose that this sort
> of text move to that section).
> 
> In what you say below, the "no parallel nexus" (assumption B) is enforced
> by the ISID RULE.  Assumption A (uniquely identified sessions) is enforced
> if the target does the right thing when selecting a TSID *to pair with* an
> ISID.  My text for the definition of TSID simply says that the target
> should find a new TSID that enforces Assumption A (no more and no less).
> All the stuff about partitioning name space belongs in "notes to
> implementers".  So, between my proposed definition of TSID and the ISID
> RULE, both assumptions are satisfied and the model works.  No finer
> restrictions are required *by the model*.
> 
> Note that in all this description, we haven't had to provide a formal
> definition of "nexus identifier".
> The reason is two fold.  First, independent of what we might use to
> identify them, the I_T nexus is defined as a relationship between a SCSI
> Initiator Port and a SCSI Target Port.  Assumption B says we can't have two
> such relationships active at one time.  As I've noted above, the ISID RULE
> enforces that.  Second, the nexus identifier doesn't get used in SAM-2
> explicitly anyway and in SAM-3 it will probably be "up to the transport to
> define AND relative to the viewpoint of the initiator or target".  That
> last part means that the nexus identifier may not need a globally unique
> value, but may depend on whose end of the nexus you're looking from.  E.g.,
> the target side need only track the "relative target port" and need not
> care about the external address/name/identifier of that port when defining
> its value for the nexus identifier.  In short, the nexus identifier issue
> is tangential (and we can safely skip it formally).
> 
> Jim Hafner
> 
> [P.S. See also the proposed rewrite of the relevant draft sections in the
> stuff I sent you off-line, as well, and see if that doesn't help clarify.]
> 
> "Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on 08/28/2001 06:20:16 pm
> 
> Please respond to cbm@rose.hp.com
> 
> Sent by:  owner-ips@ece.cmu.edu
> 
> To:   ips@ece.cmu.edu
> cc:
> Subject:  RE: iSCSI: definition of TSID (2.11.4 of draft 07)
> 
> Jim,
> 
> Thanks for the explanation.
> 
> >The model says that the *combination of ISID || TSID* has to be unique
> >between a given initiator and a given target.
> 
> Actually, I do not find this formulation stated anywhere
> in rev07.
> 
> The closest about TSID assignment policy is this sentence
> in section 1.5.3: "The TSID name space of the iSCSI Initiator
> should be partitioned among the target portal groups."
> My earlier comments were based on this quote.
> 
> More importantly, let me try to understand the reasoning
> behind this formulation.  The only reason that I could come
> up with is to preclude a "parallel nexus".  In our previous
> conversation, we identified two types of nexus ids for this
> enforcement - a)InitiatorName-ISID-TargetName-TargetPortalGroupTag
> b)SSID-InitiatorName-TargetName.  By choosing the stated
> formulation (in conjunction with the ISID RULE), are you
> attempting to ensure that a parallel nexus cannot be created
> if one goes with either definition?
> 
> Thanks.
> --
> Mallikarjun
> 
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> MS 5668   Hewlett-Packard, Roseville.
> cbm@rose.hp.com
> 
> >Mallikarjun,
> >
> >What you suggest is *more* than is required for uniqueness!  Again, that's
> >an implementation choice that goes beyond the model.
> >
> >The model says that the *combination of ISID || TSID* has to be unique
> >between a given initiator and a given target.
> >When you say " If there are multiple sessions with an initiator, each
> would
> >anyway be assigned a different TSID"  you are assuming that the TSID alone
> >provide the uniqueness (between a pair).   It can, but it's more than is
> >necessary.
> >
> >In short, you're still selecting an implementation.   Here's two other
> >implementations.  Suppose I have exactly one Target Portal Group.  Then I
> >can meet the uniqueness requirements by (a) enforcing the ISID RULE and
> (b)
> >using TSID=1 *for every session*!  This one is "minimalist" with respect
> to
> >the model.  (Because there is only one portal group, I can leverage the
> >uniqueness of the ISID to meet the general uniqueness rule -- it's very
> >different if I have more portal groups (see note below)) The "maximalist"
> >implementation with respect to the model is (a) enforce the ISID RULE and
> >(b') use a unique TSID for each session I have regardless of initiator
> >name!
> >
> >The spec should say what is required to implement the model.  In my mind,
> >that's the rule that says the combination of ISID and TSID (the SID) must
> >be unique between a pair (initiator and target).   And that's all I'm
> >asking for in the definition of TSID.
> >
> >Jim Hafner
> >
> >Note: If I had more than one portal group, I might legitimately see the
> >same ISID (from the same initiator) come in to each portal group.  In that
> >case, I need to use a different TSID for each such occurrence.  If I say,
> >for example, that each portal group always uses it's portal group tag as
> >it's TSID (not required, just a choice), then I get uniqueness of SID's
> >again.  This is again, a minimalist implementation with respect to the
> >model.   This also gives an example of why the TSID namespace "should" be
> >partitioned between the portal groups, so they can always be sure that
> they
> >won't accidentally create an SID that is the same as an existing one.  As
> >long as the "half" of the SID one portal group generates is different from
> >the half generated by another portal group, there will be no chance of
> >collision.  [This is delegation of naming authority!!!]  The same
> principle
> >holds on the initiator side in how it generates ISIDs.
> >
> >Are we getting closer?
> >
> >"Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on 08/28/2001 04:10:24 pm
> >
> >Please respond to cbm@rose.hp.com
> >
> >Sent by:  owner-ips@ece.cmu.edu
> >
> >
> >To:   Jim Hafner/Almaden/IBM@IBMUS
> >cc:   ips@ece.cmu.edu
> >Subject:  RE: iSCSI: definition of TSID (2.11.4 of draft 07)
> >
> >
> >
> >Jim,
> >
> >I see your point about the current wording possibly suggesting
> >an implementation option.
> >
> >Can I suggest the following text:
> >
> >  The TSID is a target-assigned tag which together with the InitiatorName
> >  uniquely identifies the session within the target.
> >
> >It appears to me that it's all that's required for uniqueness, I
> >don't think we need to mention ISID here.  If there are multiple
> >sessions with an initiator, each would anyway be assigned a different
> >TSID.  What am I missing?
> >--
> >Mallikarjun
> >
> >
> >Mallikarjun Chadalapaka
> >Networked Storage Architecture
> >Network Storage Solutions Organization
> >MS 5668   Hewlett-Packard, Roseville.
> >cbm@rose.hp.com
> >
> >
> >>Marj,
> >>
> >>Comments in line (as usual...).  But for the person of few words, I'd
> >agree
> >>with just this text (your first sentence only):
> >>
> >>"The TSID is the target assigned tag for a session with a specific named
> >>initiator
> >>that, together with the ISID uniquely identifies a session with that
> >>initiator."
> >>
> >>(I moved the word "name" around because the session is with the initiator
> >>not with the name.)
> >>
> >>Jim Hafner
> >>
> >>
> >>"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
> >@ece.cmu.edu
> >>on 08/28/2001 02:46:45 pm
> >>
> >>Sent by:  owner-ips@ece.cmu.edu
> >>
> >>
> >>To:   ips@ece.cmu.edu
> >>cc:
> >>Subject:  RE: iSCSI: definition of TSID (2.11.4 of draft 07)
> >>
> >>
> >>
> >>I'm curious why you've phrased it this way.  I think of it more like;
> >>
> >>"The TSID is the target assigned tag for a session with a specific
> >>initiator
> >>name that, together with the ISID uniquely identifies a session with that
> >>initiator.
> >><JLH>
> >>I don't really see the subtle difference between this text and mine, so I
> >>guess I don't have any problem with it.  At least it doesn't bind the
> >>definition to anything SCSI'ish.
> >></JLH>
> >>
> >>However, the target MUST enforce uniqueness of the SSID for a given I_T
> >>combination (in order for login and recovery rules to make sense).
> >><JLH>
> >>I think I see what you're getting at here, but I don't think the words
> >>capture it (it looks like an incorrect use of "I_T nexus" (a SCSI thing).
> >>Do you mean:
> >>
> >>  "However, the target MUST enforce the uniqueness of the SSID [aside:
> >>isn't this 'SID'?] for sessions with a given initiator."
> >>
> >>If so, I can go with this text, but I think this is stated in other
> places
> >>and need not be here.  But I won't argue if it is also here.
> >></JLH>
> >>
> >>The TSID MAY be a unique tag for a session with a specific initiator
> >name."
> >><JLH>
> >>I don't think this belongs at all.  It is an implementation statement and
> >>so outside the scope.  It's a true statement, but I don't think it should
> >>be made explicit (especially in this part of the document -- I'd have
> less
> >>problem with this in the "Notes to Implementers" but even then it is
> >>suggesting a prefered(?) implementation).
> >></JLH>
> >>
> >>I know the last "rule" is more for convenience than to follow the
> >"modeling
> >>rules" (but that's the most straight forward way to implement TSID
> >>assignment?).  From the target viewpoint, it must first set the context
> of
> >>the initiator name, secondly the ISID.
> >><JLH>
> >>First, it's not necessarily the most straightforward way. It could
> >generate
> >>a unique TSID for every session regardless of initiator name.  That gives
> >>it a twobyte pointer to the session context.  That's a lot more efficient
> >>(perhaps) than having to also have an initiator name in that "pointer".
> >>So, if you go with your implementation, you have to index on the
> >name+TSID,
> >>and that's too big, so you need an indirect pointer to the context and at
> >>that point it doesn't really matter what the TSID is relative to other
> >>TSIDs; you can use the name + joint SID=ISID||TSID as your index (it's
> >only
> >>2 bytes more out of a possible 258!).
> >>
> >>So, I argue for no statement about implementation options, leave that to
> >>the clever programmers!
> >></JLH>
> >>
> >>Marjorie Krueger
> >>Networked Storage Architecture
> >>Networked Storage Solutions Org.
> >>Hewlett-Packard
> >>tel: +1 916 785 2656
> >>fax: +1 916 785 0391
> >>email: marjorie_krueger@hp.com
> >>
> >>> -----Original Message-----
> >>> From: Jim Hafner [mailto:hafner@almaden.ibm.com]
> >>> Sent: Tuesday, August 28, 2001 12:59 PM
> >>> To: ips@ece.cmu.edu
> >>> Subject: iSCSI: definition of TSID (2.11.4 of draft 07)
> >>>
> >>>
> >>> Folks,
> >>>
> >>> The following text defines TSID in referenced document (and with the
> >>> changes proposed by Mallikarjun):
> >>>
> >>> "The TSID is a tag that identifies the SCSI initiator port.
> >>> TSID is set by
> >>> the target.  It MUST be valid only in the final response."
> >>>
> >>> I'm trying to figure out what the TSID has to do with the
> >>> SCSI initiator
> >>> port.  As I understand it, they are completely unrelated (at an
> >>> architecture level).  In implementation may choose to use the
> >>> TSID as a
> >>> pointer to the session in a unique way across all sessions in
> >>> the target or
> >>> in a unique way across all sessions with a given named iSCSI
> >>> initiator or
> >>> it can do any number of other things.  It is, in my opinion,
> >>> unrelated to
> >>> the SCSI initiator port.
> >>>
> >>> I would propose the following alternative text:
> >>>
> >>> "The TSID is a tag set by the target that, together with the ISID,
> >>> identifies a unique session with the initiator."
> >>>
> >>> Comments?
> >>>
> >>> Jim Hafner
> >>>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> >
> >


From owner-ips@ece.cmu.edu  Fri Aug 31 02:00:33 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16137
	for <ips-archive@odin.ietf.org>; Fri, 31 Aug 2001 02:00:33 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7V4UcI29768
	for ips-outgoing; Fri, 31 Aug 2001 00:30:38 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7V4UaP29762
	for <ips@ece.cmu.edu>; Fri, 31 Aug 2001 00:30:36 -0400 (EDT)
Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <RNJ898Q9>; Fri, 31 Aug 2001 00:30:31 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD69B@CORPMX14>
From: Black_David@emc.com
To: ips@ece.cmu.edu
Subject: iSCSI: login issue - partial consensus call
Date: Fri, 31 Aug 2001 00:24:17 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

A review of this long running thread.  We started out with 
Mallikarjun's three options:

       A) Should iSCSI let it happen by default as stated above (i.e. 
          same ISID, TSID=0 always wipes out the pre-existing session 
          on target, since we are mandating it to be used only when 
          initiator sees a session failure)?
       B) Should iSCSI mandate making this intended cleanup explicit 
          by setting a bit (Say C-bit, for Clear) in the Login Command 
          PDU to prevent an accidental session cleanup with a buggy 
          initiator code? 
       C) Should iSCSI merely state that targets must ascertain 
          the connection state(s) whenever a new session creation
          attempt is made with a known ISID and TSID=0?  (sort of
          defeats the intention of the initiator wanting quicker 
          session recovery since the Login command PDU would have
          to idle till target ascertains the connection state(s)).

Based on my review of the emails, here's what I think the state
of the discussion is:

(1) I see no support for Option C.  The remaining options are A, B, and
	Julian's version of B in which the X bit is reused as the C bit.

(2) I see strong objections to the reuse of the X bit that Julian
	proposed, and no interest in it from anyone other than Julian.
	The objections are that the X bit is already heavily involved
	in error recovery and adding more semantics to it is an invitation
	to trouble. Therefore, I believe the rough consensus of the IPS
	WG is that the X bit is not to be reused in this fashion.

(3) I believe the rough consensus is that the situation being analyzed
	here can occur as a consequence of an initiator reboot (i.e.,
	if the reboot is fast with respect to the target's timeout-based
	session cleanup).

The consensus calls in (2) and (3) are over Julian Satran's proposal/
comments/objection.  Anyone else who objects to these should post to
the list.

This leaves options A and B as originally stated.  Most people seem
to be in favor of option A - the two exceptions I noticed were
Julian and Venkat.  Julian's objection can be summarized with a
couple of quotes:

> Option A is prone to "wild closing of sessions"
> Option A is clearly unacceptable as an initiator may do harm.

The wild closing of sessions seems to be based on a different
iSCSI interface with the same Initiator name using the same
ISID.  This is a definite risk as it's an area in which iSCSI
differs from Fibre Channel.  FC identifies sessions via hardware
identities which tend to be static and unique, and set by the
hardware vendor.  The iSCSI ISID is a dynamically managed
entity, and bugs in managing it across multiple interfaces 
(which may involve hardware and software from multiple
vendors) will cause this session closing problem, whereas for
it to happen in FC, the hardware identity has to be duplicated.

FWIW, I do know of an FC system that rejects duplicate logins
under some circumstances rather than implicitly destroying
the existing session, although I don't believe that behavior
can be overridden via inband means as is proposed here.

OTOH, a different OS should have different iSCSI Initiator Name,
and denial of service attacks should be foiled by proper use of
authentication.  I also tend to agree with the architectural
point of view that an initiator is in charge of its own sessions.
So, I think Julian has a point here, although some of the things
he's posted are overstated.

This is also Venkat's concern - unintentional reuse of an ISID
by the same Initiator:

> 2. There is some value in protecting an accidental use of an
> existing ISID by a second client (ISID=<existing>, TSID=0).
> This can be done with a Reject of the login attempt,

In contrast to some of the responses to Venkat, I interpret
"client" to mean another iSCSI port on the same Initiator, and
then his concern matches Julian's.  Venkat seems to think that
there's a useful distinction between boot scenarios in which
teardown of existing sessions is needed and boot scenarios
in which it's not needed  - I have no idea how to figure that
out in practice, and suspect that Marj is right when she says
that the C bit will be set all the time.  I agree that the
C bit is always set in a session recovery scenario because
the intent is to blow away the existing session.

So, I'm not ready to call consensus on the A vs. B. issue.
In hopes of making further progress, I would ask the
proponents of B (Venkat, Julian, and anyone else who thinks
this is valuable - I assume Julian prefers B to A, even if
the WG does not like using the X bit for B) to post short
answers to the following questions:

	Under what circumstances would an Initiator not set the
	C bit for option B?  What information would the Initiator use
	to decide not to set the C bit?

I apologize if this was in some of the emails and I missed
it - there were a lot of them.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


From owner-ips@ece.cmu.edu  Fri Aug 31 03:16:49 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26167
	for <ips-archive@odin.ietf.org>; Fri, 31 Aug 2001 03:16:48 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7V5cV402239
	for ips-outgoing; Fri, 31 Aug 2001 01:38:31 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7V5cDP02224
	for <ips@ece.cmu.edu>; Fri, 31 Aug 2001 01:38:13 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id HAA111722
	for <ips@ece.cmu.edu>; Fri, 31 Aug 2001 07:38:06 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7V5c55119678
	for <ips@ece.cmu.edu>; Fri, 31 Aug 2001 07:38:05 +0200
Importance: Normal
Subject: iSCSI - Login changes and the latest agreements
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF09E4CA94.762BADDA-ONC2256AB9.001E9C51@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Fri, 31 Aug 2001 08:37:23 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 31/08/2001 08:38:05
MIME-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=C2256AB9001E9C518f9e8a93df938690918cC2256AB9001E9C51"
Content-Disposition: inline
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

--0__=C2256AB9001E9C518f9e8a93df938690918cC2256AB9001E9C51
Content-type: text/plain; charset=us-ascii

Here are the latest Login changes including the new consensus items.

Julo

(See attached file: Login-changes.txt)
--0__=C2256AB9001E9C518f9e8a93df938690918cC2256AB9001E9C51
Content-type: text/plain; 
	name="Login-changes.txt"
Content-Transfer-Encoding: base64

MS4yLjMgaVNDU0kgTG9naW4NCg0KVGhlIHB1cnBvc2Ugb2YgdGhlIGlTQ1NJIGxvZ2luIGlzIHRv
IGVuYWJsZSBhIFRDUCBjb25uZWN0aW9uIGZvciBpU0NTSSB1c2UsIGF1dGhlbnRpY2F0ZSB0aGUg
cGFydGllcywgbmVnb3RpYXRlIHRoZSBzZXNzaW9uJ3MgcGFyYW1ldGVycywgb3BlbiBhIHNlY3Vy
aXR5IGFzc29jaWF0aW9uIHByb3RvY29sLCBhbmQgbWFyayB0aGUgY29ubmVjdGlvbiBhcyBiZWxv
bmdpbmcgdG8gYW4gaVNDU0kgc2Vzc2lvbi4NCiANCkEgc2Vzc2lvbiBpcyB1c2VkIHRvIGlkZW50
aWZ5IHRvIGEgdGFyZ2V0IGFsbCB0aGUgY29ubmVjdGlvbnMgd2l0aCBhIGdpdmVuIGluaXRpYXRv
ciB0aGF0IGJlbG9uZyB0byB0aGUgc2FtZSBJX1QgbmV4dXMgKFNlZSAxLjUuMiBmb3IgbW9yZSBk
ZXRhaWxzIG9uIGhvdyBhIHNlc3Npb24gcmVsYXRlcyB0byBhbiBJX1QgbmV4dXMpLg0KDQpUaGUg
dGFyZ2V0cyBsaXN0ZW4gb24gYSB3ZWxsLWtub3duIFRDUCBwb3J0IG9yIG90aGVyIFRDUCBwb3J0
IGZvciBpbmNvbWluZyBjb25uZWN0aW9ucy4gVGhlIGluaXRpYXRvciBiZWdpbnMgdGhlIGxvZ2lu
IHByb2Nlc3MgYnkgY29ubmVjdGluZyB0byB0aGF0IHdlbGwta25vd24gVENQIHBvcnQuIA0KDQpB
cyBwYXJ0IG9mIHRoZSBsb2dpbiBwcm9jZXNzLCB0aGUgaW5pdGlhdG9yIGFuZCB0YXJnZXQgTUFZ
IHdpc2ggdG8gYXV0aGVudGljYXRlIGVhY2ggb3RoZXIgYW5kIHNldCBhIHNlY3VyaXR5IGFzc29j
aWF0aW9uIHByb3RvY29sIGZvciB0aGUgc2Vzc2lvbi4gVGhpcyBjYW4gb2NjdXIgaW4gbWFueSBk
aWZmZXJlbnQgd2F5cyBhbmQgaXMgc3ViamVjdCB0byBuZWdvdGlhdGlvbi4gDQoNClNlY3VyaXR5
IGFzc29jaWF0aW9ucyBlc3RhYmxpc2hlZCBiZWZvcmUgdGhlIExvZ2luIHJlcXVlc3QgYXJlIG91
dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQgYWx0aG91Z2ggdGhleSBtYXkgcmVhbGl6
ZSBhIHJlbGF0ZWQgZnVuY3Rpb24gKGUuZy4sIGVzdGFibGlzaCBhIElQc2VjIHR1bm5lbCkuIA0K
DQpUaGUgaVNDU0kgTG9naW4gUGhhc2UgaXMgY2FycmllZCB0aHJvdWdoIExvZ2luIHJlcXVlc3Rz
IGFuZCByZXNwb25zZXMuIE9uY2Ugc3VpdGFibGUgYXV0aGVudGljYXRpb24gaGFzIG9jY3VycmVk
IGFuZCBvcGVyYXRpb25hbCBwYXJhbWV0ZXJzIGhhdmUgYmVlbiBzZXQgdGhlIGluaXRpYXRvciBt
YXkgc3RhcnQgdG8gc2VuZCBTQ1NJIGNvbW1hbmRzLiBIb3cgdGhlIHRhcmdldCBjaG9vc2VzIHRv
IGF1dGhvcml6ZSBhbiBpbml0aWF0b3IgaXMgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIGRvY3Vt
ZW50LiBBIG1vcmUgZGV0YWlsZWQgZGVzY3JpcHRpb24gb2YgdGhlIExvZ2luIFBoYXNlIGNhbiBi
ZSBmb3VuZCBpbiBjaGFwdGVyIDQuDQoNCg0KVGhlIGxvZ2luIFBEVSBpbmNsdWRlcyBhIHNlc3Np
b24gSUQgdGhhdCBpcyBjb21wb3NlZCBvZiBhbiBpbml0aWF0b3IgcGFydCBJU0lEIGFuZCBhIHRh
cmdldCBwYXJ0IFRTSUQuIEZvciBhIG5ldyBzZXNzaW9uLCB0aGUgVFNJRCBpcyBudWxsLiBBcyBw
YXJ0IG9mIHRoZSByZXNwb25zZSwgdGhlIHRhcmdldCBnZW5lcmF0ZXMgYSBUU0lELiANCg0KRHVy
aW5nIHNlc3Npb24gZXN0YWJsaXNobWVudCwgdGhlIHRhcmdldCBpZGVudGlmaWVzIHRoZSBTQ1NJ
IGluaXRpYXRvciBwb3J0ICh0aGUgIkkiIGluIHRoZSAiSV9UIG5leHVzIikgdGhyb3VnaCB0aGUg
dmFsdWUgcGFpciBJbml0aWF0b3JOYW1lIGFuZCBJU0lEIChJbml0aWF0b3JOYW1lIGlzIGRlc2Ny
aWJlZCBsYXRlciBpbiB0aGlzIHBhcnQpLiAgQW55IHN0YXRlIGFzc29jaWF0ZWQgd2l0aCB0aGUg
U0NTSSBpbml0aWF0b3IgcG9ydCB0aGF0IGlzIHBlcnNpc3RlbnQgYWNjb3JkaW5nIHRvIHRoZSBT
Q1NJIHN0YW5kYXJkcyAoZS5nLiwgcGVyc2lzdGVudCByZXNlcnZhdGlvbnMpIGlzIGFzc29jaWF0
ZWQgd2l0aCB0aGUgU0NTSSBpbml0aWF0b3IgcG9ydCBiYXNlZCBvbiB0aGlzIGlkZW50aXR5LiAg
QW55IHN0YXRlIGFzc29jaWF0ZWQgd2l0aCB0aGUgU0NTSSB0YXJnZXQgcG9ydCAodGhlICJUIiBp
biB0aGUgIklfVCBuZXh1cyIpIGlzIGlkZW50aWZpZWQgZXh0ZXJuYWxseSBieSB0aGUgVGFyZ2V0
TmFtZSBhbmQgcG9ydGFsIGdyb3VwIHRhZyAoc2VlIDEuNS4xKSBhbmQgaW50ZXJuYWxseSBpbiBh
biBpbXBsZW1lbnRhdGlvbiBkZXBlbmRlbnQgd2F5LiBBcyBJU0lEIGlzIHVzZWQgdG8gaWRlbnRp
ZnkgcGVyc2lzdGVudCBzdGF0ZSBpdCBpcyBzdWJqZWN0IHRvIHJldXNlIHJlc3RyaWN0aW9ucyAo
c2VlIDEuNS4zKS4NCg0KQmVmb3JlIGZ1bGwgZmVhdHVyZSBwaGFzZSBpcyBlc3RhYmxpc2hlZCwg
b25seSBMb2dpbiBQRFVzIGFyZSBhbGxvd2VkLiBBbnkgb3RoZXIgUERVLCB3aGVuIHJlY2VpdmVk
IGF0IGluaXRpYXRvciBvciB0YXJnZXQsIGlzIGEgcHJvdG9jb2wgZXJyb3IgYW5kIE1VU1QgcmVz
dWx0IGluIHRoZSBjb25uZWN0aW9uIGJlaW5nIHRlcm1pbmF0ZWQuDQoNClNvbWUgdGV4dCBjb21t
YW5kIHBhcmFtZXRlcnMgYXJlIGFsc28gYWxsb3dlZCBvbmx5IGluIGZ1bGwgZmVhdHVyZSBwaGFz
ZSAoZS5nLiwgU2VuZFRhcmdldHMpLiANCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N
CjIuMTIgTG9naW4gUmVxdWVzdA0KDQpBZnRlciBlc3RhYmxpc2hpbmcgYSBUQ1AgY29ubmVjdGlv
biBiZXR3ZWVuIGFuIGluaXRpYXRvciBhbmQgYSB0YXJnZXQsIHRoZSBpbml0aWF0b3IgTVVTVCBz
dGFydCBhIExvZ2luIHBoYXNlIHRvIGdhaW4gZnVydGhlciBhY2Nlc3MgdG8gdGhlIHRhcmdldCdz
IHJlc291cmNlcy4gDQoNClRoZSBMb2dpbiBQaGFzZSAoc2VlIGNoYXB0ZXIgNCkgY29uc2lzdHMg
b2YgYSBzZXF1ZW5jZSBvZiBMb2dpbiByZXF1ZXN0cyBhbmQgcmVzcG9uc2VzKSB0aGF0IGNhcnJ5
IHRoZSBzYW1lIEluaXRpYXRvciBUYXNrIFRhZy4NCg0KDQoNCg0KQnl0ZSAvICAgIDAgICAgICAg
fCAgICAgICAxICAgICAgIHwgICAgICAgMiAgICAgICB8ICAgICAgIDMgICAgICAgfA0KICAgLyAg
ICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8ICAgICAgICAgICAg
ICAgfA0KICB8NyA2IDUgNCAzIDIgMSAwfDcgNiA1IDQgMyAyIDEgMHw3IDYgNSA0IDMgMiAxIDB8
NyA2IDUgNCAzIDIgMSAwfA0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0t
LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KIDB8WHxJfCAweDAzICAgICAgfEZ8QyAwIDB8
IENOeFNHIHwgVmVyc2lvbi1tYXggICB8IFZlcnNpb24tbWluICAgfA0KICArLS0tLS0tLS0tLS0t
LS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KIDR8
IFJlc2VydmVkICAgICAgfCBEYXRhU2VnbWVudExlbmd0aCAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgfA0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t
LS0rLS0tLS0tLS0tLS0tLS0tKw0KIDh8IENJRCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg
UmVzZXJ2ZWQgICAgICAgICAgICAgICAgICAgICAgfA0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0t
LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KMTJ8IElTSUQgICAg
ICAgICAgICAgICAgICAgICAgICAgIHxUU0lEICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0K
ICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0t
LS0tLS0tLS0tKw0KMTZ8IEluaXRpYXRvciBUYXNrIFRhZyAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgfA0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t
LSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KMjB8IFJlc2VydmVkICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICArLS0tLS0t
LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0t
Kw0KMjR8IENtZFNOICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgfA0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0t
LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KMjh8IEV4cFN0YXRTTiAgIG9yICAgUmVzZXJ2ZWQg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICArLS0tLS0tLS0tLS0tLS0t
Ky0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KMzIvIFJl
c2VydmVkICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgLw0KICsvICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgLw0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0t
LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KNDgvIERhdGFTZWdtZW50IC0gTG9naW4gUGFy
YW1ldGVycyBpbiBUZXh0IENvbW1hbmQgRm9ybWF0ICAgICAgICAgLw0KICsvICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLw0KICAr
LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0t
LS0tLS0tKw0KDQoyLjEyLjEgWCAtIFJlc3RhcnQgQ29ubmVjdGlvbi9TZXNzaW9uDQoNCklmIHRo
aXMgYml0IGlzIHNldCB0byAxIHRoZW4gdGhpcyBjb21tYW5kIGlzIGFuIGF0dGVtcHQgdG8gcmVp
bnN0YXRlIGEgZmFpbGVkIGNvbm5lY3Rpb24gb3IgYSBmYWlsZWQgc2Vzc2lvbi4gDQoNCklmIFRT
SUQgaXMgbm90IDAgdGhlbiB0aGlzIGlzIGEgY29ubmVjdGlvbiByZXN0YXJ0LiBDSUQgZG9lcyBu
b3QgY2hhbmdlIGFuZCB0aGlzIGNvbW1hbmQgcGVyZm9ybXMgZmlyc3QgdGhlIGxvZ291dCBmdW5j
dGlvbiBvZiB0aGUgb2xkIGNvbm5lY3Rpb24gaWYgYW4gZXhwbGljaXQgbG9nb3V0IHdhcyBub3Qg
cGVyZm9ybWVkIGVhcmxpZXIuIEluIHNlc3Npb25zIHdpdGggYSBzaW5nbGUgY29ubmVjdGlvbiwg
dGhpcyBtYXkgaW1wbHkgdGhlIG9wZW5pbmcgb2YgYSBzZWNvbmQgY29ubmVjdGlvbiB3aXRoIHRo
ZSBzb2xlIHB1cnBvc2Ugb2YgY2xlYW5pbmctdXAgdGhlIGZpcnN0LiBUYXJnZXRzIHNob3VsZCBz
dXBwb3J0IG9wZW5pbmcgYSBzZWNvbmQgY29ubmVjdGlvbiBldmVuIHdoZW4gbm90IHN1cHBvcnRp
bmcgbXVsdGlwbGUgY29ubmVjdGlvbnMgaW4gZnVsbCBmZWF0dXJlIHBoYXNlLiAgQSByZXN0YXJ0
IGxvZ2luIGluZGljYXRlcyB0byB0aGUgdGFyZ2V0IHRoYXQgY29tbWFuZHMgbWF5IGJlIG1pc3Np
bmcgYW5kIHRoZXJlZm9yZSBpdCBNVVNUIGJlIGlzc3VlZCBhcyBhbiBpbW1lZGlhdGUgY29tbWFu
ZC4NCg0KVGhlIFggYml0IE1BWSBiZSBzZXQgb25lIE9OTFkgb24gdGhlIGZpcnN0IHJlcXVlc3Qg
b2YgdGhlIExvZ2luIHBoYXNlLg0KDQoyLjEyLjIgSSAtIEltbWVkaWF0ZSANCg0KTG9naW4gU0hP
VUxEIGJlIGlzc3VlZCBhcyBhbiBpbW1lZGlhdGUgcmVxdWVzdCAoST0xKS4NCg0KMi4xMi4zIEYg
KEZpbmFsKSBCaXQNCg0KSWYgc2V0IHRvIDEgaW5kaWNhdGVzIHRoYXQgdGhlIGluaXRpYXRvciBo
YXMgbm8gbW9yZSBwYXJhbWV0ZXJzIHRvIHNldC4NCg0KMi4xMi40IEMgKENvbnRpbnVhdGlvbikg
Qml0DQoNCklmIHNldCB0byAxIGluZGljYXRlcyB0aGF0IHRoaXMgaXMgbm90IHRoZSBmaXJzdCBM
b2dpbiByZXF1ZXN0IGluIHRoZSBMb2dpbiBQaGFzZQ0KDQoyLjEyLjUgQ054U0cNCg0KVGhyb3Vn
aCB0aGlzIGZpZWxkLCBjYWxsZWQgQ3VycmVudC1OZXh0IFN0YWdlIChDTnhTRyksIHRoZSBMb2dp
biBuZWdvdGlhdGlvbiBjb21tYW5kcyBhbmQgcmVzcG9uc2VzIGFyZSBhc3NvY2lhdGVkIHdpdGgg
YSBzcGVjaWZpYyBzdGFnZSBpbiB0aGUgc2Vzc2lvbiAoU2VjdXJpdHlOZWdvdGlhdGlvbiwgTG9n
aW5PcGVyYXRpb25hbE5lZ290aWF0aW9uLCBGdWxsUGhhc2VPcGVyYXRpb25hbE5lZ290aWF0aW9u
cykgYW5kIG1heSBpbmRpY2F0ZSB0aGUgbmV4dCBzdGFnZSB0aGV5IHdhbnQgdG8gbW92ZSB0byAo
c2VlIGNoYXB0ZXIgNCkuDQogIA0KVGhlIGN1cnJlbnQgc3RhZ2UgaXMgY29kZWQgaW4gYml0cyAw
LTEgYW5kIHRoZSBuZXh0IHN0YWdlIGluIGJpdHMgMi0zLiBUaGUgbmV4dCBzdGFnZSB2YWx1ZSBp
cyB2YWxpZCBvbmx5IHdoZW4gdGhlIEYgYml0IGlzIDEgYW5kIGNhbiBiZSBpZ25vcmVkIG90aGVy
d2lzZS4NCg0KVGhlIHN0YWdlIGNvZGVzIGFyZToNCg0KLSAwIC0gU2VjdXJpdHlOZWdvdGlhdGlv
bg0KLSAxIC0gTG9naW5PcGVyYXRpb25hbE5lZ290aWF0aW9uDQotIDMgLSBGdWxsRmVhdHVyZVBo
YXNlDQogDQoyLjEyLjYgVmVyc2lvbi1tYXgNCg0KTWF4aW11bSBWZXJzaW9uIG51bWJlciBzdXBw
b3J0ZWQuDQoNCkFsbCBMb2dpbiByZXF1ZXN0cyB3aXRoaW4gdGhlIExvZ2luIHBoYXNlIE1VU1Qg
Y2FycnkgdGhlIHNhbWUgVmVyc2lvbi1tYXguDQoNClRoZSB0YXJnZXQgTVVTVCB1c2UgdGhlIHZh
bHVlIHByZXNlbnRlZCB3aXRoIHRoZSBsb2dpbiByZXF1ZXN0IHdpdGggQz0wIGFuZCBNQVkgY2hl
Y2sgdGhlIHZhbHVlIHdoZW4gQz0xLg0KDQoyLjEyLjcgVmVyc2lvbi1taW4NCg0KTWluaW11bSBW
ZXJzaW9uIHN1cHBvcnRlZA0KVGhlIHZlcnNpb24gbnVtYmVyIG9mIHRoZSBjdXJyZW50IGRyYWZ0
IGlzIDB4Mi4NCg0KQWxsIExvZ2luIHJlcXVlc3RzIHdpdGhpbiB0aGUgTG9naW4gcGhhc2UgTVVT
VCBjYXJyeSB0aGUgc2FtZSBWZXJzaW9uLW1pbi4NCg0KVGhlIHRhcmdldCBNVVNUIHVzZSB0aGUg
dmFsdWUgcHJlc2VudGVkIHdpdGggdGhlIGxvZ2luIHJlcXVlc3Qgd2l0aCBDPTAgYW5kIE1BWSBj
aGVjayB0aGUgdmFsdWUgd2hlbiBDPTEuDQoNCjIuMTIuOCBDb25uZWN0aW9uIElEIC0gQ0lEDQoN
ClRoaXMgaXMgYSB1bmlxdWUgSUQgZm9yIHRoaXMgY29ubmVjdGlvbiB3aXRoaW4gdGhlIHNlc3Np
b24uDQoNCkFsbCBMb2dpbiByZXF1ZXN0cyB3aXRoaW4gdGhlIExvZ2luIHBoYXNlIE1VU1QgY2Fy
cnkgdGhlIHNhbWUgQ0lELg0KDQpUaGUgdGFyZ2V0IE1VU1QgdXNlIHRoZSB2YWx1ZSBwcmVzZW50
ZWQgd2l0aCB0aGUgbG9naW4gcmVxdWVzdCB3aXRoIEM9MCBhbmQgTUFZIGNoZWNrIHRoZSB2YWx1
ZSB3aGVuIEM9MS4NCg0KMi4xMi45IElTSUQNCg0KVGhpcyBpcyBhbiBpbml0aWF0b3ItZGVmaW5l
ZCBzZXNzaW9uLWlkZW50aWZpZXIuICBJdCBNVVNUIGJlIHRoZSBzYW1lIGZvciBhbGwgY29ubmVj
dGlvbnMgd2l0aGluIGEgc2Vzc2lvbi4gIEEgU0NTSSBpbml0aWF0b3IgcG9ydCBpcyB1bmlxdWVs
eSBpZGVudGlmaWVkIGJ5IHRoZSB2YWx1ZSBwYWlyIChJbml0aWF0b3JOYW1lLCBJU0lEKS4NCg0K
V2hlbiBhIHRhcmdldCBkZXRlY3RzIGFuIGF0dGVtcHQgdG8gb3BlbiBhIG5ldyBzZXNzaW9uIGJ5
IHRoZSBzYW1lIFNDU0kgaW5pdGlhdG9yIHBvcnQgKHNhbWUgSW5pdGlhdG9yTmFtZSBhbmQgSVNJ
RCkgdG8gdGhlIHNhbWUgdGFyZ2V0IHBvcnRhbCBncm91cCBpdCBNVVNUIGNsb3NlIHRoZSBvbGQg
c2Vzc2lvbiBhbmQgYSBlc3RhYmxpc2ggYSBuZXcgc2Vzc2lvbi4gDQoNCkFsbCBMb2dpbiByZXF1
ZXN0cyB3aXRoaW4gdGhlIExvZ2luIHBoYXNlIE1VU1QgY2FycnkgdGhlIHNhbWUgSVNJRC4NCg0K
VGhlIHRhcmdldCBNVVNUIHVzZSB0aGUgdmFsdWUgcHJlc2VudGVkIHdpdGggdGhlIGxvZ2luIHJl
cXVlc3Qgd2l0aCBDPTAgYW5kIE1BWSBjaGVjayB0aGUgdmFsdWUgd2hlbiBDPTEuDQoNCjIuMTIu
MTAgVFNJRA0KDQpUaGUgVFNJRCBpcyBhIHRhZyAoc2V0IGJ5IHRoZSB0YXJnZXQpIHRoYXQgdG9n
ZXRoZXIgd2l0aCB0aGUNCklTSUQgaWRlbnRpZmllcyBhIHVuaXF1ZSBzZXNzaW9uIHdpdGggdGhl
IGluaXRpYXRvci4gIE9uIGEgTG9naW4gcmVxdWVzdCBhIFRTSUQgdmFsdWUgb2YgMCBpbmRpY2F0
ZXMgYSByZXF1ZXN0IHRvIG9wZW4gYSBuZXcgc2Vzc2lvbi4NCkEgbm9uIHplcm8gVFNJRCBpbmRp
Y2F0ZXMgYSByZXF1ZXN0IHRvIGFkZCBhIGNvbm5lY3Rpb24gdG8gYW4gZXhpc3Rpbmcgc2Vzc2lv
bi4NCiANCjIuMTIuMTEgQ21kU04NCg0KQ21kU04gaXMgZWl0aGVyIHRoZSBpbml0aWFsIGNvbW1h
bmQgc2VxdWVuY2UgbnVtYmVyIG9mIGEgc2Vzc2lvbiAoZm9yIHRoZSBmaXJzdCBMb2dpbiBvZiBh
IHNlc3Npb24gLSB0aGUgImxlYWRpbmciIGxvZ2luKSBvciB0aGUgY29tbWFuZCBzZXF1ZW5jZSBu
dW1iZXIgaW4gdGhlIGNvbW1hbmQgc3RyZWFtIChlLmcuLCBpZiB0aGUgbGVhZGluZyBsb2dpbiBj
YXJyaWVzIHRoZSBDbWRTTiAxMjMgdGhlIG5leHQgY29tbWFuZCBjYXJyaWVzIHRoZSBudW1iZXIg
MTI0IGV0Yy4pLiANCg0KMi4xMi4xMiBFeHBTdGF0U04NCg0KVGhpcyBpcyBFeHBTdGF0U04gZm9y
IHRoZSBvbGQgY29ubmVjdGlvbi4NCg0KVGhpcyBmaWVsZCBpcyB2YWxpZCBvbmx5IGlmIHRoZSBM
b2dpbiByZXF1ZXN0IHJlc3RhcnRzIGEgY29ubmVjdGlvbiAoaS5lLiwgWCBiaXQgaXMgMSBhbmQg
VFNJRCBpcyBub3QgemVybykuDQoNCg0KMi4xMi4xMyBMb2dpbiBQYXJhbWV0ZXJzDQoNClRoZSBp
bml0aWF0b3IgTUFZIHByb3ZpZGUgc29tZSBiYXNpYyBwYXJhbWV0ZXJzIGluIG9yZGVyIHRvIGVu
YWJsZSB0aGUgdGFyZ2V0IHRvIGRldGVybWluZSBpZiB0aGUgaW5pdGlhdG9yIG1heSB1c2UgdGhl
IHRhcmdldCdzIHJlc291cmNlcyBhbmQgdGhlIGluaXRpYWwgdGV4dCBwYXJhbWV0ZXJzIGZvciB0
aGUgc2VjdXJpdHkgZXhjaGFuZ2UuICBUaGUgZm9ybWF0IG9mIHRoZSBwYXJhbWV0ZXJzIGlzIGFz
IHNwZWNpZmllZCBmb3IgdGhlIFRleHQgQ29tbWFuZC4gICAgS2V5cyBhbmQgdGhlaXIgZXhwbGFu
YXRpb25zIGFyZSBsaXN0ZWQgaW4gdGhlIEFwcGVuZGl4ZXMuDQoNCg0KIA0KDQoyLjEzIExvZ2lu
IFJlc3BvbnNlDQoNClRoZSBMb2dpbiBSZXNwb25zZSBpbmRpY2F0ZXMgdGhlIHByb2dyZXNzIGFu
ZC9vciBlbmQgb2YgdGhlIGxvZ2luIHBoYXNlLiAgTm90ZSB0aGF0IGFmdGVyIHNlY3VyaXR5IGlz
IGVzdGFibGlzaGVkLCB0aGUgbG9naW4gcmVzcG9uc2UgaXMgYXV0aGVudGljYXRlZC4NCg0KDQpC
eXRlIC8gICAgMCAgICAgICB8ICAgICAgIDEgICAgICAgfCAgICAgICAyICAgICAgIHwgICAgICAg
MyAgICAgICB8DQogICAvICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfCAgICAgICAgICAg
ICAgIHwgICAgICAgICAgICAgICB8DQogIHw3IDYgNSA0IDMgMiAxIDB8NyA2IDUgNCAzIDIgMSAw
fDcgNiA1IDQgMyAyIDEgMHw3IDYgNSA0IDMgMiAxIDB8DQogICstLS0tLS0tLS0tLS0tLS0rLS0t
LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rDQogMHwxfDF8IDB4
MjMgICAgICB8RnwwIDAgMHwgQ054U0cgfCBWZXJzaW9uLW1heCAgIHwgVmVyc2lvbi1hY3RpdmV8
DQogICstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0t
LS0tLS0tLS0tLS0rDQogNHwgUmVzZXJ2ZWQgICAgICB8IERhdGFTZWdtZW50TGVuZ3RoICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICB8DQogICstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t
LS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rDQogOHwgUmVzZXJ2ZWQgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICstLS0t
LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t
LS0rDQoxMnwgSVNJRCAgICAgICAgICAgICAgICAgICAgICAgICAgfFRTSUQgICAgICAgICAgICAg
ICAgICAgICAgICAgICB8DQogICstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0t
LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rDQoxNnwgSW5pdGlhdG9yIFRhc2sgVGFnICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICstLS0tLS0tLS0tLS0t
LS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rDQoyMHwg
UmVzZXJ2ZWQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICB8DQogICstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t
LSstLS0tLS0tLS0tLS0tLS0rDQoyNHwgU3RhdFNOICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICstLS0tLS0tLS0tLS0tLS0rLS0tLS0t
LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rDQoyOHwgRXhwQ21kU04g
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQog
ICstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0t
LS0tLS0tLS0rDQozMnwgTWF4Q21kU04gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICB8DQogICstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0t
Ky0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rDQozNnwgU3RhdHVzLUNsYXNzICB8IFN0
YXR1cy1EZXRhaWwgfCBSZXNlcnZlZCAgICAgICAgICAgICAgICAgICAgICB8DQogICstLS0tLS0t
LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0r
DQo0MC8gUmVzZXJ2ZWQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAvDQogKy8gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAvDQogICstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t
LS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rDQo0OHwgRGlnZXN0cyBpZiBhbnku
Li4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICstLS0t
LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t
LS0rDQogIC8gRGF0YVNlZ21lbnQgLSBMb2dpbiBQYXJhbWV0ZXJzIGluIFRleHQgQ29tbWFuZCBG
b3JtYXQgICAgICAgICAvDQogKy8gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAvDQogICstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0t
LS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rDQoNCjIuMTMuMSBGIChGaW5h
bCkgYml0DQoNCkZpbmFsIGJpdCBpcyBzZXQgdG8gMSBhcyBhbiBpbmRpY2F0b3Igb2YgZW5kIG9m
IHN0YWdlLiBJZiB0aGUgbmV4dCBzdGFnZSBwYXJ0IGluIENOeFNHIGlzIEZ1bGxGZWF0dXJlUGhh
c2UgYW5kIHRoZSBGIGJpdCBpcyBzZXQgdG8gMSB0aGVuIHRoaXMgaXMgYWxzbyB0aGUgRmluYWwg
TG9naW4gUmVzcG9uc2UgKHNlZSBjaGFwdGVyIDQpLiBBIEZpbmFsIGJpdCBvZiAwIGluZGljYXRl
cyBhICJwYXJ0aWFsIiByZXNwb25zZSwgd2hpY2ggbWVhbnMgIm1vcmUgbmVnb3RpYXRpb24gbmVl
ZGVkIi4NCg0KQSBsb2dpbiByZXNwb25zZSB3aXRoIGEgRiBiaXQgc2V0IHRvIDEgTVVTVCBOT1Qg
Y29udGFpbiBrZXk9dmFsdWUgcGFpcnMgdGhhdCBtYXkgcmVxdWlyZSBhZGRpdGlvbmFsIGFuc3dl
cnMgZnJvbSB0aGUgaW5pdGlhdG9yIHdpdGhpbiB0aGUgc2FtZSBzdGFnZS4NCg0KDQoyLjEzLjIg
VmVyc2lvbi1tYXgNCg0KVGhpcyBpcyB0aGUgaGlnaGVzdCB2ZXJzaW9uIG51bWJlciBzdXBwb3J0
ZWQgYnkgdGhlIHRhcmdldC4NCg0KQWxsIExvZ2luIHJlc3BvbnNlcyB3aXRoaW4gdGhlIExvZ2lu
IHBoYXNlIE1VU1QgY2FycnkgdGhlIHNhbWUgVmVyc2lvbi1tYXguDQoNClRoZSBpbml0aWF0b3Ig
TVVTVCB1c2UgdGhlIHZhbHVlIHByZXNlbnRlZCBhcyByZXNwb25zZSB0byB0aGUgbG9naW4gcmVx
dWVzdCB3aXRoIEM9MCBhbmQgTUFZIGNoZWNrIHRoZSB2YWx1ZSBvdGhlcndpc2UuDQoNCg0KMi4x
My4zIFZlcnNpb24tYWN0aXZlDQoNCkluZGljYXRlcyB0aGUgdmVyc2lvbiBzdXBwb3J0ZWQgKHRo
ZSBoaWdoZXN0IHZlcnNpb24gc3VwcG9ydGVkIGJ5IHRoZSB0YXJnZXQgYW5kIGluaXRpYXRvciku
IElmIHRoZSB0YXJnZXQgZG9lcyBub3Qgc3VwcG9ydCBhIHZlcnNpb24gd2l0aGluIHRoZSByYW5n
ZSBzcGVjaWZpZWQgYnkgdGhlIGluaXRpYXRvciwgdGhlIHRhcmdldCByZWplY3RzIHRoZSBsb2dp
biBhbmQgdGhpcyBmaWVsZCBpbmRpY2F0ZXMgdGhlIGxvd2VzdCB2ZXJzaW9uIHN1cHBvcnRlZCBi
eSB0aGUgdGFyZ2V0Lg0KDQpBbGwgTG9naW4gcmVzcG9uc2VzIHdpdGhpbiB0aGUgTG9naW4gcGhh
c2UgTVVTVCBjYXJyeSB0aGUgc2FtZSBWZXJzaW9uLWFjdGl2ZS4NCg0KVGhlIGluaXRpYXRvciBN
VVNUIHVzZSB0aGUgdmFsdWUgcHJlc2VudGVkIGFzIHJlc3BvbnNlIHRvIHRoZSBsb2dpbiByZXF1
ZXN0IHdpdGggQz0wIGFuZCBNQVkgY2hlY2sgdGhlIHZhbHVlIG90aGVyd2lzZS4NCg0KMi4xMy40
IFRTSUQNCg0KVGhlIFRTSUQgaXMgYSB0YWcgc2V0IGJ5IHRoZSB0YXJnZXQgdGhhdCB0b2dldGhl
ciB3aXRoIHRoZQ0KSVNJRCBpZGVudGlmaWVzIGEgdW5pcXVlIHNlc3Npb24gd2l0aCB0aGUgaW5p
dGlhdG9yLiAgSXQgTVVTVCBiZSB2YWxpZCBvbmx5IGluIHRoZSBmaW5hbCByZXNwb25zZS4NCiAN
CjIuMTMuNSBTdGF0U04NCg0KRm9yIHRoZSBmaXJzdCBMb2dpbiBSZXNwb25zZSAodGhlIHJlc3Bv
bnNlIHRvIGEgTG9naW4gUmVxdWVzdCB3aXRoIEM9MCkgdGhpcyBpcyB0aGUgc3RhcnRpbmcgc3Rh
dHVzIFNlcXVlbmNlIE51bWJlciBmb3IgdGhlIGNvbm5lY3Rpb24gKHRoZSBuZXh0IHJlc3BvbnNl
IG9mIGFueSBraW5kIHdpbGwgY2FycnkgdGhpcyBudW1iZXIgKyAxKS4gVGhpcyBmaWVsZCBpcyB2
YWxpZCBvbmx5IGlmIHRoZSBTdGF0dXMgQ2xhc3MgaXMgMC4NCg0KMi4xMy42IFN0YXR1cy1DbGFz
cyBhbmQgU3RhdHVzLURldGFpbA0KDQpUaGUgU3RhdHVzIHJldHVybmVkIGluIGEgTG9naW4gUmVz
cG9uc2UgaW5kaWNhdGVzIHRoZSBleGVjdXRpb24gc3RhdHVzIG9mIHRoZSBsb2dpbiBwaGFzZS4g
VGhlIHN0YXR1cyBpbmNsdWRlczoNCg0KU3RhdHVzLUNsYXNzIA0KU3RhdHVzLURldGFpbA0KDQpU
aGUgU3RhdHVzLUNsYXNzIGlzIHN1ZmZpY2llbnQgZm9yIGEgc2ltcGxlIGluaXRpYXRvciB0byB1
c2Ugd2hlbiBoYW5kbGluZyBlcnJvcnMsIHdpdGhvdXQgaGF2aW5nIHRvIGxvb2sgYXQgdGhlIFN0
YXR1cy1EZXRhaWwuICBUaGUgU3RhdHVzLURldGFpbCBhbGxvd3MgZmluZXItZ3JhaW5lZCBlcnJv
ciByZWNvdmVyeSBmb3IgbW9yZSBzb3BoaXN0aWNhdGVkIGluaXRpYXRvcnMsIGFzIHdlbGwgYXMg
YmV0dGVyIGluZm9ybWF0aW9uIGZvciBlcnJvciBsb2dnaW5nLg0KDQpUaGUgc3RhdHVzIGNsYXNz
ZXMgYXJlIGFzIGZvbGxvd3M6DQoNCjAgLSBTdWNjZXNzIC0gaW5kaWNhdGVzIHRoYXQgdGhlIGlT
Q1NJIHRhcmdldCBzdWNjZXNzZnVsbHkgcmVjZWl2ZWQsIHVuZGVyc3Rvb2QsIGFuZCBhY2NlcHRl
ZCB0aGUgcmVxdWVzdC4gVGhlIG51bWJlcmluZyBmaWVsZHMgKFN0YXRTTiwgRXhwQ21kU04sIE1h
eENtZFNOIGFyZSB2YWxpZCBvbmx5IGlmIFN0YXR1cy1DbGFzcyBpcyAwKS4NCg0KMSAtIFJlZGly
ZWN0aW9uIC0gaW5kaWNhdGVzIHRoYXQgZnVydGhlciBhY3Rpb24gbXVzdCBiZSB0YWtlbiBieSB0
aGUgaW5pdGlhdG9yIHRvIGNvbXBsZXRlIHRoZSByZXF1ZXN0LiBUaGlzIGlzIHVzdWFsbHkgZHVl
IHRvIHRoZSB0YXJnZXQgbW92aW5nIHRvIGEgZGlmZmVyZW50IGFkZHJlc3MuIEFsbCBvZiB0aGUg
cmVkaXJlY3Rpb24gc3RhdHVzIGNsYXNzIHJlc3BvbnNlcyBNVVNUIHJldHVybiBvbmUgb3IgbW9y
ZSB0ZXh0IGtleSBwYXJhbWV0ZXJzIG9mIHRoZSB0eXBlICJUYXJnZXRBZGRyZXNzIiwgd2hpY2gg
aW5kaWNhdGVzIHRoZSB0YXJnZXQncyBuZXcgYWRkcmVzcy4NCg0KMiAtIEluaXRpYXRvciBFcnJv
ciAtIGluZGljYXRlcyB0aGF0IHRoZSBpbml0aWF0b3IgbGlrZWx5IGNhdXNlZCB0aGUgZXJyb3Iu
IFRoaXMgTUFZIGJlIGR1ZSB0byBhIHJlcXVlc3QgZm9yIGEgcmVzb3VyY2UgZm9yIHdoaWNoIHRo
ZSBpbml0aWF0b3IgZG9lcyBub3QgaGF2ZSBwZXJtaXNzaW9uLiAgVGhlIHJlcXVlc3Qgc2hvdWxk
IG5vdCBiZSB0cmllZCBhZ2Fpbi4NCg0KMyAtIFRhcmdldCBFcnJvciAtIGluZGljYXRlcyB0aGF0
IHRoZSB0YXJnZXQgc2VlcyBubyBlcnJvcnMgaW4gdGhlIGluaXRpYXRvcpJzIGxvZ2luIHJlcXVl
c3QsIGJ1dCBpcyBjdXJyZW50bHkgaW5jYXBhYmxlIG9mIGZ1bGZpbGxpbmcgdGhlIHJlcXVlc3Qu
ICBUaGUgY2xpZW50IG1heSByZS10cnkgdGhlIHNhbWUgbG9naW4gcmVxdWVzdCBsYXRlci4NCg0K
VGhlIHRhYmxlIGJlbG93IHNob3dzIGFsbCBvZiB0aGUgY3VycmVudGx5IGFsbG9jYXRlZCBzdGF0
dXMgY29kZXMuICBUaGUgY29kZXMgYXJlIGluIGhleGFkZWNpbWFsOyB0aGUgZmlyc3QgYnl0ZSBp
cyB0aGUgc3RhdHVzIGNsYXNzIGFuZCB0aGUgc2Vjb25kIGJ5dGUgaXMgdGhlIHN0YXR1cyBkZXRh
aWwuICBUaGUgYWxsb3dhYmxlIHN0YXRlIG9mIHRoZSBGaW5hbCAoRikgYml0IGluIHJlc3BvbnNl
cyB3aXRoIGVhY2ggb2YgdGhlIGNvZGVzIGlzIGFsc28gZGlzcGxheWVkLg0KDQotLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K
U3RhdHVzICAgICAgICB8IENvZGUgfEZpbmFsfCAgIERlc2NyaXB0aW9uDQogICAgICAgICAgICAg
IHwoaGV4KSB8IGJpdCB8DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQWNjZXB0IExvZ2luICB8IDAwMDAgfCAxLzAgfCBM
b2dpbiBpcyBPSywgbW92aW5nIHRvIEZ1bGwgRmVhdHVyZQ0KICAgICAgICAgICAgICB8ICAgICAg
fCAgICAgfCBQaGFzZSBvciBMb2dpbk9wZXJhdGlvbmFsTmVnb3RpYXRpb24gDQogICAgICAgICAg
ICAgIHwgICAgICB8ICAgICB8IHN0YWdlICgqMSkNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpBdXRoZW50aWNhdGUgIHwg
MDAwMSB8IDAgICB8IFRoZSBpU0NTSSBUYXJnZXROYW1lIChJVE4pIGV4aXN0cyBhbmQgDQogICAg
ICAgICAgICAgIHwgICAgICB8ICAgICB8IGF1dGhlbnRpY2F0aW9uIHByb2NlZWRzLg0KLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0NCmlTQ1NJIFRhcmdldCAgfCAwMDAyIHwgMCAgIHwgVGhlIElUTiBtdXN0IGJlIHByb3ZpZGVk
ICANCk5hbWUgcmVxdWlyZWQgfCAgICAgIHwgICAgIHwgZm9yIGF1dGhlbnRpY2F0aW9uIHRvIHBy
b2NlZWQuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLQ0KVGFyZ2V0IE1vdmVkICB8IDAxMDEgfCAxICAgfCBUaGUgcmVxdWVz
dGVkIElUTiBoYXMgbW92ZWQNClRlbXBvcmFyaWx5ICAgfCAgICAgIHwgICAgIHwgdGVtcG9yYXJp
bHkgdG8gdGhlIGFkZHJlc3MgcHJvdmlkZWQuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGFyZ2V0IE1vdmVkICB8IDAx
MDIgfCAxICAgfCBUaGUgcmVxdWVzdGVkIElUTiBoYXMgbW92ZWQNClBlcm1hbmVudGx5ICAgfCAg
ICAgIHwgICAgIHwgcGVybWFuZW50bHkgdG8gdGhlIGFkZHJlc3MgcHJvdmlkZWQuDQotLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LQ0KSW5pdGlhdG9yICAgICB8IDAyMDAgfCAxICAgfCBNaXNjZWxsYW5lb3VzIGlTQ1NJIGluaXRp
YXRvciANCkVycm9yICAgICAgICAgfCAgICAgIHwgICAgIHwgZXJyb3JzDQotLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQXV0
aGVudGljYXRpb258IDAyMDEgfCAxICAgfCBUaGUgaW5pdGlhdG9yIGNvdWxkIG5vdCBiZQ0KRmFp
bHVyZSAgICAgICB8ICAgICAgfCAgICAgfCBzdWNjZXNzZnVsbHkgYXV0aGVudGljYXRlZC4NCi0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tDQpBdXRob3JpemF0aW9uIHwgMDIwMiB8IDEgICB8IFRoZSBpbml0aWF0b3IgaXMgbm90
IGFsbG93ZWQgYWNjZXNzDQpGYWlsdXJlICAgICAgIHwgICAgICB8ICAgICB8IHRvIHRoZSBnaXZl
biB0YXJnZXQuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLQ0KTm90IEZvdW5kICAgICB8IDAyMDMgfCAxICAgfCBUaGUgcmVx
dWVzdGVkIElUTiBkb2VzIG5vdA0KICAgICAgICAgICAgICB8ICAgICAgfCAgICAgfCBleGlzdCBh
dCB0aGlzIGFkZHJlc3MuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGFyZ2V0IFJlbW92ZWR8IDAyMDQgfCAxICAgfCBU
aGUgcmVxdWVzdGVkIElUTiBoYXMgYmVlbg0KICAgICAgICAgICAgICB8ICAgICAgfCAgICAgfCBy
ZW1vdmVkLiBObyBmb3J3YXJkaW5nIGFkZHJlc3MgaXMNCiAgICAgICAgICAgICAgfCAgICAgIHwg
ICAgIHwgcHJvdmlkZWQuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVW5zdXBwb3J0ZWQgICB8IDAyMDUgfCAxICAgfCBU
aGUgcmVxdWVzdGVkIGlTQ1NJIHZlcnNpb24gcmFuZ2UgaXMgDQpWZXJzaW9uICAgICAgIHwgICAg
ICB8ICAgICB8IG5vdCBzdXBwb3J0ZWQgYnkgdGhlIHRhcmdldC4gDQotLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KSW5pdGlh
dG9yICAgICB8IDAyMDYgfCAxICAgfCBJbnZhbGlkIFNJRCAtIG5vIG1vcmUgY29ubmVjdGlvbnMg
IA0KU0lEIGVycm9yICAgICB8ICAgICAgfCAgICAgfCBhY2NlcHRlZCANCi0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpNaXNz
aW5nICAgICAgIHwgMDIwNyB8IDEgICB8IE1pc3NpbmcgcGFyYW1ldGVycyAoZS5nLiwgaVNDU0kg
DQpwYXJhbWV0ZXIgICAgIHwgICAgICB8ICAgICB8IEluaXRpYXRvciBhbmQvb3IgVGFyZ2V0IE5h
bWUpDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLQ0KQ2FuJ3QgaW5jbHVkZSB8IDAyMDggfCAxICAgfCBUYXJnZXQgZG9lcyBu
b3Qgc3VwcG9ydCBzZXNzaW9uICANCmluIHNlc3Npb24gICAgfCAgICAgIHwgICAgIHwgc3Bhbm5p
bmcgdG8gdGhpcyBjb25uZWN0aW9uIChhZGRyZXNzKQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClNlc3Npb24gdHlwZSAg
fCAwMjA5IHwgMSAgIHwgVGFyZ2V0IGRvZXMgbm90IHN1cHBvcnQgdGhpcyB0eXBlIG9mICANCk5v
dCBzdXBwb3J0ZWQgfCAgICAgIHwgICAgIHwgb2Ygc2Vzc2lvbiAobm90IGZyb20gdGhpcyBJbml0
aWF0b3IpDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLQ0KVGFyZ2V0IEVycm9yICB8IDAzMDAgfCAxICAgfCBUYXJnZXQgaGFy
ZHdhcmUgb3Igc29mdHdhcmUgZXJyb3IuDQogICAgICAgICAgICAgIHwgICAgICB8ICAgICB8IA0K
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0NClNlcnZpY2UgICAgICAgfCAwMzAxIHwgMSAgIHwgVGhlIGlTQ1NJIHNlcnZpY2Ug
b3IgdGFyZ2V0IGlzIG5vdA0KVW5hdmFpbGFibGUgICB8ICAgICAgfCAgICAgfCBjdXJyZW50bHkg
b3BlcmF0aW9uYWwuIA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCk91dCBvZiAgICAgICAgfCAwMzAyIHwgMSAgIHwgVGhl
IHRhcmdldCBoYXMgaW5zdWZmaWNpZW50IHNlc3Npb24sIA0KUmVzb3VyY2VzICAgICB8ICAgICAg
fCAgICAgfCBjb25uZWN0aW9uLCBvciBvdGhlciByZXNvdXJjZXMuDQotLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQooKjEp
SWYgdGhlIFN0YXR1cyBpcyAiYWNjZXB0IGxvZ2luIiAoMHgwMDAwKSB0aGUgaW5pdGlhdG9yIGhh
cyBzdGF0ZWQgdGhlIGN1cnJlbnQgc3RhZ2UgYXMgTG9naW5PcGVyYXRpb25hbE5lZ290aWF0aW9u
IChhbmQgaWYgdGhlIEYgYml0IHdhcyAxIHRoZSBuZXh0IHN0YWdlIHRvIEZ1bGxGZWF0dXJlUGhh
c2UpLiBJZiB0aGUgcmVzcG9uc2UgRiBiaXQgaXMgMSAodGhlIG5leHQgc3RhZ2UgcGFydCBpcyBh
bHNvIEZ1bGxGZWF0dXJlUGhhc2UgaW4gYm90aCB0aGUgcmVxdWVzdCBhbmQgdGhlIHJlc3BvbnNl
KSB0aGUgbG9naW4gcGhhc2UgaXMgZmluaXNoZWQgYW5kIHRoZSBpbml0aWF0b3IgbWF5IHByb2Nl
ZWQgdG8gaXNzdWUgU0NTSSBjb21tYW5kcy4gSWYgdGhlIFN0YXR1cyBpcyAiYWNjZXB0IGxvZ2lu
IiAoMHgwMDAwKSBhbmQgdGhlIEYgYml0IGlzIDAsIHRoZSBpbml0aWF0b3IgbWF5IHByb2NlZWQg
dG8gbmVnb3RpYXRlIG9wZXJhdGlvbmFsIHBhcmFtZXRlcnMuDQogDQpJZiB0aGUgU3RhdHVzIENs
YXNzIGlzIG5vdCAwLCB0aGUgaW5pdGlhdG9yIGFuZCB0YXJnZXQgTVVTVCBjbG9zZSB0aGUgVENQ
IGNvbm5lY3Rpb24uIA0KDQpJZiB0aGUgdGFyZ2V0IHdpc2hlcyB0byByZWplY3QgdGhlIGxvZ2lu
IHJlcXVlc3QgZm9yIG1vcmUgdGhhbiBvbmUgcmVhc29uLCBpdCBzaG91bGQgcmV0dXJuIHRoZSBw
cmltYXJ5IHJlYXNvbiBmb3IgdGhlIHJlamVjdGlvbi4NCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0t
LS0NCjQuIExvZ2luIFBoYXNlDQoNCkluIHRoZSByZXN0IG9mIHRoaXMgY2hhcHRlciwgd2hlbmV2
ZXIgd2UgbWVudGlvbiBzZWN1cml0eSB3ZSBtZWFuIHNlY3VyaXR5IGFuZC9vciBkYXRhIGludGVn
cml0eS4NCg0KVGhlIGxvZ2luIHBoYXNlIGVzdGFibGlzaGVzIGFuIGlTQ1NJIHNlc3Npb24gYmV0
d2VlbiBpbml0aWF0b3IgYW5kIHRhcmdldC4gSXQgc2V0cyB0aGUgaVNDU0kgcHJvdG9jb2wgcGFy
YW1ldGVycywgc2VjdXJpdHkgcGFyYW1ldGVycywgYW5kIGF1dGhlbnRpY2F0ZXMgdGhlIGluaXRp
YXRvciBhbmQgdGFyZ2V0IHRvIGVhY2ggb3RoZXIuDQoNClRoZSBsb2dpbiBwaGFzZSBpcyBpbXBs
ZW1lbnRlZCB2aWEgbG9naW4gcmVxdWVzdCBhbmQgcmVzcG9uc2VzIG9ubHkuICBUaGUgd2hvbGUg
bG9naW4gcGhhc2UgaXMgY29uc2lkZXJlZCBhcyBhIHNpbmdsZSB0YXNrIGFuZCBoYXMgYSBzaW5n
bGUgSW5pdGlhdG9yIFRhc2sgVGFnIChzaW1pbGFyIHRvIHRoZSBsaW5rZWQgU0NTSSBjb21tYW5k
cykuDQoNClRoZSBsb2dpbiBwaGFzZSBzZXF1ZW5jZSBvZiBjb21tYW5kcyBhbmQgcmVzcG9uc2Vz
IHByb2NlZWRzIGFzIGZvbGxvd3M6DQoNCi0gTG9naW4gaW5pdGlhbCByZXF1ZXN0IChDIGJpdCBz
ZXQgdG8gMCkNCi0gTG9naW4gcGFydGlhbCByZXNwb25zZSAob3B0aW9uYWwpIA0KLSBNb3JlIExv
Z2luIHJlcXVlc3RzIGFuZCByZXNwb25zZXMgKG9wdGlvbmFsKQ0KLSBMb2dpbiBGaW5hbC1SZXNw
b25zZSAobWFuZGF0b3J5KQ0KDQpUaGUgaW5pdGlhbCBMb2dpbiByZXF1ZXN0IE1VU1QgaW5jbHVk
ZSB0aGUgSW5pdGlhdG9yTmFtZSBhbmQgU2Vzc2lvblR5cGUga2V5PXZhbHVlIHBhaXJzLiAgSWYg
dGhlIFNlc3Npb25UeXBlIGlzIG5vdCAiZGlzY292ZXJ5IiB0aGVuIHRoZSBpbml0aWFsIExvZ2lu
IFJlcXVlc3QgTVVTVCBhbHNvIGluY2x1ZGUgdGhlIGtleT12YWx1ZSBwYWlyIFRhcmdldE5hbWUu
DQoNClRoZSBMb2dpbiBGaW5hbC1yZXNwb25zZSBhY2NlcHRzIG9yIHJlamVjdHMgdGhlIExvZ2lu
IENvbW1hbmQuDQoNClRoZSBMb2dpbiBQaGFzZSBNQVkgaW5jbHVkZSBhIFNlY3VyaXR5TmVnb3Rp
YXRpb24gc3RhZ2UgYW5kIGEgTG9naW5PcGVyYXRpb25hbE5lZ290aWF0aW9uIHN0YWdlIGFuZCBN
VVNUIGluY2x1ZGUgYXQgbGVhc3Qgb25lIG9mIHRoZW0sIGJ1dCB0aGUgaW5jbHVkZWQgc3RhZ2Ug
TUFZIGJlIGVtcHR5LiANCg0KVGhlIGxvZ2luIHJlcXVlc3RzIGFuZCByZXNwb25zZXMgY29udGFp
biBhIGZpZWxkIHRoYXQgaW5kaWNhdGVzIHRoZSBuZWdvdGlhdGlvbiBzdGFnZSAoU2VjdXJpdHlO
ZWdvdGlhdGlvbiBvciBMb2dpbk9wZXJhdGlvbmFsTmVnb3RpYXRpb24pLiAgSWYgYm90aCBzdGFn
ZXMgYXJlIHVzZWQgdGhlIFNlY3VyaXR5TmVnb3RpYXRpb24gTVVTVCBwcmVjZWRlIHRoZSBMb2dp
bk9wZXJhdGlvbmFsTmVnb3RpYXRpb24uDQoNClNvbWUgb3BlcmF0aW9uYWwgcGFyYW1ldGVycyBj
YW4gYmUgbmVnb3RpYXRlZCBvdXRzaWRlIGxvZ2luLCB0aHJvdWdoIHRleHQgY29tbWFuZCByZXNw
b25zZS4NCiANClNlY3VyaXR5IE1VU1QgYmUgY29tcGxldGVseSBuZWdvdGlhdGVkIHdpdGhpbiB0
aGUgTG9naW4gUGhhc2Ugb3IgcHJvdmlkZWQgYnkgZXh0ZXJuYWwgbWVhbnMgKGUuZy4sIElQU2Vj
KS4NCg0KSW4gc29tZSBlbnZpcm9ubWVudHMsIGEgdGFyZ2V0IG9yIGFuIGluaXRpYXRvciBpcyBu
b3QgaW50ZXJlc3RlZCBpbiBhdXRoZW50aWNhdGluZyBpdHMgY291bnRlcnBhcnQuIEl0IGlzIHBv
c3NpYmxlIHRvIGJ5cGFzcyBhdXRoZW50aWNhdGlvbiB0aHJvdWdoIHRoZSBMb2dpbiByZXF1ZXN0
IGFuZCByZXNwb25zZS4NCg0KVGhlIGluaXRpYXRvciBhbmQgdGFyZ2V0IE1BWSB3YW50IHRvIG5l
Z290aWF0ZSBhdXRoZW50aWNhdGlvbiBhbmQgZGF0YSBpbnRlZ3JpdHkgcGFyYW1ldGVycy4gT25j
ZSB0aGlzIG5lZ290aWF0aW9uIGlzIGNvbXBsZXRlZCwgdGhlIGNoYW5uZWwgaXMgY29uc2lkZXJl
ZCBzZWN1cmUuDQoNCkF1dGhlbnRpY2F0aW9uIGFuZCBhIFNlY3VyZSBDaGFubmVsIHNldHVwIE1B
WSBiZSBwZXJmb3JtZWQgaW5kZXBlbmRlbnQgb2YgaVNDU0kgKGFzIHdoZW4gdXNpbmcgdHVubmVs
aW5nIElQU2VjIG9yIHNvbWUgaW1wbGVtZW50YXRpb25zIG9mIHRyYW5zcG9ydCBJUFNlYykgaW4g
d2hpY2ggY2FzZSB0aGUgTG9naW4gcGhhc2UgY2FuIGJlIHJlZHVjZWQgdG8gb3BlcmF0aW9uYWwg
cGFyYW1ldGVyIG5lZ290aWF0aW9ucy4NCiANCk1vc3Qgb2YgdGhlIG5lZ290aWF0aW9uIGtleXMg
YXJlIGFsbG93ZWQgb25seSBpbiBhIHNwZWNpZmljIHN0YWdlIC0gdGhlIFNlY3VyaXR5TmVnb3Rp
YXRpb24ga2V5cyBhcHBlYXIgYWxsIGluIEFwcGVuZGl4IEEgd2hpbGUgdGhlIExvZ2luT3BlcmF0
aW9uYWxOZWdvdGlhdGlvbiBrZXlzIGFwcGVhciBpbiBBcHBlbmRpeCBELg0KT25seSBhIGxpbWl0
ZWQgc2V0IG9mIGtleXMgKG1hcmtlZCBhcyBEZWNsYXJhdGl2ZSBpbiBBcHBlbmRpeCBEKSBtYXkg
YmUgdXNlZCBpbiBhbnkgb2YgdGhlIDIgc3RhZ2VzLg0KDQpBbnkgZ2l2ZW4gTG9naW4gcmVxdWVz
dCBvciByZXNwb25zZSBiZWxvbmdzIHRvIGEgc3BlY2lmaWMgc3RhZ2UgYW5kIHRoaXMgZGV0ZXJt
aW5lcyB0aGUgbmVnb3RpYXRpb24ga2V5cyBhbGxvd2VkIHdpdGggdGhlIGNvbW1hbmQgb3IgcmVz
cG9uc2UuDQoNClN0YWdlIHRyYW5zaXRpb24gaXMgcGVyZm9ybWVkIHRocm91Z2ggYSBjb21tYW5k
IGV4Y2hhbmdlIChyZXF1ZXN0L3Jlc3BvbnNlKSBjYXJyeWluZyB0aGUgRiBiaXQgYW5kIHRoZSBz
YW1lIGN1cnJlbnQgc3RhZ2UgY29kZS4gIER1cmluZyB0aGlzIGV4Y2hhbmdlLCB0aGUgbmV4dCBz
dGFnZSBzZWxlY3RlZCBpcyB0aGUgbG93ZXIgb2YgdGhlIHR3byBuZXh0IHN0YWdlIGNvZGVzLiAg
VGhlIGluaXRpYXRvciBjYW4gcmVxdWVzdCBhIHRyYW5zaXRpb24gd2hlbmV2ZXIgaXQgaXMgcmVh
ZHkgYnV0IGEgdGFyZ2V0IGNhbiByZXNwb25kIHdpdGggYSB0cmFuc2l0aW9uIG9ubHkgYWZ0ZXIg
aXQgaXMgb2ZmZXJlZCBvbmUgYnkgdGhlIGluaXRpYXRvci4NCg0KSW4gYSBuZWdvdGlhdGlvbiBz
ZXF1ZW5jZSwgdGhlIEYgYml0IHNldHRpbmdzIGluIG9uZSBwYWlyIG9mIGxvZ2luIHJlcXVlc3Qt
cmVzcG9uc2VzIGhhdmUgbm8gYmVhcmluZyBvbiB0aGUgRiBiaXQgc2V0dGluZ3Mgb2YgdGhlIG5l
eHQgcGFpci4gIEFuIGluaXRpYXRvciBoYXZpbmcgRiBiaXQgc2V0IHRvIDEgaW4gb25lIHBhaXIg
YW5kIGJlaW5nIGFuc3dlcmVkIHdpdGggYW4gRiBiaXQgc2V0dGluZyBvZiAwIG1heSBpc3N1ZSB0
aGUgbmV4dCByZXF1ZXN0IHdpdGggRiBiaXQgc2V0IHRvIDAuDQoNClN0YWdlIHRyYW5zaXRpb25z
IGR1cmluZyBsb2dpbiAoaW5jbHVkaW5nIGVudGVyaW5nIGFuZCBleGl0KSBhcmUgcG9zc2libGUg
b25seSBhcyBvdXRsaW5lZCBpbiB0aGUgZm9sbG93aW5nIHRhYmxlOg0KDQorLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQp8RnJvbSAg
ICAgVG8gLT4gICB8IFNlY3VyaXR5ICAgIHwgT3BlcmF0aW9uYWwgfCBGdWxsRmVhdHVyZSB8ICAN
CnwgIHwgICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAg
ICAgIHwgDQp8ICBWICAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAg
ICAgICAgICAgICB8DQorLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0rDQp8IChzdGFydCkgICAgICAgICB8ICB5ZXMgICAgICAgIHwgIHll
cyAgICAgICAgfCAgbm8gICAgICAgICB8ICAgDQorLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQp8IFNlY3VyaXR5ICAgICAgICB8ICBu
byAgICAgICAgIHwgIHllcyAgICAgICAgfCAgeWVzICAgICAgICB8DQorLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQp8IE9wZXJhdGlv
bmFsICAgICB8ICBubyAgICAgICAgIHwgIG5vICAgICAgICAgfCAgeWVzICAgICAgICB8DQorLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r
DQoNClRoZSBMb2dpbiBGaW5hbC1SZXNwb25zZSB0aGF0IGFjY2VwdHMgYSBMb2dpbiBDb21tYW5k
IGNhbiBjb21lIG9ubHkgYXMgYSByZXNwb25zZSB0byBhIExvZ2luIGNvbW1hbmQgd2l0aCB0aGUg
RiBiaXQgc2V0IHRvIDEgd2l0aCB0aGUgRiBiaXQgc2V0IHRvIDEgYW5kIGJvdGggdGhlIGNvbW1h
bmQgYW5kIHJlc3BvbnNlIE1VU1QgaGF2ZSBGdWxsRmVhdHVyZVBoYXNlIGluIHRoZSBuZXh0IHN0
YWdlIHBhcnQgb2YgdGhlIENOeFNHIGZpZWxkLg0KDQoNCjQuMSBMb2dpbiBQaGFzZSBTdGFydA0K
DQpUaGUgbG9naW4gcGhhc2Ugc3RhcnRzIHdpdGggYSBsb2dpbiByZXF1ZXN0IGZyb20gdGhlIGlu
aXRpYXRvciB0byB0aGUgdGFyZ2V0LiBUaGUgaW5pdGlhbCBsb2dpbiByZXF1ZXN0IGluY2x1ZGVz
Og0KDQotUHJvdG9jb2wgdmVyc2lvbiBzdXBwb3J0ZWQgYnkgdGhlIGluaXRpYXRvciAoY3VycmVu
dGx5IDB4JzAyJykNCi1TZXNzaW9uIGFuZCBjb25uZWN0aW9uIElkcw0KLVRoZSBuZWdvdGlhdGlv
biBzdGFnZSB0aGF0IHRoZSBpbml0aWF0b3IgaXMgcmVhZHkgdG8gZW50ZXINCi1UaGUgQyBiaXQg
c2V0IHRvIDAgKGZpcnN0IGxvZ2luIHJlcXVlc3Qgb24gYSBjb25uZWN0aW9uKQ0KDQpPcHRpb25h
bGx5IHRoZSBsb2dpbiByZXF1ZXN0IG1heSBpbmNsdWRlOg0KDQotU2VjdXJpdHkvSW50ZWdyaXR5
IHBhcmFtZXRlcnMgT1INCi1pU0NTSSBvcGVyYXRpb25hbCBwYXJhbWV0ZXJzIEFORC9PUg0KLVRo
ZSBuZXh0IG5lZ290aWF0aW9uIHN0YWdlIHRoYXQgdGhlIGluaXRpYXRvciBpcyByZWFkeSB0byBl
bnRlcg0KDQpUaGUgdGFyZ2V0IGNhbiBhbnN3ZXIgdGhlIGxvZ2luIGluIHRoZSBmb2xsb3dpbmcg
d2F5czoNCg0KLUxvZ2luIFJlc3BvbnNlIHdpdGggTG9naW4gUmVqZWN0LiAgVGhpcyBpcyBhbiBp
bW1lZGlhdGUgcmVqZWN0aW9uIGZyb20gdGhlIHRhcmdldCB0aGF0IGNhdXNlcyB0aGUgc2Vzc2lv
biB0byB0ZXJtaW5hdGUuIFRoZSBGIGJpdCBvZiB0aGUgcmVzcG9uc2UgTVVTVCBiZSBzZXQgdG8g
MSBhbmQgdGhlIENOeFNHIGlzIHRvIGJlIGlnbm9yZWQNCi1Mb2dpbiBSZXNwb25zZSB3aXRoIExv
Z2luIEFjY2VwdCBhcyBhIGZpbmFsIHJlc3BvbnNlIChGIGJpdCBzZXQgdG8gMSBhbmQgdGhlIG5l
eHQgcGFydCBvZiBDTnhTRyBpbiBib3RoIGNvbW1hbmQgYSByZXNwb25zZSBhcmUgc2V0IHRvIEZ1
bGxGZWF0dXJlUGhhc2UpLiBUaGUgcmVzcG9uc2UgaW5jbHVkZXMgdGhlIHByb3RvY29sIHZlcnNp
b24gc3VwcG9ydGVkIGJ5IHRoZSB0YXJnZXQgIGFuZCB0aGUgc2Vzc2lvbiBJRCBhbmQgbWF5ICBp
bmNsdWRlIGlTQ1NJIG9wZXJhdGlvbmFsIG9yIHNlY3VyaXR5IHBhcmFtZXRlcnMgKGRlcGVuZGlu
ZyBvbiB0aGUgY3VycmVudCBzdGFnZSkuDQotTG9naW4gUmVzcG9uc2Ugd2l0aCBMb2dpbiBBY2Nl
cHQgYXMgYSBwYXJ0aWFsIHJlc3BvbnNlIGluZGljYXRpbmcgdGhlIHN0YXJ0IG9mIGEgbmVnb3Rp
YXRpb24gc2VxdWVuY2UuICBUaGUgcmVzcG9uc2UgaW5jbHVkZXMgdGhlIHByb3RvY29sIHZlcnNp
b24gc3VwcG9ydGVkIGJ5IHRoZSB0YXJnZXQgYW5kIGVpdGhlciBzZWN1cml0eS9pbnRlZ3JpdHkg
cGFyYW1ldGVycyBvciBpU0NTSSBwYXJhbWV0ZXJzICh3aGVuIG5vIHNlY3VyaXR5L2ludGVncml0
eSBtZWNoYW5pc20gaXMgY2hvc2VuKSBzdXBwb3J0ZWQgYnkgdGhlIHRhcmdldC4NCg0KSWYgdGhl
IGluaXRpYXRvciBkZWNpZGVzIHRvIGZvcmVnbyB0aGUgU2VjdXJpdHlOZWdvdGlhdGlvbiBzdGFn
ZSBpdCBpc3N1ZXMgdGhlIExvZ2luIHdpdGggdGhlIENOeFNHIHNldCB0byBMb2dpbk9wZXJhdGlv
bmFsTmVnb3RpYXRpb24gaW4gdGhlIGN1cnJlbnQgc3RhZ2UgYW5kIHRoZSB0YXJnZXQgbWF5IHJl
cGx5IHdpdGggYSBMb2dpbiBSZXNwb25zZSBpbmRpY2F0aW5nIHRoYXQgaXQgaXMgdW53aWxsaW5n
IHRvIGFjY2VwdCB0aGUgY29ubmVjdGlvbiB3aXRob3V0IFNlY3VyaXR5TmVnb3RpYXRpb24gYW5k
IHRlcm1pbmF0ZSB0aGUgY29ubmVjdGlvbi4NCg0KSWYgdGhlIGluaXRpYXRvciBpcyB3aWxsaW5n
IG5vIG5lZ290aWF0ZSBzZWN1cml0eSBidXQgaXQgaXMgdW53aWxsaW5nIHRvIG1ha2UgdGhlIGlu
aXRpYWwgcGFyYW1ldGVyIG9mZmVyIGFuZCBtYXkgYWNjZXB0IGEgY29ubmVjdGlvbiB3aXRob3V0
IHNlY3VyaXR5IGl0IGlzc3VlcyB0aGUgTG9naW4gd2l0aCB0aGUgRiBiaXQgc2V0IHRvIDEsIHRo
ZSBDTnhTRyBzZXQgdG8gU2VjdXJpdHlOZWdvdGlhdGlvbiBpbiB0aGUgY3VycmVudCBzdGFnZSBh
bmQgTG9naW5PcGVyYXRpb25hbE5lZ290aWF0aW9uIGluIHRoZSBuZXh0IHN0YWdlLiBJZiB0aGUg
dGFyZ2V0IGlzIGFsc28gcmVhZHkgdG8gZm9yZWdvIHNlY3VyaXR5IHRoZSBMb2dpbiByZXNwb25z
ZSBpcyBlbXB0eSBhbmQgaGFzIEYgYml0IGlzIHNldCB0byAxIGFuZCB0aGUgQ054U0cgc2V0IHRv
IFNlY3VyaXR5TmVnb3RpYXRpb24gaW4gdGhlIGN1cnJlbnQgc3RhZ2UgYW5kIExvZ2luT3BlcmF0
aW9uYWxOZWdvdGlhdGlvbiBpbiB0aGUgbmV4dCBzdGFnZS4NCg0KQW4gaW5pdGlhdG9yIHRoYXQg
Y2FuIG9wZXJhdGUgd2l0aG91dCBzZWN1cml0eSBhbmQgd2l0aCBhbGwgdGhlIG9wZXJhdGlvbmFs
IHBhcmFtZXRlcnMgdGFraW5nIHRoZSBkZWZhdWx0IHZhbHVlcyBpc3N1ZXMgdGhlIExvZ2luIHdp
dGggdGhlIEYgYml0IHNldCB0byAxLCB0aGUgQ054U0cgc2V0IHRvIExvZ2luT3BlcmF0aW9uYWxO
ZWdvdGlhdGlvbiBpbiB0aGUgY3VycmVudCBzdGFnZSBhbmQgRnVsbEZlYXR1cmVQaGFzZSBpbiB0
aGUgbmV4dCBzdGFnZS4gSWYgdGhlIHRhcmdldCBpcyBhbHNvIHJlYWR5IHRvIGZvcmVnbyBzZWN1
cml0eSBhbmQgTG9naW5PcGVyYXRpb25hbE5lZ290aWF0aW9uIHRoZSBMb2dpbiByZXNwb25zZSBp
cyBlbXB0eSBhbmQgaGFzIEYgYml0IGlzIHNldCB0byAxIGFuZCB0aGUgQ054U0cgc2V0IHRvIExv
Z2luT3BlcmF0aW9uYWxOZWdvdGlhdGlvbiBpbiB0aGUgY3VycmVudCBzdGFnZSBhbmQgRnVsbEZl
YXR1cmVQaGFzZSBpbiB0aGUgbmV4dCBzdGFnZS4NCg0KQSB0YXJnZXQgTUFZIHVzZSB0aGUgaVND
U0kgSW5pdGlhdG9yIE5hbWUgYXMgcGFydCBvZiBpdHMgYWNjZXNzIGNvbnRyb2wgbWVjaGFuaXNt
OyB0aGVyZWZvcmUsIHRoZSBpU0NTSSBJbml0aWF0b3IgTmFtZSBNVVNUIGJlIHNlbnQgYmVmb3Jl
IHRoZSB0YXJnZXQgaXMgcmVxdWlyZWQgdG8gZGlzY2xvc2UgaXRzIExVcy4NCg0KSWYgdGhlIGlT
Q1NJIFRhcmdldCBOYW1lIGFuZC9vciBpU0NTSSBJbml0aWF0b3IgTmFtZSBpcyBnb2luZyB0byBi
ZSB1c2VkIGluIGRldGVybWluaW5nIHRoZSBzZWN1cml0eSBtb2RlIG9yIGl0IGlzIGltcGxpY2l0
IHBhcnQgb2YgYXV0aGVudGljYXRpb24sIHRoZW4gdGhlIGlTQ1NJIFRhcmdldCBOYW1lIGFuZC9v
ciBpU0NTSSBJbml0aWF0b3IgTmFtZSBNVVNUIGJlIHNlbnQgaW4gdGhlIGxvZ2luIGNvbW1hbmQg
Zm9yIHRoZSBmaXJzdCBjb25uZWN0aW9uIG9mIGEgc2Vzc2lvbiB0byBpZGVudGlmeSB0aGUgc3Rv
cmFnZSBlbmRwb2ludCBvZiB0aGUgc2Vzc2lvbi4gSWYgc2VudCBvbiBuZXcgY29ubmVjdGlvbnMg
d2l0aGluIGFuIGV4aXN0aW5nIHNlc3Npb24gaXQgTVVTVCBiZSB0aGUgc2FtZSBhcyB0aGUgb25l
IHVzZWQgZm9yIHRoZSBsZWFkaW5nIGNvbm5lY3Rpb24uICBJZiB0aGUgaVNDU0kgVGFyZ2V0IE5h
bWUgYW5kL29yIGlTQ1NJIEluaXRpYXRvciBOYW1lIGlzIGdvaW5nIHRvIGJlIHVzZWQgb25seSBm
b3IgYWNjZXNzIGNvbnRyb2wsIGl0IGNhbiBiZSBzZW50IGFmdGVyIHRoZSBTZWN1cml0eU5lZ290
aWF0aW9uIHN0YWdlLiBBIHRhcmdldCBjYW4gYmUgYWNjZXNzZWQgd2l0aG91dCBhIFRhcmdldCBO
YW1lIG9ubHkgaWYgdGhlIHNlc3Npb24gdHlwZSBpcyBhIGRpc2NvdmVyeSBzZXNzaW9uLg0KIA0K
VGhlIGlTQ1NJIE5hbWVzIE1VU1QgYmUgaW4gdGV4dCBjb21tYW5kIGZvcm1hdC4NCg0KNC4yIGlT
Q1NJIFNlY3VyaXR5IGFuZCBJbnRlZ3JpdHkgTmVnb3RpYXRpb24NCg0KVGhlIHNlY3VyaXR5IGV4
Y2hhbmdlIHNldHMgdGhlIHNlY3VyaXR5IG1lY2hhbmlzbSBhbmQgYXV0aGVudGljYXRlcyB0aGUg
dXNlciBhbmQgdGhlIHRhcmdldCB0byBlYWNoIG90aGVyLiBUaGUgZXhjaGFuZ2UgcHJvY2VlZHMg
YWNjb3JkaW5nIHRvIHRoZSBhbGdvcml0aG1zIHRoYXQgd2VyZSBjaG9zZW4gaW4gdGhlIG5lZ290
aWF0aW9uIHBoYXNlIGFuZCBpcyBjb25kdWN0ZWQgYnkgdGhlIGxvZ2luIGFuZCB0ZXh0IGNvbW1h
bmRzIGtleT12YWx1ZSBwYXJhbWV0ZXJzLg0KDQpUaGUgbmVnb3RpYWJsZSBzZWN1cml0eSBtZWNo
YW5pc21zIGluY2x1ZGUgdGhlIGZvbGxvd2luZyBtb2RlczoNCg0KLUluaXRpYXRvci10YXJnZXQg
YXV0aGVudGljYXRpb24gLSB0aGUgaG9zdCBhbmQgdGhlIHRhcmdldCBhdXRoZW50aWNhdGUgdGhl
bXNlbHZlcyB0byBlYWNoIG90aGVyLiBBIG5lZ290aWFibGUgYWxnb3JpdGhtIHN1Y2ggYXMgS2Vy
YmVyb3MgcHJvdmlkZXMgdGhpcyBmZWF0dXJlLg0KLVBEVSBpbnRlZ3JpdHkgLSBhbiBpbnRlZ3Jp
dHkvYXV0aGVudGljYXRpb24gZGlnZXN0IGlzIGF0dGFjaGVkIHRvIGVhY2ggcGFja2V0LiAgVGhl
IGFsZ29yaXRobSBpcyBuZWdvdGlhYmxlLg0KIA0KVXNpbmcgSVBzZWMgZm9yIGVuY3J5cHRpb24g
b3IgYXV0aGVudGljYXRpb24gbWF5IGVsaW1pbmF0ZSBwYXJ0IG9mIHRoZSBzZWN1cml0eSBuZWdv
dGlhdGlvbiBhdCB0aGUgaVNDU0kgbGV2ZWwgYnV0IG5vdCBuZWNlc3NhcmlseSBhbGwuIA0KDQpJ
ZiBzZWN1cml0eSBpcyBlc3RhYmxpc2hlZCBpbiB0aGUgbG9naW4gcGhhc2UgdGhlbiBhZnRlciB0
aGUgc2VjdXJpdHkgbmVnb3RpYXRpb24gaXMgY29tcGxldGUsIGVhY2ggaVNDU0kgUERVIE1VU1Qg
aW5jbHVkZSB0aGUgYXBwcm9wcmlhdGUgZGlnZXN0IGZpZWxkIGlmIGFueS4NCg0KVGhlIG5lZ290
aWF0aW9uIHByb2NlZWRzIGFzIGZvbGxvd3M6DQoNCi1UaGUgaW5pdGlhdG9yIHNlbmRzIGEgbG9n
aW4gcmVxdWVzdCB3aXRoIGFuIG9yZGVyZWQgbGlzdCBvZiB0aGUgb3B0aW9ucyBpdCBzdXBwb3J0
cyBmb3IgZWFjaCBzdWJqZWN0IChhdXRoZW50aWNhdGlvbiBhbGdvcml0aG0sIGlTQ1NJIHBhcmFt
ZXRlcnMgYW5kIHNvIG9uKS4gVGhlIG9wdGlvbnMgYXJlIGxpc3RlZCBpbiB0aGUgaW5pdGlhdG9y
J3Mgb3JkZXIgb2YgcHJlZmVyZW5jZS4gDQotVGhlIHRhcmdldCBNVVNUIHJlcGx5IHdpdGggdGhl
IGZpcnN0IG9wdGlvbiBpbiB0aGUgbGlzdCBpdCBzdXBwb3J0cyBhbmQgaXMgYWxsb3dlZCBmb3Ig
dGhlIHNwZWNpZmljIGluaXRpYXRvci4gIFRoZSBwYXJhbWV0ZXJzIGFyZSBlbmNvZGVkIGluIFVU
RjggYXMga2V5PXZhbHVlLiAgVGhlIGluaXRpYXRvciBNQVkgYWxzbyBzZW5kIHByb3ByaWV0YXJ5
IG9wdGlvbnMuIFRoZSAibm9uZSIgb3B0aW9uLCBpZiBhbGxvd2VkLCBNVVNUIGJlIGluY2x1ZGVk
IGluIHRoZSBsaXN0LCB3aGljaCBpbmRpY2F0ZXMgdGhhdCBubyBhbGdvcml0aG0gaXMgc3VwcG9y
dGVkIGJ5IHRoZSB0YXJnZXQuIEZvciBhIGxpc3Qgb2Ygc2VjdXJpdHkgcGFyYW1ldGVycyBzZWUg
QXBwZW5kaXggQS4NCg0KLVRoZSBpbml0aWF0b3IgbXVzdCBiZSBhd2FyZSBvZiB0aGUgaW1taW5l
bnQgY29tcGxldGlvbiBvZiB0aGUgU2VjdXJpdHlOZWdvdGlhdGlvbiBzdGFnZSBhbmQgTVVTVCBz
ZXQgdGhlIEYgYml0IHRvIDEgYW5kIHRoZSBuZXh0IHN0YWdlIHBhcnQgb2YgQ054U0cgdG8gd2hh
dCBpdCB3b3VsZCBsaWtlIHRoZSBuZXh0IHN0YWdlIHRvIGJlLiBUaGUgdGFyZ2V0IHdpbGwgYW5z
d2VyIHdpdGggYSBMb2dpbiByZXNwb25zZSB3aXRoIHRoZSBGIGJpdCBzZXQgdG8gMSBhbmQgdGhl
IG5leHQgc3RhZ2UgcGFydCBvZiBDTnhTRyB0byB3aGF0IGl0IHdvdWxkIGxpa2UgdGhlIG5leHQg
c3RhZ2UgdG8gYmUuIFRoZSBuZXh0IHN0YWdlIHNlbGVjdGVkIHdpbGwgYmUgdGhlICJsb3dlciIg
b2YgdGhlIHR3by4gSWYgdGhlIG5leHQgc3RhZ2UgaXMgRnVsbEZlYXR1cmVQaGFzZSwgdGhlIHRh
cmdldCBNVVNUIHJlc3BvbmQgd2l0aCBhIExvZ2luIFJlc3BvbnNlIHdpdGggdGhlIFNlc3Npb24g
SUQgYW5kIHRoZSBwcm90b2NvbCB2ZXJzaW9uLiANCg0KDQpBbGwgUERVcyBzZW50IGFmdGVyIHRo
ZSBzZWN1cml0eSBuZWdvdGlhdGlvbiBzdGFnZSBNVVNUIGJlIGJ1aWx0IHVzaW5nIHRoZSBhZ3Jl
ZWQgc2VjdXJpdHkuIA0KDQpJZiB0aGUgc2VjdXJpdHkgbmVnb3RpYXRpb24gZmFpbHMgYXQgdGhl
IHRhcmdldCB0aGVuIHRoZSB0YXJnZXQgTVVTVCBzZW5kIHRoZSBhcHByb3ByaWF0ZSBMb2dpbiBS
ZXNwb25zZSBQRFUuICBJZiB0aGUgc2VjdXJpdHkgbmVnb3RpYXRpb24gZmFpbHMgYXQgdGhlIGlu
aXRpYXRvciwgdGhlIGluaXRpYXRvciBzaGFsbCBkcm9wIHRoZSBjb25uZWN0aW9uLiANCg0KNC4z
IE9wZXJhdGlvbmFsIFBhcmFtZXRlciBOZWdvdGlhdGlvbiBEdXJpbmcgdGhlIExvZ2luIFBoYXNl
DQoNCk9wZXJhdGlvbmFsIHBhcmFtZXRlciBuZWdvdGlhdGlvbiBkdXJpbmcgdGhlIGxvZ2luIE1B
WSBiZSBkb25lOg0KDQotIHN0YXJ0aW5nIHdpdGggdGhlIGZpcnN0IExvZ2luIHJlcXVlc3QgaWYg
dGhlIGluaXRpYXRvciBkb2VzIG5vdCBvZmZlciAgYW55IHNlY3VyaXR5LyBpbnRlZ3JpdHkgb3B0
aW9uDQotIHN0YXJ0aW5nIGltbWVkaWF0ZWx5IGFmdGVyIHRoZSBzZWN1cml0eS9pbnRlZ3JpdHkg
bmVnb3RpYXRpb24gaWYgdGhlIGluaXRpYXRvciBhbmQgdGFyZ2V0IHBlcmZvcm0gc3VjaCBhIG5l
Z290aWF0aW9uDQoNCkFuIG9wZXJhdGlvbmFsIHBhcmFtZXRlciBuZWdvdGlhdGlvbiBvbiBhIGNv
bm5lY3Rpb24gTVVTVCBOT1Qgc3RhcnQgYmVmb3JlIHRoZSBzZWN1cml0eSBuZWdvdGlhdGlvbiBp
ZiBhIHNlY3VyaXR5IG5lZ290aWF0aW9uIGV4aXN0cy4gIA0KDQpPcGVyYXRpb25hbCBwYXJhbWV0
ZXIgbmVnb3RpYXRpb24gTUFZIGludm9sdmUgc2V2ZXJhbCBMb2dpbiByZXF1ZXN0LXJlc3BvbnNl
IGV4Y2hhbmdlcyBzdGFydGVkIGFuZCB0ZXJtaW5hdGVkIGJ5IHRoZSBpbml0aWF0b3IuIFRoZSBp
bml0aWF0b3IgTVVTVCBpbmRpY2F0ZSBpdHMgaW50ZW50IHRvIHRlcm1pbmF0ZSB0aGUgbmVnb3Rp
YXRpb24gYnkgc2V0dGluZyB0aGUgRiBiaXQgdG8gMTsgdGhlIHRhcmdldCBzZXRzIHRoZSBGIGJp
dCB0byAxIG9uIHRoZSBsYXN0IHJlc3BvbnNlLiBUaGUgbGFzdCByZXNwb25zZSBNVVNUIGJlIHRo
ZSBMb2dpbiBSZXNwb25zZS4NCklmIHRoZSB0YXJnZXQgcmVzcG9uZHMgdG8gYSBMb2dpbiByZXF1
ZXN0IHdpdGggdGhlIEYgYml0IHNldCB0byAxLCB3aXRoIGEgTG9naW4gcmVzcG9uc2Ugd2l0aCB0
aGUgRiBiaXQgc2V0IHRvIDAsIHRoZSBpbml0aWF0b3IgbXVzdCBrZWVwIHNlbmRpbmcgdGhlIExv
Z2luIHJlcXVlc3QgKGV2ZW4gZW1wdHkpIHdpdGggdGhlIEYgYml0IHNldCB0byAxIHVudGlsIGl0
IGdldHMgdGhlIExvZ2luIFJlc3BvbnNlIHdpdGggdGhlIEYgYml0IHNldCB0byAxLg0KDQpXaGVu
ZXZlciBwYXJhbWV0ZXIgYWN0aW9uIG9yIGFjY2VwdGFuY2UgaXMgZGVwZW5kZW50IG9uIG90aGVy
IHBhcmFtZXRlcnMgdGhlIGRlcGVuZGVudCBwYXJhbWV0ZXJzIE1VU1QgYmUgc2VudCBhZnRlciB0
aGUgcGFyYW1ldGVycyB0aGV5IGRlcGVuZCBvbi4gIElmIHRoZXkgYXJlIHNlbnQgd2l0aGluIHRo
ZSBzYW1lIGNvbW1hbmQgYSByZXNwb25zZSBmb3IgYSBwYXJhbWV0ZXIgbWlnaHQgaW1wbHkgcmVz
cG9uc2VzIGZvciBvdGhlcnMuDQoNCkFuIGluaXRpYXRvciBNVVNUIHNlbmQgYSBzaW5nbGUgTG9n
aW4gcmVxdWVzdCB3aXRoIHRoZSBDIGJpdCBzZXQgdG8gMCBwZXIgY29ubmVjdGlvbiwgcGVyIHNl
c3Npb24uIA0KDQpTZXNzaW9uIHNwZWNpZmljIHBhcmFtZXRlcnMgY2FuIGJlIHNwZWNpZmllZCBv
bmx5IGR1cmluZyB0aGUgbG9naW4gcGhhc2UgICAgIGJlZ3VuIGJ5IGEgbG9naW4gY29tbWFuZCBj
b250YWluaW5nIGEgbnVsbCBUU0lEIChlLmcuLCB0aGUgbWF4aW11bSBudW1iZXIgb2YgY29ubmVj
dGlvbnMgdGhhdCBjYW4gYmUgdXNlZCBmb3IgdGhpcyBzZXNzaW9uKS4gIENvbm5lY3Rpb24gc3Bl
Y2lmaWMgcGFyYW1ldGVycywgaWYgYW55LCBjYW4gYmUgc3BlY2lmaWVkIGR1cmluZyB0aGUgbG9n
aW4gcGhhc2UgYmVndW4gYnkgYW55IGxvZ2luIGNvbW1hbmQuIFRodXMsIGEgc2Vzc2lvbiBpcyBv
cGVyYXRpb25hbCBvbmNlIGl0IGhhcyBhdCBsZWFzdCBvbmUgY29ubmVjdGlvbi4gDQoNCkZvciBh
IGxpc3Qgb2Ygb3BlcmF0aW9uYWwgcGFyYW1ldGVycywgc2VlIEFwcGVuZGl4IEQuIA0KDQoNCi0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCjAwMyBMb2dpbiBQaGFzZSBFeGFtcGxlcw0KDQpJ
biB0aGUgZmlyc3QgZXhhbXBsZSwgdGhlIGluaXRpYXRvciBhbmQgdGFyZ2V0IGF1dGhlbnRpY2F0
ZSBlYWNoIG90aGVyIHZpYSBLZXJiZXJvczoNCg0KSS0+IExvZ2luIChDPTAsIENOeFNHPTAsMSBG
PTEpDQogICAgSW5pdGlhdG9yTmFtZT1pcW4uMTk5OS0wNy5jb20ub3MuaG9zdGlkLjc3DQogICAg
VGFyZ2V0TmFtZT1pcW4uMTk5OS0wNy5jb20uYWNtZS5kaXNrYXJyYXkuc24uODggDQogICAgSGVh
ZGVyRGlnZXN0PUNSQy0zMkMsbm9uZSANCiAgICBEYXRhRGlnZXN0PUNSQy0zMkMsbm9uZQ0KICAg
IEF1dGhNZXRob2Q9U1JQLEtSQjUsbm9uZSANCg0KVC0+IExvZ2luIChDTnhTRz0wLDEgRj0wKQ0K
ICAgIEhlYWRlckRpZ2VzdD1DUkMtMzJDDQogICAgRGF0YURpZ2VzdD1DUkMtMzJDDQogICAgQXV0
aE1ldGhvZD1LUkI1DQoNCg0KSS0+IExvZ2luIChDPTEsIENOeFNHPTAsMSBGPTEpDQogICAgS1JC
X0FQX1JFUT08a3JiX2FwX3JlcT4NCg0KKGtyYl9hcF9yZXEgY29udGFpbnMgdGhlIEtlcmJlcm9z
IFY1IHRpY2tldCBhbmQgYXV0aGVudGljYXRvciB3aXRoIE1VVFVBTC1SRVFVSVJFRCBzZXQgaW4g
dGhlIGFwLW9wdGlvbnMgZmllbGQpDQoNCklmIHRoZSBhdXRoZW50aWNhdGlvbiBpcyBzdWNjZXNz
ZnVsLCB0aGUgdGFyZ2V0IHByb2NlZWRzIHdpdGg6DQoNClQtPiBMb2dpbiAoQ054U0c9MCwxIEY9
MSkNCiAgICBLUkJfQVBfUkVQPTxrcmJfYXBfcmVwPiANCg0KKGtyYl9hcF9yZXAgaXMgdGhlIEtl
cmJlcm9zIFY1IG11dHVhbCBhdXRoZW50aWNhdGlvbiByZXBseSkgDQogDQpJZiB0aGUgYXV0aGVu
dGljYXRpb24gaXMgc3VjY2Vzc2Z1bCwgdGhlIGluaXRpYXRvciBwcm9jZWVkcy4NCg0KRnJvbSB0
aGlzIHBvaW50IG9uLCBhbnkgTG9naW4gY29tbWFuZCBhbmQgZWFjaCBQRFUgdGhlcmVhZnRlciBN
VVNUIGhhdmUgQ1JDLTMyQyBkaWdlc3RzIGZvciB0aGUgaGVhZGVyIGFuZCB0aGUgZGF0YS4NCg0K
VGhlIGluaXRpYXRvciBtYXkgcHJvY2VlZDoNCg0KSS0+IExvZ2luIChDPTEsIENOeFNHPTEsMyBG
PTApDQogICAgLi4uIGlTQ1NJIE9wZXJhdGlvbmFsIFBhcmFtZXRlcnMNCg0KVC0+IExvZ2luIChD
TnhTRz0xLDMgRj0wKQ0KICAgIC4uLiBpU0NTSSBPcGVyYXRpb25hbCBQYXJhbWV0ZXJzIA0KDQpB
bmQgYXQgdGhlIGVuZDoNCg0KSS0+IExvZ2luIChDPTEsIENOeFNHPTEsMyBGPTEpDQogICAgb3B0
aW9uYWwgaVNDU0kgcGFyYW1ldGVycw0KICAgIFRhcmdldE5hbWU9aXFuLjE5OTktMDcuY29tLmFj
bWUuZGlza2FycmF5LnNuLjg4DQoNClQtPiBMb2dpbiAoQ054U0c9MSwzIEY9MSkgImxvZ2luIGFj
Y2VwdCIgDQoNCklmIHRoZSBpbml0aWF0b3IgYXV0aGVudGljYXRpb24gYnkgdGhlIHRhcmdldCBp
cyBub3Qgc3VjY2Vzc2Z1bCwgdGhlIHRhcmdldCByZXNwb25kcyB3aXRoOg0KDQpULT4gTG9naW4g
ImxvZ2luIHJlamVjdCINCg0KaW5zdGVhZCBvZiB0aGUgTG9naW4gS1JCX0FQX1JFUCBtZXNzYWdl
LCBhbmQgdGVybWluYXRlcyB0aGUgY29ubmVjdGlvbi4NCg0KSWYgdGhlIHRhcmdldCBhdXRoZW50
aWNhdGlvbiBieSB0aGUgaW5pdGlhdG9yIGlzIG5vdCBzdWNjZXNzZnVsLCB0aGUgaW5pdGlhdG9y
IHRlcm1pbmF0ZXMgdGhlIGNvbm5lY3Rpb24gKHdpdGhvdXQgcmVzcG9uZGluZyB0byB0aGUgTG9n
aW4gS1JCX0FQX1JFUCBtZXNzYWdlKS4NCg0KSW4gdGhlIG5leHQgZXhhbXBsZSBvbmx5IHRoZSBp
bml0aWF0b3IgaXMgYXV0aGVudGljYXRlZCBieSB0aGUgdGFyZ2V0IHZpYSBLZXJiZXJvczoNCg0K
SS0+IExvZ2luIChDPTAsIENOeFNHPTAsMSBGPTEpDQogICAgSW5pdGlhdG9yTmFtZT1pcW4uMTk5
OS0wNy5jb20ub3MuaG9zdGlkLjc3DQogICAgVGFyZ2V0TmFtZT1pcW4uMTk5OS0wNy5jb20uYWNt
ZS5kaXNrYXJyYXkuc24uODggIA0KICAgIEhlYWRlckRpZ2VzdD1DUkMtMzJDLG5vbmUNCiAgICBE
YXRhRGlnZXN0PUNSQy0zMkMsbm9uZQ0KICAgIEF1dGhNZXRob2Q9U1JQLEtSQjUsbm9uZSANCg0K
VC0+IExvZ2luLVBSIChDTnhTRz0wLDEgRj0wKQ0KICAgIEhlYWRlckRpZ2VzdD1DUkMtMzJDDQog
ICAgRGF0YURpZ2VzdD1DUkMtMzJDIA0KICAgIEF1dGhNZXRob2Q9S1JCNSANCg0KSS0+IExvZ2lu
IChDPTEsIENOeFNHPTAsMSBGPTEpDQogICAgS1JCX0FQX1JFUT1rcmJfYXBfcmVxIA0KDQooTVVU
VUFMLVJFUVVJUkVEIG5vdCBzZXQgaW4gdGhlIGFwLW9wdGlvbnMgZmllbGQgb2Yga3JiX2FwX3Jl
cSkNCg0KSWYgdGhlIGF1dGhlbnRpY2F0aW9uIGlzIHN1Y2Nlc3NmdWwsIHRoZSB0YXJnZXQgcHJv
Y2VlZHMgd2l0aDoNCg0KVC0+IExvZ2luIChDTnhTRz0wLDEgRj0xKQ0KDQpGcm9tIHRoaXMgcG9p
bnQgb24sIGFueSBMb2dpbiBjb21tYW5kIGFuZCBlYWNoIFBEVSB0aGVyZWFmdGVyIE1VU1QgaGF2
ZSBDUkMtMzJDIGRpZ2VzdHMgZm9yIHRoZSBoZWFkZXIgYW5kIHRoZSBkYXRhLg0KDQpJLT4gTG9n
aW4gKEM9MSwgQ054U0c9MSwzIEY9MCkNCiAgICAuLi4gaVNDU0kgcGFyYW1ldGVycw0KDQpULT4g
TG9naW4gKEM9MSwgQ054U0c9MSwzIEY9MCkNCiAgICAuLi4gaVNDU0kgcGFyYW1ldGVycw0KDQou
IC4gLg0KDQpULT4gTG9naW4gKENOeFNHPTEsMyBGPTEpImxvZ2luIGFjY2VwdCINCiAgICBUYXJn
ZXROYW1lPWlxbi4xOTk5LTA3LmNvbS5hY21lLmRpc2thcnJheS5zbi44OA0KDQoNCkluIHRoZSBu
ZXh0IGV4YW1wbGUsIHRoZSBpbml0aWF0b3IgYW5kIHRhcmdldCBhdXRoZW50aWNhdGUgZWFjaCBv
dGhlciB2aWEgU1BLTS0xOg0KDQpJLT4gTG9naW4gKEM9MCwgQ054U0c9MCwxIEY9MSkNCiAgICBJ
bml0aWF0b3JOYW1lPWlxbi4xOTk5LTA3LmNvbS5vcy5ob3N0aWQuNzcNCiAgICBUYXJnZXROYW1l
PWlxbi4xOTk5LTA3LmNvbS5hY21lLmRpc2thcnJheS5zbi44OA0KICAgIEhlYWRlckRpZ2VzdD1D
UkMtMzJDLG5vbmUgDQogICAgRGF0YURpZ2VzdD1DUkMtMzJDLCBub25lDQogICAgQXV0aE1ldGhv
ZD1TUEtNLTEsS1JCNSxub25lIA0KDQpULT4gTG9naW4gKENOeFNHPTAsMSBGPTApDQogICAgSGVh
ZGVyRGlnZXN0PUNSQy0zMkMNCiAgICBEYXRhRGlnZXN0PVNQS00NCiAgICBBdXRoTWV0aG9kPVNQ
S00tMQ0KDQpJLT4gTG9naW4gKEM9MSwgQ054U0c9MCwxIEY9MCkNCiAgICBTUEtNLVJFUT08c3Br
bS1yZXE+DQoNCihzcGttLXJlcSBpcyB0aGUgU1BLTS1SRVEgdG9rZW4gd2l0aCB0aGUgbXV0dWFs
LXN0YXRlIGJpdCBpbiB0aGUgb3B0aW9ucyBmaWVsZCBvZiB0aGUgUkVRLVRPS0VOIHNldCkNCg0K
VC0+IExvZ2luIChDTnhTRz0wLDEgRj0wKQ0KICAgIFNQS00tUkVQLVRJPTxzcGttLXJlcC10aT4g
DQoNCklmIHRoZSBhdXRoZW50aWNhdGlvbiBpcyBzdWNjZXNzZnVsLCB0aGUgaW5pdGlhdG9yIHBy
b2NlZWRzOg0KDQpJLT4gTG9naW4gKEM9MSwgQ054U0c9MCwxIEY9MSkNCiAgICBTUEtNLVJFUC1J
VD08c3BrbS1yZXAtaXQ+DQogDQpJZiB0aGUgYXV0aGVudGljYXRpb24gaXMgc3VjY2Vzc2Z1bCwg
dGhlIHRhcmdldCBwcm9jZWVkcyB3aXRoOg0KDQpULT4gTG9naW4gKENOeFNHPTAsMSBGPTEpDQoN
CkZyb20gdGhpcyBwb2ludCBvbiwgYW55IExvZ2luIGNvbW1hbmQgYW5kIGVhY2ggUERVIHRoZXJl
YWZ0ZXIgTVVTVCBoYXZlIENSQy0zMkMgZGlnZXN0cyBmb3IgdGhlIGhlYWRlciBhbmQgdGhlIGRh
dGEuDQoNClRoZSBpbml0aWF0b3IgbWF5IHByb2NlZWQ6DQoNCkktPiBMb2dpbiAgKEM9MSwgQ054
U0c9MSwzIEY9MCkgLi4uIGlTQ1NJIHBhcmFtZXRlcnMNClQtPiBMb2dpbiAgKENOeFNHPTEsMyBG
PTApIC4uLiBpU0NTSSBwYXJhbWV0ZXJzDQoNCkFuZCBhdCB0aGUgZW5kOg0KDQpJLT4gTG9naW4g
IChDPTEsIENOeFNHPTEsMyBGPTEpDQogICAgb3B0aW9uYWwgaVNDU0kgcGFyYW1ldGVycyANCg0K
VC0+IExvZ2luIChDTnhTRz0xLDMgRj0xKSAibG9naW4gYWNjZXB0Ig0KICAgIFRhcmdldE5hbWU9
aXFuLjE5OTktMDcuY29tLmFjbWUuZGlza2FycmF5LnNuLjg4DQoNCg0KSWYgdGhlIHRhcmdldCBh
dXRoZW50aWNhdGlvbiBieSB0aGUgaW5pdGlhdG9yIGlzIG5vdCBzdWNjZXNzZnVsLCB0aGUgaW5p
dGlhdG9yIHRlcm1pbmF0ZXMgdGhlIGNvbm5lY3Rpb24gKHdpdGhvdXQgcmVzcG9uZGluZyB0byB0
aGUgTG9naW4gU1BLTS1SRVAtVEkgbWVzc2FnZSkuDQoNCklmIHRoZSBpbml0aWF0b3IgYXV0aGVu
dGljYXRpb24gYnkgdGhlIHRhcmdldCBpcyBub3Qgc3VjY2Vzc2Z1bCwgdGhlIHRhcmdldCByZXNw
b25kcyB3aXRoOg0KDQpULT4gTG9naW4gImxvZ2luIHJlamVjdCINCg0KaW5zdGVhZCBvZiB0aGUg
TG9naW4gU2VjdXJpdHlDb250ZXh0Q29tcGxldGU9eWVzIG1lc3NhZ2UsIGFuZCB0ZXJtaW5hdGVz
IHRoZSBjb25uZWN0aW9uLg0KDQoNCkluIHRoZSBuZXh0IGV4YW1wbGUsIHRoZSBpbml0aWF0b3Ig
YW5kIHRhcmdldCBhdXRoZW50aWNhdGUgZWFjaCBvdGhlciB2aWEgU1BLTS0yOg0KDQpJLT4gTG9n
aW4gKEM9MCwgQ054U0c9MCwxIEY9MCkNCiAgICBJbml0aWF0b3JOYW1lPWlxbi4xOTk5LTA3LmNv
bS5vcy5ob3N0aWQuNzcNCiAgICBUYXJnZXROYW1lPWlxbi4xOTk5LTA3LmNvbS5hY21lLmRpc2th
cnJheS5zbi44OA0KICAgIEhlYWRlckRpZ2VzdD0gQ1JDLTMyQyxub25lDQogICAgICAgICAgRGF0
YURpZ2VzdD1DUkMtMzJDLG5vbmUNCiAgICAgICAgICBBdXRoTWV0aG9kPVNQS00tMSxTUEtNLTIg
DQoNClQtPiBMb2dpbi1QUiAoQ054U0c9MCwxIEY9MCkNCiAgICBIZWFkZXJEaWdlc3Q9Q1JDLTMy
Qw0KICAgIERhdGFEaWdlc3Q9Q1JDLTMyQw0KICAgIEF1dGhNZXRob2Q9U1BLTS0yDQoNCkktPiBM
b2dpbiAoQz0xLCBDTnhTRz0wLDEgRj0xKQ0KICAgIFNQS00tUkVRPTxzcGttLXJlcT4NCg0KKHNw
a20tcmVxIGlzIHRoZSBTUEtNLVJFUSB0b2tlbiB3aXRoIHRoZSBtdXR1YWwtc3RhdGUgYml0IGlu
IHRoZSBvcHRpb25zIGZpZWxkIG9mIHRoZSBSRVEtVE9LRU4gbm90IHNldCkNCg0KSWYgdGhlIGF1
dGhlbnRpY2F0aW9uIGlzIHN1Y2Nlc3NmdWwsIHRoZSB0YXJnZXQgcHJvY2VlZHMgd2l0aDoNCg0K
VC0+IExvZ2luIChDTnhTRz0wLDEgRj0xKSANCg0KRnJvbSB0aGlzIHBvaW50IG9uLCBhbnkgTG9n
aW4gY29tbWFuZCBhbmQgZWFjaCBQRFUgdGhlcmVhZnRlciBNVVNUIGhhdmUgQ1JDLTMyQyBkaWdl
c3RzIGZvciB0aGUgaGVhZGVyIGFuZCB0aGUgZGF0YS4NCg0KVGhlIGluaXRpYXRvciBtYXkgcHJv
Y2VlZDoNCg0KSS0+IExvZ2luIChDPTEsIENOeFNHPTEsMyBGPTApDQogICAgLi4uIGlTQ1NJIHBh
cmFtZXRlcnMNCg0KVC0+IExvZ2luIChDTnhTRz0xLDMgRj0wKQ0KICAgIC4uLiBpU0NTSSBwYXJh
bWV0ZXJzDQoNCkFuZCBhdCB0aGUgZW5kOg0KDQpJLT4gTG9naW4gIChDPTEsIENOeFNHPTEsMyBG
PTEpDQogICAgb3B0aW9uYWwgaVNDU0kgcGFyYW1ldGVycw0KDQpULT4gTG9naW4gKENOeFNHPTEs
MyBGPTEpICJsb2dpbiBhY2NlcHQiDQogICAgVGFyZ2V0TmFtZT1pcW4uMTk5OS0wNy5jb20uYWNt
ZS5kaXNrYXJyYXkuc24uODgNCg0KDQpJbiB0aGUgbmV4dCBleGFtcGxlLCB0aGUgaW5pdGlhdG9y
IGFuZCB0YXJnZXQgYXV0aGVudGljYXRlIGVhY2ggb3RoZXIgdmlhIFNSUDoNCg0KSS0+IExvZ2lu
IChDPTAsIENOeFNHPTAsMSBGPTEpDQogICAgSW5pdGlhdG9yTmFtZT1pcW4uMTk5OS0wNy5jb20u
b3MuaG9zdGlkLjc3DQogICAgVGFyZ2V0TmFtZT1pcW4uMTk5OS0wNy5jb20uYWNtZS5kaXNrYXJy
YXkuc24uODggDQogICAgSGVhZGVyRGlnZXN0PUNSQy0zMkMsbm9uZQ0KICAgIERhdGFEaWdlc3Q9
Q1JDLTMyQyxub25lDQogICAgQXV0aE1ldGhvZD1LUkI1LFNSUCxub25lDQogDQpULT4gTG9naW4t
UFIgIChDPTEsIENOeFNHPTAsMSBGPTApDQogICAgSGVhZGVyRGlnZXN0PUNSQy0zMkMNCiAgICBE
YXRhRGlnZXN0PUNSQy0zMkMNCiAgICBBdXRoTWV0aG9kPVNSUA0KDQpJLT4gTG9naW4gKEM9MSwg
Q054U0c9MCwxIEY9MCkNCiAgICBVPTx1c2VyPg0KICAgIFRhcmdldEF1dGg9eWVzDQoNClQtPiBM
b2dpbiAoQ054U0c9MCwxIEY9MCkNCiAgICBOPTxOPg0KICAgIGc9PGc+DQogICAgcz08cz4NCg0K
SS0+IExvZ2luIChDPTEsIENOeFNHPTAsMSBGPTApDQogICAgQT08QT4NCg0KVC0+IExvZ2luIChD
TnhTRz0wLDEgRj0wKQ0KICAgIEI9PEI+DQoNCkktPiBMb2dpbiAoQz0xLCBDTnhTRz0wLDEgRj0x
KQ0KICAgIE09PE0+DQoNCklmIHRoZSBpbml0aWF0b3IgYXV0aGVudGljYXRpb24gaXMgc3VjY2Vz
c2Z1bCwgdGhlIHRhcmdldCBwcm9jZWVkczoNCg0KVC0+IExvZ2luIChDTnhTRz0wLDEgRj0xKQ0K
ICAgIEhNPTxIKEEgfCBNIHwgSyk+DQoNCiAgIFdoZXJlIE4sIGcsIHMsIEEsIEIsIE0sIGFuZCBI
KEEgfCBNIHwgSykgYXJlIGRlZmluZWQgaW4gW1JGQzI5NDVdLg0KDQpJZiB0aGUgdGFyZ2V0IGF1
dGhlbnRpY2F0aW9uIGlzIG5vdCBzdWNjZXNzZnVsLCB0aGUgaW5pdGlhdG9yIHRlcm1pbmF0ZXMg
dGhlIGNvbm5lY3Rpb24uIE90aGVyd2lzZSBpdCBwcm9jZWVkcy4NCg0KRnJvbSB0aGlzIHBvaW50
IG9uLCBhbnkgTG9naW4gY29tbWFuZCBhbmQgZWFjaCBQRFUgdGhlcmVhZnRlciBNVVNUIGhhdmUg
Q1JDLTMyQyBkaWdlc3RzIGZvciB0aGUgaGVhZGVyIGFuZCB0aGUgZGF0YS4NCg0KSS0+IExvZ2lu
IChDPTEsIENOeFNHPTEsMyBGPTApDQogICAgLi4uIGlTQ1NJIHBhcmFtZXRlcnMNCg0KVC0+IExv
Z2luIChDTnhTRz0xLDMgRj0wKQ0KICAgIC4uLiBpU0NTSSBwYXJhbWV0ZXJzDQoNCkFuZCBhdCB0
aGUgZW5kOg0KDQpJLT4gTG9naW4gKEM9MSwgQ054U0c9MSwzIEY9MSkNCiAgICBvcHRpb25hbCBp
U0NTSSBwYXJhbWV0ZXJzIA0KDQpULT4gTG9naW4gIChDTnhTRz0xLDMgRj0xKSAibG9naW4gYWNj
ZXB0Ig0KICAgIFRhcmdldE5hbWU9aXFuLjE5OTktMDcuY29tLmFjbWUuZGlza2FycmF5LnNuLjg4
DQoNCklmIHRoZSBpbml0aWF0b3IgYXV0aGVudGljYXRpb24gaXMgbm90IHN1Y2Nlc3NmdWwsIHRo
ZSB0YXJnZXQgcmVzcG9uZHMgd2l0aDoNCg0KVC0+IExvZ2luICJsb2dpbiByZWplY3QiDQoNCklu
c3RlYWQgb2YgdGhlIFQtPiBMb2dpbiBITT08SChBIHwgTSB8IEspPiAgbWVzc2FnZSBhbmQgdGVy
bWluYXRlcyB0aGUgY29ubmVjdGlvbi4NCg0KSW4gdGhlIG5leHQgZXhhbXBsZSBvbmx5IHRoZSBp
bml0aWF0b3IgaXMgYXV0aGVudGljYXRlZCBieSB0aGUgdGFyZ2V0IHZpYSBTUlA6DQoNCkktPiBM
b2dpbiAoQz0wLCBDTnhTRz0wLDEgRj0xKQ0KICAgIEluaXRpYXRvck5hbWU9aXFuLjE5OTktMDcu
Y29tLm9zLmhvc3RpZC43Nw0KICAgIFRhcmdldE5hbWU9aXFuLjE5OTktMDcuY29tLmFjbWUuZGlz
a2FycmF5LnNuLjg4IA0KICAgIEhlYWRlckRpZ2VzdD1DUkMtMzJDLG5vbmUNCiAgICBEYXRhRGln
ZXN0PUNSQy0zMkMsbm9uZQ0KICAgIEF1dGhNZXRob2Q9S1JCNSxTUlAsbm9uZSANCg0KVC0+IExv
Z2luLVBSIChDTnhTRz0wLDEgRj0wKQ0KICAgIEhlYWRlckRpZ2VzdD1DUkMtMzJDDQogICAgRGF0
YURpZ2VzdD1DUkMtMzJDDQogICAgQXV0aE1ldGhvZD1TUlANCg0KSS0+IExvZ2luIChDPTEsIENO
eFNHPTAsMSBGPTApDQogICAgVT08dXNlcj4NCiAgICBUYXJnZXRBdXRoPW5vDQoNCiAgIFQtPiBM
b2dpbiAoQ054U0c9MCwxIEY9MCkNCiAgICAgICBOPTxOPiANCiAgICAgICBnPTxnPg0KICAgICAg
IHM9PHM+DQoNCkktPiBMb2dpbiAoQz0xLCBDTnhTRz0wLDEgRj0wKSANCiAgICBBPTxBPg0KDQpU
LT4gTG9naW4gKENOeFNHPTAsMSBGPTApIA0KICAgIEI9PEI+DQoNCkktPiBMb2dpbiAoQz0xLCBD
TnhTRz0wLDEgRj0xKSANCiAgICBNPTxNPg0KIA0KSWYgdGhlIGluaXRpYXRvciBhdXRoZW50aWNh
dGlvbiBpcyBzdWNjZXNzZnVsLCB0aGUgdGFyZ2V0IHByb2NlZWRzOg0KDQpULT4gTG9naW4gKENO
eFNHPTAsMSBGPTEpDQoNCkZyb20gdGhpcyBwb2ludCBvbiwgYW55IExvZ2luIGNvbW1hbmQgYW5k
IGVhY2ggUERVIHRoZXJlYWZ0ZXIgTVVTVCBoYXZlIENSQy0zMkMgZGlnZXN0cyBmb3IgdGhlIGhl
YWRlciBhbmQgdGhlIGRhdGEuDQoNCkktPiBMb2dpbiAoQz0xLCBDTnhTRz0xLDMgRj0wKSANCiAg
ICAuLi4gaVNDU0kgcGFyYW1ldGVycw0KDQpULT4gTG9naW4gKEM9MSwgQ054U0c9MSwzIEY9MCkN
CiAgICAuLi4gaVNDU0kgcGFyYW1ldGVycw0KDQpBbmQgYXQgdGhlIGVuZDoNCg0KSS0+IExvZ2lu
IChDPTEsIENOeFNHPTEsMyBGPTEpDQogICAgb3B0aW9uYWwgaVNDU0kgcGFyYW1ldGVycw0KDQpU
LT4gTG9naW4gKENOeFNHPTEsMyBGPTEpICJsb2dpbiBhY2NlcHQiDQogICAgVGFyZ2V0TmFtZT1p
cW4uMTk5OS0wNy5jb20uYWNtZS5kaXNrYXJyYXkuc24uODgNCg0KDQpJbiB0aGUgbmV4dCBleGFt
cGxlIHRoZSBpbml0aWF0b3IgYW5kIHRhcmdldCBhdXRoZW50aWNhdGUgZWFjaCBvdGhlciB2aWEg
Q0hBUDoNCg0KSS0+IExvZ2luIChDPTAsIENOeFNHPTAsMSBGPTApIA0KICAgIEluaXRpYXRvck5h
bWU9aXFuLjE5OTktMDcuY29tLm9zLmhvc3RpZC43Nw0KICAgIFRhcmdldE5hbWU9aXFuLjE5OTkt
MDcuY29tLmFjbWUuZGlza2FycmF5LnNuLjg4IA0KICAgIEhlYWRlckRpZ2VzdD1DUkMtMzJDLG5v
bmUNCiAgICBEYXRhRGlnZXN0PUNSQy0zMkMsbm9uZQ0KICAgIEF1dGhNZXRob2Q9S1JCNSxDSEFQ
LG5vbmUgDQoNClQtPiBMb2dpbi1QUiAoQ054U0c9MCwxIEY9MCkNCiAgICBIZWFkZXJEaWdlc3Q9
Q1JDLTMyQw0KICAgIERhdGFEaWdlc3Q9Q1JDLTMyQw0KICAgIEF1dGhNZXRob2Q9Q0hBUA0KDQpJ
LT4gTG9naW4gKEM9MSwgQ054U0c9MCwxIEY9MCkNCiAgICBBPTxBMSxBMj4NCg0KICAgVC0+IExv
Z2luIChDTnhTRz0wLDEgRj0wKSANCiAgICAgICBBPTxBMT4gDQogICAgICAgST08ST4gDQogICAg
ICAgQz08Qz4NCg0KSS0+IExvZ2luIChDPTEsIENOeFNHPTAsMSBGPTEpDQogICAgTj08Tj4gDQog
ICAgUj08Uj4gDQogICAgST08ST4gDQogICAgQz08Qz4gDQoNCklmIHRoZSBpbml0aWF0b3IgYXV0
aGVudGljYXRpb24gaXMgc3VjY2Vzc2Z1bCwgdGhlIHRhcmdldCBwcm9jZWVkczoNCg0KVC0+IExv
Z2luIChDTnhTRz0wLDEgRj0xKSANCiAgICBOPTxOPiANCiAgICBSPTxSPg0KDQpJZiB0aGUgdGFy
Z2V0IGF1dGhlbnRpY2F0aW9uIGlzIG5vdCBzdWNjZXNzZnVsLCB0aGUgaW5pdGlhdG9yIGFib3J0
cyB0aGUgY29ubmVjdGlvbi4gT3RoZXJ3aXNlIGl0IHByb2NlZWRzLg0KDQpGcm9tIHRoaXMgcG9p
bnQgb24sIGFueSBMb2dpbiBjb21tYW5kIGFuZCBlYWNoIFBEVSB0aGVyZWFmdGVyIE1VU1QgaGF2
ZSBDUkMtMzJDIGRpZ2VzdHMgZm9yIHRoZSBoZWFkZXIgYW5kIHRoZSBkYXRhLg0KDQpJLT4gTG9n
aW4gKEM9MSwgQ054U0c9MSwzIEY9MCkgDQogICAgLi4uIGlTQ1NJIHBhcmFtZXRlcnMNClQtPiBM
b2dpbiAoQ054U0c9MSwzIEY9MCkgDQogICAgLi4uIGlTQ1NJIHBhcmFtZXRlcnMNCg0KQW5kIGF0
IHRoZSBlbmQ6DQoNCkktPiBMb2dpbiAoQz0xLCBDTnhTRz0xLDMgRj0xKSANCiAgICBvcHRpb25h
bCBpU0NTSSBwYXJhbWV0ZXJzDQoNClQtPiBMb2dpbiAoQ054U0c9MSwzIEY9MSkgImxvZ2luIGFj
Y2VwdCIgDQogICAgVGFyZ2V0TmFtZT1pcW4uMTk5OS0wNy5jb20uYWNtZS5kaXNrYXJyYXkuc24u
ODgNCg0KSWYgdGhlIGluaXRpYXRvciBhdXRoZW50aWNhdGlvbiBpcyBub3Qgc3VjY2Vzc2Z1bCwg
dGhlIHRhcmdldCByZXNwb25kcyB3aXRoOg0KDQpULT4gTG9naW4gImxvZ2luIHJlamVjdCINCg0K
SW5zdGVhZCBvZiB0aGUgTG9naW4gUj08cmVzcG9uc2U+IFNlY3VyaXR5Q29udGV4dENvbXBsZXRl
PXllcw0KbWVzc2FnZSBhbmQgdGVybWluYXRlcyB0aGUgY29ubmVjdGlvbi4NCg0KDQpJbiB0aGUg
bmV4dCBleGFtcGxlIG9ubHkgdGhlIGluaXRpYXRvciBpcyBhdXRoZW50aWNhdGVkIGJ5IHRoZSB0
YXJnZXQgdmlhIENIQVA6DQoNCkktPiBMb2dpbiAoQz0wLCBDTnhTRz0wLDEgRj0wKSANCiAgICBJ
bml0aWF0b3JOYW1lPWlxbi4xOTk5LTA3LmNvbS5vcy5ob3N0aWQuNzcNCiAgICBUYXJnZXROYW1l
PWlxbi4xOTk5LTA3LmNvbS5hY21lLmRpc2thcnJheS5zbi44OCANCiAgICBIZWFkZXJEaWdlc3Q9
Q1JDLTMyQyxub25lDQogICAgRGF0YURpZ2VzdD1DUkMtMzJDLG5vbmUNCiAgICBBdXRoTWV0aG9k
PUtSQjUsQ0hBUCxub25lIA0KDQpULT4gTG9naW4tUFIgKENOeFNHPTAsMSBGPTApDQogICAgSGVh
ZGVyRGlnZXN0PUNSQy0zMkMNCiAgICBEYXRhRGlnZXN0PUNSQy0zMkMgDQogICAgQXV0aE1ldGhv
ZD1DSEFQDQoNCkktPiBMb2dpbiAoQz0xLCBDTnhTRz0wLDEgRj0wKSANCiAgICBBPTxBMSxBMj4N
Cg0KICAgVC0+IExvZ2luIChDTnhTRz0wLDEgRj0wKSANCiAgICAgICBBPTxBMT4gDQogICAgICAg
ST08ST4gDQogICAgICAgQz08Qz4NCg0KSS0+IExvZ2luIChDPTEsIENOeFNHPTAsMSBGPTEpIA0K
ICAgIE49PE4+IA0KICAgIFI9PFI+IA0KDQpJZiB0aGUgaW5pdGlhdG9yIGF1dGhlbnRpY2F0aW9u
IGlzIHN1Y2Nlc3NmdWwsIHRoZSB0YXJnZXQgcHJvY2VlZHM6DQoNClQtPiBMb2dpbiAoQ054U0c9
MCwxIEY9MSkNCg0KSS0+IExvZ2luIChDPTEsIENOeFNHPTEsMyBGPTApIA0KICAgIC4uLiBpU0NT
SSBwYXJhbWV0ZXJzDQoNClQtPiBMb2dpbiAoQ054U0c9MSwzIEY9MCkgDQogICAgLi4uIGlTQ1NJ
IHBhcmFtZXRlcnMNCg0KQW5kIGF0IHRoZSBlbmQ6DQoNCkktPiBMb2dpbiAoQz0xLCBDTnhTRz0x
LDMgRj0xKSANCiAgICBvcHRpb25hbCBpU0NTSSBwYXJhbWV0ZXJzDQoNClQtPiBMb2dpbiAoQ054
U0c9MSwzIEY9MSkgImxvZ2luIGFjY2VwdCIgDQogICAgVGFyZ2V0TmFtZT1pcW4uMTk5OS0wNy5j
b20uYWNtZS5kaXNrYXJyYXkuc24uODgNCg0KDQpJbiB0aGUgbmV4dCBleGFtcGxlLCB0aGUgaW5p
dGlhdG9yIGRvZXMgbm90IG9mZmVyIGFueSBzZWN1cml0eS9pbnRlZ3JpdHkgcGFyYW1ldGVycywg
c28gaXQgbWF5IG9mZmVyIGlTQ1NJIHBhcmFtZXRlcnMgb24gdGhlIExvZ2luIFBEVSB3aXRoIHRo
ZSBGIGJpdCBzZXQgdG8gMSwgYW5kIHRoZSB0YXJnZXQgbWF5IHJlc3BvbmQgd2l0aCBhIGZpbmFs
IExvZ2luIFJlc3BvbnNlIFBEVSBpbW1lZGlhdGVseToNCg0KSS0+IExvZ2luIChDPTAsIENOeFNH
PTEsMyBGPTEpIA0KICAgIEluaXRpYXRvck5hbWU9aXFuLjE5OTktMDcuY29tLm9zLmhvc3RpZC43
Nw0KICAgIFRhcmdldE5hbWU9aXFuLjE5OTktMDcuY29tLmFjbWUuZGlza2FycmF5LnNuLjg4ICAN
CiAgICAuLi4gaVNDU0kgcGFyYW1ldGVycw0KDQpULT4gTG9naW4gKENOeFNHPTEsMyBGPTEpICJs
b2dpbiBhY2NlcHQiIA0KICAgIFRhcmdldE5hbWU9aXFuLjE5OTktMDcuY29tLmFjbWUuZGlza2Fy
cmF5LnNuLjg4ICANCiAgICAuLi4gSVNDU0kgcGFyYW1ldGVycw0KDQpJbiB0aGUgbmV4dCBleGFt
cGxlLCB0aGUgaW5pdGlhdG9yIGRvZXMgb2ZmZXIgc2VjdXJpdHkvaW50ZWdyaXR5IHBhcmFtZXRl
cnMgb24gdGhlIExvZ2luIFBEVSwgYnV0IHRoZSB0YXJnZXQgZG9lcyBub3QgY2hvb3NlIGFueSAo
aS5lLiwgY2hvb3NlcyB0aGUgIm5vbmUiIHZhbHVlcyk6DQoNCkktPiBMb2dpbiAoQz0wLCBDTnhT
Rz0wLDEgRj0xKSANCiAgICBJbml0aWF0b3JOYW1lPWlxbi4xOTk5LTA3LmNvbS5vcy5ob3N0aWQu
NzcNCiAgICBUYXJnZXROYW1lPWlxbi4xOTk5LTA3LmNvbS5hY21lLmRpc2thcnJheS5zbi44OCAN
CiAgICBIZWFkZXJEaWdlc3Q9Q1JDLTMyQyxub25lIA0KICAgIERhdGFEaWdlc3Q9Q1JDLTMyQyxu
b25lIA0KICAgIEF1dGhNZXRob2Q6S1JCNSxTUlAsbm9uZQ0KDQpULT4gTG9naW4tUFIgKENOeFNH
PTAsMSBGPTEpIA0KICAgIEhlYWRlckRpZ2VzdD1ub25lIA0KICAgIERhdGFEaWdlc3Q9bm9uZSAN
CiAgICBBdXRoTWV0aG9kPW5vbmUNCg0KSS0+IExvZ2luIChDPTEsIENOeFNHPTEsMyBGPTApIA0K
ICAgIC4uLiBpU0NTSSBwYXJhbWV0ZXJzDQoNClQtPiBMb2dpbiAoQ054U0c9MSwzIEY9MCkgDQog
ICAgLi4uIGlTQ1NJIHBhcmFtZXRlcnMNCg0KQW5kIGF0IHRoZSBlbmQ6DQoNCkktPiBMb2dpbiAo
Qz0xLCBDTnhTRz0xLDMgRj0xKSANCiAgICBvcHRpb25hbCBpU0NTSSBwYXJhbWV0ZXJzDQoNClQt
PiBMb2dpbiAoQ054U0c9MSwzIEY9MSkgImxvZ2luIGFjY2VwdCIgDQogICAgVGFyZ2V0TmFtZT1p
cW4uMTk5OS0wNy5jb20uYWNtZS5kaXNrYXJyYXkuc24uODgNCg0K

--0__=C2256AB9001E9C518f9e8a93df938690918cC2256AB9001E9C51--



From owner-ips@ece.cmu.edu  Fri Aug 31 03:17:22 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26180
	for <ips-archive@odin.ietf.org>; Fri, 31 Aug 2001 03:17:21 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7V5sW902799
	for ips-outgoing; Fri, 31 Aug 2001 01:54:32 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7V5sUP02793
	for <ips@ece.cmu.edu>; Fri, 31 Aug 2001 01:54:30 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id HAA18208
	for <ips@ece.cmu.edu>; Fri, 31 Aug 2001 07:54:20 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7V5sJ5276120
	for <ips@ece.cmu.edu>; Fri, 31 Aug 2001 07:54:19 +0200
Importance: Normal
Subject: Re: iSCSI: login issue - partial consensus call
To: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF8D2EE765.6BB24C6F-ONC2256AB9.00200DA5@telaviv.ibm.com>
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Date: Fri, 31 Aug 2001 08:53:40 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at
 31/08/2001 08:54:19
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


The X bit sematic in login today is "restart the connection".
You may add to it "restart the session" and Marjorie was the only one
(mildly) objecting to it.
However I would like to point out that the C bit has no real value if not
checked as users are prone to set it always on.
If checking is out then A is good enough.

Julo

Black_David@emc.com@ece.cmu.edu on 31-08-2001 07:24:17

Please respond to Black_David@emc.com

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  iSCSI: login issue - partial consensus call



A review of this long running thread.  We started out with
Mallikarjun's three options:

       A) Should iSCSI let it happen by default as stated above (i.e.
          same ISID, TSID=0 always wipes out the pre-existing session
          on target, since we are mandating it to be used only when
          initiator sees a session failure)?
       B) Should iSCSI mandate making this intended cleanup explicit
          by setting a bit (Say C-bit, for Clear) in the Login Command
          PDU to prevent an accidental session cleanup with a buggy
          initiator code?
       C) Should iSCSI merely state that targets must ascertain
          the connection state(s) whenever a new session creation
          attempt is made with a known ISID and TSID=0?  (sort of
          defeats the intention of the initiator wanting quicker
          session recovery since the Login command PDU would have
          to idle till target ascertains the connection state(s)).

Based on my review of the emails, here's what I think the state
of the discussion is:

(1) I see no support for Option C.  The remaining options are A, B, and
     Julian's version of B in which the X bit is reused as the C bit.

(2) I see strong objections to the reuse of the X bit that Julian
     proposed, and no interest in it from anyone other than Julian.
     The objections are that the X bit is already heavily involved
     in error recovery and adding more semantics to it is an invitation
     to trouble. Therefore, I believe the rough consensus of the IPS
     WG is that the X bit is not to be reused in this fashion.

(3) I believe the rough consensus is that the situation being analyzed
     here can occur as a consequence of an initiator reboot (i.e.,
     if the reboot is fast with respect to the target's timeout-based
     session cleanup).

The consensus calls in (2) and (3) are over Julian Satran's proposal/
comments/objection.  Anyone else who objects to these should post to
the list.

This leaves options A and B as originally stated.  Most people seem
to be in favor of option A - the two exceptions I noticed were
Julian and Venkat.  Julian's objection can be summarized with a
couple of quotes:

> Option A is prone to "wild closing of sessions"
> Option A is clearly unacceptable as an initiator may do harm.

The wild closing of sessions seems to be based on a different
iSCSI interface with the same Initiator name using the same
ISID.  This is a definite risk as it's an area in which iSCSI
differs from Fibre Channel.  FC identifies sessions via hardware
identities which tend to be static and unique, and set by the
hardware vendor.  The iSCSI ISID is a dynamically managed
entity, and bugs in managing it across multiple interfaces
(which may involve hardware and software from multiple
vendors) will cause this session closing problem, whereas for
it to happen in FC, the hardware identity has to be duplicated.

FWIW, I do know of an FC system that rejects duplicate logins
under some circumstances rather than implicitly destroying
the existing session, although I don't believe that behavior
can be overridden via inband means as is proposed here.

OTOH, a different OS should have different iSCSI Initiator Name,
and denial of service attacks should be foiled by proper use of
authentication.  I also tend to agree with the architectural
point of view that an initiator is in charge of its own sessions.
So, I think Julian has a point here, although some of the things
he's posted are overstated.

This is also Venkat's concern - unintentional reuse of an ISID
by the same Initiator:

> 2. There is some value in protecting an accidental use of an
> existing ISID by a second client (ISID=<existing>, TSID=0).
> This can be done with a Reject of the login attempt,

In contrast to some of the responses to Venkat, I interpret
"client" to mean another iSCSI port on the same Initiator, and
then his concern matches Julian's.  Venkat seems to think that
there's a useful distinction between boot scenarios in which
teardown of existing sessions is needed and boot scenarios
in which it's not needed  - I have no idea how to figure that
out in practice, and suspect that Marj is right when she says
that the C bit will be set all the time.  I agree that the
C bit is always set in a session recovery scenario because
the intent is to blow away the existing session.

So, I'm not ready to call consensus on the A vs. B. issue.
In hopes of making further progress, I would ask the
proponents of B (Venkat, Julian, and anyone else who thinks
this is valuable - I assume Julian prefers B to A, even if
the WG does not like using the X bit for B) to post short
answers to the following questions:

     Under what circumstances would an Initiator not set the
     C bit for option B?  What information would the Initiator use
     to decide not to set the C bit?

I apologize if this was in some of the emails and I missed
it - there were a lot of them.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------





From owner-ips@ece.cmu.edu  Fri Aug 31 04:06:30 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26566
	for <ips-archive@odin.ietf.org>; Fri, 31 Aug 2001 04:06:30 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7V6gC304541
	for ips-outgoing; Fri, 31 Aug 2001 02:42:12 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from TYO201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.214])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7V6gAP04535
	for <ips@ece.cmu.edu>; Fri, 31 Aug 2001 02:42:10 -0400 (EDT)
Received: from mailgate4.nec.co.jp ([10.7.69.193])
	by TYO201.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id f7V6g0a13902
	for <ips@ece.cmu.edu>; Fri, 31 Aug 2001 15:42:00 +0900 (JST)
Received: from mailsv.nec.co.jp (mailgate51.nec.co.jp [10.7.69.190]) by mailgate4.nec.co.jp (8.11.3/3.7W-MAILGATE-NEC) with ESMTP
	id f7V6fx617022; Fri, 31 Aug 2001 15:41:59 +0900 (JST)
Received: from fmail01.nw1.file.fc.nec.co.jp (fmail01.nw1.file.fc.nec.co.jp [10.33.80.1]) by mailsv.nec.co.jp (8.11.3/3.7W-MAILSV-NEC) with ESMTP
	id f7V6fj828379; Fri, 31 Aug 2001 15:41:57 +0900 (JST)
Received: from fcfiledbp149 (fcfilespe149.file.fc.nec.co.jp [10.33.80.149])
	by fmail01.nw1.file.fc.nec.co.jp (8.9.3/3.7W/11/11/99) with SMTP id PAA18707;
	Fri, 31 Aug 2001 15:41:45 +0900 (JST)
Message-Id: <200108310641.PAA18707@fmail01.nw1.file.fc.nec.co.jp>
To: ips@ece.cmu.edu
Subject: remove
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
From: remove <yone@nw1.file.fc.nec.co.jp>
Date: Fri, 31 Aug 2001 15:46:48 +09:00
X-Mailer: WeMail32[1.74] ID:FILE00
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

remove


From owner-ips@ece.cmu.edu  Fri Aug 31 12:51:11 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10133
	for <ips-archive@odin.ietf.org>; Fri, 31 Aug 2001 12:51:11 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7VFLSW10581
	for ips-outgoing; Fri, 31 Aug 2001 11:21:28 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mxic1.isus.emc.com ([168.159.129.100])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7VFLRP10577
	for <ips@ece.cmu.edu>; Fri, 31 Aug 2001 11:21:27 -0400 (EDT)
Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <R08MXVGR>; Fri, 31 Aug 2001 11:23:28 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD6A2@CORPMX14>
From: Black_David@emc.com
To: hufferd@us.ibm.com
Cc: ips@ece.cmu.edu
Subject: RE: IKE and iSCSI Authentication
Date: Fri, 31 Aug 2001 11:15:05 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

> I really did understand what it take to associate the iSCSI nitiator Name
> with the UserID.  I said that an tight binding table was needed.  I also
> said that you have to be sure that it is kept in sync with the
> Installations User/Password Database/Directory.  You did not refute that,
> just attempted to trivialize the relationship table that 
> needs to be built.
> 
> We have never address this Table as part of iSCSI before, and it is
> important that everyone understands this, and that we understand how it is
> to be kept in sync with the installations User/Password Directory.  As
part
> of doing this, we need to really understand what directories prevent our
> use of iSCSI Node Names, and which permit it.  We need to understand if it
> is possible to have more then one UserID associated with a single iSCSI
> Node Name, etc.

John,

The conventional name for this "Table" is an Access Control List (ACL).
Between LUN masking/mapping and management products, this is already a
familiar
concept in storage systems.  If the number of targets is a concern, there
are well-known ways to make ACLs scalable.  In practice, keeping ACLs in
sync with the enterprise authentication system is not that difficult -
only the userids appear in the ACLs, and hence they aren't changed when
a password is changed because the password-related data is passed to an
external server for verification.  Administration of userid changes can
consume some time, but administrators of secure internal web sites seem
to have mastered this.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


From owner-ips@ece.cmu.edu  Fri Aug 31 12:56:46 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10262
	for <ips-archive@odin.ietf.org>; Fri, 31 Aug 2001 12:56:46 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7VFZt911507
	for ips-outgoing; Fri, 31 Aug 2001 11:35:55 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7VFZrP11502
	for <ips@ece.cmu.edu>; Fri, 31 Aug 2001 11:35:53 -0400 (EDT)
Received: from xparelay2.corp.hp.com (unknown [15.58.137.112])
	by palrel2.hp.com (Postfix) with ESMTP id E9D9D1534
	for <ips@ece.cmu.edu>; Fri, 31 Aug 2001 08:35:48 -0700 (PDT)
Received: from xpabh1.corp.hp.com (xpabh1.corp.hp.com [15.58.136.191])
	by xparelay2.corp.hp.com (Postfix) with ESMTP id 9E0031F529
	for <ips@ece.cmu.edu>; Fri, 31 Aug 2001 08:35:48 -0700 (PDT)
Received: by xpabh1.corp.hp.com with Internet Mail Service (5.5.2653.19)
	id <QVBBAQ7C>; Fri, 31 Aug 2001 08:35:48 -0700
Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF0A2@xrose06.rose.hp.com>
From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
To: ips@ece.cmu.edu
Subject: RE: iSCSI: login issue - partial consensus call
Date: Fri, 31 Aug 2001 08:35:45 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

One clarification..

> This is also Venkat's concern - unintentional reuse of an ISID
> by the same Initiator:
> 
> > 2. There is some value in protecting an accidental use of an
> > existing ISID by a second client (ISID=<existing>, TSID=0).
> > This can be done with a Reject of the login attempt,
> 
> In contrast to some of the responses to Venkat, I interpret
> "client" to mean another iSCSI port on the same Initiator, and
> then his concern matches Julian's. 

"Another port on the same initiator" by definition has a different ISID and
thus this problem is not possible.  Maybe you mean another iSCSI driver?


> Venkat seems to think that
> there's a useful distinction between boot scenarios in t which
> teardown of existing sessions is needed and boot scenarios
> in which it's not needed

I haven't seen any examples where teardown of the dup session would not be
the desired behavior (or would be harmful).  That's the rationale I'd like
to hear.  If there isn't any conceivable use of the login reject
information, then perhaps it would satisfy Julian and others if we could
maintain the behavior of option A, but inform the initiator (via some sort
of reponse code) that an existing session had been aborted as a result of
this login?

Marj


From owner-ips@ece.cmu.edu  Fri Aug 31 12:58:52 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10334
	for <ips-archive@odin.ietf.org>; Fri, 31 Aug 2001 12:58:52 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7VFoVh12404
	for ips-outgoing; Fri, 31 Aug 2001 11:50:31 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mxic2.us.dg.com (mxic2.us.dg.com [128.221.31.40])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7VFoTP12396
	for <ips@ece.cmu.edu>; Fri, 31 Aug 2001 11:50:29 -0400 (EDT)
Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19)
	id <RX0AC6Q5>; Fri, 31 Aug 2001 11:48:06 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD6A3@CORPMX14>
From: Black_David@emc.com
To: marjorie_krueger@hp.com, ips@ece.cmu.edu
Subject: RE: iSCSI: login issue - partial consensus call
Date: Fri, 31 Aug 2001 11:44:06 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

> One clarification..
> 
> > This is also Venkat's concern - unintentional reuse of an ISID
> > by the same Initiator:
> > 
> > > 2. There is some value in protecting an accidental use of an
> > > existing ISID by a second client (ISID=<existing>, TSID=0).
> > > This can be done with a Reject of the login attempt,
> > 
> > In contrast to some of the responses to Venkat, I interpret
> > "client" to mean another iSCSI port on the same Initiator, and
> > then his concern matches Julian's. 
> 
> "Another port on the same initiator" by definition has a different ISID
and
> thus this problem is not possible.  Maybe you mean another iSCSI driver?

Looks like I should have capitalized Initiator, as I meant it in the sense
that iSCSI defines the term.  The potential scenario here is two different
iSCSI boards are part of the same iSCSI Initiator, and something goes wrong
in the ISID coordination that has to happen between them.  Two different
device drivers is one way to increase the ways to get this wrong (yes,
the ISIDs are supposed to be different, but they're set up dynamically
between the devices and their drivers, and software bugs happen).

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


From owner-ips@ece.cmu.edu  Fri Aug 31 13:00:13 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10372
	for <ips-archive@odin.ietf.org>; Fri, 31 Aug 2001 13:00:12 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7VG1PZ13063
	for ips-outgoing; Fri, 31 Aug 2001 12:01:26 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e33.bld.us.ibm.com (e33.co.us.ibm.com [32.97.110.131])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7VG1JP13046
	for <ips@ece.cmu.edu>; Fri, 31 Aug 2001 12:01:19 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e33.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA10032
	for <ips@ece.cmu.edu>; Fri, 31 Aug 2001 10:59:06 -0500
Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7VG01l134210
	for <ips@ece.cmu.edu>; Fri, 31 Aug 2001 10:00:01 -0600
Importance: Normal
Subject: Re: iSCSI: definition of TSID (2.11.4 of draft 07)
To: ips@ece.cmu.edu
From: "Jim Hafner" <hafner@almaden.ibm.com>
Date: Fri, 31 Aug 2001 08:59:59 -0700
Message-ID: <OF6B53FDD9.F7A4C274-ON88256AB9.005599EB@boulder.ibm.com>
X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at
 08/31/2001 09:00:01 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


Mallikarjun,

Comments in line.

Jim Hafner


"Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on 08/30/2001 09:57:09 pm

Please respond to cbm@rose.hp.com

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  Re: iSCSI: definition of TSID (2.11.4 of draft 07)



Jim,

Sorry, I was travelling, so couldn't get back sooner.  Let me say first
off that I am not disagreeing with you, only suggesting more explicit
wording.

I see that the text you sent offline does contain "assumption A" stated
explicitly - thanks.  I believe that's necessary since one could very
well
attach new connections to an existing SSID when its uniqueness is
maintained
between just the target portal group and the initiator.

I am still though missing the rationale for mandating uniqueness of SSID
between the target (across all portals) and initiator.  I assume target
knows the portal group based on which IP address the login arrives on -
eventhough not explicitly carried in the payload.

<JLH>
Are you saying that iSCSI *doesn't* need to ensure uniquess of SSID between
a single iSCSI initiator and single iSCSI target?  Is that because of
"locality" within the portal group?  Curious!   I had asked a number of
months ago what the value of the SSID was in the first place!  I had
thought that it was to parallel the S_ID, D_ID of FC, but the answer I got
was "NO", it's just to give each end an inband handle for a session
context.  I took that to imply some uniqueness.  Then I leveraged that for
the model.

But I think there might be problems (for one end or the other) if SSIDs are
not unique.  Suppose initiator A opens one session (ISID=1) to target B on
Portal Group X and gets TSID=1.  Then A opens session (ISID=1) to B on TG Y
and again gets TSID=1.  Now, B has done its job of enforcing no repeated
ISID *to the same portal group* but A may be confused when a messages comes
from B with SSID=(1,1).  Unless it *also* tracks the TCP connection as part
of the "session context", it can't tell to what session the message
belongs.  [Note that in this example, B didn't 'partition' TSIDs between
its portal groups -- this is what enabled the duplicate SSID to be
created.]

In short, it is possible for A to "live with" multiple independent sessions
with the same SSID, but it crosses layering (it requires non-iSCSI protocol
handles).  In a nut shell, I think we should require this SSID uniqueness.
</JLH>

Coming to my harping on the nexus identifier, there are two reasons -
 -  It seems to provide a nice rationale for the above issue (refer
    to my previous mail at the bottom on how).  Please set me straight
    if I am totally ignoring something I shouldn't.
 -  You stated that iSCSI is the first transport which opens the
    possibility of "parallel nexus" and so iSCSI mandates implementations
    not to allow it - but appears to stop short of specifying an
    identifier/means to enforce this mandatory requirement.  May be
    it's just me who is troubled by this...
<JLH>
Well, yes, we haven't specified *directly* an identifier/means for
enforcing no parallel nexus.  We have specified the ISID RULE.  Remember
that I said that the nexus is a "relationship" (not an identifier) between
two specific SCSI ports; the ISID RULE prevents two independent such
relationships.  We don't have an explicit (SCSI) nexus identifier mechanism
for checking, but we have an explicit iSCSI identifier mechanism for
checking!.  But, if you prevent the relationship from coming into
existence, then you get no matching nexus identifiers (regardless of how
that might be reasonably defined) for free.

Is this another one of those places where we're not explicit enough in the
text?  :-{)

To ease your mind, I have no objection to adding a sentence that defines
the nexus identifier as the conjunction of the two SCSI portnames and
observe that by this definition and the ISID RULE, two nexus with the same
identifier should never occur.
Does that cover it?
</JLH>




Regards.
--
Mallikarjun

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


Jim Hafner wrote:
>
> Mallikarjun,
>
> There are two assumptions that go into the model and requirements (as I
see
> it).  One is currently implicit in draft-07 and is an iSCSI issue, the
> other is a bit more explicit and is a SCSI issue with iSCSI implications.
> These are
>
> A) (Uniqueness of SIDs) Between a given iSCSI Initiator Node and iSCSI
> Target Node there can be only one session with a given SID.  [This is
> implied by the language that says that a login attempt that uses an
> existing SID=ISID||TSID is an attempt to *add* a connection to the
existing
> session. (This is the response I got from Julian when I suggested making
> this explicit.)
>
> B) (No parallel I_T nexus) Between a given SCSI Initiator Port and SCSI
> Target Port there can be only one nexus.  [With the definition of SCSI
> Initiator Port as the endpoint of a session identified by iSCSI Initiator
> Name + ISID, and with the definition of the SCSI Target Port as the
target
> portal group identified by the iSCSI Target Name + portal group tag, we
get
> the ISID RULE as stated (or intended) in the draft.]
>
> The minimalist requirement is to meet the these two rules (assumptions).
>
> There is a typo in the text you quote.  It should read "The TSID name
space
> of the iSCSI Target should be partitioned among the target portal
groups".
> But as we've discussed this really less of a requirement than it is a
> desirable "note to implementers" (and I'm going to propose that this sort
> of text move to that section).
>
> In what you say below, the "no parallel nexus" (assumption B) is enforced
> by the ISID RULE.  Assumption A (uniquely identified sessions) is
enforced
> if the target does the right thing when selecting a TSID *to pair with*
an
> ISID.  My text for the definition of TSID simply says that the target
> should find a new TSID that enforces Assumption A (no more and no less).
> All the stuff about partitioning name space belongs in "notes to
> implementers".  So, between my proposed definition of TSID and the ISID
> RULE, both assumptions are satisfied and the model works.  No finer
> restrictions are required *by the model*.
>
> Note that in all this description, we haven't had to provide a formal
> definition of "nexus identifier".
> The reason is two fold.  First, independent of what we might use to
> identify them, the I_T nexus is defined as a relationship between a SCSI
> Initiator Port and a SCSI Target Port.  Assumption B says we can't have
two
> such relationships active at one time.  As I've noted above, the ISID
RULE
> enforces that.  Second, the nexus identifier doesn't get used in SAM-2
> explicitly anyway and in SAM-3 it will probably be "up to the transport
to
> define AND relative to the viewpoint of the initiator or target".  That
> last part means that the nexus identifier may not need a globally unique
> value, but may depend on whose end of the nexus you're looking from.
E.g.,
> the target side need only track the "relative target port" and need not
> care about the external address/name/identifier of that port when
defining
> its value for the nexus identifier.  In short, the nexus identifier issue
> is tangential (and we can safely skip it formally).
>
> Jim Hafner
>
> [P.S. See also the proposed rewrite of the relevant draft sections in the
> stuff I sent you off-line, as well, and see if that doesn't help
clarify.]
>
> "Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on 08/28/2001 06:20:16 pm
>
> Please respond to cbm@rose.hp.com
>
> Sent by:  owner-ips@ece.cmu.edu
>
> To:   ips@ece.cmu.edu
> cc:
> Subject:  RE: iSCSI: definition of TSID (2.11.4 of draft 07)
>
> Jim,
>
> Thanks for the explanation.
>
> >The model says that the *combination of ISID || TSID* has to be unique
> >between a given initiator and a given target.
>
> Actually, I do not find this formulation stated anywhere
> in rev07.
>
> The closest about TSID assignment policy is this sentence
> in section 1.5.3: "The TSID name space of the iSCSI Initiator
> should be partitioned among the target portal groups."
> My earlier comments were based on this quote.
>
> More importantly, let me try to understand the reasoning
> behind this formulation.  The only reason that I could come
> up with is to preclude a "parallel nexus".  In our previous
> conversation, we identified two types of nexus ids for this
> enforcement - a)InitiatorName-ISID-TargetName-TargetPortalGroupTag
> b)SSID-InitiatorName-TargetName.  By choosing the stated
> formulation (in conjunction with the ISID RULE), are you
> attempting to ensure that a parallel nexus cannot be created
> if one goes with either definition?
>
> Thanks.
> --
> Mallikarjun
>
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> MS 5668   Hewlett-Packard, Roseville.
> cbm@rose.hp.com
>
> >Mallikarjun,
> >
> >What you suggest is *more* than is required for uniqueness!  Again,
that's
> >an implementation choice that goes beyond the model.
> >
> >The model says that the *combination of ISID || TSID* has to be unique
> >between a given initiator and a given target.
> >When you say " If there are multiple sessions with an initiator, each
> would
> >anyway be assigned a different TSID"  you are assuming that the TSID
alone
> >provide the uniqueness (between a pair).   It can, but it's more than is
> >necessary.
> >
> >In short, you're still selecting an implementation.   Here's two other
> >implementations.  Suppose I have exactly one Target Portal Group.  Then
I
> >can meet the uniqueness requirements by (a) enforcing the ISID RULE and
> (b)
> >using TSID=1 *for every session*!  This one is "minimalist" with respect
> to
> >the model.  (Because there is only one portal group, I can leverage the
> >uniqueness of the ISID to meet the general uniqueness rule -- it's very
> >different if I have more portal groups (see note below)) The
"maximalist"
> >implementation with respect to the model is (a) enforce the ISID RULE
and
> >(b') use a unique TSID for each session I have regardless of initiator
> >name!
> >
> >The spec should say what is required to implement the model.  In my
mind,
> >that's the rule that says the combination of ISID and TSID (the SID)
must
> >be unique between a pair (initiator and target).   And that's all I'm
> >asking for in the definition of TSID.
> >
> >Jim Hafner
> >
> >Note: If I had more than one portal group, I might legitimately see the
> >same ISID (from the same initiator) come in to each portal group.  In
that
> >case, I need to use a different TSID for each such occurrence.  If I
say,
> >for example, that each portal group always uses it's portal group tag as
> >it's TSID (not required, just a choice), then I get uniqueness of SID's
> >again.  This is again, a minimalist implementation with respect to the
> >model.   This also gives an example of why the TSID namespace "should"
be
> >partitioned between the portal groups, so they can always be sure that
> they
> >won't accidentally create an SID that is the same as an existing one.
As
> >long as the "half" of the SID one portal group generates is different
from
> >the half generated by another portal group, there will be no chance of
> >collision.  [This is delegation of naming authority!!!]  The same
> principle
> >holds on the initiator side in how it generates ISIDs.
> >
> >Are we getting closer?
> >
> >"Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on 08/28/2001 04:10:24 pm
> >
> >Please respond to cbm@rose.hp.com
> >
> >Sent by:  owner-ips@ece.cmu.edu
> >
> >
> >To:   Jim Hafner/Almaden/IBM@IBMUS
> >cc:   ips@ece.cmu.edu
> >Subject:  RE: iSCSI: definition of TSID (2.11.4 of draft 07)
> >
> >
> >
> >Jim,
> >
> >I see your point about the current wording possibly suggesting
> >an implementation option.
> >
> >Can I suggest the following text:
> >
> >  The TSID is a target-assigned tag which together with the
InitiatorName
> >  uniquely identifies the session within the target.
> >
> >It appears to me that it's all that's required for uniqueness, I
> >don't think we need to mention ISID here.  If there are multiple
> >sessions with an initiator, each would anyway be assigned a different
> >TSID.  What am I missing?
> >--
> >Mallikarjun
> >
> >
> >Mallikarjun Chadalapaka
> >Networked Storage Architecture
> >Network Storage Solutions Organization
> >MS 5668   Hewlett-Packard, Roseville.
> >cbm@rose.hp.com
> >
> >
> >>Marj,
> >>
> >>Comments in line (as usual...).  But for the person of few words, I'd
> >agree
> >>with just this text (your first sentence only):
> >>
> >>"The TSID is the target assigned tag for a session with a specific
named
> >>initiator
> >>that, together with the ISID uniquely identifies a session with that
> >>initiator."
> >>
> >>(I moved the word "name" around because the session is with the
initiator
> >>not with the name.)
> >>
> >>Jim Hafner
> >>
> >>
> >>"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
> >@ece.cmu.edu
> >>on 08/28/2001 02:46:45 pm
> >>
> >>Sent by:  owner-ips@ece.cmu.edu
> >>
> >>
> >>To:   ips@ece.cmu.edu
> >>cc:
> >>Subject:  RE: iSCSI: definition of TSID (2.11.4 of draft 07)
> >>
> >>
> >>
> >>I'm curious why you've phrased it this way.  I think of it more like;
> >>
> >>"The TSID is the target assigned tag for a session with a specific
> >>initiator
> >>name that, together with the ISID uniquely identifies a session with
that
> >>initiator.
> >><JLH>
> >>I don't really see the subtle difference between this text and mine, so
I
> >>guess I don't have any problem with it.  At least it doesn't bind the
> >>definition to anything SCSI'ish.
> >></JLH>
> >>
> >>However, the target MUST enforce uniqueness of the SSID for a given I_T
> >>combination (in order for login and recovery rules to make sense).
> >><JLH>
> >>I think I see what you're getting at here, but I don't think the words
> >>capture it (it looks like an incorrect use of "I_T nexus" (a SCSI
thing).
> >>Do you mean:
> >>
> >>  "However, the target MUST enforce the uniqueness of the SSID [aside:
> >>isn't this 'SID'?] for sessions with a given initiator."
> >>
> >>If so, I can go with this text, but I think this is stated in other
> places
> >>and need not be here.  But I won't argue if it is also here.
> >></JLH>
> >>
> >>The TSID MAY be a unique tag for a session with a specific initiator
> >name."
> >><JLH>
> >>I don't think this belongs at all.  It is an implementation statement
and
> >>so outside the scope.  It's a true statement, but I don't think it
should
> >>be made explicit (especially in this part of the document -- I'd have
> less
> >>problem with this in the "Notes to Implementers" but even then it is
> >>suggesting a prefered(?) implementation).
> >></JLH>
> >>
> >>I know the last "rule" is more for convenience than to follow the
> >"modeling
> >>rules" (but that's the most straight forward way to implement TSID
> >>assignment?).  From the target viewpoint, it must first set the context
> of
> >>the initiator name, secondly the ISID.
> >><JLH>
> >>First, it's not necessarily the most straightforward way. It could
> >generate
> >>a unique TSID for every session regardless of initiator name.  That
gives
> >>it a twobyte pointer to the session context.  That's a lot more
efficient
> >>(perhaps) than having to also have an initiator name in that "pointer".
> >>So, if you go with your implementation, you have to index on the
> >name+TSID,
> >>and that's too big, so you need an indirect pointer to the context and
at
> >>that point it doesn't really matter what the TSID is relative to other
> >>TSIDs; you can use the name + joint SID=ISID||TSID as your index (it's
> >only
> >>2 bytes more out of a possible 258!).
> >>
> >>So, I argue for no statement about implementation options, leave that
to
> >>the clever programmers!
> >></JLH>
> >>
> >>Marjorie Krueger
> >>Networked Storage Architecture
> >>Networked Storage Solutions Org.
> >>Hewlett-Packard
> >>tel: +1 916 785 2656
> >>fax: +1 916 785 0391
> >>email: marjorie_krueger@hp.com
> >>
> >>> -----Original Message-----
> >>> From: Jim Hafner [mailto:hafner@almaden.ibm.com]
> >>> Sent: Tuesday, August 28, 2001 12:59 PM
> >>> To: ips@ece.cmu.edu
> >>> Subject: iSCSI: definition of TSID (2.11.4 of draft 07)
> >>>
> >>>
> >>> Folks,
> >>>
> >>> The following text defines TSID in referenced document (and with the
> >>> changes proposed by Mallikarjun):
> >>>
> >>> "The TSID is a tag that identifies the SCSI initiator port.
> >>> TSID is set by
> >>> the target.  It MUST be valid only in the final response."
> >>>
> >>> I'm trying to figure out what the TSID has to do with the
> >>> SCSI initiator
> >>> port.  As I understand it, they are completely unrelated (at an
> >>> architecture level).  In implementation may choose to use the
> >>> TSID as a
> >>> pointer to the session in a unique way across all sessions in
> >>> the target or
> >>> in a unique way across all sessions with a given named iSCSI
> >>> initiator or
> >>> it can do any number of other things.  It is, in my opinion,
> >>> unrelated to
> >>> the SCSI initiator port.
> >>>
> >>> I would propose the following alternative text:
> >>>
> >>> "The TSID is a tag set by the target that, together with the ISID,
> >>> identifies a unique session with the initiator."
> >>>
> >>> Comments?
> >>>
> >>> Jim Hafner
> >>>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> >
> >





From owner-ips@ece.cmu.edu  Fri Aug 31 13:52:06 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12036
	for <ips-archive@odin.ietf.org>; Fri, 31 Aug 2001 13:52:06 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7VGKnp14170
	for ips-outgoing; Fri, 31 Aug 2001 12:20:49 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from med.corp.rhapsodynetworks.com (64-160-62-201.rhapsodynetworks.com [64.160.62.201] (may be forged))
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7VG1MP13049
	for <ips@ece.cmu.edu>; Fri, 31 Aug 2001 12:01:22 -0400 (EDT)
Received: by med.corp.rhapsodynetworks.com with Internet Mail Service (5.5.2653.19)
	id <NXFDGB1S>; Fri, 31 Aug 2001 09:01:00 -0700
Message-ID: <45BEF1D68145D51186C100B0D0AABE6503D6D1@med.corp.rhapsodynetworks.com>
From: Venkat Rangan <vrangan@rhapsodynetworks.com>
To: "'Black_David@emc.com'" <Black_David@emc.com>, ips@ece.cmu.edu
Subject: RE: iSCSI: login issue - partial consensus call
Date: Fri, 31 Aug 2001 09:00:55 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


>	Under what circumstances would an Initiator not set the
>	C bit for option B?  What information would the Initiator use
>	to decide not to set the C bit?

The only time an Initiator would set the C bit is when it knows
by its own state that the target needs to be cleaned, i.e., it did not
cleanly logout all sessions cleanly, using a normal shutdown. How this
state is preserved across reboots is implementation detail on the
Initiator.

In any case, this adds complexity on the initiator, for which there
seems to be only marginal benefit.

Venkat Rangan
Rhapsody Networks Inc.
http://www.rhapsodynetworks.com

-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Thursday, August 30, 2001 9:24 PM
To: ips@ece.cmu.edu
Subject: iSCSI: login issue - partial consensus call


A review of this long running thread.  We started out with 
Mallikarjun's three options:

       A) Should iSCSI let it happen by default as stated above (i.e. 
          same ISID, TSID=0 always wipes out the pre-existing session 
          on target, since we are mandating it to be used only when 
          initiator sees a session failure)?
       B) Should iSCSI mandate making this intended cleanup explicit 
          by setting a bit (Say C-bit, for Clear) in the Login Command 
          PDU to prevent an accidental session cleanup with a buggy 
          initiator code? 
       C) Should iSCSI merely state that targets must ascertain 
          the connection state(s) whenever a new session creation
          attempt is made with a known ISID and TSID=0?  (sort of
          defeats the intention of the initiator wanting quicker 
          session recovery since the Login command PDU would have
          to idle till target ascertains the connection state(s)).

Based on my review of the emails, here's what I think the state
of the discussion is:

(1) I see no support for Option C.  The remaining options are A, B, and
	Julian's version of B in which the X bit is reused as the C bit.

(2) I see strong objections to the reuse of the X bit that Julian
	proposed, and no interest in it from anyone other than Julian.
	The objections are that the X bit is already heavily involved
	in error recovery and adding more semantics to it is an invitation
	to trouble. Therefore, I believe the rough consensus of the IPS
	WG is that the X bit is not to be reused in this fashion.

(3) I believe the rough consensus is that the situation being analyzed
	here can occur as a consequence of an initiator reboot (i.e.,
	if the reboot is fast with respect to the target's timeout-based
	session cleanup).

The consensus calls in (2) and (3) are over Julian Satran's proposal/
comments/objection.  Anyone else who objects to these should post to
the list.

This leaves options A and B as originally stated.  Most people seem
to be in favor of option A - the two exceptions I noticed were
Julian and Venkat.  Julian's objection can be summarized with a
couple of quotes:

> Option A is prone to "wild closing of sessions"
> Option A is clearly unacceptable as an initiator may do harm.

The wild closing of sessions seems to be based on a different
iSCSI interface with the same Initiator name using the same
ISID.  This is a definite risk as it's an area in which iSCSI
differs from Fibre Channel.  FC identifies sessions via hardware
identities which tend to be static and unique, and set by the
hardware vendor.  The iSCSI ISID is a dynamically managed
entity, and bugs in managing it across multiple interfaces 
(which may involve hardware and software from multiple
vendors) will cause this session closing problem, whereas for
it to happen in FC, the hardware identity has to be duplicated.

FWIW, I do know of an FC system that rejects duplicate logins
under some circumstances rather than implicitly destroying
the existing session, although I don't believe that behavior
can be overridden via inband means as is proposed here.

OTOH, a different OS should have different iSCSI Initiator Name,
and denial of service attacks should be foiled by proper use of
authentication.  I also tend to agree with the architectural
point of view that an initiator is in charge of its own sessions.
So, I think Julian has a point here, although some of the things
he's posted are overstated.

This is also Venkat's concern - unintentional reuse of an ISID
by the same Initiator:

> 2. There is some value in protecting an accidental use of an
> existing ISID by a second client (ISID=<existing>, TSID=0).
> This can be done with a Reject of the login attempt,

In contrast to some of the responses to Venkat, I interpret
"client" to mean another iSCSI port on the same Initiator, and
then his concern matches Julian's.  Venkat seems to think that
there's a useful distinction between boot scenarios in which
teardown of existing sessions is needed and boot scenarios
in which it's not needed  - I have no idea how to figure that
out in practice, and suspect that Marj is right when she says
that the C bit will be set all the time.  I agree that the
C bit is always set in a session recovery scenario because
the intent is to blow away the existing session.

So, I'm not ready to call consensus on the A vs. B. issue.
In hopes of making further progress, I would ask the
proponents of B (Venkat, Julian, and anyone else who thinks
this is valuable - I assume Julian prefers B to A, even if
the WG does not like using the X bit for B) to post short
answers to the following questions:

	Under what circumstances would an Initiator not set the
	C bit for option B?  What information would the Initiator use
	to decide not to set the C bit?

I apologize if this was in some of the emails and I missed
it - there were a lot of them.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


From owner-ips@ece.cmu.edu  Fri Aug 31 13:53:52 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12063
	for <ips-archive@odin.ietf.org>; Fri, 31 Aug 2001 13:53:47 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7VGKPo14146
	for ips-outgoing; Fri, 31 Aug 2001 12:20:25 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from med.corp.rhapsodynetworks.com (64-160-62-201.rhapsodynetworks.com [64.160.62.201] (may be forged))
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7VFljP12238
	for <ips@ece.cmu.edu>; Fri, 31 Aug 2001 11:47:46 -0400 (EDT)
Received: by med.corp.rhapsodynetworks.com with Internet Mail Service (5.5.2653.19)
	id <NXFDGB1J>; Fri, 31 Aug 2001 08:47:29 -0700
Message-ID: <45BEF1D68145D51186C100B0D0AABE6503D6D0@med.corp.rhapsodynetworks.com>
From: Venkat Rangan <vrangan@rhapsodynetworks.com>
To: "'Black_David@emc.com'" <Black_David@emc.com>, ips@ece.cmu.edu
Subject: RE: iSCSI: login issue - partial consensus call
Date: Fri, 31 Aug 2001 08:47:27 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

David,

Benefits of Option B) appear to be small for the added complexity, so I also
am now convinced that Option A) is a better choice.

Venkat Rangan
Rhapsody Networks Inc.
http://www.rhapsodynetworks.com

-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Thursday, August 30, 2001 9:24 PM
To: ips@ece.cmu.edu
Subject: iSCSI: login issue - partial consensus call


A review of this long running thread.  We started out with 
Mallikarjun's three options:

       A) Should iSCSI let it happen by default as stated above (i.e. 
          same ISID, TSID=0 always wipes out the pre-existing session 
          on target, since we are mandating it to be used only when 
          initiator sees a session failure)?
       B) Should iSCSI mandate making this intended cleanup explicit 
          by setting a bit (Say C-bit, for Clear) in the Login Command 
          PDU to prevent an accidental session cleanup with a buggy 
          initiator code? 
       C) Should iSCSI merely state that targets must ascertain 
          the connection state(s) whenever a new session creation
          attempt is made with a known ISID and TSID=0?  (sort of
          defeats the intention of the initiator wanting quicker 
          session recovery since the Login command PDU would have
          to idle till target ascertains the connection state(s)).

Based on my review of the emails, here's what I think the state
of the discussion is:

(1) I see no support for Option C.  The remaining options are A, B, and
	Julian's version of B in which the X bit is reused as the C bit.

(2) I see strong objections to the reuse of the X bit that Julian
	proposed, and no interest in it from anyone other than Julian.
	The objections are that the X bit is already heavily involved
	in error recovery and adding more semantics to it is an invitation
	to trouble. Therefore, I believe the rough consensus of the IPS
	WG is that the X bit is not to be reused in this fashion.

(3) I believe the rough consensus is that the situation being analyzed
	here can occur as a consequence of an initiator reboot (i.e.,
	if the reboot is fast with respect to the target's timeout-based
	session cleanup).

The consensus calls in (2) and (3) are over Julian Satran's proposal/
comments/objection.  Anyone else who objects to these should post to
the list.

This leaves options A and B as originally stated.  Most people seem
to be in favor of option A - the two exceptions I noticed were
Julian and Venkat.  Julian's objection can be summarized with a
couple of quotes:

> Option A is prone to "wild closing of sessions"
> Option A is clearly unacceptable as an initiator may do harm.

The wild closing of sessions seems to be based on a different
iSCSI interface with the same Initiator name using the same
ISID.  This is a definite risk as it's an area in which iSCSI
differs from Fibre Channel.  FC identifies sessions via hardware
identities which tend to be static and unique, and set by the
hardware vendor.  The iSCSI ISID is a dynamically managed
entity, and bugs in managing it across multiple interfaces 
(which may involve hardware and software from multiple
vendors) will cause this session closing problem, whereas for
it to happen in FC, the hardware identity has to be duplicated.

FWIW, I do know of an FC system that rejects duplicate logins
under some circumstances rather than implicitly destroying
the existing session, although I don't believe that behavior
can be overridden via inband means as is proposed here.

OTOH, a different OS should have different iSCSI Initiator Name,
and denial of service attacks should be foiled by proper use of
authentication.  I also tend to agree with the architectural
point of view that an initiator is in charge of its own sessions.
So, I think Julian has a point here, although some of the things
he's posted are overstated.

This is also Venkat's concern - unintentional reuse of an ISID
by the same Initiator:

> 2. There is some value in protecting an accidental use of an
> existing ISID by a second client (ISID=<existing>, TSID=0).
> This can be done with a Reject of the login attempt,

In contrast to some of the responses to Venkat, I interpret
"client" to mean another iSCSI port on the same Initiator, and
then his concern matches Julian's.  Venkat seems to think that
there's a useful distinction between boot scenarios in which
teardown of existing sessions is needed and boot scenarios
in which it's not needed  - I have no idea how to figure that
out in practice, and suspect that Marj is right when she says
that the C bit will be set all the time.  I agree that the
C bit is always set in a session recovery scenario because
the intent is to blow away the existing session.

So, I'm not ready to call consensus on the A vs. B. issue.
In hopes of making further progress, I would ask the
proponents of B (Venkat, Julian, and anyone else who thinks
this is valuable - I assume Julian prefers B to A, even if
the WG does not like using the X bit for B) to post short
answers to the following questions:

	Under what circumstances would an Initiator not set the
	C bit for option B?  What information would the Initiator use
	to decide not to set the C bit?

I apologize if this was in some of the emails and I missed
it - there were a lot of them.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


From owner-ips@ece.cmu.edu  Fri Aug 31 13:56:09 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12142
	for <ips-archive@odin.ietf.org>; Fri, 31 Aug 2001 13:56:07 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7VGjtw15720
	for ips-outgoing; Fri, 31 Aug 2001 12:45:55 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from zcamail05.zca.compaq.com (zcamail05.zca.compaq.com [161.114.32.105])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7VGjqP15714
	for <ips@ece.cmu.edu>; Fri, 31 Aug 2001 12:45:52 -0400 (EDT)
Received: by zcamail05.zca.compaq.com (Postfix, from userid 12345)
	id B3A071902; Fri, 31 Aug 2001 09:49:53 -0700 (PDT)
Received: from exchou-gh02.cca.cpqcorp.net (exchou-gh02.cca.cpqcorp.net [16.110.248.202])
	by zcamail05.zca.compaq.com (Postfix) with ESMTP
	id D1E7F1A9A; Fri, 31 Aug 2001 09:49:52 -0700 (PDT)
Received: by exchou-gh02.cca.cpqcorp.net with Internet Mail Service (5.5.2652.78)
	id <R7G4CAMN>; Fri, 31 Aug 2001 11:45:37 -0500
Message-ID: <31891B757C09184BBFEC5275F85D5595104DB9@cceexc18.americas.cpqcorp.net>
From: "Martin, Nick" <Nick.Martin@compaq.com>
To: "'Black_David@emc.com'" <Black_David@emc.com>, ips@ece.cmu.edu
Subject: RE: iSCSI: login issue - partial consensus call
Date: Fri, 31 Aug 2001 11:45:25 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

David,

I think we should give Initiators both 1) the capability to attempt a "new
login" which can do no harm, but will fail if a session with this ISID in
use, and 2) the capability to force an existing session to reset and
re-login.  I support the idea that the initiator should state its intention,
and if the action would not match the intention, no action is performed, and
an error code is returned.

Given both capabilities, I would always attempt the "new login" first.

In particular this enables independent agents within the same initiator to
attempt a login without knowing all ISIDs in use by other agents.  Each
agent would know the ISID of sessions it had successfully established, but
not the ISIDs for sessions established by others.  It can use the ISIDs it
knows to recover sessions it owns.  If an agent gets a failure attempting to
establish a new session, it would pick a different ISID and retry (or just
quit), rather than disrupting a session of another agent.

I have a big problem with A) where independent agents must know the ISIDs
established by others in order to do no harm.  To clarify independent
agents, this refers to any iSCSI stack which may not be able to co-ordinate
ISIDs with others within the same Initiator.  These could include BIOS ROM,
iSCSI software stacks, and/or iSCSI acceleration hardware or firmware any of
which may be controlling one or more instances of similar, or dissimilar
shared or unshared network interfaces within one or more chassis can which
act as one iSCSI Initiator.  

I support B) without having a strong opinion about C bit versus X bit.

I still have questions about how long we expect it to take for a target to
detect a missing initiator and clean up an old session without being asked
to do so.  (If no-one forces a session to close, how long will it remain
"active" in the target after its initiator fails.)  Also I am unsure of the
proper steps the target should take in attempting to discover or verify a
missing initiator.  Will these be specified, or left to implementors?

Thanks,
Nick
-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Thursday, August 30, 2001 11:24 PM
To: ips@ece.cmu.edu
Subject: iSCSI: login issue - partial consensus call


A review of this long running thread.  We started out with 
Mallikarjun's three options:

       A) Should iSCSI let it happen by default as stated above (i.e. 
          same ISID, TSID=0 always wipes out the pre-existing session 
          on target, since we are mandating it to be used only when 
          initiator sees a session failure)?
       B) Should iSCSI mandate making this intended cleanup explicit 
          by setting a bit (Say C-bit, for Clear) in the Login Command 
          PDU to prevent an accidental session cleanup with a buggy 
          initiator code? 
       C) Should iSCSI merely state that targets must ascertain 
          the connection state(s) whenever a new session creation
          attempt is made with a known ISID and TSID=0?  (sort of
          defeats the intention of the initiator wanting quicker 
          session recovery since the Login command PDU would have
          to idle till target ascertains the connection state(s)).

Based on my review of the emails, here's what I think the state
of the discussion is:

(1) I see no support for Option C.  The remaining options are A, B, and
	Julian's version of B in which the X bit is reused as the C bit.

(2) I see strong objections to the reuse of the X bit that Julian
	proposed, and no interest in it from anyone other than Julian.
	The objections are that the X bit is already heavily involved
	in error recovery and adding more semantics to it is an invitation
	to trouble. Therefore, I believe the rough consensus of the IPS
	WG is that the X bit is not to be reused in this fashion.

(3) I believe the rough consensus is that the situation being analyzed
	here can occur as a consequence of an initiator reboot (i.e.,
	if the reboot is fast with respect to the target's timeout-based
	session cleanup).

The consensus calls in (2) and (3) are over Julian Satran's proposal/
comments/objection.  Anyone else who objects to these should post to
the list.

This leaves options A and B as originally stated.  Most people seem
to be in favor of option A - the two exceptions I noticed were
Julian and Venkat.  Julian's objection can be summarized with a
couple of quotes:

> Option A is prone to "wild closing of sessions"
> Option A is clearly unacceptable as an initiator may do harm.

The wild closing of sessions seems to be based on a different
iSCSI interface with the same Initiator name using the same
ISID.  This is a definite risk as it's an area in which iSCSI
differs from Fibre Channel.  FC identifies sessions via hardware
identities which tend to be static and unique, and set by the
hardware vendor.  The iSCSI ISID is a dynamically managed
entity, and bugs in managing it across multiple interfaces 
(which may involve hardware and software from multiple
vendors) will cause this session closing problem, whereas for
it to happen in FC, the hardware identity has to be duplicated.

FWIW, I do know of an FC system that rejects duplicate logins
under some circumstances rather than implicitly destroying
the existing session, although I don't believe that behavior
can be overridden via inband means as is proposed here.

OTOH, a different OS should have different iSCSI Initiator Name,
and denial of service attacks should be foiled by proper use of
authentication.  I also tend to agree with the architectural
point of view that an initiator is in charge of its own sessions.
So, I think Julian has a point here, although some of the things
he's posted are overstated.

This is also Venkat's concern - unintentional reuse of an ISID
by the same Initiator:

> 2. There is some value in protecting an accidental use of an
> existing ISID by a second client (ISID=<existing>, TSID=0).
> This can be done with a Reject of the login attempt,

In contrast to some of the responses to Venkat, I interpret
"client" to mean another iSCSI port on the same Initiator, and
then his concern matches Julian's.  Venkat seems to think that
there's a useful distinction between boot scenarios in which
teardown of existing sessions is needed and boot scenarios
in which it's not needed  - I have no idea how to figure that
out in practice, and suspect that Marj is right when she says
that the C bit will be set all the time.  I agree that the
C bit is always set in a session recovery scenario because
the intent is to blow away the existing session.

So, I'm not ready to call consensus on the A vs. B. issue.
In hopes of making further progress, I would ask the
proponents of B (Venkat, Julian, and anyone else who thinks
this is valuable - I assume Julian prefers B to A, even if
the WG does not like using the X bit for B) to post short
answers to the following questions:

	Under what circumstances would an Initiator not set the
	C bit for option B?  What information would the Initiator use
	to decide not to set the C bit?

I apologize if this was in some of the emails and I missed
it - there were a lot of them.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


From owner-ips@ece.cmu.edu  Fri Aug 31 13:59:31 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12219
	for <ips-archive@odin.ietf.org>; Fri, 31 Aug 2001 13:59:31 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7VGOfl14370
	for ips-outgoing; Fri, 31 Aug 2001 12:24:41 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7VGOdP14364
	for <ips@ece.cmu.edu>; Fri, 31 Aug 2001 12:24:39 -0400 (EDT)
Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <RNJ9A1X9>; Fri, 31 Aug 2001 12:24:30 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD6A5@CORPMX14>
From: Black_David@emc.com
To: ips@ece.cmu.edu
Subject: IPS Draft charter revision
Date: Fri, 31 Aug 2001 12:18:15 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Here's a draft of the revised charter for the IP Storage
WG.  Aside from the schedule update, the following substantial
changes have been made:

- Security requirements reflect the current "MUST implement"
	status of confidentiality.
- Text on bridges and gateways to existing protocols has been
	reworded to avoid any implication that proxy support
	is required.
- We have to finish some of what we're doing before undertaking
	any new protocol encapsulation work.

There have also been some minor editorial cleanups.

Comments to the list, please.  This'll go to the Area Directors
for approval and posting on the IETF web site in about a week.

Thanks,
--David

IP Storage (ips) 

Chair(s):
Elizabeth Rodriguez <egrodriguez@lucent.com>
David Black <black_david@emc.com>

Transport Area Director(s): 
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@isi.edu>

Transport Area Advisor: 
Allison Mankin <mankin@isi.edu>

Technical Advisor(s): 
Keith McCloghrie <kzm@cisco.com>

Mailing Lists: 
General Discussion:ips@ece.cmu.edu 
To Subscribe: ips-request@ece.cmu.edu 
In Body: subscribe ips 
Archive: http://www.pdl.cmu.edu/mailinglists/ips/mail/maillist.html 

Description of Working Group: 
There is significant interest in using IP-based networks to transport block
storage
traffic. This group will pursue the pragmatic approach of encapsulating
existing
protocols, such as SCSI and Fibre Channel, in an IP-based transport or
transports.
The group will focus on the transport or transports and related issues
(e.g.,
security, naming, discovery, and configuration), as opposed to modifying
existing protocols. Standards for the protocols to be encapsulated are
controlled
by other standards organizations (e.g., T10 [SCSI] and T11 [Fibre Channel]).
The
WG cannot assume that any changes it desires will be made in these
standards, and
hence will pursue approaches that do not depend on such changes unless they
are
unavoidable. In that case the WG will create a document to be forwarded to
the
standards group responsible for the technology explaining the issue and
requesting
the desired changes be considered. The WG will endeavor to ensure high
quality
communications with these standards organizations. The WG will consider
whether
a layered architecture providing common transport, security, and/or other
functionality for its encapsulations is the best technical approach.

The protocols to be encapsulated expect a reliable transport, in that
failure to
deliver data is considered to be a rare event for which time-consuming
recovery
at higher levels is acceptable. This has implications for both the choice of
transport protocols and design of the encapsulation(s). The WG's
encapsulations
may require quality of service assurances (e.g., bounded latency) to operate
successfully; the WG will consider what assurances are appropriate and how
to
provide them in shared traffic environments (e.g., the Internet) based on
existing IETF QoS mechanisms such as Differentiated Services. 

Use of IP-based transports raises issues that do not occur in the existing
transports for the protocols to be encapsulated.  The WG's protocol
encapsulations will incorporate the following: 

- Congestion control suitable for shared traffic network environments such
as the
	Internet. 
- Security including authentication, keyed cryptographic data integrity
	and confidentiality, sufficient to defend against threats up to and
including
	those that can be expected on a public network.  Implementation of
basic
	security functionality will be required, although usage may be
optional.

The WG will also address the following issues related to its protocol
encapsulations:

- Naming and discovery mechanisms for the encapsulated protocols on IP-based
	networks, including both discovery of resources (e.g., storage) for
	access by the discovering entity, and discovery for management. 
- Management, including appropriate MIB definition(s). 

These may be addressed is documents separate from the main protocol
specifications.

The WG specifications will allow the implementation of bridges and gateways
that connect to existing implementations of the encapsulated protocols.
The WG will preserve the approaches to discovery, multi-pathing, booting,
and
similar issues taken by the protocols it encapsulates to the extent
feasible. 

It may be necessary for traffic utilizing the WG's encapsulations to pass
through
Network Address Translators (NATs) and/or firewalls in some circumstances;
the
WG will endeavor to design NAT- and firewall-friendly protocols that do not
dynamically select target ports or require Application Level Gateways. 

Effective implementations of some IP transports for the encapsulated
protocols
are likely to require hardware acceleration; the WG will consider issues
concerning
the effective implementation of its protocols in hardware. 

The standard internet checksum is weaker than the checksums use by other
implementations of the protocols to be encapsulated. The WG will consider
what
levels of data integrity assurance are required and how they should be
achieved. 

The WG will produce requirements and specification documents for each
protocol
encapsulation, and may produce applicability statements. The requirements
and
specification documents will consider both disk and tape devices, taking
note
of the variation in scale from single drives to large disk arrays and tape
libraries, although the requirements and specifications need not encompass
all such devices. 

The WG will not work on: 

- Extensions to existing protocols such as SCSI and Fibre Channel beyond
	those strictly necessary for the use of IP-based transports. 
- Modifications to internet transport protocols or approaches requiring
	transport protocol options that are not widely supported, although
the
	WG may recommend use of such options for block storage traffic. 
- Support for environments in which significant data loss or data corruption
	is acceptable. 
- File system protocols. 

Operational Structure: 

Due to the scope of the task and the need for parallel progress on multiple
work items, the WG effort is organized as follows: 

A technical coordinator will be identified and selected for each protocol
encapsulation adopted as a work item by the group. This person will be
responsible for
coordinating the technical efforts of the group with respect to that
encapsulation,
working with and motivating the document editors, and evangelizing the
group's work
within both the community and relevant external organizations such as T10
and T11. 

In addition to the normal responsibilities of IETF working group chairs, the
IPS
chairs are responsible for selection of coordinators, identifying areas of
technical
commonality and building cross-technology efforts within the group. 

Coordinators for initially important encapsulations: 

SCSI over IP (aka iSCSI): John Hufferd (hufferd@us.ibm.com) 
Fibre Channel (FC-2) over IP: Murali Rajagopal (muralir@lightsand.com) 
iFCP: Franco Travostino (travos@nortelnetworks.com) 

The WG will not undertake any new protocol encapsulation work before
successfully
completing WG Last Call on one or more of the encapsulations that it is
currently
working on.

Goals and Milestones:

Done    Submit final version of iSCSI requirements draft to the IESG for
consideration
		as an Informational RFC.
Oct 01  Post initial version of draft specifying DHCP usage for booting via
iSCSI,
		and revised version of iSCSI boot draft on Internet-Draft
servers.
Dec 01  Meet at Salt Lake City IETF meetings with goal of closing all issues
for main
		protocol specifications.
Feb 02  WG Last Calls on main protocol specifications (iSCSI, iSCSI
naming/discovery
		FCIP, iFCP, FC common encapsulation).
Mar 02  Meet at Minneapolis IETF meetings with goal of closing all issues
for all
		other drafts.
Apr 02  Submit main protocol specifications to IESG.
Apr 02  WG Last Calls on SLP usage, iSCSI boot and iSNS drafts.
Jun 02  Submit SLP usage, iSCSI boot and iSNS drafts to IESG.
Jun 02  WG Last Calls on MIBs
Jul 02  Meet at Yokohama IETF meetings to deal with any remaining issues and
consider
		what (if any) additional work the WG should undertake.
Aug 02  Submit MIB drafts to IESG.


From owner-ips@ece.cmu.edu  Fri Aug 31 14:44:53 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13308
	for <ips-archive@odin.ietf.org>; Fri, 31 Aug 2001 14:44:48 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7VHu3K19791
	for ips-outgoing; Fri, 31 Aug 2001 13:56:03 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7VHu2P19787
	for <ips@ece.cmu.edu>; Fri, 31 Aug 2001 13:56:02 -0400 (EDT)
Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA18073; Fri, 31 Aug 2001 13:55:49 -0400 (EDT)
Message-ID: <3B8FCDF1.56B7E891@cisco.com>
Date: Fri, 31 Aug 2001 12:48:33 -0500
From: Mark Bakke <mbakke@cisco.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686)
X-Accept-Language: en, de
MIME-Version: 1.0
To: John Hufferd <hufferd@us.ibm.com>
CC: Bill Strahm <bill@sanera.net>, "Ips@Ece. Cmu. Edu" <ips@ece.cmu.edu>
Subject: Re: ISCSI: User authentication vs. Machine Authentication for iSCSI
References: <OF7F53A14D.D8E9C3B4-ON88256AB7.0061F075@boulder.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

John-

Just wanted to point out that CHAP does not send passwords
in the clear; it hashes them.  The reason that SRP was chosen
as the MUST over CHAP is that in a non-IPsec environment, 
the CHAP exchange is not as robust as SRP's exchange, and is
more vulnerable to some types of attacks (I can't remember
which ones off-hand).  IPsec provides an authenticated
environment in which to do the CHAP exchange, which takes
care of these potential problems.

--
Mark

John Hufferd wrote:
> 3. Chap can  be used in this environment since the Link is already secure
> and encrypted, and sending the password in what otherwise would have been
> in the clear, is protected by the link encryption.

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054


From owner-ips@ece.cmu.edu  Fri Aug 31 14:48:00 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13358
	for <ips-archive@odin.ietf.org>; Fri, 31 Aug 2001 14:47:55 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7VH9SY17081
	for ips-outgoing; Fri, 31 Aug 2001 13:09:28 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from atlrel7.hp.com (atlrel7.hp.com [192.151.27.9])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7VH9QP17072
	for <ips@ece.cmu.edu>; Fri, 31 Aug 2001 13:09:26 -0400 (EDT)
Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190])
	by atlrel7.hp.com (Postfix) with ESMTP
	id B92311F7D6; Fri, 31 Aug 2001 13:07:55 -0400 (EDT)
Received: from xatlbh4.atl.hp.com (xatlbh4.atl.hp.com [15.45.89.189])
	by xatlrelay1.atl.hp.com (Postfix) with ESMTP
	id DDB911F543; Fri, 31 Aug 2001 13:09:20 -0400 (EDT)
Received: by xatlbh4.atl.hp.com with Internet Mail Service (5.5.2653.19)
	id <R9VKH5PP>; Fri, 31 Aug 2001 13:09:20 -0400
Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF0A7@xrose06.rose.hp.com>
From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
To: "'Martin, Nick'" <Nick.Martin@compaq.com>, ips@ece.cmu.edu
Subject: RE: iSCSI: login issue - partial consensus call
Date: Fri, 31 Aug 2001 13:09:18 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

> In particular this enables independent agents within the same initiator to
> attempt a login without knowing all ISIDs in use by other agents.  Each
> agent would know the ISID of sessions it had successfully  established,
but
> not the ISIDs for sessions established by others.  It can use the ISIDs it
> knows to recover sessions it owns.  If an agent gets a  failure attempting
to
> establish a new session, it would pick a different ISID and 
> retry (or just quit), rather than disrupting a session of another agent.

The intent of the presentation on SCSI/iSCSI modeling, and the text in the
draft, is to illustrate how this example is not a recommended implementation
choice due to the probability of violating the SCSI/iSCSI rules pointed out.
If the "independant agents" had partitioned the ISID space, there would be
no collision on login and no time wasted.  Your illustrated implementation
could spend significant time "trying" ISID's in use by the "other agents".

However, I'm starting to have more sympathy with Julian's concerns due to
the apparent risks of different vendors' initiator implementations not
following the rules.

I just imagined having vendor A's HBA installed and happily servicing
applications, installing vendor B's "plug-n-play" implementation, and having
all A's sessions aborted cause B doesn't know how to play right :-(

Marj


From owner-ips@ece.cmu.edu  Fri Aug 31 14:51:18 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13474
	for <ips-archive@odin.ietf.org>; Fri, 31 Aug 2001 14:51:18 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7VHPIE18001
	for ips-outgoing; Fri, 31 Aug 2001 13:25:18 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7VHPGP17997
	for <ips@ece.cmu.edu>; Fri, 31 Aug 2001 13:25:16 -0400 (EDT)
Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100])
	by atlrel2.hp.com (Postfix) with ESMTP id C8960957
	for <ips@ece.cmu.edu>; Fri, 31 Aug 2001 13:25:08 -0400 (EDT)
Received: (from cbm@localhost) by core.rose.hp.com (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id KAA04531 for ips@ece.cmu.edu; Fri, 31 Aug 2001 10:26:26 -0700 (PDT)
Message-Id: <200108311726.KAA04531@core.rose.hp.com>
Subject: Re: iSCSI: definition of TSID (2.11.4 of draft 07)
To: ips@ece.cmu.edu
Date: Fri, 31 Aug 2001 10:26:26 PDT
Reply-To: cbm@rose.hp.com
From: "Mallikarjun C." <cbm@rose.hp.com>
X-Mailer: Elm [revision: 212.4]
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Jim,

>Now, B has done its job of enforcing no repeated
>ISID *to the same portal group* but A may be confused when a messages comes
>from B with SSID=(1,1).

I assume A knows the iSCSI target portal group for each SSID -
so has a means of distinction without crossing layers into TCP.

But, I see it's simpler to keep it this way.  I am perfectly okay
with this.  Thanks for the explanation.

>I have no objection to adding a sentence that defines
>the nexus identifier as the conjunction of the two SCSI portnames and
>observe that by this definition and the ISID RULE, two nexus with the same
>identifier should never occur.

Thanks, that is a reasonable way of suggesting a means of enforcement.

Regards.
--
Mallikarjun 


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


>Mallikarjun,
>
>Comments in line.
>
>Jim Hafner
>
>
>"Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on 08/30/2001 09:57:09 pm
>
>Please respond to cbm@rose.hp.com
>
>Sent by:  owner-ips@ece.cmu.edu
>
>
>To:   ips@ece.cmu.edu
>cc:
>Subject:  Re: iSCSI: definition of TSID (2.11.4 of draft 07)
>
>
>
>Jim,
>
>Sorry, I was travelling, so couldn't get back sooner.  Let me say first
>off that I am not disagreeing with you, only suggesting more explicit
>wording.
>
>I see that the text you sent offline does contain "assumption A" stated
>explicitly - thanks.  I believe that's necessary since one could very
>well
>attach new connections to an existing SSID when its uniqueness is
>maintained
>between just the target portal group and the initiator.
>
>I am still though missing the rationale for mandating uniqueness of SSID
>between the target (across all portals) and initiator.  I assume target
>knows the portal group based on which IP address the login arrives on -
>eventhough not explicitly carried in the payload.
>
><JLH>
>Are you saying that iSCSI *doesn't* need to ensure uniquess of SSID between
>a single iSCSI initiator and single iSCSI target?  Is that because of
>"locality" within the portal group?  Curious!   I had asked a number of
>months ago what the value of the SSID was in the first place!  I had
>thought that it was to parallel the S_ID, D_ID of FC, but the answer I got
>was "NO", it's just to give each end an inband handle for a session
>context.  I took that to imply some uniqueness.  Then I leveraged that for
>the model.
>
>But I think there might be problems (for one end or the other) if SSIDs are
>not unique.  Suppose initiator A opens one session (ISID=1) to target B on
>Portal Group X and gets TSID=1.  Then A opens session (ISID=1) to B on TG Y
>and again gets TSID=1.  Now, B has done its job of enforcing no repeated
>ISID *to the same portal group* but A may be confused when a messages comes
>from B with SSID=(1,1).  Unless it *also* tracks the TCP connection as part
>of the "session context", it can't tell to what session the message
>belongs.  [Note that in this example, B didn't 'partition' TSIDs between
>its portal groups -- this is what enabled the duplicate SSID to be
>created.]
>
>In short, it is possible for A to "live with" multiple independent sessions
>with the same SSID, but it crosses layering (it requires non-iSCSI protocol
>handles).  In a nut shell, I think we should require this SSID uniqueness.
></JLH>
>
>Coming to my harping on the nexus identifier, there are two reasons -
> -  It seems to provide a nice rationale for the above issue (refer
>    to my previous mail at the bottom on how).  Please set me straight
>    if I am totally ignoring something I shouldn't.
> -  You stated that iSCSI is the first transport which opens the
>    possibility of "parallel nexus" and so iSCSI mandates implementations
>    not to allow it - but appears to stop short of specifying an
>    identifier/means to enforce this mandatory requirement.  May be
>    it's just me who is troubled by this...
><JLH>
>Well, yes, we haven't specified *directly* an identifier/means for
>enforcing no parallel nexus.  We have specified the ISID RULE.  Remember
>that I said that the nexus is a "relationship" (not an identifier) between
>two specific SCSI ports; the ISID RULE prevents two independent such
>relationships.  We don't have an explicit (SCSI) nexus identifier mechanism
>for checking, but we have an explicit iSCSI identifier mechanism for
>checking!.  But, if you prevent the relationship from coming into
>existence, then you get no matching nexus identifiers (regardless of how
>that might be reasonably defined) for free.
>
>Is this another one of those places where we're not explicit enough in the
>text?  :-{)
>
>To ease your mind, I have no objection to adding a sentence that defines
>the nexus identifier as the conjunction of the two SCSI portnames and
>observe that by this definition and the ISID RULE, two nexus with the same
>identifier should never occur.
>Does that cover it?
></JLH>
>
>
>
>
>Regards.
>--
>Mallikarjun
>
>Mallikarjun Chadalapaka
>Networked Storage Architecture
>Network Storage Solutions Organization
>MS 5668 Hewlett-Packard, Roseville.
>cbm@rose.hp.com
>
>
>Jim Hafner wrote:
>>
>> Mallikarjun,
>>
>> There are two assumptions that go into the model and requirements (as I
>see
>> it).  One is currently implicit in draft-07 and is an iSCSI issue, the
>> other is a bit more explicit and is a SCSI issue with iSCSI implications.
>> These are
>>
>> A) (Uniqueness of SIDs) Between a given iSCSI Initiator Node and iSCSI
>> Target Node there can be only one session with a given SID.  [This is
>> implied by the language that says that a login attempt that uses an
>> existing SID=ISID||TSID is an attempt to *add* a connection to the
>existing
>> session. (This is the response I got from Julian when I suggested making
>> this explicit.)
>>
>> B) (No parallel I_T nexus) Between a given SCSI Initiator Port and SCSI
>> Target Port there can be only one nexus.  [With the definition of SCSI
>> Initiator Port as the endpoint of a session identified by iSCSI Initiator
>> Name + ISID, and with the definition of the SCSI Target Port as the
>target
>> portal group identified by the iSCSI Target Name + portal group tag, we
>get
>> the ISID RULE as stated (or intended) in the draft.]
>>
>> The minimalist requirement is to meet the these two rules (assumptions).
>>
>> There is a typo in the text you quote.  It should read "The TSID name
>space
>> of the iSCSI Target should be partitioned among the target portal
>groups".
>> But as we've discussed this really less of a requirement than it is a
>> desirable "note to implementers" (and I'm going to propose that this sort
>> of text move to that section).
>>
>> In what you say below, the "no parallel nexus" (assumption B) is enforced
>> by the ISID RULE.  Assumption A (uniquely identified sessions) is
>enforced
>> if the target does the right thing when selecting a TSID *to pair with*
>an
>> ISID.  My text for the definition of TSID simply says that the target
>> should find a new TSID that enforces Assumption A (no more and no less).
>> All the stuff about partitioning name space belongs in "notes to
>> implementers".  So, between my proposed definition of TSID and the ISID
>> RULE, both assumptions are satisfied and the model works.  No finer
>> restrictions are required *by the model*.
>>
>> Note that in all this description, we haven't had to provide a formal
>> definition of "nexus identifier".
>> The reason is two fold.  First, independent of what we might use to
>> identify them, the I_T nexus is defined as a relationship between a SCSI
>> Initiator Port and a SCSI Target Port.  Assumption B says we can't have
>two
>> such relationships active at one time.  As I've noted above, the ISID
>RULE
>> enforces that.  Second, the nexus identifier doesn't get used in SAM-2
>> explicitly anyway and in SAM-3 it will probably be "up to the transport
>to
>> define AND relative to the viewpoint of the initiator or target".  That
>> last part means that the nexus identifier may not need a globally unique
>> value, but may depend on whose end of the nexus you're looking from.
>E.g.,
>> the target side need only track the "relative target port" and need not
>> care about the external address/name/identifier of that port when
>defining
>> its value for the nexus identifier.  In short, the nexus identifier issue
>> is tangential (and we can safely skip it formally).
>>
>> Jim Hafner
>>
>> [P.S. See also the proposed rewrite of the relevant draft sections in the
>> stuff I sent you off-line, as well, and see if that doesn't help
>clarify.]
>>
>> "Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on 08/28/2001 06:20:16 pm
>>
>> Please respond to cbm@rose.hp.com
>>
>> Sent by:  owner-ips@ece.cmu.edu
>>
>> To:   ips@ece.cmu.edu
>> cc:
>> Subject:  RE: iSCSI: definition of TSID (2.11.4 of draft 07)
>>
>> Jim,
>>
>> Thanks for the explanation.
>>
>> >The model says that the *combination of ISID || TSID* has to be unique
>> >between a given initiator and a given target.
>>
>> Actually, I do not find this formulation stated anywhere
>> in rev07.
>>
>> The closest about TSID assignment policy is this sentence
>> in section 1.5.3: "The TSID name space of the iSCSI Initiator
>> should be partitioned among the target portal groups."
>> My earlier comments were based on this quote.
>>
>> More importantly, let me try to understand the reasoning
>> behind this formulation.  The only reason that I could come
>> up with is to preclude a "parallel nexus".  In our previous
>> conversation, we identified two types of nexus ids for this
>> enforcement - a)InitiatorName-ISID-TargetName-TargetPortalGroupTag
>> b)SSID-InitiatorName-TargetName.  By choosing the stated
>> formulation (in conjunction with the ISID RULE), are you
>> attempting to ensure that a parallel nexus cannot be created
>> if one goes with either definition?
>>
>> Thanks.
>> --
>> Mallikarjun
>>
>> Mallikarjun Chadalapaka
>> Networked Storage Architecture
>> Network Storage Solutions Organization
>> MS 5668   Hewlett-Packard, Roseville.
>> cbm@rose.hp.com
>>
>> >Mallikarjun,
>> >
>> >What you suggest is *more* than is required for uniqueness!  Again,
>that's
>> >an implementation choice that goes beyond the model.
>> >
>> >The model says that the *combination of ISID || TSID* has to be unique
>> >between a given initiator and a given target.
>> >When you say " If there are multiple sessions with an initiator, each
>> would
>> >anyway be assigned a different TSID"  you are assuming that the TSID
>alone
>> >provide the uniqueness (between a pair).   It can, but it's more than is
>> >necessary.
>> >
>> >In short, you're still selecting an implementation.   Here's two other
>> >implementations.  Suppose I have exactly one Target Portal Group.  Then
>I
>> >can meet the uniqueness requirements by (a) enforcing the ISID RULE and
>> (b)
>> >using TSID=1 *for every session*!  This one is "minimalist" with respect
>> to
>> >the model.  (Because there is only one portal group, I can leverage the
>> >uniqueness of the ISID to meet the general uniqueness rule -- it's very
>> >different if I have more portal groups (see note below)) The
>"maximalist"
>> >implementation with respect to the model is (a) enforce the ISID RULE
>and
>> >(b') use a unique TSID for each session I have regardless of initiator
>> >name!
>> >
>> >The spec should say what is required to implement the model.  In my
>mind,
>> >that's the rule that says the combination of ISID and TSID (the SID)
>must
>> >be unique between a pair (initiator and target).   And that's all I'm
>> >asking for in the definition of TSID.
>> >
>> >Jim Hafner
>> >
>> >Note: If I had more than one portal group, I might legitimately see the
>> >same ISID (from the same initiator) come in to each portal group.  In
>that
>> >case, I need to use a different TSID for each such occurrence.  If I
>say,
>> >for example, that each portal group always uses it's portal group tag as
>> >it's TSID (not required, just a choice), then I get uniqueness of SID's
>> >again.  This is again, a minimalist implementation with respect to the
>> >model.   This also gives an example of why the TSID namespace "should"
>be
>> >partitioned between the portal groups, so they can always be sure that
>> they
>> >won't accidentally create an SID that is the same as an existing one.
>As
>> >long as the "half" of the SID one portal group generates is different
>from
>> >the half generated by another portal group, there will be no chance of
>> >collision.  [This is delegation of naming authority!!!]  The same
>> principle
>> >holds on the initiator side in how it generates ISIDs.
>> >
>> >Are we getting closer?
>> >
>> >"Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on 08/28/2001 04:10:24 pm
>> >
>> >Please respond to cbm@rose.hp.com
>> >
>> >Sent by:  owner-ips@ece.cmu.edu
>> >
>> >
>> >To:   Jim Hafner/Almaden/IBM@IBMUS
>> >cc:   ips@ece.cmu.edu
>> >Subject:  RE: iSCSI: definition of TSID (2.11.4 of draft 07)
>> >
>> >
>> >
>> >Jim,
>> >
>> >I see your point about the current wording possibly suggesting
>> >an implementation option.
>> >
>> >Can I suggest the following text:
>> >
>> >  The TSID is a target-assigned tag which together with the
>InitiatorName
>> >  uniquely identifies the session within the target.
>> >
>> >It appears to me that it's all that's required for uniqueness, I
>> >don't think we need to mention ISID here.  If there are multiple
>> >sessions with an initiator, each would anyway be assigned a different
>> >TSID.  What am I missing?
>> >--
>> >Mallikarjun
>> >
>> >
>> >Mallikarjun Chadalapaka
>> >Networked Storage Architecture
>> >Network Storage Solutions Organization
>> >MS 5668   Hewlett-Packard, Roseville.
>> >cbm@rose.hp.com
>> >
>> >
>> >>Marj,
>> >>
>> >>Comments in line (as usual...).  But for the person of few words, I'd
>> >agree
>> >>with just this text (your first sentence only):
>> >>
>> >>"The TSID is the target assigned tag for a session with a specific
>named
>> >>initiator
>> >>that, together with the ISID uniquely identifies a session with that
>> >>initiator."
>> >>
>> >>(I moved the word "name" around because the session is with the
>initiator
>> >>not with the name.)
>> >>
>> >>Jim Hafner
>> >>
>> >>
>> >>"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
>> >@ece.cmu.edu
>> >>on 08/28/2001 02:46:45 pm
>> >>
>> >>Sent by:  owner-ips@ece.cmu.edu
>> >>
>> >>
>> >>To:   ips@ece.cmu.edu
>> >>cc:
>> >>Subject:  RE: iSCSI: definition of TSID (2.11.4 of draft 07)
>> >>
>> >>
>> >>
>> >>I'm curious why you've phrased it this way.  I think of it more like;
>> >>
>> >>"The TSID is the target assigned tag for a session with a specific
>> >>initiator
>> >>name that, together with the ISID uniquely identifies a session with
>that
>> >>initiator.
>> >><JLH>
>> >>I don't really see the subtle difference between this text and mine, so
>I
>> >>guess I don't have any problem with it.  At least it doesn't bind the
>> >>definition to anything SCSI'ish.
>> >></JLH>
>> >>
>> >>However, the target MUST enforce uniqueness of the SSID for a given I_T
>> >>combination (in order for login and recovery rules to make sense).
>> >><JLH>
>> >>I think I see what you're getting at here, but I don't think the words
>> >>capture it (it looks like an incorrect use of "I_T nexus" (a SCSI
>thing).
>> >>Do you mean:
>> >>
>> >>  "However, the target MUST enforce the uniqueness of the SSID [aside:
>> >>isn't this 'SID'?] for sessions with a given initiator."
>> >>
>> >>If so, I can go with this text, but I think this is stated in other
>> places
>> >>and need not be here.  But I won't argue if it is also here.
>> >></JLH>
>> >>
>> >>The TSID MAY be a unique tag for a session with a specific initiator
>> >name."
>> >><JLH>
>> >>I don't think this belongs at all.  It is an implementation statement
>and
>> >>so outside the scope.  It's a true statement, but I don't think it
>should
>> >>be made explicit (especially in this part of the document -- I'd have
>> less
>> >>problem with this in the "Notes to Implementers" but even then it is
>> >>suggesting a prefered(?) implementation).
>> >></JLH>
>> >>
>> >>I know the last "rule" is more for convenience than to follow the
>> >"modeling
>> >>rules" (but that's the most straight forward way to implement TSID
>> >>assignment?).  From the target viewpoint, it must first set the context
>> of
>> >>the initiator name, secondly the ISID.
>> >><JLH>
>> >>First, it's not necessarily the most straightforward way. It could
>> >generate
>> >>a unique TSID for every session regardless of initiator name.  That
>gives
>> >>it a twobyte pointer to the session context.  That's a lot more
>efficient
>> >>(perhaps) than having to also have an initiator name in that "pointer".
>> >>So, if you go with your implementation, you have to index on the
>> >name+TSID,
>> >>and that's too big, so you need an indirect pointer to the context and
>at
>> >>that point it doesn't really matter what the TSID is relative to other
>> >>TSIDs; you can use the name + joint SID=ISID||TSID as your index (it's
>> >only
>> >>2 bytes more out of a possible 258!).
>> >>
>> >>So, I argue for no statement about implementation options, leave that
>to
>> >>the clever programmers!
>> >></JLH>
>> >>
>> >>Marjorie Krueger
>> >>Networked Storage Architecture
>> >>Networked Storage Solutions Org.
>> >>Hewlett-Packard
>> >>tel: +1 916 785 2656
>> >>fax: +1 916 785 0391
>> >>email: marjorie_krueger@hp.com
>> >>
>> >>> -----Original Message-----
>> >>> From: Jim Hafner [mailto:hafner@almaden.ibm.com]
>> >>> Sent: Tuesday, August 28, 2001 12:59 PM
>> >>> To: ips@ece.cmu.edu
>> >>> Subject: iSCSI: definition of TSID (2.11.4 of draft 07)
>> >>>
>> >>>
>> >>> Folks,
>> >>>
>> >>> The following text defines TSID in referenced document (and with the
>> >>> changes proposed by Mallikarjun):
>> >>>
>> >>> "The TSID is a tag that identifies the SCSI initiator port.
>> >>> TSID is set by
>> >>> the target.  It MUST be valid only in the final response."
>> >>>
>> >>> I'm trying to figure out what the TSID has to do with the
>> >>> SCSI initiator
>> >>> port.  As I understand it, they are completely unrelated (at an
>> >>> architecture level).  In implementation may choose to use the
>> >>> TSID as a
>> >>> pointer to the session in a unique way across all sessions in
>> >>> the target or
>> >>> in a unique way across all sessions with a given named iSCSI
>> >>> initiator or
>> >>> it can do any number of other things.  It is, in my opinion,
>> >>> unrelated to
>> >>> the SCSI initiator port.
>> >>>
>> >>> I would propose the following alternative text:
>> >>>
>> >>> "The TSID is a tag set by the target that, together with the ISID,
>> >>> identifies a unique session with the initiator."
>> >>>
>> >>> Comments?
>> >>>
>> >>> Jim Hafner
>> >>>
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>> >
>> >
>> >
>> >
>
>
>




From owner-ips@ece.cmu.edu  Fri Aug 31 15:24:11 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14576
	for <ips-archive@odin.ietf.org>; Fri, 31 Aug 2001 15:24:11 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7VIQaD24741
	for ips-outgoing; Fri, 31 Aug 2001 14:26:36 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7VIQYP24736
	for <ips@ece.cmu.edu>; Fri, 31 Aug 2001 14:26:34 -0400 (EDT)
Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA27613; Fri, 31 Aug 2001 14:26:20 -0400 (EDT)
Message-ID: <3B8FD518.ED422B42@cisco.com>
Date: Fri, 31 Aug 2001 13:19:04 -0500
From: Mark Bakke <mbakke@cisco.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686)
X-Accept-Language: en, de
MIME-Version: 1.0
To: Joshua Tseng <jtseng@NishanSystems.com>
CC: "'Stephen Bailey'" <steph@cs.uchicago.edu>, ips@ece.cmu.edu
Subject: Re: ISCSI: User authentication vs. Machine Authentication for iSCSI
References: <B300BD9620BCD411A366009027C21D9B5BAE36@ariel.nishansystems.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


From a who-owns-what point of view, it's the end user or application
that owns the data on a device.  Neither the device nor the application
really cares about targets or even LUNs; this is all above SCSI.  I
have a picture of this that I used in the interim meeting to discuss
iSCSI authentication requirements; it's at:

ftp://ftpeng.cisco.com/mbakke/iscsi/Visio-iscsi-security-rqmts.pdf

Anyway, the user or application (perhaps a database, or file system
on a host, or just a raw device that's used for something special)
would be, in an ideal world, the entity we might want to authenticate
before granting access to a device.  This is not currently practical,
however, since most operating systems assume responsibility for the
device on behalf of the user or application, and are trusted by the
users and applications sharing an OS to keep track of who-gets-what,
and enforce these rules properly.

Back to iSCSI-land, we can't authenticate anything that's at a
higher layer than the InitiatorName, so from the device's point
of view, the InitiatorName is as far as we can go.  However, an
implementer of an initiator could have the ability to do things
like provide multiple InitiatorNames in the same driver, and have
these InitiatorNames represent more abstract entities than just
the machine itself.  It's the implementation's binding of an iSCSI
InitiatorName to something at a higher level that allows iSCSI to
provide the "user level security" that Steven is talking about.
Most of today's operating systems don't necessarily provide an
easy way to do this, but by allowing the notion of an Initiator
to be separate from the notion of a machine means that future
implementors (or perhaps clever current implementors) will have
a way to provide a more "network-capable" storage stack.

On the target side, there's more potential for flexibility, since
the implementor is not generally subject to regular operation system
stacks and semantics, and can implement whatever access control and/or
authentication scheme he or she wants.  In the end, it would be the
device that matters from an access control point-of-view; this device
can appear behind any number of LUNs behind any number of targets, so
there are a lot of creative ways in which these can be correlated and
different points at which access control can be done.

However, the simplest place to provide access control is at the iSCSI
target.  Considering that a target is no longer bound to one interface,
there is no need for a device to appear behind multiple targets for an
initiator to have multiple paths to it.  This makes the iSCSI target
a very nice, centralized point at which to do access control.  If an
{application, user, O/S} needs another device, it can simply be added
as a logical unit behind a target to which that entity already has the
appropriate access.  If the target device adds another port or changes
addresses, it's added in front of the target itself, and does not matter.
Doing access control at the iSCSI target means that setting it up once
is sufficient; it need not be modified in order to add access to storage,
or add interfaces.  This means that in some cases, the complexity of
SCSI-level access control can be avoided.

At any rate, Josh is also right; iSCSI can only worry about authenticating
its initiator and target endpoints.  However, an implementation at either
end can "map" these endpoints to whatever it wants; there is no restriction
that an initiator or target be mapped to a machine, interface port, or any
other piece of hardware.  Implementations that find ways to map initiators
and targets to the entities that the user really understands will have the
opportunity to provide authentication closer to the "user-level security"
that may be what people really want.

(BTW, I include "applications" as equals to "users"; the "user" for most
block-level storage is usually a filesystem or database, rather than an
actual person).

This was some of what the slide I had presented was getting at; that
although iSCSI cannot be aware of the layers above it, at least it provides
the flexibility in its endpoints to be mapped to upper layers in creative,
and hopefully easier to manage, ways.

(Oh, also BTW, please don't confuse the term "user" in this email with
the "username" used by the CHAP and SRP protocols; they are also separate
concepts).

--
Mark

Joshua Tseng wrote:
> 
> Stephen,
> >
> > I agree with Jim Hafner.  The notion of `user level security' is
> > exactly what iSCSI needs, due to the unique combination of factors
> > that compose an iSCSI system.  In the initial case, where the iSCSI
> > client is the host OS, the OS is fully capable of representing an
> > identity (being a user) and hiding that identity from unprivileged
> > users of that system.
> 
> iSCSI is a transport protocol.  Its role is to transport SCSI commands
> and data.  Therefore, the security associations negotiated during the
> inband iSCSI security login phase should be bound to the principals
> that define the iSCSI endpoints.  I believe this is the "iSCSI Name"
> (formerly WWUI).  Attempting to bind iSCSI security to something that
> sits above iSCSI is a layering violation.  This includes SCSI, OS, or
> user identities, which all should be transparent to iSCSI.
> 
> >
> > > I'm not sure the problem you mentioned is specific to iSCSI
> > as I have seen
> > > a user-level Fibre Channel driver in action.
> >
> > True.  However, the user-mode driver is granted full `control'
> > (i.e. root) privs if it is allowed to execute arbitrary SCSI commands.
> >
> > Access to raw storage has traditionally been a rigidly protected
> > resource, which when granted, gives complete control of the associated
> > domain (which might be more than one system in a SAN or cluster).
> > This is a well-understood characteristic of the raw storage trust
> > model.
> 
> This is SCSI's problem.  You should bring this up with T10.
> 
> Josh
> 
> >
> > In the Berkeley networking model (praise the mighty), access to
> > network communication (other than evesdropping) is not a rigidly
> > protected resource.  The assumption is that the local endpoint is not
> > granted any additional power by being able to communicate arbitrarily,
> > and the remote endpoint must protect itself as appropriate to the
> > service it offers.
> >
> > > The issue here is that the notion of user is an operating system
> > > abstraction and has no meaning in domains in which the
> > > OS has no administrative control (such as a SAN).
> >
> > Not really.  A user is an authenticable identity in any form.  The
> > control is the access provided.
> >
> > > Extending the notion of an user outside the domain of an OS requires
> > > primitives current SAN technology does not support (yet!)
> >
> > I agree that the present infrastructure doesn't support this idea
> > well.  However, what we should do is define our security in such a way
> > that the SAN infrastructure can evolve towards the same type of
> > identity mechanisms that other networking services (try to) support.
> >
> > If we do this right (and I think Jim's got the idea) it can support
> > both `the OS is completely trusted' (for now) and `each user has their
> > own credentials' (later) models.  We just need to make sure we don't
> > do anything stupid like claim that authenticable entity == IP address
> > in the protocol itself.  At present we're not in risk of doing that,
> > but maybe I should come out in support of it just in case :^)
> >
> > I don't think there's any concrete change to what's already specified
> > to support this.  We certainly don't have to dot every I and cross
> > every T on the multiple identities per system model
> > (i.e. authentication and authorization infrastructure needn't
> > instantly be created to solve the full problem), but I guess we should
> > be aware of what we're shooting for as we specify additional security
> > behavior.
> >
> > Steph
> >

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054


From owner-ips@ece.cmu.edu  Fri Aug 31 15:34:59 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14734
	for <ips-archive@odin.ietf.org>; Fri, 31 Aug 2001 15:34:59 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7VHtHA19746
	for ips-outgoing; Fri, 31 Aug 2001 13:55:17 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7VHtFP19741
	for <ips@ece.cmu.edu>; Fri, 31 Aug 2001 13:55:15 -0400 (EDT)
Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100])
	by palrel2.hp.com (Postfix) with ESMTP id 95C1D16B9
	for <ips@ece.cmu.edu>; Fri, 31 Aug 2001 10:55:14 -0700 (PDT)
Received: (from cbm@localhost) by core.rose.hp.com (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id KAA07822 for ips@ece.cmu.edu; Fri, 31 Aug 2001 10:56:32 -0700 (PDT)
Message-Id: <200108311756.KAA07822@core.rose.hp.com>
Subject: iSCSI: error recovery striation for rev08 (Was: iSCSI - open issues - no discussion - recovery levels)
To: ips@ece.cmu.edu
Date: Fri, 31 Aug 2001 10:56:32 PDT
Reply-To: cbm@rose.hp.com
From: "Mallikarjun C." <cbm@rose.hp.com>
X-Mailer: Elm [revision: 212.4]
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

>- on the recovery there is consesus that it is a good idea; there is no
>consensus on how many layers to enforce (I think that 2 - all or nothing is
>a good choice).

I am sure Julian is trying to kick off a discussion here, after 
collaborating with me on the London proposals  :-)

Seriously, Julian and I were both hoping for more comments before
rev08 in this area - which I haven't seen too many of.

Let me state for the record (as I already said in London) that 
all-or-nothing is not to my favor - IMHO, that erects a too steep 
barrier between the two levels.

I however can see the case for considering decreasing the number 
of levels.  Allow me sometime for cogitation on this once rev08 
is published.  I hope to post an alternative scheme of striation 
by the end of next week for WG consideration.  For rev08, current 
plan is to capture what was presented in London, but state clearly
that this area is still under debate.

Thanks.
--
Mallikarjun 


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


>Dear colleagues,
>
>Considering that the next plugfest is getting close and we would like to
>have
>version 08 ready for it.
>
>We have two open items that got little attention on the list up to now:
>
>- taking out the markers and inserting a reference to an external framing
>draft (what is mandatory, what is optional etc.)
>- recovery the recovery levels proposal
>
>The status  with both is as follows:
>
>- on the framing there is consensus that it is a good idea; there is no
>consensus on what is  MUST, SHOULD etc.
>- on the recovery there is consesus that it is a good idea; there is no
>consensus on how many layers to enforce (I think that 2 - all or nothing is
>a good choice).
>
>Regards,
>Julo
>
>
>




From owner-ips@ece.cmu.edu  Fri Aug 31 15:41:19 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14883
	for <ips-archive@odin.ietf.org>; Fri, 31 Aug 2001 15:41:19 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7VIDWD23999
	for ips-outgoing; Fri, 31 Aug 2001 14:13:32 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from cisco.com (cypher.cisco.com [171.69.11.18])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7VIDUP23989
	for <ips@ece.cmu.edu>; Fri, 31 Aug 2001 14:13:30 -0400 (EDT)
Received: (from kzm@localhost)
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id LAA18458;
	Fri, 31 Aug 2001 11:13:14 -0700 (PDT)
From: Keith McCloghrie <kzm@cisco.com>
Message-Id: <200108311813.LAA18458@cisco.com>
Subject: Re: IPS Draft charter revision
To: Black_David@emc.com
Date: Fri, 31 Aug 2001 11:13:14 -0700 (PDT)
Cc: ips@ece.cmu.edu
In-Reply-To: <277DD60FB639D511AC0400B0D068B71ECAD6A5@CORPMX14> from "Black_David@emc.com" at Aug 31, 2001 12:18:15 PM
X-Mailer: ELM [version 2.5 PL1]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

David,

The schedule below lumps all the MIBs together in the Milestones.
However, the various MIBs are at different stages of development.  
I would expect that the first MIB to be completed does not need to
wait for the last.  Do you want to reflect this in the schedule ?

Keith.

> Here's a draft of the revised charter for the IP Storage
> WG.  Aside from the schedule update, the following substantial
> changes have been made:
> 
> - Security requirements reflect the current "MUST implement"
> 	status of confidentiality.
> - Text on bridges and gateways to existing protocols has been
> 	reworded to avoid any implication that proxy support
> 	is required.
> - We have to finish some of what we're doing before undertaking
> 	any new protocol encapsulation work.
> 
> There have also been some minor editorial cleanups.
> 
> Comments to the list, please.  This'll go to the Area Directors
> for approval and posting on the IETF web site in about a week.
> 
> Thanks,
> --David
> 
> IP Storage (ips) 
> 
> Chair(s):
> Elizabeth Rodriguez <egrodriguez@lucent.com>
> David Black <black_david@emc.com>
> 
> Transport Area Director(s): 
> Scott Bradner <sob@harvard.edu>
> Allison Mankin <mankin@isi.edu>
> 
> Transport Area Advisor: 
> Allison Mankin <mankin@isi.edu>
> 
> Technical Advisor(s): 
> Keith McCloghrie <kzm@cisco.com>
> 
> Mailing Lists: 
> General Discussion:ips@ece.cmu.edu 
> To Subscribe: ips-request@ece.cmu.edu 
> In Body: subscribe ips 
> Archive: http://www.pdl.cmu.edu/mailinglists/ips/mail/maillist.html 
> 
> Description of Working Group: 
> There is significant interest in using IP-based networks to transport block
> storage
> traffic. This group will pursue the pragmatic approach of encapsulating
> existing
> protocols, such as SCSI and Fibre Channel, in an IP-based transport or
> transports.
> The group will focus on the transport or transports and related issues
> (e.g.,
> security, naming, discovery, and configuration), as opposed to modifying
> existing protocols. Standards for the protocols to be encapsulated are
> controlled
> by other standards organizations (e.g., T10 [SCSI] and T11 [Fibre Channel]).
> The
> WG cannot assume that any changes it desires will be made in these
> standards, and
> hence will pursue approaches that do not depend on such changes unless they
> are
> unavoidable. In that case the WG will create a document to be forwarded to
> the
> standards group responsible for the technology explaining the issue and
> requesting
> the desired changes be considered. The WG will endeavor to ensure high
> quality
> communications with these standards organizations. The WG will consider
> whether
> a layered architecture providing common transport, security, and/or other
> functionality for its encapsulations is the best technical approach.
> 
> The protocols to be encapsulated expect a reliable transport, in that
> failure to
> deliver data is considered to be a rare event for which time-consuming
> recovery
> at higher levels is acceptable. This has implications for both the choice of
> transport protocols and design of the encapsulation(s). The WG's
> encapsulations
> may require quality of service assurances (e.g., bounded latency) to operate
> successfully; the WG will consider what assurances are appropriate and how
> to
> provide them in shared traffic environments (e.g., the Internet) based on
> existing IETF QoS mechanisms such as Differentiated Services. 
> 
> Use of IP-based transports raises issues that do not occur in the existing
> transports for the protocols to be encapsulated.  The WG's protocol
> encapsulations will incorporate the following: 
> 
> - Congestion control suitable for shared traffic network environments such
> as the
> 	Internet. 
> - Security including authentication, keyed cryptographic data integrity
> 	and confidentiality, sufficient to defend against threats up to and
> including
> 	those that can be expected on a public network.  Implementation of
> basic
> 	security functionality will be required, although usage may be
> optional.
> 
> The WG will also address the following issues related to its protocol
> encapsulations:
> 
> - Naming and discovery mechanisms for the encapsulated protocols on IP-based
> 	networks, including both discovery of resources (e.g., storage) for
> 	access by the discovering entity, and discovery for management. 
> - Management, including appropriate MIB definition(s). 
> 
> These may be addressed is documents separate from the main protocol
> specifications.
> 
> The WG specifications will allow the implementation of bridges and gateways
> that connect to existing implementations of the encapsulated protocols.
> The WG will preserve the approaches to discovery, multi-pathing, booting,
> and
> similar issues taken by the protocols it encapsulates to the extent
> feasible. 
> 
> It may be necessary for traffic utilizing the WG's encapsulations to pass
> through
> Network Address Translators (NATs) and/or firewalls in some circumstances;
> the
> WG will endeavor to design NAT- and firewall-friendly protocols that do not
> dynamically select target ports or require Application Level Gateways. 
> 
> Effective implementations of some IP transports for the encapsulated
> protocols
> are likely to require hardware acceleration; the WG will consider issues
> concerning
> the effective implementation of its protocols in hardware. 
> 
> The standard internet checksum is weaker than the checksums use by other
> implementations of the protocols to be encapsulated. The WG will consider
> what
> levels of data integrity assurance are required and how they should be
> achieved. 
> 
> The WG will produce requirements and specification documents for each
> protocol
> encapsulation, and may produce applicability statements. The requirements
> and
> specification documents will consider both disk and tape devices, taking
> note
> of the variation in scale from single drives to large disk arrays and tape
> libraries, although the requirements and specifications need not encompass
> all such devices. 
> 
> The WG will not work on: 
> 
> - Extensions to existing protocols such as SCSI and Fibre Channel beyond
> 	those strictly necessary for the use of IP-based transports. 
> - Modifications to internet transport protocols or approaches requiring
> 	transport protocol options that are not widely supported, although
> the
> 	WG may recommend use of such options for block storage traffic. 
> - Support for environments in which significant data loss or data corruption
> 	is acceptable. 
> - File system protocols. 
> 
> Operational Structure: 
> 
> Due to the scope of the task and the need for parallel progress on multiple
> work items, the WG effort is organized as follows: 
> 
> A technical coordinator will be identified and selected for each protocol
> encapsulation adopted as a work item by the group. This person will be
> responsible for
> coordinating the technical efforts of the group with respect to that
> encapsulation,
> working with and motivating the document editors, and evangelizing the
> group's work
> within both the community and relevant external organizations such as T10
> and T11. 
> 
> In addition to the normal responsibilities of IETF working group chairs, the
> IPS
> chairs are responsible for selection of coordinators, identifying areas of
> technical
> commonality and building cross-technology efforts within the group. 
> 
> Coordinators for initially important encapsulations: 
> 
> SCSI over IP (aka iSCSI): John Hufferd (hufferd@us.ibm.com) 
> Fibre Channel (FC-2) over IP: Murali Rajagopal (muralir@lightsand.com) 
> iFCP: Franco Travostino (travos@nortelnetworks.com) 
> 
> The WG will not undertake any new protocol encapsulation work before
> successfully
> completing WG Last Call on one or more of the encapsulations that it is
> currently
> working on.
> 
> Goals and Milestones:
> 
> Done    Submit final version of iSCSI requirements draft to the IESG for
> consideration
> 		as an Informational RFC.
> Oct 01  Post initial version of draft specifying DHCP usage for booting via
> iSCSI,
> 		and revised version of iSCSI boot draft on Internet-Draft
> servers.
> Dec 01  Meet at Salt Lake City IETF meetings with goal of closing all issues
> for main
> 		protocol specifications.
> Feb 02  WG Last Calls on main protocol specifications (iSCSI, iSCSI
> naming/discovery
> 		FCIP, iFCP, FC common encapsulation).
> Mar 02  Meet at Minneapolis IETF meetings with goal of closing all issues
> for all
> 		other drafts.
> Apr 02  Submit main protocol specifications to IESG.
> Apr 02  WG Last Calls on SLP usage, iSCSI boot and iSNS drafts.
> Jun 02  Submit SLP usage, iSCSI boot and iSNS drafts to IESG.
> Jun 02  WG Last Calls on MIBs
> Jul 02  Meet at Yokohama IETF meetings to deal with any remaining issues and
> consider
> 		what (if any) additional work the WG should undertake.
> Aug 02  Submit MIB drafts to IESG.
> 



From owner-ips@ece.cmu.edu  Fri Aug 31 16:23:44 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15271
	for <ips-archive@odin.ietf.org>; Fri, 31 Aug 2001 16:23:42 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7VIjgh25810
	for ips-outgoing; Fri, 31 Aug 2001 14:45:42 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f7VIjeP25803
	for <ips@ece.cmu.edu>; Fri, 31 Aug 2001 14:45:40 -0400 (EDT)
Received: from scummy.research.bell-labs.com ([135.104.2.10]) by crufty; Fri Aug 31 14:40:41 EDT 2001
Received: from aura.research.bell-labs.com (aura.research.bell-labs.com [135.104.46.10])
	by scummy.research.bell-labs.com (8.11.4/8.11.4) with ESMTP id f7VIiDl63942;
	Fri, 31 Aug 2001 14:44:13 -0400 (EDT)
Received: from research.bell-labs.com (IDENT:sandeepj@sandeepj-pcmh.research.bell-labs.com [135.104.47.90])
	by aura.research.bell-labs.com (8.9.1/8.9.1) with ESMTP id OAA21211;
	Fri, 31 Aug 2001 14:44:13 -0400 (EDT)
Message-ID: <3B8FDAFD.1867BC70@research.bell-labs.com>
Date: Fri, 31 Aug 2001 14:44:13 -0400
From: Sandeep Joshi <sandeepj@research.bell-labs.com>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-3 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: cbm@rose.hp.com
CC: ips@ece.cmu.edu
Subject: Re: iSCSI: error recovery striation for rev08 (Was: iSCSI - open issues 
 - no discussion - recovery levels)
References: <200108311756.KAA07822@core.rose.hp.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


Mallikarjun,

My vote would be for two levels only.

If its bad weather(transport), you turn on maximum error recovery.
If its good weather, you live with session recovery.
Anything in-between may complicate implementations which
wish to isolate logic paths.

Since you wish to suggest a better division, let me add that
a new scheme for dividing recovery levels would need to be
backed up by potential usage scenarios.  
e.g. if you are doing tape backup, use level A
     if this is within-enterprise access, use level B
     if this is <something..something>, use level C

IMHO, more than two levels would make good sense only if there
were some good real-world scenarios to exploit them.  Otherwise
it may just end up as a case of over-engineering.

-Sandeep
 

"Mallikarjun C." wrote:
> 
> >- on the recovery there is consesus that it is a good idea; there is no
> >consensus on how many layers to enforce (I think that 2 - all or nothing is
> >a good choice).
> 
> I am sure Julian is trying to kick off a discussion here, after
> collaborating with me on the London proposals  :-)
> 
> Seriously, Julian and I were both hoping for more comments before
> rev08 in this area - which I haven't seen too many of.
> 
> Let me state for the record (as I already said in London) that
> all-or-nothing is not to my favor - IMHO, that erects a too steep
> barrier between the two levels.
> 
> I however can see the case for considering decreasing the number
> of levels.  Allow me sometime for cogitation on this once rev08
> is published.  I hope to post an alternative scheme of striation
> by the end of next week for WG consideration.  For rev08, current
> plan is to capture what was presented in London, but state clearly
> that this area is still under debate.
> 
> Thanks.
> --
> Mallikarjun
> 
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> MS 5668 Hewlett-Packard, Roseville.
> cbm@rose.hp.com
> 
> >Dear colleagues,
> >
> >Considering that the next plugfest is getting close and we would like to
> >have
> >version 08 ready for it.
> >
> >We have two open items that got little attention on the list up to now:
> >
> >- taking out the markers and inserting a reference to an external framing
> >draft (what is mandatory, what is optional etc.)
> >- recovery the recovery levels proposal
> >
> >The status  with both is as follows:
> >
> >- on the framing there is consensus that it is a good idea; there is no
> >consensus on what is  MUST, SHOULD etc.
> >- on the recovery there is consesus that it is a good idea; there is no
> >consensus on how many layers to enforce (I think that 2 - all or nothing is
> >a good choice).
> >
> >Regards,
> >Julo
> >
> >
> >


From owner-ips@ece.cmu.edu  Fri Aug 31 17:27:37 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16381
	for <ips-archive@odin.ietf.org>; Fri, 31 Aug 2001 17:27:37 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7VJwHD29952
	for ips-outgoing; Fri, 31 Aug 2001 15:58:17 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7VJwGP29947
	for <ips@ece.cmu.edu>; Fri, 31 Aug 2001 15:58:16 -0400 (EDT)
Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <RNJ9ATJC>; Fri, 31 Aug 2001 15:58:10 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD6A9@CORPMX14>
From: Black_David@emc.com
To: mbakke@cisco.com, ips@ece.cmu.edu
Subject: iSCSI: CHAP and SRP comparison
Date: Fri, 31 Aug 2001 15:51:54 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Quick CHAP comparison to SRP:

- CHAP is vulnerable to an off-line dictionary attack in which
	the attacker captures the traffic and tries passwords
	from a dictionary.  SRP is not.  
- CHAP requires that the password be available as a password
	on the Target.  SRP requires only a password verifier
	from which the password is not readily recoverable.
- CHAP is one-way authentication, SRP is bidirectional
	because the Target demonstrates that it knows the verifier.

IPsec can take care of the first issue by providing an
encrypted channel (attacker has to break the IPsec encryption
key before mounting the dictionary attack against CHAP), and
the third issue by having IKE handle the authentication
in the other direction.  It doesn't help with the second issue,
which is more of an administration issue than a protocol
vulnerability.

--David

> -----Original Message-----
> From: Mark Bakke [mailto:mbakke@cisco.com]
> Sent: Friday, August 31, 2001 1:49 PM
> To: John Hufferd
> Cc: Bill Strahm; Ips@Ece. Cmu. Edu
> Subject: Re: ISCSI: User authentication vs. Machine Authentication for
> iSCSI
> 
> 
> John-
> 
> Just wanted to point out that CHAP does not send passwords
> in the clear; it hashes them.  The reason that SRP was chosen
> as the MUST over CHAP is that in a non-IPsec environment, 
> the CHAP exchange is not as robust as SRP's exchange, and is
> more vulnerable to some types of attacks (I can't remember
> which ones off-hand).  IPsec provides an authenticated
> environment in which to do the CHAP exchange, which takes
> care of these potential problems.
> 
> --
> Mark
> 
> John Hufferd wrote:
> > 3. Chap can  be used in this environment since the Link is 
> already secure
> > and encrypted, and sending the password in what otherwise 
> would have been
> > in the clear, is protected by the link encryption.
> 
> -- 
> Mark A. Bakke
> Cisco Systems
> mbakke@cisco.com
> 763.398.1054
> 


From owner-ips@ece.cmu.edu  Fri Aug 31 17:32:10 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16503
	for <ips-archive@odin.ietf.org>; Fri, 31 Aug 2001 17:32:10 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7VK2mo00204
	for ips-outgoing; Fri, 31 Aug 2001 16:02:48 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mxic1.isus.emc.com ([168.159.129.100])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7VK2gP00198
	for <ips@ece.cmu.edu>; Fri, 31 Aug 2001 16:02:47 -0400 (EDT)
Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <R08MY1FF>; Fri, 31 Aug 2001 16:04:44 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD6AA@CORPMX14>
From: Black_David@emc.com
To: kzm@cisco.com
Cc: ips@ece.cmu.edu
Subject: RE: IPS Draft charter revision
Date: Fri, 31 Aug 2001 15:56:19 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

I can do that, with the caveat that each MIB needs to be
Last Called after its associated protocol.  I'm guessing
that the iSCSI MIB will be done well before the others.
Are there any other MIBs that seem likely to be ready
around the end of the year?  In practice, there's no
problem with completing things before the milestone date on
the charter.

Thanks,
--David

> -----Original Message-----
> From: Keith McCloghrie [mailto:kzm@cisco.com]
> Sent: Friday, August 31, 2001 2:13 PM
> To: Black_David@emc.com
> Cc: ips@ece.cmu.edu
> Subject: Re: IPS Draft charter revision
> 
> 
> David,
> 
> The schedule below lumps all the MIBs together in the Milestones.
> However, the various MIBs are at different stages of development.  
> I would expect that the first MIB to be completed does not need to
> wait for the last.  Do you want to reflect this in the schedule ?
> 
> Keith.
> 
> > Here's a draft of the revised charter for the IP Storage
> > WG.  Aside from the schedule update, the following substantial
> > changes have been made:
> > 
> > - Security requirements reflect the current "MUST implement"
> > 	status of confidentiality.
> > - Text on bridges and gateways to existing protocols has been
> > 	reworded to avoid any implication that proxy support
> > 	is required.
> > - We have to finish some of what we're doing before undertaking
> > 	any new protocol encapsulation work.
> > 
> > There have also been some minor editorial cleanups.
> > 
> > Comments to the list, please.  This'll go to the Area Directors
> > for approval and posting on the IETF web site in about a week.
> > 
> > Thanks,
> > --David
> > 
> > IP Storage (ips) 
> > 
> > Chair(s):
> > Elizabeth Rodriguez <egrodriguez@lucent.com>
> > David Black <black_david@emc.com>
> > 
> > Transport Area Director(s): 
> > Scott Bradner <sob@harvard.edu>
> > Allison Mankin <mankin@isi.edu>
> > 
> > Transport Area Advisor: 
> > Allison Mankin <mankin@isi.edu>
> > 
> > Technical Advisor(s): 
> > Keith McCloghrie <kzm@cisco.com>
> > 
> > Mailing Lists: 
> > General Discussion:ips@ece.cmu.edu 
> > To Subscribe: ips-request@ece.cmu.edu 
> > In Body: subscribe ips 
> > Archive: http://www.pdl.cmu.edu/mailinglists/ips/mail/maillist.html 
> > 
> > Description of Working Group: 
> > There is significant interest in using IP-based networks to 
> transport block
> > storage
> > traffic. This group will pursue the pragmatic approach of 
> encapsulating
> > existing
> > protocols, such as SCSI and Fibre Channel, in an IP-based 
> transport or
> > transports.
> > The group will focus on the transport or transports and 
> related issues
> > (e.g.,
> > security, naming, discovery, and configuration), as opposed 
> to modifying
> > existing protocols. Standards for the protocols to be 
> encapsulated are
> > controlled
> > by other standards organizations (e.g., T10 [SCSI] and T11 
> [Fibre Channel]).
> > The
> > WG cannot assume that any changes it desires will be made in these
> > standards, and
> > hence will pursue approaches that do not depend on such 
> changes unless they
> > are
> > unavoidable. In that case the WG will create a document to 
> be forwarded to
> > the
> > standards group responsible for the technology explaining 
> the issue and
> > requesting
> > the desired changes be considered. The WG will endeavor to 
> ensure high
> > quality
> > communications with these standards organizations. The WG 
> will consider
> > whether
> > a layered architecture providing common transport, 
> security, and/or other
> > functionality for its encapsulations is the best technical approach.
> > 
> > The protocols to be encapsulated expect a reliable 
> transport, in that
> > failure to
> > deliver data is considered to be a rare event for which 
> time-consuming
> > recovery
> > at higher levels is acceptable. This has implications for 
> both the choice of
> > transport protocols and design of the encapsulation(s). The WG's
> > encapsulations
> > may require quality of service assurances (e.g., bounded 
> latency) to operate
> > successfully; the WG will consider what assurances are 
> appropriate and how
> > to
> > provide them in shared traffic environments (e.g., the 
> Internet) based on
> > existing IETF QoS mechanisms such as Differentiated Services. 
> > 
> > Use of IP-based transports raises issues that do not occur 
> in the existing
> > transports for the protocols to be encapsulated.  The WG's protocol
> > encapsulations will incorporate the following: 
> > 
> > - Congestion control suitable for shared traffic network 
> environments such
> > as the
> > 	Internet. 
> > - Security including authentication, keyed cryptographic 
> data integrity
> > 	and confidentiality, sufficient to defend against 
> threats up to and
> > including
> > 	those that can be expected on a public network.  
> Implementation of
> > basic
> > 	security functionality will be required, although usage may be
> > optional.
> > 
> > The WG will also address the following issues related to 
> its protocol
> > encapsulations:
> > 
> > - Naming and discovery mechanisms for the encapsulated 
> protocols on IP-based
> > 	networks, including both discovery of resources (e.g., 
> storage) for
> > 	access by the discovering entity, and discovery for management. 
> > - Management, including appropriate MIB definition(s). 
> > 
> > These may be addressed is documents separate from the main protocol
> > specifications.
> > 
> > The WG specifications will allow the implementation of 
> bridges and gateways
> > that connect to existing implementations of the 
> encapsulated protocols.
> > The WG will preserve the approaches to discovery, 
> multi-pathing, booting,
> > and
> > similar issues taken by the protocols it encapsulates to the extent
> > feasible. 
> > 
> > It may be necessary for traffic utilizing the WG's 
> encapsulations to pass
> > through
> > Network Address Translators (NATs) and/or firewalls in some 
> circumstances;
> > the
> > WG will endeavor to design NAT- and firewall-friendly 
> protocols that do not
> > dynamically select target ports or require Application 
> Level Gateways. 
> > 
> > Effective implementations of some IP transports for the encapsulated
> > protocols
> > are likely to require hardware acceleration; the WG will 
> consider issues
> > concerning
> > the effective implementation of its protocols in hardware. 
> > 
> > The standard internet checksum is weaker than the checksums 
> use by other
> > implementations of the protocols to be encapsulated. The WG 
> will consider
> > what
> > levels of data integrity assurance are required and how 
> they should be
> > achieved. 
> > 
> > The WG will produce requirements and specification 
> documents for each
> > protocol
> > encapsulation, and may produce applicability statements. 
> The requirements
> > and
> > specification documents will consider both disk and tape 
> devices, taking
> > note
> > of the variation in scale from single drives to large disk 
> arrays and tape
> > libraries, although the requirements and specifications 
> need not encompass
> > all such devices. 
> > 
> > The WG will not work on: 
> > 
> > - Extensions to existing protocols such as SCSI and Fibre 
> Channel beyond
> > 	those strictly necessary for the use of IP-based transports. 
> > - Modifications to internet transport protocols or 
> approaches requiring
> > 	transport protocol options that are not widely 
> supported, although
> > the
> > 	WG may recommend use of such options for block storage traffic. 
> > - Support for environments in which significant data loss 
> or data corruption
> > 	is acceptable. 
> > - File system protocols. 
> > 
> > Operational Structure: 
> > 
> > Due to the scope of the task and the need for parallel 
> progress on multiple
> > work items, the WG effort is organized as follows: 
> > 
> > A technical coordinator will be identified and selected for 
> each protocol
> > encapsulation adopted as a work item by the group. This 
> person will be
> > responsible for
> > coordinating the technical efforts of the group with respect to that
> > encapsulation,
> > working with and motivating the document editors, and 
> evangelizing the
> > group's work
> > within both the community and relevant external 
> organizations such as T10
> > and T11. 
> > 
> > In addition to the normal responsibilities of IETF working 
> group chairs, the
> > IPS
> > chairs are responsible for selection of coordinators, 
> identifying areas of
> > technical
> > commonality and building cross-technology efforts within the group. 
> > 
> > Coordinators for initially important encapsulations: 
> > 
> > SCSI over IP (aka iSCSI): John Hufferd (hufferd@us.ibm.com) 
> > Fibre Channel (FC-2) over IP: Murali Rajagopal 
> (muralir@lightsand.com) 
> > iFCP: Franco Travostino (travos@nortelnetworks.com) 
> > 
> > The WG will not undertake any new protocol encapsulation work before
> > successfully
> > completing WG Last Call on one or more of the 
> encapsulations that it is
> > currently
> > working on.
> > 
> > Goals and Milestones:
> > 
> > Done    Submit final version of iSCSI requirements draft to 
> the IESG for
> > consideration
> > 		as an Informational RFC.
> > Oct 01  Post initial version of draft specifying DHCP usage 
> for booting via
> > iSCSI,
> > 		and revised version of iSCSI boot draft on 
> Internet-Draft
> > servers.
> > Dec 01  Meet at Salt Lake City IETF meetings with goal of 
> closing all issues
> > for main
> > 		protocol specifications.
> > Feb 02  WG Last Calls on main protocol specifications (iSCSI, iSCSI
> > naming/discovery
> > 		FCIP, iFCP, FC common encapsulation).
> > Mar 02  Meet at Minneapolis IETF meetings with goal of 
> closing all issues
> > for all
> > 		other drafts.
> > Apr 02  Submit main protocol specifications to IESG.
> > Apr 02  WG Last Calls on SLP usage, iSCSI boot and iSNS drafts.
> > Jun 02  Submit SLP usage, iSCSI boot and iSNS drafts to IESG.
> > Jun 02  WG Last Calls on MIBs
> > Jul 02  Meet at Yokohama IETF meetings to deal with any 
> remaining issues and
> > consider
> > 		what (if any) additional work the WG should undertake.
> > Aug 02  Submit MIB drafts to IESG.
> > 
> 


From owner-ips@ece.cmu.edu  Fri Aug 31 17:32:32 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16517
	for <ips-archive@odin.ietf.org>; Fri, 31 Aug 2001 17:32:32 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7VKaBC02193
	for ips-outgoing; Fri, 31 Aug 2001 16:36:11 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from verdi.jlc.net (mailhost.jlc.net [199.201.159.9])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7VKRrP01751
	for <ips@ece.cmu.edu>; Fri, 31 Aug 2001 16:27:57 -0400 (EDT)
Received: from PKONING.equallogic.com (pm3-204.dialup.jlc.net [206.183.133.204])
	by verdi.jlc.net (Postfix) with ESMTP
	id 88603337A0; Fri, 31 Aug 2001 16:10:36 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15247.61263.778000.70560@gargle.gargle.HOWL>
Date: Fri, 31 Aug 2001 16:10:55 -0400
From: Paul Koning <pkoning@jlc.net>
To: Black_David@emc.com
Cc: bill@sanera.net, ips@ece.cmu.edu
Subject: RE: ISCSI: Required Crytographic transforms for iSCSI
References: <277DD60FB639D511AC0400B0D068B71ECAD68E@CORPMX14>
X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Excerpt of message (sent 30 August 2001) by Black_David@emc.com:
> The good news in the other direction is that we don't need any
> additional language to enable Encryption without a MAC - IKE/ISAKMP
> allows this by omission of negotiation of the MAC (just to confuse
> things, a MAC is an "Authentication Algorithm" in ISAKMP-speak).
> Encryption ("Transform" in ISAKMP-speak, includes both the actual
> crypto algorithm and its operating mode) negotiation cannot
> be omitted for ESP due to design decisions in ESP and ISAKMP,
> hence the need to make "NULL encryption" a "MUST implement".

Please note that Steve Bellovin has shown
(http://www.research.att.com/~smb/papers/badesp.pdf) that this
combination is insecure, and the fact that it is "must" in IPSec is
definitely controversial.  The argument for its existence is that the
security hole goes away if the protocols you carry over IPSec happen
to have their own cryptographic integrity mechanism at a higher layer
AND you check that integrity function in the same system that does the
decrypt.

Refer to Steve's paper for details, it a pretty one.

      paul


From owner-ips@ece.cmu.edu  Fri Aug 31 17:33:16 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16543
	for <ips-archive@odin.ietf.org>; Fri, 31 Aug 2001 17:33:15 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7VKCbF00711
	for ips-outgoing; Fri, 31 Aug 2001 16:12:37 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from cisco.com (cypher.cisco.com [171.69.11.18])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7VKCZP00703
	for <ips@ece.cmu.edu>; Fri, 31 Aug 2001 16:12:35 -0400 (EDT)
Received: (from kzm@localhost)
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id NAA23432;
	Fri, 31 Aug 2001 13:12:23 -0700 (PDT)
From: Keith McCloghrie <kzm@cisco.com>
Message-Id: <200108312012.NAA23432@cisco.com>
Subject: Re: IPS Draft charter revision
To: Black_David@emc.com
Date: Fri, 31 Aug 2001 13:12:23 -0700 (PDT)
Cc: kzm@cisco.com, ips@ece.cmu.edu
In-Reply-To: <277DD60FB639D511AC0400B0D068B71ECAD6AA@CORPMX14> from "Black_David@emc.com" at Aug 31, 2001 03:56:19 PM
X-Mailer: ELM [version 2.5 PL1]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

As you say, the iSCSI MIB would seem to be the only one which is likely
to be done early next year.  So, maybe it's the only one worth
separating out.

Keith.
 
> I can do that, with the caveat that each MIB needs to be
> Last Called after its associated protocol.  I'm guessing
> that the iSCSI MIB will be done well before the others.
> Are there any other MIBs that seem likely to be ready
> around the end of the year?  In practice, there's no
> problem with completing things before the milestone date on
> the charter.
> 
> Thanks,
> --David
> 
> > -----Original Message-----
> > From: Keith McCloghrie [mailto:kzm@cisco.com]
> > Sent: Friday, August 31, 2001 2:13 PM
> > To: Black_David@emc.com
> > Cc: ips@ece.cmu.edu
> > Subject: Re: IPS Draft charter revision
> > 
> > 
> > David,
> > 
> > The schedule below lumps all the MIBs together in the Milestones.
> > However, the various MIBs are at different stages of development.  
> > I would expect that the first MIB to be completed does not need to
> > wait for the last.  Do you want to reflect this in the schedule ?
> > 
> > Keith.
> > 
> > > Here's a draft of the revised charter for the IP Storage
> > > WG.  Aside from the schedule update, the following substantial
> > > changes have been made:
> > > 
> > > - Security requirements reflect the current "MUST implement"
> > > 	status of confidentiality.
> > > - Text on bridges and gateways to existing protocols has been
> > > 	reworded to avoid any implication that proxy support
> > > 	is required.
> > > - We have to finish some of what we're doing before undertaking
> > > 	any new protocol encapsulation work.
> > > 
> > > There have also been some minor editorial cleanups.
> > > 
> > > Comments to the list, please.  This'll go to the Area Directors
> > > for approval and posting on the IETF web site in about a week.
> > > 
> > > Thanks,
> > > --David
> > > 
> > > IP Storage (ips) 
> > > 
> > > Chair(s):
> > > Elizabeth Rodriguez <egrodriguez@lucent.com>
> > > David Black <black_david@emc.com>
> > > 
> > > Transport Area Director(s): 
> > > Scott Bradner <sob@harvard.edu>
> > > Allison Mankin <mankin@isi.edu>
> > > 
> > > Transport Area Advisor: 
> > > Allison Mankin <mankin@isi.edu>
> > > 
> > > Technical Advisor(s): 
> > > Keith McCloghrie <kzm@cisco.com>
> > > 
> > > Mailing Lists: 
> > > General Discussion:ips@ece.cmu.edu 
> > > To Subscribe: ips-request@ece.cmu.edu 
> > > In Body: subscribe ips 
> > > Archive: http://www.pdl.cmu.edu/mailinglists/ips/mail/maillist.html 
> > > 
> > > Description of Working Group: 
> > > There is significant interest in using IP-based networks to 
> > transport block
> > > storage
> > > traffic. This group will pursue the pragmatic approach of 
> > encapsulating
> > > existing
> > > protocols, such as SCSI and Fibre Channel, in an IP-based 
> > transport or
> > > transports.
> > > The group will focus on the transport or transports and 
> > related issues
> > > (e.g.,
> > > security, naming, discovery, and configuration), as opposed 
> > to modifying
> > > existing protocols. Standards for the protocols to be 
> > encapsulated are
> > > controlled
> > > by other standards organizations (e.g., T10 [SCSI] and T11 
> > [Fibre Channel]).
> > > The
> > > WG cannot assume that any changes it desires will be made in these
> > > standards, and
> > > hence will pursue approaches that do not depend on such 
> > changes unless they
> > > are
> > > unavoidable. In that case the WG will create a document to 
> > be forwarded to
> > > the
> > > standards group responsible for the technology explaining 
> > the issue and
> > > requesting
> > > the desired changes be considered. The WG will endeavor to 
> > ensure high
> > > quality
> > > communications with these standards organizations. The WG 
> > will consider
> > > whether
> > > a layered architecture providing common transport, 
> > security, and/or other
> > > functionality for its encapsulations is the best technical approach.
> > > 
> > > The protocols to be encapsulated expect a reliable 
> > transport, in that
> > > failure to
> > > deliver data is considered to be a rare event for which 
> > time-consuming
> > > recovery
> > > at higher levels is acceptable. This has implications for 
> > both the choice of
> > > transport protocols and design of the encapsulation(s). The WG's
> > > encapsulations
> > > may require quality of service assurances (e.g., bounded 
> > latency) to operate
> > > successfully; the WG will consider what assurances are 
> > appropriate and how
> > > to
> > > provide them in shared traffic environments (e.g., the 
> > Internet) based on
> > > existing IETF QoS mechanisms such as Differentiated Services. 
> > > 
> > > Use of IP-based transports raises issues that do not occur 
> > in the existing
> > > transports for the protocols to be encapsulated.  The WG's protocol
> > > encapsulations will incorporate the following: 
> > > 
> > > - Congestion control suitable for shared traffic network 
> > environments such
> > > as the
> > > 	Internet. 
> > > - Security including authentication, keyed cryptographic 
> > data integrity
> > > 	and confidentiality, sufficient to defend against 
> > threats up to and
> > > including
> > > 	those that can be expected on a public network.  
> > Implementation of
> > > basic
> > > 	security functionality will be required, although usage may be
> > > optional.
> > > 
> > > The WG will also address the following issues related to 
> > its protocol
> > > encapsulations:
> > > 
> > > - Naming and discovery mechanisms for the encapsulated 
> > protocols on IP-based
> > > 	networks, including both discovery of resources (e.g., 
> > storage) for
> > > 	access by the discovering entity, and discovery for management. 
> > > - Management, including appropriate MIB definition(s). 
> > > 
> > > These may be addressed is documents separate from the main protocol
> > > specifications.
> > > 
> > > The WG specifications will allow the implementation of 
> > bridges and gateways
> > > that connect to existing implementations of the 
> > encapsulated protocols.
> > > The WG will preserve the approaches to discovery, 
> > multi-pathing, booting,
> > > and
> > > similar issues taken by the protocols it encapsulates to the extent
> > > feasible. 
> > > 
> > > It may be necessary for traffic utilizing the WG's 
> > encapsulations to pass
> > > through
> > > Network Address Translators (NATs) and/or firewalls in some 
> > circumstances;
> > > the
> > > WG will endeavor to design NAT- and firewall-friendly 
> > protocols that do not
> > > dynamically select target ports or require Application 
> > Level Gateways. 
> > > 
> > > Effective implementations of some IP transports for the encapsulated
> > > protocols
> > > are likely to require hardware acceleration; the WG will 
> > consider issues
> > > concerning
> > > the effective implementation of its protocols in hardware. 
> > > 
> > > The standard internet checksum is weaker than the checksums 
> > use by other
> > > implementations of the protocols to be encapsulated. The WG 
> > will consider
> > > what
> > > levels of data integrity assurance are required and how 
> > they should be
> > > achieved. 
> > > 
> > > The WG will produce requirements and specification 
> > documents for each
> > > protocol
> > > encapsulation, and may produce applicability statements. 
> > The requirements
> > > and
> > > specification documents will consider both disk and tape 
> > devices, taking
> > > note
> > > of the variation in scale from single drives to large disk 
> > arrays and tape
> > > libraries, although the requirements and specifications 
> > need not encompass
> > > all such devices. 
> > > 
> > > The WG will not work on: 
> > > 
> > > - Extensions to existing protocols such as SCSI and Fibre 
> > Channel beyond
> > > 	those strictly necessary for the use of IP-based transports. 
> > > - Modifications to internet transport protocols or 
> > approaches requiring
> > > 	transport protocol options that are not widely 
> > supported, although
> > > the
> > > 	WG may recommend use of such options for block storage traffic. 
> > > - Support for environments in which significant data loss 
> > or data corruption
> > > 	is acceptable. 
> > > - File system protocols. 
> > > 
> > > Operational Structure: 
> > > 
> > > Due to the scope of the task and the need for parallel 
> > progress on multiple
> > > work items, the WG effort is organized as follows: 
> > > 
> > > A technical coordinator will be identified and selected for 
> > each protocol
> > > encapsulation adopted as a work item by the group. This 
> > person will be
> > > responsible for
> > > coordinating the technical efforts of the group with respect to that
> > > encapsulation,
> > > working with and motivating the document editors, and 
> > evangelizing the
> > > group's work
> > > within both the community and relevant external 
> > organizations such as T10
> > > and T11. 
> > > 
> > > In addition to the normal responsibilities of IETF working 
> > group chairs, the
> > > IPS
> > > chairs are responsible for selection of coordinators, 
> > identifying areas of
> > > technical
> > > commonality and building cross-technology efforts within the group. 
> > > 
> > > Coordinators for initially important encapsulations: 
> > > 
> > > SCSI over IP (aka iSCSI): John Hufferd (hufferd@us.ibm.com) 
> > > Fibre Channel (FC-2) over IP: Murali Rajagopal 
> > (muralir@lightsand.com) 
> > > iFCP: Franco Travostino (travos@nortelnetworks.com) 
> > > 
> > > The WG will not undertake any new protocol encapsulation work before
> > > successfully
> > > completing WG Last Call on one or more of the 
> > encapsulations that it is
> > > currently
> > > working on.
> > > 
> > > Goals and Milestones:
> > > 
> > > Done    Submit final version of iSCSI requirements draft to 
> > the IESG for
> > > consideration
> > > 		as an Informational RFC.
> > > Oct 01  Post initial version of draft specifying DHCP usage 
> > for booting via
> > > iSCSI,
> > > 		and revised version of iSCSI boot draft on 
> > Internet-Draft
> > > servers.
> > > Dec 01  Meet at Salt Lake City IETF meetings with goal of 
> > closing all issues
> > > for main
> > > 		protocol specifications.
> > > Feb 02  WG Last Calls on main protocol specifications (iSCSI, iSCSI
> > > naming/discovery
> > > 		FCIP, iFCP, FC common encapsulation).
> > > Mar 02  Meet at Minneapolis IETF meetings with goal of 
> > closing all issues
> > > for all
> > > 		other drafts.
> > > Apr 02  Submit main protocol specifications to IESG.
> > > Apr 02  WG Last Calls on SLP usage, iSCSI boot and iSNS drafts.
> > > Jun 02  Submit SLP usage, iSCSI boot and iSNS drafts to IESG.
> > > Jun 02  WG Last Calls on MIBs
> > > Jul 02  Meet at Yokohama IETF meetings to deal with any 
> > remaining issues and
> > > consider
> > > 		what (if any) additional work the WG should undertake.
> > > Aug 02  Submit MIB drafts to IESG.
> > > 
> > 
> 



From owner-ips@ece.cmu.edu  Fri Aug 31 18:10:31 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17051
	for <ips-archive@odin.ietf.org>; Fri, 31 Aug 2001 18:10:31 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7VKsVk03381
	for ips-outgoing; Fri, 31 Aug 2001 16:54:31 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mxic1.isus.emc.com ([168.159.129.100])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7VKsOP03370
	for <ips@ece.cmu.edu>; Fri, 31 Aug 2001 16:54:25 -0400 (EDT)
Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19)
	id <R08MYG1S>; Fri, 31 Aug 2001 16:56:26 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD6AB@CORPMX14>
From: Black_David@emc.com
To: pkoning@jlc.net, ips@ece.cmu.edu
Subject: RE: ISCSI: Required Crytographic transforms for iSCSI
Date: Fri, 31 Aug 2001 16:48:02 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Always check assumptions carefully when reading a security paper ...

The worst of those attacks are enabled by the use of host-pair
keying where all connections between two hosts share the same
key and hence an attacker has a fairly easy time convincing
IPsec to use that key on traffic of the attacker's choice.  The
use of IKE for iSCSI is based on draft-aboba-ips-iscsi-security-00.txt
which recommends per-connection keying (Phase 2 Quick Mode per
TCP connection).

Steve Bellovin's paper indicates that this is a significant
improvement, but the bottom line remains that in the absence
of cryptographic integrity, one is vulnerable to connection
hijacking, some forms of data tampering and/or the injection
of junk into an encrypted connection.  So, while I think Paul's
overstated the case, I also agree that in most cases where
encryption is used, cryptographic integrity is also a requirement.
Making this (use cryptographic integrity when encryption is
in use) at least a "SHOULD" seems reasonable.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


> -----Original Message-----
> From: Paul Koning [mailto:pkoning@jlc.net]
> Sent: Friday, August 31, 2001 4:11 PM
> To: Black_David@emc.com
> Cc: bill@sanera.net; ips@ece.cmu.edu
> Subject: RE: ISCSI: Required Crytographic transforms for iSCSI
> 
> 
> Excerpt of message (sent 30 August 2001) by Black_David@emc.com:
> > The good news in the other direction is that we don't need any
> > additional language to enable Encryption without a MAC - IKE/ISAKMP
> > allows this by omission of negotiation of the MAC (just to confuse
> > things, a MAC is an "Authentication Algorithm" in ISAKMP-speak).
> > Encryption ("Transform" in ISAKMP-speak, includes both the actual
> > crypto algorithm and its operating mode) negotiation cannot
> > be omitted for ESP due to design decisions in ESP and ISAKMP,
> > hence the need to make "NULL encryption" a "MUST implement".
> 
> Please note that Steve Bellovin has shown
> (http://www.research.att.com/~smb/papers/badesp.pdf) that this
> combination is insecure, and the fact that it is "must" in IPSec is
> definitely controversial.  The argument for its existence is that the
> security hole goes away if the protocols you carry over IPSec happen
> to have their own cryptographic integrity mechanism at a higher layer
> AND you check that integrity function in the same system that does the
> decrypt.
> 
> Refer to Steve's paper for details, it a pretty one.
> 
>       paul
> 


From owner-ips@ece.cmu.edu  Fri Aug 31 18:12:51 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17082
	for <ips-archive@odin.ietf.org>; Fri, 31 Aug 2001 18:12:51 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7VL39v03853
	for ips-outgoing; Fri, 31 Aug 2001 17:03:09 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mtvxch12.veritas.com (bay-bridge.veritas.com [143.127.3.10])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7VL36P03848
	for <ips@ece.cmu.edu>; Fri, 31 Aug 2001 17:03:06 -0400 (EDT)
Received: by mtvxch12.veritas.com with Internet Mail Service (5.5.2653.19)
	id <RSQYMSSW>; Fri, 31 Aug 2001 14:04:06 -0700
Message-ID: <C3CC003A39C7D411910F0008C786A64511500A@mtvxch12.veritas.com>
From: Dhanesh Joshi <Dhanesh@veritas.com>
To: "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
Subject: Question about framing support 
Date: Fri, 31 Aug 2001 14:04:01 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Hi,
I came across the proposal "draft-ietf-tsvwg-tcp-ulp-frame-00.txt" about
reducing the overhead of buffer copy and reassembly buffer. I would like to
get such NIC to do some experiments. Is anyone manufacturing such NICs ? I
will appreciated any more help about this. 

thanks !
-- dhanesh joshi
 



From owner-ips@ece.cmu.edu  Fri Aug 31 18:15:46 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17118
	for <ips-archive@odin.ietf.org>; Fri, 31 Aug 2001 18:15:45 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7VLDZx04641
	for ips-outgoing; Fri, 31 Aug 2001 17:13:35 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from e32.bld.us.ibm.com (e32.co.us.ibm.com [32.97.110.130])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7VLDYP04637
	for <ips@ece.cmu.edu>; Fri, 31 Aug 2001 17:13:34 -0400 (EDT)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e32.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA31770;
	Fri, 31 Aug 2001 17:11:21 -0400
Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49])
	by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7VLCHl127832;
	Fri, 31 Aug 2001 15:12:17 -0600
X-Priority: 1 (High)
Importance: Normal
Subject: RE: IKE and iSCSI Authentication
To: Black_David@emc.com
Cc: ips@ece.cmu.edu
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OF1D4332EC.319C960A-ON88256AB9.0073F3C0@boulder.ibm.com>
From: "John Hufferd" <hufferd@us.ibm.com>
Date: Fri, 31 Aug 2001 14:11:40 -0700
X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at
 08/31/2001 03:12:17 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


David,
Up to this point in time the item that we have put into the ACL was the
iSCSI Initiator Node Name, NOT a UserID.  This is a new and different
thought, and we need to completely understand the impact.

We spent a great deal of time making sure that the iSCSI Initiator Node
Name was unique in the world, and now we seem to only care about the
UserID.  There is clearly something new or missing here in our thoughts.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com


Black_David@emc.com@ece.cmu.edu on 08/31/2001 08:15:05 AM

Sent by:  owner-ips@ece.cmu.edu


To:   John Hufferd/San Jose/IBM@IBMUS
cc:   ips@ece.cmu.edu
Subject:  RE: IKE and iSCSI Authentication



> I really did understand what it take to associate the iSCSI nitiator Name
> with the UserID.  I said that an tight binding table was needed.  I also
> said that you have to be sure that it is kept in sync with the
> Installations User/Password Database/Directory.  You did not refute that,
> just attempted to trivialize the relationship table that
> needs to be built.
>
> We have never address this Table as part of iSCSI before, and it is
> important that everyone understands this, and that we understand how it
is
> to be kept in sync with the installations User/Password Directory.  As
part
> of doing this, we need to really understand what directories prevent our
> use of iSCSI Node Names, and which permit it.  We need to understand if
it
> is possible to have more then one UserID associated with a single iSCSI
> Node Name, etc.

John,

The conventional name for this "Table" is an Access Control List (ACL).
Between LUN masking/mapping and management products, this is already a
familiar
concept in storage systems.  If the number of targets is a concern, there
are well-known ways to make ACLs scalable.  In practice, keeping ACLs in
sync with the enterprise authentication system is not that difficult -
only the userids appear in the ACLs, and hence they aren't changed when
a password is changed because the password-related data is passed to an
external server for verification.  Administration of userid changes can
consume some time, but administrators of secure internal web sites seem
to have mastered this.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------





From owner-ips@ece.cmu.edu  Fri Aug 31 19:33:50 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17645
	for <ips-archive@odin.ietf.org>; Fri, 31 Aug 2001 19:33:49 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f7VLrdc06980
	for ips-outgoing; Fri, 31 Aug 2001 17:53:39 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7VLrcP06975
	for <ips@ece.cmu.edu>; Fri, 31 Aug 2001 17:53:38 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-68-173.cisco.com [161.44.68.173]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA20628; Fri, 31 Aug 2001 17:53:32 -0400 (EDT)
Message-ID: <3B90074F.8FE0ACB@cisco.com>
Date: Fri, 31 Aug 2001 16:53:19 -0500
From: Steve Senum <ssenum@cisco.com>
X-Mailer: Mozilla 4.73 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-ips <ips@ece.cmu.edu>, Julian Satran <julian_satran@il.ibm.com>
Subject: Re: iSCSI - Login changes and the latest agreements
References: <OF09E4CA94.762BADDA-ONC2256AB9.001E9C51@telaviv.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Julian,

Ayman and I have spent some time looking at your
latest login proposal.  We believe it solves
all of the issues with login that we knew of,
and provides a bit (no pun intended) cleaner approach.

Though we also think simply requiring the security phase,
including the old SecurityContextComplete=yes
handshake, would have solved the same issues with
draft 07.

The addition of the "C" bit solves our concerns
with the use of only login command/login response
pairs for the entire login sequence.

I have some (mostly) editorial comments on your
current proposal:

1. You might consider changing the name of the
   F (Final) bit to something like the T (Transition)
   bit to help alert implementers that the semantics
   of the bit have changed.

2. In the login header:

       +---------------+---------------+---------------+---------------+
      0|X|I| 0x03      |F|C 0 0| CNxSG | Version-max   | Version-min   |
       +---------------+---------------+---------------+---------------+

   You might want to insert a "|" between the "C" and "0" bits.

3. Section 2.12.3 F (Final) Bit:

      If set to 1 indicates that the initiator has no more parameters to set.

   You might want to change this text to better reflect the F bit's
   expanded role, like you did for section 2.13.1.

4. Section 2.13.1 F (Final) Bit:

   You might want to mention that the target can only set the F bit
   on the response if the initiator set it on the command.

5. Login Response Status Table:

   You should remove code 0002 since it is no longer needed.
   You might also want to remove code 0001, since it seems
   to now provide redundant information with the CNxSG field,
   and remove or simplify the note about status code 0000.

6. End of section 4.1:

   Remove text about when IIN and ITN can be sent, since they
   are now required in the initial Login request.

   Move the sentence:

      The iSCSI Names MUST be in text command format.

   To the paragraph near the begining of section 4 that
   starts "The initial Login request MUST include the
   InitiatorName ...."


Regards,
Steve Senum


From owner-ips@ece.cmu.edu  Fri Aug 31 23:55:37 2001
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23614
	for <ips-archive@odin.ietf.org>; Fri, 31 Aug 2001 23:55:37 -0400 (EDT)
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id f812LXb17661
	for ips-outgoing; Fri, 31 Aug 2001 22:21:33 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from ariel.nishansystems.com (smtp.nishansystems.com [216.217.36.162])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f812LVP17657
	for <ips@ece.cmu.edu>; Fri, 31 Aug 2001 22:21:31 -0400 (EDT)
Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19)
	id <RDTY643C>; Fri, 31 Aug 2001 19:21:12 -0700
Message-ID: <B300BD9620BCD411A366009027C21D9B5BAE60@ariel.nishansystems.com>
From: Joshua Tseng <jtseng@NishanSystems.com>
To: ips@ece.cmu.edu
Subject: iSCSI: Public Key Method
Date: Fri, 31 Aug 2001 19:21:11 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

This message is in response to the action item David Black gave me
at the Interim meeting to investigate the need for a Public Key Method
for iSCSI.

My recommendation is that if we include the Kerberos method in iSCSI,
then we should also include at least one Public Key Method as well.
I don't see any problem with using SPKM-1 and SPKM-2.  The only
difference between them is that SPKM-2 includes a timestamp.

Although Kerberos has been in use for a longer period of time,
public key offers significant scaling advantages.  It is also widely
recognized as the next-generation key distribution method, and
I believe iSCSI should not leave it out.

Some of the key advantages of public key:

1)  Key distribution does not require a secure communication
channel between the communicating principals and the key distribution
authority.  Public keys can be distributed in the clear.  On the
other hand, Kerberos requires an additional set of security associations
between the Kerberos server and every principal, or manual distribution
and configuration of keys, which can be an administrative nightmare.

2)  In Public Key, there is no single point of failure as there is
with a Kerberos Server.  If the Kerberos Server is wiped out in
a DOS attack, no one can access its keys, and no one can talk securely.
Also, if the contents of the Kerberos Server is compromised, anyone
can be impersonated.  On the other hand, if the CA is wiped out,
holders of public keys can still continue to function.  Furthermore,
CA's can be distributed, making them resilient to attacks.

3)  In Public Key, there is no single physical location or device
in the network that can be considered a performance bottleneck.
This is another reason why Public Key is far more scalable than
Kerberos.

4)  Of all the iSCSI authentication methods in the current draft
(KRB5, SRP, CHAP), SPKM-1 and SPKM-2 require the least amount
of manual administration.

Given the above, it makes sense to me that if we include Kerberos,
then we ought to also include Public Key.  We may not need both
SPKM-1 and SPKM-2, but I think we should include at least one of
them.  I believe the current text in the iSCSI document is fine
(good job Ofer!).

Josh