From ips-bounces@ietf.org Mon Jan 02 17:57:14 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtYc6-0004Q2-Jd; Mon, 02 Jan 2006 17:57:14 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtYc4-0004Ps-6x
	for ips@megatron.ietf.org; Mon, 02 Jan 2006 17:57:12 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25070
	for <ips@ietf.org>; Mon, 2 Jan 2006 17:55:58 -0500 (EST)
Received: from ihemail1.lucent.com ([192.11.222.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtYhB-0000Nc-EA
	for ips@ietf.org; Mon, 02 Jan 2006 18:02:32 -0500
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com
	[135.85.76.62])
	by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k02Mv0iq010821; 
	Mon, 2 Jan 2006 16:57:00 -0600 (CST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service
	(5.5.2657.72) id <X5BR802F>; Mon, 2 Jan 2006 23:56:58 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15508F18064@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: ips mailing list <ips@ietf.org>
Date: Mon, 2 Jan 2006 23:56:58 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Cc: "Allison Mankin \(E-mail\)" <mankin@psg.com>
Subject: [Ips] MIB DOctor review: draft-ietf-ips-scsi-mib-08.txt
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=subscribe>
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org

Except for the below nits I am happy with this doc to go to IETF Last Call.
Up to Allison if she wants the below addressed first or if she wants to 
consider it as intial IETF Last Call comments.

Bert

--------

I get these reference/citation reports:

  !! Missing citation for Normative reference:
  P091 L025:    [RFC3411]  Harrington, D., Presuhn, R., and B. Wijnen, "An

You IMPORT SnmpAdminSTring from it, so it needs a citation to the
normative reference.

  !! Missing citation for Informative reference:
  P092 L020:    [RFC3980]  Krueger, M., Chadalapaka, M., and R. Elliott, "T11 Network

Your problem to solve

  !! Missing Reference for citation: [SAM-2]
  P038 L009:           more SCSI Target Ports ([SAM-2] chapter 5.9.6, 5.9.7)
  P065 L049:         ([SAM-2] Chapters 5.9.6, 5.9.7).

I think you just beed to s/SAM-2/SAM2/

They are normal (i.e. not MIB specific) issues, so I leave it to Allison as
to how she wants to handle that.

In the Security COnsiderations Section, I do not see an description of
security/privacy considerations for read-write objects in scsiInstanceTable,
in the scsiDeviceTable.

In total I count 17 tables, and in the Security Considerations there is
only mention of 5 or 6. Do the other tables not have any security or
privacy considerations?

I know that recently the IESG did send a MIB document back to the WG/authors
to fix a similar problem.

Again, this is something I leave to Allison on how she wants to handle it.

Bert

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips



From ips-bounces@ietf.org Mon Jan 02 18:17:04 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtYvI-0005Cg-Hj; Mon, 02 Jan 2006 18:17:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtYvG-0005CY-I3
	for ips@megatron.ietf.org; Mon, 02 Jan 2006 18:17:02 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26478
	for <ips@ietf.org>; Mon, 2 Jan 2006 18:15:48 -0500 (EST)
Message-Id: <200601022315.SAA26478@ietf.org>
Received: from psg.com ([147.28.0.62] ident=mailnull)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtZ0N-0000u8-56
	for ips@ietf.org; Mon, 02 Jan 2006 18:22:22 -0500
Received: from localhost ([127.0.0.1] helo=psg.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <mankin@psg.com>)
	id 1EtYv9-0005Ey-3B; Mon, 02 Jan 2006 23:16:55 +0000
To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
Date: Mon, 02 Jan 2006 15:16:55 -0800
From: Allison Mankin <mankin@psg.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
Cc: ips mailing list <ips@ietf.org>, mankin@psg.com
Subject: [Ips] Re: MIB DOctor review: draft-ietf-ips-scsi-mib-08.txt 
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=subscribe>
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org

Bert,

Thank you very much for this review.  I'm going to
send the SCSI MIB to IETF Last Call now, but the authors
should take Bert's comments on the security details
of the tables into consideration, and we will handle them
some way before placing the document before the IESG.

Allison


_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips



From ips-bounces@ietf.org Mon Jan 02 21:19:51 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtbmB-000507-U8; Mon, 02 Jan 2006 21:19:51 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtbmA-000502-Cj
	for ips@megatron.ietf.org; Mon, 02 Jan 2006 21:19:50 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11933
	for <ips@ietf.org>; Mon, 2 Jan 2006 21:18:37 -0500 (EST)
Received: from sccrmhc14.comcast.net ([63.240.77.84])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtbrM-0005yr-7e
	for ips@ietf.org; Mon, 02 Jan 2006 21:25:12 -0500
Received: from ivvtdkv0981
	(adsl-070-155-067-194.sip.asm.bellsouth.net[70.155.67.194])
	by comcast.net (sccrmhc14) with SMTP
	id <20060103021935014002bh3pe>; Tue, 3 Jan 2006 02:19:36 +0000
Message-ID: <002401c6100c$24c32aa0$ec03470a@ivivity.com>
From: "Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>
To: "Somesh Gupta" <sgupta@silverbacksystems.com>, "IPS" <ips@ietf.org>
References: <2ad37449fcea8441a349deeddd843927@mail2.silverbacksystems.com>
Subject: Re: [Ips] Fast multi-task abort model
Date: Mon, 2 Jan 2006 21:19:35 -0500
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2670
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a
Content-Transfer-Encoding: 7bit
Cc: 
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=subscribe>
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org

Where can I find the latest draft on this subject?

Eddy

----- Original Message ----- 
From: "Somesh Gupta" <sgupta@silverbacksystems.com>
To: "IPS" <ips@ietf.org>
Sent: Wednesday, December 07, 2005 3:43 PM
Subject: RE: [Ips] Fast multi-task abort model


The discussion prompted me to take a closer look at
the fast multi-task abort model. In principal, I agree
that the new async PDU helps the target and initiator
reach a common understanding of which tasks have
been cleared, and stop processing them.

However, I think the language of the proposal puts
too much knowledge in the target transport layer -
the language implies that the target transport layer
is managing the task set for a LUN - it is responsible
for determining which initiators have active tasks on
a specific LUN, and which tasks these are, what their
disposition is - and for sending a TMF response (and which
TMFs are supported and what the back-end impact of each is).

It is not so simple since the values of the TAS, TST and
Qerr bits really determine the actions.

There is some unavoidable interaction/modification of
the SCSI layer to handle this situation correctly -
because only the SCSI layer knows whether for the cleared tasks
a. the initiator is really not expecting anything
   (the nexus is the same as which received the tmf command)
b. should be sent an explicit status of ABORTED BY ANOTHER
   INITIATOR
c. No impact
d. Needs to be cleaned up through the asynch notification
   mechanism (different nexus, TST=0:Qerr=01b;TAS=0)
c. Whether the initiator is likely to be dead (LUN Reset
   with reserve/release model or equivalent behavior in
   persistent reservation model)

In other words, the asynch PDU must be explicitly triggered
by the SCSI layer on each impacted Nexus - if adding the
asynch PDU becomes an issues, we can use a new response
code which would be sent for every command. In any case,
the statsn acknowledgement rule should help the initiator
and target flush all impacted commands in the pipe, and
have a common understanding of what is impacted.

Bill makes a very valid point about the real world situation
of clusters. Shouldn't the SCSI layer be able to send a
response for the TMF when it has triggered the asynch PDU on
each of the Nexuses (is it Nexi?). The acknowledgement or
time-out is only for the purposes of recovering the buffers?

>-----Original Message-----
>From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On 
>Behalf Of Mallikarjun C.
>Sent: Tuesday, December 06, 2005 3:13 PM
>To: IPS
>Subject: Re: [Ips] Fast multi-task abort model
>
>
>>Mark
>> the tcb as 
>> terminated, then wait for the TTs to complete. When
>> they are done, 
>> throw the whole thing out.
>
>Reasonable, and this is in abstract what the new
>proposal does.
>
>RFC 3720 does not explicitly say "wait for TTTs to
>complete even after TMF is completed".  The only
>default interpretation of the 3720 text today would be
>to invalidate the TTTs along with the buffer
>associations when a task is "terminated" and the TMF
>completion is generated.  An invalid TTT/STag is in
>fact a problem for at least two reasons - 
>
>a) All Data-Out PDU (with the now invalid TTTs) are
>protocol errors that should be Reject'ed.
>b) Any DDP tagged data segment to an invalid STag
>immediately takes the connection down (for
>iSCSI/iSER).
>
>What I am suggesting in the new proposal is that there
>be an explicit event to conclude the "waiting for TTTs
>to complete" for a target at the iSCSI control
>protocol level (not at the Datamover level).  That new
>event is the reception of the Nop-Out ack'ing the new
>Async PDU.  And that brings us to the new proposal.
>
>I think the 3720 text is self-consistent (although it
>isn't the most efficient).  Simply scratching the TTT
>cross-nexus requirement off the current text, IMHO, is
>not the right thing. We need to specify the new
>initiator and target semantics in the absence of that
>requirement, and that's what the fast multi-task abort
>proposal attempts.
>
>Mallikarjun
>
>
> 
>
>--- William Studenmund <wrstuden@wasabisystems.com>
>wrote:
>
>> On Dec 1, 2005, at 4:01 PM, Mallikarjun C. wrote:
>> 
>> >> Why does it need to be cross-nexus, other than
>> the
>> >> fact that RFC 3720
>> >> says it should be?
>> >
>> > There's a good rationale behind RFC 3720 text:
>> >
>> > TMF cannot complete until all affected tasks are
>> > terminated on the target per SAM.  Receiving stale
>> > data after tasks are terminated is a problem. 
>> Waiting
>> > for all active TTTs of all affected tasks (same
>> and/or
>> > other nexus) to finish was thus the adopted
>> approach
>> > to avoid stale data for any affected task.
>> 
>> Shouldn't we leave how the target avoids/copes with
>> stale data to the 
>> target?
>> 
>> I guess I don't see how receiving "stale" data after
>> a task has been 
>> terminated is a problem. Specifically I don't see
>> how it's a problem to 
>> receive data you knew was in-flight at the moment
>> the termination 
>> happened. You have your tcb structure (however you
>> have it laid out), 
>> and you know what TTs are associated with it. Mark
>> the tcb as 
>> terminated, then wait for the TTs to complete. When
>> they are done, 
>> throw the whole thing out.
>> 
>> > What the new proposal does is to make receiving
>> stale
>> > data after task terminations a non-problem - via a
>> > separate accounting scheme and new target
>> semantics.
>> 
>> And I think this is a good thing. However I still
>> think we need to 
>> abandon the inter-nexus TT wait for the old scheme.
>> 
>> Take care,
>> 
>> Bill
>> 
>> 
>
>
>
> 
>__________________________________________ 
>Yahoo! DSL - Something to write home about. 
>Just $16.99/mo. or less. 
>dsl.yahoo.com 
>
>
>_______________________________________________
>Ips mailing list
>Ips@ietf.org
>https://www1.ietf.org/mailman/listinfo/ips
>




_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips


_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips



From ips-bounces@ietf.org Mon Jan 02 23:14:42 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtdZK-0001G5-LS; Mon, 02 Jan 2006 23:14:42 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtdZE-0001FN-RI; Mon, 02 Jan 2006 23:14:36 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22540;
	Mon, 2 Jan 2006 23:13:23 -0500 (EST)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EtdeS-0000xv-1v; Mon, 02 Jan 2006 23:20:00 -0500
Received: from apache by newodin.ietf.org with local (Exim 4.43)
	id 1EtdZE-0007Pk-6u; Mon, 02 Jan 2006 23:14:36 -0500
X-test-idtracker: no
To: IETF-Announce <ietf-announce@ietf.org>
From: The IESG <iesg-secretary@ietf.org>
Message-Id: <E1EtdZE-0007Pk-6u@newodin.ietf.org>
Date: Mon, 02 Jan 2006 23:14:36 -0500
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Cc: ips@ietf.org
Subject: [Ips] Last Call: 'Definition of Managed Objects for SCSI Entities'
 to Proposed Standard 
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: iesg@ietf.org
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=subscribe>
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org

The IESG has received a request from the IP Storage WG to consider the 
following document:

- 'Definition of Managed Objects for SCSI Entities '
   <draft-ietf-ips-scsi-mib-08.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by 2006-01-16.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ips-scsi-mib-08.txt


_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips



From ips-bounces@ietf.org Tue Jan 03 14:36:52 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Etrxk-0004my-7C; Tue, 03 Jan 2006 14:36:52 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Etrxi-0004mK-Uw
	for ips@megatron.ietf.org; Tue, 03 Jan 2006 14:36:51 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17535
	for <ips@ietf.org>; Tue, 3 Jan 2006 14:35:35 -0500 (EST)
From: Black_David@emc.com
Received: from mexforward.lss.emc.com ([168.159.213.200])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ets33-0000Bf-6w
	for ips@ietf.org; Tue, 03 Jan 2006 14:42:21 -0500
Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14])
	by mexforward.lss.emc.com (Switch-3.1.0/Switch-3.1.7) with ESMTP id
	k03JaSD4017251; Tue, 3 Jan 2006 14:36:28 -0500 (EST)
Received: from MAHO3MSX2.corp.emc.com (maho3msx2.corp.emc.com [128.221.11.32])
	by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id
	k03JaOKn010082; Tue, 3 Jan 2006 14:36:25 -0500 (EST)
Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19)
	id <ZJCHCY1D>; Tue, 3 Jan 2006 14:36:23 -0500
Message-ID: <F222151D3323874393F83102D614E055013E8F89@CORPUSMX20A.corp.emc.com>
To: ips@ietf.org
Date: Tue, 3 Jan 2006 14:36:19 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0,
	Antispam-Data: 2006.1.3.21
X-PerlMx-Spam: Gauge=, SPAM=1%, Reasons='EMC_FROM_00+ -3, NO_REAL_NAME 0,
	__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0,
	__IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0,
	__SANE_MSGID 0'
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 2086112c730e13d5955355df27e3074b
Cc: bwijnen@lucent.com
Subject: [Ips] SCSI MIB - proposed security text
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=subscribe>
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org

In response to Bert Wijnen's observation on lack of scope/coverage
in the SCSI MIB draft's security considerations text, here's proposed
new text for the Security Considerations section (with many thanks
to Keith McCloghrie for producing the text on short notice).  If
there are issues, please raise them here (Bert's comment is already
considered to be an IETF Last Call comment).  In the absence of
further comment, this text (without the edit tags in the left-hand
margin) will be put into the next (post-IETF-Last-Call) version
of the SCSI MIB draft.

Thanks,
--David (IPS WG chair)

This is a complete replacement for section 12 of the SCSI MIB draft;
the left-hand margin indicates "|" for modified, "+" for added.

  12.  Security Considerations
  
     There are a number of management objects defined in this MIB module
     that have a MAX-ACCESS clause of read-write and/or read-create.  Such
     objects may be considered sensitive or vulnerable in some network
     environments.  The support for SET operations in a non-secure
     environment without proper protection can have a negative effect on
     network operations.  These are:
  
+    o  scsiInstAlias, scsiInstScsiNotificationsEnable, scsiInstStorageType
+       and scsiDeviceAlias: these objects can be manipulated to affect
+       the management of a SCSI instance and its devices; specifically,
+       the SCSI instance's administrative alias, whether it generates
+       notifications, whether its non-default parameter settings are
+       retained over restarts, and the administrative alias for each of
+       its devices.

     o  scsiIntrDevTgtAccessMode: this object can be manipulated to allow
        immediate access by local SCSI initiator devices to discovered
        SCSI target devices without waiting for administrator approval,
        where such approval might not be forthcoming.
  
     o  scsiDscTgtTable: the objects in this table can be manipulated to
        remove administrator-specified controls on access by local SCSI
        initiator devices to discovered SCSI target devices.
  
     o  scsiAuthorizedIntrTable: the objects in this table can be
        manipulated to remove administrator-specified controls on access
        by remote SCSI initiator devices to local SCSI target devices.
  
     o  scsiLunMapTable: the objects in this table can be manipulated to
        provide access by a remote SCSI initiator device to logical units
        which an administrator has configured as not accessible to said
        initiator.
  
|    In each of the last four cases above, the objects in the tables can
also be
     manipulated to cause a Denial-of-Service attack, by preventing
     administrator-authorized access.
  
     Some of the readable objects in this MIB module (i.e., objects with a
     MAX-ACCESS other than not-accessible) may be considered sensitive or
     vulnerable in some network environments.  It is thus important to
     control even GET and/or NOTIFY access to these objects and possibly
     to even encrypt the values of these objects when sending them over
|    the network via SNMP.  All seventeen of the tables in this MIB module
|    contain information which might be considered sensitive to read access
|    in some environments, e.g.,

|      - the settings of all read-write/read-create paremeter objects
|        mentioned above,
|
|      - scsiInstSoftwareIndex, scsiInstVendorVersion
|         -- which version of which software is running;

+      - scsiDeviceRole, scsiPortRole, scsiTransportType,
scsiTransportPointer,
+        scsiTransportDevName, scsiDscLunIdCodeSet, scsiDscLunIdAssociation,
+        scsiDscLunIdType, scsiDscLunIdValue plus information in several
+        tables: scsiTgtDevTable, scsiLuTable, scsiLuIdTable,
scsiLunMapTable
+         -- topology information indicating which devices/ports are
targets,
+            about the transport protocols they use, and more specific
+            information about such targets, including detailed information
+            about the LUNs they expose and how they are mapped onto Logical
+            Units;
 
+      - scsiIntrPortOutCommands, scsiIntrPortWrittenMegaBytes,
+        scsiIntrPortReadMegaBytes, scsiIntrPortHSOutCommands
+        scsiDscTgtInCommands, scsiDscTgtWrittenMegaBytes,
+        scsiDscTgtReadMegaBytes, scsiDscTgtHSInCommands, 
+        scsiTgtPortInCommands, scsiTgtPortWrittenMegaBytes,
+        scsiTgtPortReadMegaBytes, scsiTgtPortHSInCommands,
+        scsiAuthIntrAttachedTimes, scsiAuthIntrOutCommands,
+        scsiAuthIntrReadMegaBytes, scsiAuthIntrWrittenMegaBytes,
+        scsiAuthIntrHSOutCommands, scsiLuInCommands, scsiLuReadMegaBytes,
+        scsiLuWrittenMegaBytes, scsiLuHSInCommands 
+         -- statistics which could be used for traffic analysis.
 
+      - scsiAttTgtPortTable
+         -- information on which initiators are connected to which targets
+            which could be used for traffic analysis.
 
|      - scsiAuthorizedIntrTable and scsiAttIntrPortTable tables
|         -- information about which initiators are authorized to connect
|            to which targets. 

     SNMP versions prior to SNMPv3 did not include adequate security.
     Even if the network itself is secure (for example by using IPSec),
     even then, there is no control as to who on the secure network is
     allowed to access and GET/SET (read/change/create/delete) the objects
     in this MIB module.

     It is RECOMMENDED that implementers consider the security features as
     provided by the SNMPv3 framework (see [RFC3410], section 8),
     including full support for the SNMPv3 cryptographic mechanisms (for
     authentication and privacy).

     Further, deployment of SNMP versions prior to SNMPv3 is NOT
     RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to
     enable cryptographic security.  It is then a customer/operator
     responsibility to ensure that the SNMP entity giving access to an
     instance of this MIB module is properly configured to give access to
     the objects only to those principals (users) that have legitimate
     rights to indeed GET or SET (change/create/delete) them.



_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips



From ips-bounces@ietf.org Tue Jan 03 16:10:36 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EttQS-0002B4-Lc; Tue, 03 Jan 2006 16:10:36 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EttQR-0002Ab-0N
	for ips@megatron.ietf.org; Tue, 03 Jan 2006 16:10:35 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05248
	for <ips@ietf.org>; Tue, 3 Jan 2006 16:09:20 -0500 (EST)
Message-Id: <200601032109.QAA05248@ietf.org>
Received: from psg.com ([147.28.0.62] ident=mailnull)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EttVj-0005N9-ES
	for ips@ietf.org; Tue, 03 Jan 2006 16:16:06 -0500
Received: from localhost ([127.0.0.1] helo=psg.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <mankin@psg.com>)
	id 1EttQL-000Ltu-AE; Tue, 03 Jan 2006 21:10:29 +0000
To: Black_David@emc.com
Subject: Re: [Ips] SCSI MIB - proposed security text 
Date: Tue, 03 Jan 2006 13:10:29 -0800
From: Allison Mankin <mankin@psg.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014
Cc: bwijnen@lucent.com, ips@ietf.org, mankin@psg.com
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=subscribe>
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org

Thanks very much to Keith!

If Bert says he likes this text, I can put it in the
tracker for now as a Note to the RFC Editor, 
in the thought that there may not need to be any
other revision. (Always possible to take it out
if that changes).

Allison

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips



From ips-bounces@ietf.org Tue Jan 03 17:31:15 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtugV-0000o3-U2; Tue, 03 Jan 2006 17:31:15 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtugT-0000nv-R3
	for ips@megatron.ietf.org; Tue, 03 Jan 2006 17:31:13 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25726
	for <ips@ietf.org>; Tue, 3 Jan 2006 17:29:59 -0500 (EST)
Received: from ihemail1.lucent.com ([192.11.222.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Etulp-0003ML-HP
	for ips@ietf.org; Tue, 03 Jan 2006 17:36:46 -0500
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com
	[135.85.76.62])
	by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k03MV1QA028878; 
	Tue, 3 Jan 2006 16:31:01 -0600 (CST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service
	(5.5.2657.72) id <X5BR9RGV>; Tue, 3 Jan 2006 23:30:59 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15508FC87B8@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: Allison Mankin <mankin@psg.com>, Black_David@emc.com
Subject: RE: [Ips] SCSI MIB - proposed security text 
Date: Tue, 3 Jan 2006 23:30:58 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Cc: ips@ietf.org
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=subscribe>
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org

The text looks fine to me.

Bert

> -----Original Message-----
> From: Allison Mankin [mailto:mankin@psg.com]
> Sent: Tuesday, January 03, 2006 22:10
> To: Black_David@emc.com
> Cc: ips@ietf.org; bwijnen@lucent.com; mankin@psg.com
> Subject: Re: [Ips] SCSI MIB - proposed security text 
> 
> 
> Thanks very much to Keith!
> 
> If Bert says he likes this text, I can put it in the
> tracker for now as a Note to the RFC Editor, 
> in the thought that there may not need to be any
> other revision. (Always possible to take it out
> if that changes).
> 
> Allison
> 

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips



From ips-bounces@ietf.org Tue Jan 03 20:43:31 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EtxgZ-00061U-AJ; Tue, 03 Jan 2006 20:43:31 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EtxgY-00060P-5d
	for ips@megatron.ietf.org; Tue, 03 Jan 2006 20:43:30 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18382
	for <ips@ietf.org>; Tue, 3 Jan 2006 20:42:14 -0500 (EST)
Received: from web51906.mail.yahoo.com ([206.190.48.69])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Etxls-0001P6-To
	for ips@ietf.org; Tue, 03 Jan 2006 20:49:04 -0500
Received: (qmail 16468 invoked by uid 60001); 4 Jan 2006 01:43:12 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=SYE1ukNI6UhJeAE+wsP4lS/a1USKBPolnbwrPyjqeZL4jQrAmUe7++kNLQRP7loR5wrJpt+M1nLfocY8dFYLSCN0JK+HLyWCY+3PPOvcMlusvpCew1YXVFvvZj8a30Kgp7H/a0Rl7cCtbqSOu8r5Xq1Wd5pNUSpaH42I6e1Bwtg=
	; 
Message-ID: <20060104014312.16466.qmail@web51906.mail.yahoo.com>
Received: from [156.153.255.243] by web51906.mail.yahoo.com via HTTP;
	Tue, 03 Jan 2006 17:43:12 PST
Date: Tue, 3 Jan 2006 17:43:12 -0800 (PST)
From: "Mallikarjun C." <cb_mallikarjun@yahoo.com>
Subject: Re: [Ips] Fast multi-task abort model
To: IPS <ips@ietf.org>
In-Reply-To: <002401c6100c$24c32aa0$ec03470a@ivivity.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id UAA18382
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=subscribe>
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org

The original proposal was described in an email. =20

http://www1.ietf.org/mail-archive/web/ips/current/msg01707.html

I have subsequently agreed to add a couple of
clarifications to this.  It is time to include the
updated proposal into the draft for reference purposes
such as this.  I will shortly do it.  Until then,
please reference the email.

Mallikarjun


--- Eddy Quicksall
<eddy_quicksall_iVivity_iSCSI@comcast.net> wrote:

> Where can I find the latest draft on this subject?
>=20
> Eddy
>=20


--
Mallikarjun


Mallikarjun Chadalapaka


	=09
__________________________________________=20
Yahoo! DSL =96 Something to write home about.=20
Just $16.99/mo. or less.=20
dsl.yahoo.com=20


_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips



From ips-bounces@ietf.org Fri Jan 06 14:42:18 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuxTe-0004Cp-Nl; Fri, 06 Jan 2006 14:42:18 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuxTd-00043f-Eh
	for ips@megatron.ietf.org; Fri, 06 Jan 2006 14:42:17 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00744
	for <ips@ietf.org>; Fri, 6 Jan 2006 14:40:57 -0500 (EST)
Received: from [216.148.227.153] (helo=rwcrmhc12.comcast.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuxZU-0005wR-0W
	for ips@ietf.org; Fri, 06 Jan 2006 14:48:21 -0500
Received: from ivvtdkv0981 (unknown[64.238.111.98])
	by comcast.net (rwcrmhc13) with SMTP
	id <2006010619415901500daem7e>; Fri, 6 Jan 2006 19:42:00 +0000
Message-ID: <000601c612f9$42f0c5b0$3a01a8c0@ivivity.com>
From: "Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>
To: <ips@ietf.org>
Date: Fri, 6 Jan 2006 14:41:57 -0500
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2670
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670
X-Spam-Score: 0.1 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Subject: [Ips] iSER API's
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0995724805=="
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0995724805==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0003_01C612CF.58390560"

This is a multi-part message in MIME format.

------=_NextPart_000_0003_01C612CF.58390560
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Is there any work afoot to design some standard iSER API's?

Eddy
------=_NextPart_000_0003_01C612CF.58390560
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 6.00.2900.2802" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>Is there any work afoot to design some =
standard&nbsp;iSER=20
API's?</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Eddy</FONT></DIV></BODY></HTML>

------=_NextPart_000_0003_01C612CF.58390560--



--===============0995724805==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--===============0995724805==--





From ips-bounces@ietf.org Fri Jan 06 16:18:09 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EuyyP-0002YX-1G; Fri, 06 Jan 2006 16:18:09 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EuyyN-0002YP-5h
	for ips@megatron.ietf.org; Fri, 06 Jan 2006 16:18:07 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12328
	for <ips@ietf.org>; Fri, 6 Jan 2006 16:16:49 -0500 (EST)
Received: from mail75.messagelabs.com ([216.82.255.83])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Euz4J-00026z-AZ
	for ips@ietf.org; Fri, 06 Jan 2006 16:24:17 -0500
X-VirusChecked: Checked
X-Env-Sender: jhufferd@Brocade.COM
X-Msg-Ref: server-11.tower-75.messagelabs.com!1136582269!63663078!1
X-StarScan-Version: 5.5.9.1; banners=-,-,-
X-Originating-IP: [66.243.153.112]
Received: (qmail 16824 invoked from network); 6 Jan 2006 21:17:49 -0000
Received: from f112.brocade.com (HELO blasphemy.brocade.com) (66.243.153.112)
	by server-11.tower-75.messagelabs.com with SMTP;
	6 Jan 2006 21:17:49 -0000
Received: from hq-ex-7.corp.brocade.com (hq-ex-7 [192.168.38.33])
	by blasphemy.brocade.com (Postfix) with ESMTP id 16BBF1425F;
	Fri,  6 Jan 2006 13:17:49 -0800 (PST)
Received: from hq-ex-6.corp.brocade.com ([192.168.38.36]) by
	hq-ex-7.corp.brocade.com with Microsoft SMTPSVC(5.0.2195.6713); 
	Fri, 6 Jan 2006 13:17:48 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Ips] iSER API's
Date: Fri, 6 Jan 2006 13:17:48 -0800
Message-ID: <EE86A2987768164188932981F6EBE69E021BDE8A@hq-ex-6.brocade.com>
Thread-Topic: [Ips] iSER API's
Thread-Index: AcYS+cAH9MLCfpIqQ6OtIJC+I2pK7wACnXkA
From: "John Hufferd" <jhufferd@Brocade.COM>
To: "Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>, <ips@ietf.org>
X-OriginalArrivalTime: 06 Jan 2006 21:17:48.0993 (UTC)
	FILETIME=[A541EB10:01C61306]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 7e267523e0685e5aa2dbbdde4b659686
Cc: 
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0642822870=="
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0642822870==
content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C61306.A5139D39"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C61306.A5139D39
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Eddy,

What APIs are you asking about?  The SCSI CLASS Driver to the Device
Driver (Mini Port Driver) should have the same interfaces for iSER as it
is available for iSCSI.  If you mean between the Device Driver (Mini
Port Driver) and the RNIC, that will probably be the RNIC vendors
interface if they have implemented all or part of the iSER or Data Mover
in the RNIC itself, or the RNIC vendor's interfaces to their version of
the verbs (at least until the OS implements its own RDMA interfaces that
implement the RDMA verbs).=20

=20

I believe that, over time, most OSs will have generic RDMA interfaces,
which can be use by all certified RNIC hardware, and any application
(user space or kernel space); in that case the iSER module will probably
interface to that OS's RDMA interfaces.

=20

.

.

.

John L Hufferd

Sr. Executive Director of Technology

Brocade Communications Systems, Inc

jhufferd@brocade.com

Office Phone: (408) 333-5244; eFAX: (408) 904-4688

Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606

=20

  _____ =20

From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of
Eddy Quicksall
Sent: Friday, January 06, 2006 11:42 AM
To: ips@ietf.org
Subject: [Ips] iSER API's

=20

Is there any work afoot to design some standard iSER API's?

=20

Eddy


------_=_NextPart_001_01C61306.A5139D39
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body bgcolor=3Dwhite lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Eddy,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>What APIs are you asking about? =
&nbsp;The SCSI
CLASS Driver to the Device Driver (Mini Port Driver) should have the =
same interfaces
for iSER as it is available for iSCSI.&nbsp; If you mean between the =
Device
Driver (Mini Port Driver) and the RNIC, that will probably be the RNIC =
vendors
interface if they have implemented all or part of the iSER or Data Mover =
in the
RNIC itself, or the RNIC vendor&#8217;s interfaces to their version of =
the
verbs (at least until the OS implements its own RDMA interfaces that =
implement the
RDMA verbs). <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I believe that, over time, most =
<st1:City
w:st=3D"on"><st1:place w:st=3D"on">OSs</st1:place></st1:City> will have =
generic
RDMA interfaces, which can be use by all certified RNIC hardware, and =
any
application (user space or kernel space); in that case the iSER module =
will probably
interface to that OS&#8217;s RDMA =
interfaces.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt;color:navy'>.</span></font><font =
color=3Dnavy><span
style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt;color:navy'>.</span></font><font =
color=3Dnavy><span
style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt;color:navy'>.</span></font><font =
color=3Dnavy><span
style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt;color:navy'>John L Hufferd</span></font><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt;color:navy'>Sr. Executive Director of =
Technology</span></font><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt;color:navy'>Brocade Communications Systems, =
Inc</span></font><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt;color:navy'><a =
href=3D"mailto:jhufferd@brocade.com"
title=3D"mailto:jhufferd@brocade.com">jhufferd@brocade.com</a></span></fo=
nt><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt;color:navy'>Office Phone: (408) 333-5244; =
eFAX: (408)
904-4688</span></font><font color=3Dnavy><span =
style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt;color:navy'>Alt Office Phone: (408) 997-6136; =
Cell:
(408) 627-9606</span></font><font color=3Dnavy><span =
style=3D'color:navy'><o:p></o:p></span></font></p>

</div>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] <b><span =
style=3D'font-weight:
bold'>On Behalf Of </span></b>Eddy Quicksall<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Friday, January 06, =
2006
11:42 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> ips@ietf.org<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> [Ips] iSER =
API's</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt'>Is there any work afoot to design some standard&nbsp;iSER =
API's?</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt'>Eddy</span></font><o:p></o:p></p>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C61306.A5139D39--


--===============0642822870==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--===============0642822870==--




From ips-bounces@ietf.org Sun Jan 08 20:51:13 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EvmBl-0001Ns-Bn; Sun, 08 Jan 2006 20:51:13 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EvmBk-0001Nn-3r
	for ips@megatron.ietf.org; Sun, 08 Jan 2006 20:51:12 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04157
	for <ips@ietf.org>; Sun, 8 Jan 2006 20:49:54 -0500 (EST)
Received: from taurus.voltaire.com ([193.47.165.240])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvmI3-0003B2-NR
	for ips@ietf.org; Sun, 08 Jan 2006 20:57:46 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Ips] iSER API's
Date: Mon, 9 Jan 2006 03:50:39 +0200
Message-ID: <D4F8F0B3820E754C887699BEF26A8940D7A990@taurus.voltaire.com>
Thread-Topic: [Ips] iSER API's
Thread-Index: AcYS+cAH9MLCfpIqQ6OtIJC+I2pK7wACnXkAAG6MM3A=
From: "Dan Bar Dov" <danb@voltaire.com>
To: "John Hufferd" <jhufferd@Brocade.COM>,
	"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>, <ips@ietf.org>
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 5ba9b8496764663b12c333825fbf6b3d
Cc: 
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0630704827=="
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0630704827==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C614BF.1ACF56D2"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C614BF.1ACF56D2
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Indeed on Linux the direction is towards a generic RDMA interface. CMA =
provides a generic CM abstraction, and the ib_verbs API is planned to =
extend over iWARP one way or another.=20
The DM was deemed unnecessary, the API between iSCSI & SCSI and the =
underlying iSER enforced redesign of the iSER API to conform with iSCSI =
and SCSI rather then implement yet another layer between iSER and =
iSCSI/SCSI (namely DM).
=20
Dan


________________________________

	From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of =
John Hufferd
	Sent: Friday, January 06, 2006 11:18 PM
	To: Eddy Quicksall; ips@ietf.org
	Subject: RE: [Ips] iSER API's
=09
=09

	Eddy,

	What APIs are you asking about?  The SCSI CLASS Driver to the Device =
Driver (Mini Port Driver) should have the same interfaces for iSER as it =
is available for iSCSI.  If you mean between the Device Driver (Mini =
Port Driver) and the RNIC, that will probably be the RNIC vendors =
interface if they have implemented all or part of the iSER or Data Mover =
in the RNIC itself, or the RNIC vendor's interfaces to their version of =
the verbs (at least until the OS implements its own RDMA interfaces that =
implement the RDMA verbs).=20

	=20

	I believe that, over time, most OSs will have generic RDMA interfaces, =
which can be use by all certified RNIC hardware, and any application =
(user space or kernel space); in that case the iSER module will probably =
interface to that OS's RDMA interfaces.

	=20

	.

	.

	.

	John L Hufferd

	Sr. Executive Director of Technology

	Brocade Communications Systems, Inc

	jhufferd@brocade.com

	Office Phone: (408) 333-5244; eFAX: (408) 904-4688

	Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606

	=20

=09
________________________________


	From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of =
Eddy Quicksall
	Sent: Friday, January 06, 2006 11:42 AM
	To: ips@ietf.org
	Subject: [Ips] iSER API's

	=20

	Is there any work afoot to design some standard iSER API's?

	=20

	Eddy


------_=_NextPart_001_01C614BF.1ACF56D2
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.2802" name=3DGENERATOR><!--[if !mso]>
<STYLE>v\:* {
	BEHAVIOR: url(#default#VML)
}
o\:* {
	BEHAVIOR: url(#default#VML)
}
w\:* {
	BEHAVIOR: url(#default#VML)
}
.shape {
	BEHAVIOR: url(#default#VML)
}
</STYLE>
<![endif]--><o:SmartTagType name=3D"City"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
name=3D"place"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><!--[if !mso]>
<STYLE>st1\:* {
	BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: Tahoma;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.EmailStyle17 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
DIV.Section1 {
	page: Section1
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=3DEN-US vLink=3Dpurple link=3Dblue bgColor=3Dwhite>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D650424501-09012006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Indeed on Linux the direction is towards a =
generic RDMA=20
interface. CMA provides a generic CM abstraction, and the ib_verbs API =
is=20
planned to extend over iWARP one way or another. </FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D650424501-09012006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>The DM was deemed unnecessary, the API between =
iSCSI &amp;=20
SCSI and the underlying iSER enforced redesign of the iSER API to =
conform with=20
iSCSI and SCSI rather then implement yet another layer between iSER and=20
iSCSI/SCSI (namely DM).</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D650424501-09012006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D650424501-09012006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Dan</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> ips-bounces@ietf.org=20
  [mailto:ips-bounces@ietf.org] <B>On Behalf Of </B>John =
Hufferd<BR><B>Sent:</B>=20
  Friday, January 06, 2006 11:18 PM<BR><B>To:</B> Eddy Quicksall;=20
  ips@ietf.org<BR><B>Subject:</B> RE: [Ips] iSER =
API's<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Eddy,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">What APIs =
are you=20
  asking about? &nbsp;The SCSI CLASS Driver to the Device Driver (Mini =
Port=20
  Driver) should have the same interfaces for iSER as it is available =
for=20
  iSCSI.&nbsp; If you mean between the Device Driver (Mini Port Driver) =
and the=20
  RNIC, that will probably be the RNIC vendors interface if they have=20
  implemented all or part of the iSER or Data Mover in the RNIC itself, =
or the=20
  RNIC vendor=92s interfaces to their version of the verbs (at least =
until the OS=20
  implements its own RDMA interfaces that implement the RDMA verbs).=20
  <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I believe =
that, over=20
  time, most <st1:City w:st=3D"on"><st1:place =
w:st=3D"on">OSs</st1:place></st1:City>=20
  will have generic RDMA interfaces, which can be use by all certified =
RNIC=20
  hardware, and any application (user space or kernel space); in that =
case the=20
  iSER module will probably interface to that OS=92s RDMA=20
  interfaces.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dnavy =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy">.</SPAN></FONT><FONT =
color=3Dnavy><SPAN=20
  style=3D"COLOR: navy"><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dnavy =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy">.</SPAN></FONT><FONT =
color=3Dnavy><SPAN=20
  style=3D"COLOR: navy"><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dnavy =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy">.</SPAN></FONT><FONT =
color=3Dnavy><SPAN=20
  style=3D"COLOR: navy"><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dnavy =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy">John L =
Hufferd</SPAN></FONT><FONT=20
  color=3Dnavy><SPAN style=3D"COLOR: navy"><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dnavy =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy">Sr. Executive Director of=20
  Technology</SPAN></FONT><FONT color=3Dnavy><SPAN=20
  style=3D"COLOR: navy"><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dnavy =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy">Brocade Communications Systems, =

  Inc</SPAN></FONT><FONT color=3Dnavy><SPAN=20
  style=3D"COLOR: navy"><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dnavy =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy"><A =
title=3Dmailto:jhufferd@brocade.com=20
  =
href=3D"mailto:jhufferd@brocade.com">jhufferd@brocade.com</A></SPAN></FON=
T><FONT=20
  color=3Dnavy><SPAN style=3D"COLOR: navy"><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dnavy =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy">Office Phone: (408) 333-5244; =
eFAX: (408)=20
  904-4688</SPAN></FONT><FONT color=3Dnavy><SPAN=20
  style=3D"COLOR: navy"><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dnavy =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy">Alt Office Phone: (408) =
997-6136; Cell:=20
  (408) 627-9606</SPAN></FONT><FONT color=3Dnavy><SPAN=20
  style=3D"COLOR: navy"><o:p></o:p></SPAN></FONT></P></DIV>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <DIV>
  <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" =
align=3Dcenter><FONT=20
  face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt">
  <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
  </SPAN></FONT></DIV>
  <P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:</SPAN></FONT></B><FONT=20
  face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">=20
  ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] <B><SPAN=20
  style=3D"FONT-WEIGHT: bold">On Behalf Of </SPAN></B>Eddy =
Quicksall<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Friday, January 06, 2006 =
11:42=20
  AM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B>=20
  ips@ietf.org<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Subject:</SPAN></B> [Ips]=20
  iSER API's</SPAN></FONT><o:p></o:p></P></DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">Is there any work afoot to design some=20
  standard&nbsp;iSER API's?</SPAN></FONT><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
  <DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D2><SPAN=20
  style=3D"FONT-SIZE: =
10pt">Eddy</SPAN></FONT><o:p></o:p></P></DIV></DIV></BLOCKQUOTE></BODY></=
HTML>

------_=_NextPart_001_01C614BF.1ACF56D2--


--===============0630704827==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--===============0630704827==--




From ips-bounces@ietf.org Mon Jan 09 10:07:08 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Evyc0-0000zZ-IX; Mon, 09 Jan 2006 10:07:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Evybx-0000yP-IG
	for ips@megatron.ietf.org; Mon, 09 Jan 2006 10:07:07 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20233
	for <ips@ietf.org>; Mon, 9 Jan 2006 10:05:45 -0500 (EST)
Received: from sccrmhc13.comcast.net ([63.240.77.83])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvyiR-0007OR-F8
	for ips@ietf.org; Mon, 09 Jan 2006 10:13:48 -0500
Received: from ivvtdkv0981 (c-66-177-56-218.hsd1.fl.comcast.net[66.177.56.218])
	by comcast.net (sccrmhc13) with SMTP
	id <20060109150650013008ueupe>; Mon, 9 Jan 2006 15:06:50 +0000
Message-ID: <002601c6152e$51419810$08031eac@ivivity.com>
From: "Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>
To: "Dan Bar Dov" <danb@voltaire.com>, "John Hufferd" <jhufferd@Brocade.COM>, 
	<ips@ietf.org>
References: <D4F8F0B3820E754C887699BEF26A8940D7A990@taurus.voltaire.com>
Subject: Re: [Ips] iSER API's
Date: Mon, 9 Jan 2006 10:06:49 -0500
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2670
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 8aa7cbc518894eb04182283f0682f662
Cc: 
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1938654579=="
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1938654579==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0023_01C61504.67FB9030"

This is a multi-part message in MIME format.

------=_NextPart_000_0023_01C61504.67FB9030
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Here is an example of what I mean when I say API:

ISER_SendControl is used to send SCSI commands, SCSI TMF's, unsolicited =
SCSI Data-out, SCSI Responses and iSCSI Asyncronous Message.

=20

ISER_RC_T ISER_SendControl(=20

ISER_CONNECTION_HANDLE_T connectionHandle,

pISCSI_HEADER pHeader,

pISER_PDU_QUALIFIERS pPDUQualifiers );

=20

Returns: ISER_GOOD or ISER_FAILED

=20

connectionHandle The connection handle returned by ISER_Connect

pHeader              A pointer to an iSCSI header.

pPDUQualifiers     A pointer to a set of qualifiers. The only qualifiers =
that need to be actually set are the ones relevant to the iSCSI header.

  ----- Original Message -----=20
  From: Dan Bar Dov=20
  To: John Hufferd ; Eddy Quicksall ; ips@ietf.org=20
  Sent: Sunday, January 08, 2006 8:50 PM
  Subject: RE: [Ips] iSER API's


  Indeed on Linux the direction is towards a generic RDMA interface. CMA =
provides a generic CM abstraction, and the ib_verbs API is planned to =
extend over iWARP one way or another.=20
  The DM was deemed unnecessary, the API between iSCSI & SCSI and the =
underlying iSER enforced redesign of the iSER API to conform with iSCSI =
and SCSI rather then implement yet another layer between iSER and =
iSCSI/SCSI (namely DM).

  Dan



-------------------------------------------------------------------------=
---
    From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf =
Of John Hufferd
    Sent: Friday, January 06, 2006 11:18 PM
    To: Eddy Quicksall; ips@ietf.org
    Subject: RE: [Ips] iSER API's


    Eddy,

    What APIs are you asking about?  The SCSI CLASS Driver to the Device =
Driver (Mini Port Driver) should have the same interfaces for iSER as it =
is available for iSCSI.  If you mean between the Device Driver (Mini =
Port Driver) and the RNIC, that will probably be the RNIC vendors =
interface if they have implemented all or part of the iSER or Data Mover =
in the RNIC itself, or the RNIC vendor's interfaces to their version of =
the verbs (at least until the OS implements its own RDMA interfaces that =
implement the RDMA verbs).=20

    =20

    I believe that, over time, most OSs will have generic RDMA =
interfaces, which can be use by all certified RNIC hardware, and any =
application (user space or kernel space); in that case the iSER module =
will probably interface to that OS's RDMA interfaces.

    =20

    .

    .

    .

    John L Hufferd

    Sr. Executive Director of Technology

    Brocade Communications Systems, Inc

    jhufferd@brocade.com

    Office Phone: (408) 333-5244; eFAX: (408) 904-4688

    Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606

    =20


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

    From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf =
Of Eddy Quicksall
    Sent: Friday, January 06, 2006 11:42 AM
    To: ips@ietf.org
    Subject: [Ips] iSER API's

    =20

    Is there any work afoot to design some standard iSER API's?

    =20

    Eddy

------=_NextPart_000_0023_01C61504.67FB9030
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.2802" name=3DGENERATOR><!--[if !mso]>
<STYLE>v\:* {
	BEHAVIOR: url(#default#VML)
}
o\:* {
	BEHAVIOR: url(#default#VML)
}
w\:* {
	BEHAVIOR: url(#default#VML)
}
.shape {
	BEHAVIOR: url(#default#VML)
}
</STYLE>
<![endif]--><o:SmartTagType=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"=20
name=3D"City"></o:SmartTagType><o:SmartTagType=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"=20
name=3D"place"></o:SmartTagType><!--[if !mso]>
<STYLE>st1\:* {
	BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: Tahoma;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.EmailStyle17 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
DIV.Section1 {
	page: Section1
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=3DEN-US vLink=3Dpurple link=3Dblue bgColor=3Dwhite>
<DIV><FONT size=3D2>Here is an example of what I mean when I say =
API:</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3DVerdana=20
size=3D2>ISER_SendControl is used to send SCSI commands, SCSI TMF=92s, =
unsolicited=20
SCSI Data-out, SCSI Responses and iSCSI Asyncronous Message.</FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3DVerdana=20
size=3D2>&nbsp;</FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3DVerdana=20
size=3D2>ISER_RC_T ISER_SendControl( </FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt; TEXT-INDENT: =
0.5in"><FONT=20
face=3DVerdana size=3D2>ISER_CONNECTION_HANDLE_T =
connectionHandle,</FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt; TEXT-INDENT: =
0.5in"><FONT=20
face=3DVerdana size=3D2>pISCSI_HEADER pHeader,</FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt; TEXT-INDENT: =
0.5in"><FONT=20
face=3DVerdana size=3D2>pISER_PDU_QUALIFIERS pPDUQualifiers =
);</FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt; TEXT-INDENT: =
0.5in"><o:p><FONT=20
face=3DVerdana size=3D2>&nbsp;</FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT size=3D2><FONT=20
face=3DVerdana>Returns: ISER_GOOD or ISER_FAILED</FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3DVerdana=20
size=3D2>&nbsp;</FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3DVerdana=20
size=3D2>connectionHandle The connection handle returned by=20
ISER_Connect</FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3DVerdana=20
size=3D2>pHeader&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;=20
A pointer to an iSCSI header.</FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt 1.5in; TEXT-INDENT: =
-1.5in"><FONT=20
face=3DVerdana size=3D2>pPDUQualifiers<SPAN=20
style=3D"mso-tab-count: 1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>A =
pointer to a set=20
of qualifiers. The only qualifiers that need to be actually set are the =
ones=20
relevant to the iSCSI header.</FONT></P></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=3Ddanb@voltaire.com href=3D"mailto:danb@voltaire.com">Dan Bar =
Dov</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=3Djhufferd@Brocade.COM=20
  href=3D"mailto:jhufferd@Brocade.COM">John Hufferd</A> ; <A=20
  title=3Deddy_quicksall_iVivity_iSCSI@comcast.net=20
  href=3D"mailto:eddy_quicksall_iVivity_iSCSI@comcast.net">Eddy =
Quicksall</A> ; <A=20
  title=3Dips@ietf.org href=3D"mailto:ips@ietf.org">ips@ietf.org</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Sunday, January 08, 2006 =
8:50=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: [Ips] iSER =
API's</DIV>
  <DIV><BR></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D650424501-09012006><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>Indeed on Linux the direction is towards a =
generic RDMA=20
  interface. CMA provides a generic CM abstraction, and the ib_verbs API =
is=20
  planned to extend over iWARP one way or another. </FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D650424501-09012006><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>The DM was deemed unnecessary, the API =
between iSCSI=20
  &amp; SCSI and the underlying iSER enforced redesign of the iSER API =
to=20
  conform with iSCSI and SCSI rather then implement yet another layer =
between=20
  iSER and iSCSI/SCSI (namely DM).</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D650424501-09012006><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D650424501-09012006><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>Dan</FONT></SPAN></DIV><BR>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
    <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft>
    <HR tabIndex=3D-1>
    <FONT face=3DTahoma size=3D2><B>From:</B> <A=20
    href=3D"mailto:ips-bounces@ietf.org">ips-bounces@ietf.org</A>=20
    [mailto:ips-bounces@ietf.org] <B>On Behalf Of </B>John=20
    Hufferd<BR><B>Sent:</B> Friday, January 06, 2006 11:18 =
PM<BR><B>To:</B> Eddy=20
    Quicksall; ips@ietf.org<BR><B>Subject:</B> RE: [Ips] iSER=20
    API's<BR></FONT><BR></DIV>
    <DIV></DIV>
    <DIV class=3DSection1>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Eddy,<o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">What APIs =
are you=20
    asking about? &nbsp;The SCSI CLASS Driver to the Device Driver (Mini =
Port=20
    Driver) should have the same interfaces for iSER as it is available =
for=20
    iSCSI.&nbsp; If you mean between the Device Driver (Mini Port =
Driver) and=20
    the RNIC, that will probably be the RNIC vendors interface if they =
have=20
    implemented all or part of the iSER or Data Mover in the RNIC =
itself, or the=20
    RNIC vendor=92s interfaces to their version of the verbs (at least =
until the=20
    OS implements its own RDMA interfaces that implement the RDMA =
verbs).=20
    <o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I believe =
that,=20
    over time, most <st1:City w:st=3D"on"><st1:place=20
    w:st=3D"on">OSs</st1:place></st1:City> will have generic RDMA =
interfaces,=20
    which can be use by all certified RNIC hardware, and any application =
(user=20
    space or kernel space); in that case the iSER module will probably =
interface=20
    to that OS=92s RDMA interfaces.<o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <DIV>
    <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dnavy =
size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy">.</SPAN></FONT><FONT =
color=3Dnavy><SPAN=20
    style=3D"COLOR: navy"><o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dnavy =
size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy">.</SPAN></FONT><FONT =
color=3Dnavy><SPAN=20
    style=3D"COLOR: navy"><o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dnavy =
size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy">.</SPAN></FONT><FONT =
color=3Dnavy><SPAN=20
    style=3D"COLOR: navy"><o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dnavy =
size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy">John L =
Hufferd</SPAN></FONT><FONT=20
    color=3Dnavy><SPAN style=3D"COLOR: =
navy"><o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dnavy =
size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy">Sr. Executive Director of=20
    Technology</SPAN></FONT><FONT color=3Dnavy><SPAN=20
    style=3D"COLOR: navy"><o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dnavy =
size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy">Brocade Communications =
Systems,=20
    Inc</SPAN></FONT><FONT color=3Dnavy><SPAN=20
    style=3D"COLOR: navy"><o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dnavy =
size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy"><A =
title=3Dmailto:jhufferd@brocade.com=20
    =
href=3D"mailto:jhufferd@brocade.com">jhufferd@brocade.com</A></SPAN></FON=
T><FONT=20
    color=3Dnavy><SPAN style=3D"COLOR: =
navy"><o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dnavy =
size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy">Office Phone: (408) 333-5244; =
eFAX:=20
    (408) 904-4688</SPAN></FONT><FONT color=3Dnavy><SPAN=20
    style=3D"COLOR: navy"><o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dnavy =
size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy">Alt Office Phone: (408) =
997-6136; Cell:=20
    (408) 627-9606</SPAN></FONT><FONT color=3Dnavy><SPAN=20
    style=3D"COLOR: navy"><o:p></o:p></SPAN></FONT></P></DIV>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <DIV>
    <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" =
align=3Dcenter><FONT=20
    face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt">
    <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
    </SPAN></FONT></DIV>
    <P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20
    style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:</SPAN></FONT></B><FONT=20
    face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">=20
    ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] <B><SPAN=20
    style=3D"FONT-WEIGHT: bold">On Behalf Of </SPAN></B>Eddy =
Quicksall<BR><B><SPAN=20
    style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Friday, January 06, =
2006 11:42=20
    AM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B>=20
    ips@ietf.org<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Subject:</SPAN></B> [Ips]=20
    iSER API's</SPAN></FONT><o:p></o:p></P></DIV>
    <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
    style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <DIV>
    <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt">Is there any work afoot to design some=20
    standard&nbsp;iSER API's?</SPAN></FONT><o:p></o:p></P></DIV>
    <DIV>
    <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
    style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
    <DIV>
    <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D2><SPAN=20
    style=3D"FONT-SIZE: =
10pt">Eddy</SPAN></FONT><o:p></o:p></P></DIV></DIV></BLOCKQUOTE></BLOCKQU=
OTE></BODY></HTML>

------=_NextPart_000_0023_01C61504.67FB9030--



--===============1938654579==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--===============1938654579==--





From ips-bounces@ietf.org Wed Jan 11 00:18:00 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EwYMy-0004X9-TR; Wed, 11 Jan 2006 00:18:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EwYMx-0004X1-3S
	for ips@megatron.ietf.org; Wed, 11 Jan 2006 00:17:59 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13296
	for <ips@ietf.org>; Wed, 11 Jan 2006 00:16:39 -0500 (EST)
Received: from uproxy.gmail.com ([66.249.92.197])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwYTl-0006RR-Bk
	for ips@ietf.org; Wed, 11 Jan 2006 00:25:03 -0500
Received: by uproxy.gmail.com with SMTP id o2so18851uge
	for <ips@ietf.org>; Tue, 10 Jan 2006 21:17:49 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:mime-version:content-type;
	b=jPMerNgclLFqMCrryzDhZto19CkwkxA8hjNBE14CymOLzYvMnJgfVUnKM2VTgNXmTk288GR7siOm/3bQtRTb9f6TU82EROJto+AGXu5izZsAcveMw5c387bsFY1TRogFNlbe5/h921hiuy5AaaoODnFCobUM0PPODzlbwbRMzdo=
Received: by 10.66.220.5 with SMTP id s5mr142555ugg;
	Tue, 10 Jan 2006 21:17:48 -0800 (PST)
Received: by 10.66.222.6 with HTTP; Tue, 10 Jan 2006 21:17:48 -0800 (PST)
Message-ID: <f11fe6980601102117u4dc95f39ud4eb4c0c20acdd2e@mail.gmail.com>
Date: Wed, 11 Jan 2006 10:47:48 +0530
From: Aravind Rajagopal <aravind.mails@gmail.com>
To: ips@ietf.org
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Subject: [Ips] Doubt in Login sequence.
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0506368180=="
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org

--===============0506368180==
Content-Type: multipart/alternative; 
	boundary="----=_Part_55473_11252841.1136956668829"

------=_Part_55473_11252841.1136956668829
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi iSCSI Authors,

I'm facing a scenario in the Login Sequence which might be illegal, but I a=
m
unsure of the same. I would like to know what you think of the exchange.

The AuthMethod negotiated is CHAP and once the Chap Challenge is sent by th=
e
Target, the Init responds with the Chap response with CSG=3DNSG=3D0 and T=
=3D0.
This is validated by the target which finds Authentication to be successful
and the Login Response also has CSG=3DNSG=3DT=3D0.
Now, the Init sends a Login Req with CSG=3DNSG=3D0 and T=3D0 and with no da=
ta
attached. The target responds with a Login reponse with Status Class =3D0x3
indicating failure on the Target side to continue the login.
My concern is over the Last Login Req which according to the draft is not
strictly speaking illegal. So should the target respond with a Login Resp
with again CSG=3DNSG=3DT=3D0. Or is it justified in reporting an error?

Thanks!
Aravind.

------=_Part_55473_11252841.1136956668829
Content-Type: text/html; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi iSCSI Authors,<br>
<br>
I'm facing a scenario in the Login Sequence which might be illegal, but
I am unsure of the same. I would like to know what you think of the
exchange.<br>
<br>
The AuthMethod negotiated is CHAP and once the Chap Challenge is sent
by the Target, the Init responds with the Chap response with CSG=3DNSG=3D0
and T=3D0. This is validated by the target which finds Authentication to
be successful and the Login Response also has CSG=3DNSG=3DT=3D0.<br>
Now, the Init sends a Login Req with CSG=3DNSG=3D0 and T=3D0 and with no da=
ta
attached. The target responds with a Login reponse with Status Class
=3D0x3 indicating failure on the Target side to continue the login.<br>
My concern is over the Last Login Req which according to the draft is
not strictly speaking illegal. So should the target respond with a
Login Resp with again CSG=3DNSG=3DT=3D0. Or is it justified in reporting an
error?<br>
<br>
Thanks!<br>
Aravind.<br>


------=_Part_55473_11252841.1136956668829--


--===============0506368180==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--===============0506368180==--




From ips-bounces@ietf.org Wed Jan 11 19:46:21 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ewqbd-0003jk-NK; Wed, 11 Jan 2006 19:46:21 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewqbc-0003jc-5B
	for ips@megatron.ietf.org; Wed, 11 Jan 2006 19:46:20 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00975
	for <ips@ietf.org>; Wed, 11 Jan 2006 19:44:57 -0500 (EST)
Received: from mononoke.wasabisystems.com ([66.173.145.228])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwqiZ-0007Hq-Ex
	for ips@ietf.org; Wed, 11 Jan 2006 19:53:32 -0500
Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91])
	by mononoke.wasabisystems.com (Postfix) with ESMTP
	id 87D43870AB; Wed, 11 Jan 2006 19:46:03 -0500 (EST)
In-Reply-To: <f11fe6980601102117u4dc95f39ud4eb4c0c20acdd2e@mail.gmail.com>
References: <f11fe6980601102117u4dc95f39ud4eb4c0c20acdd2e@mail.gmail.com>
Mime-Version: 1.0 (Apple Message framework v623)
Message-Id: <fe835bc61eb46efd22eb909ba1abd88e@wasabisystems.com>
From: William Studenmund <wrstuden@wasabisystems.com>
Subject: Re: [Ips] Doubt in Login sequence.
Date: Wed, 11 Jan 2006 16:45:51 -0800
To: Aravind Rajagopal <aravind.mails@gmail.com>
X-Pgp-Agent: GPGMail 1.0 (v30, 10.3)
X-Mailer: Apple Mail (2.623)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Cc: ips@ietf.org
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0693122808=="
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org


--===============0693122808==
Content-Type: multipart/signed; protocol="application/pgp-signature";
	micalg=pgp-sha1; boundary="Apple-Mail-6--194238655"
Content-Transfer-Encoding: 7bit


--Apple-Mail-6--194238655
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit


On Jan 10, 2006, at 9:17 PM, Aravind Rajagopal wrote:

> Hi iSCSI Authors,
>
>  I'm facing a scenario in the Login Sequence which might be illegal, 
> but I am unsure of the same. I would like to know what you think of 
> the exchange.
>
>  The AuthMethod negotiated is CHAP and once the Chap Challenge is sent 
> by the Target, the Init responds with the Chap response with CSG=NSG=0 
> and T=0. This is validated by the target which finds Authentication to 
> be successful and the Login Response also has CSG=NSG=T=0.
>  Now, the Init sends a Login Req with CSG=NSG=0 and T=0 and with no 
> data attached. The target responds with a Login reponse with Status 
> Class =0x3 indicating failure on the Target side to continue the 
> login.
>  My concern is over the Last Login Req which according to the draft is 
> not strictly speaking illegal. So should the target respond with a 
> Login Resp with again CSG=NSG=T=0. Or is it justified in reporting an 
> error?

The target is ALWAYS free to report a Status Class =0x3 error. It can 
do so due to an internal error, because it thinks you won the lottery, 
because it thinks you didn't win the lottery, or because of the phase 
of the moon.

Obviously it is best if it actually logs you in instead, but it is 
permissible.

To be honest, I wonder why the initiator sent the empty NSG=0/T=0 
packet. The only reason to not continue CHAP is if the initiator wants 
to perform mutual auth, but to do so it should have sent a new 
challenge and I value when it sent back the response and name. Thus 
there really is no reason to not be transitioning out of security. So 
the target is probably shutting things down as the initiator looks 
broken.

Take care,

Bill

--Apple-Mail-6--194238655
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iD8DBQFDxabJDJT2Egh26K0RAj4UAJ9OqVEKagR9ktoeEqJ6kaB3k8TuqwCfcXDB
iUcJrc31GglP7iq30umR5Zk=
=wOmb
-----END PGP SIGNATURE-----

--Apple-Mail-6--194238655--



--===============0693122808==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--===============0693122808==--





From ips-bounces@ietf.org Sun Jan 15 10:54:01 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EyACf-0003uB-Rj; Sun, 15 Jan 2006 10:54:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EyAB6-0003JA-Br
	for ips@megatron.ietf.org; Sun, 15 Jan 2006 10:52:27 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20388
	for <ips@ietf.org>; Sun, 15 Jan 2006 10:50:33 -0500 (EST)
From: Black_David@emc.com
Received: from mexforward.lss.emc.com ([168.159.213.200])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Exw2o-0003gC-Nh
	for ips@ietf.org; Sat, 14 Jan 2006 19:46:55 -0500
Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.11])
	by mexforward.lss.emc.com (Switch-3.1.0/Switch-3.1.7) with ESMTP id
	k0F0cpD4020194
	for <ips@ietf.org>; Sat, 14 Jan 2006 19:38:51 -0500 (EST)
Received: from MAHO3MSX2.corp.emc.com (maho3msx2.corp.emc.com [128.221.11.32])
	by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id
	k0F0clVk026809
	for <ips@ietf.org>; Sat, 14 Jan 2006 19:38:47 -0500 (EST)
Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19)
	id <CKRHRFQA>; Sat, 14 Jan 2006 19:38:47 -0500
Message-ID: <F222151D3323874393F83102D614E055013E904A@CORPUSMX20A.corp.emc.com>
To: ips@ietf.org
Date: Sat, 14 Jan 2006 19:38:43 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0,
	Antispam-Data: 2006.01.14.161105
X-PerlMx-Spam: Gauge=, SPAM=1%, Reasons='EMC_FROM_00+ -3, EMC_BODY_1+ -1,
	IP_HTTP_ADDR 0, NO_REAL_NAME 0, __C230066_P5 0, __CT 0,
	__CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0,
	__IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0,
	__SANE_MSGID 0, __STOCK_CRUFT 0'
X-Spam-Score: 0.3 (/)
X-Scan-Signature: a743e34ab8eb08259de9a7307caed594
Subject: [Ips] iSCSI ACA - Implementers Guide (long, sorry)
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=subscribe>
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org

An Implementer working on ACA (Auto-Contingent Allegiance)
has pointed out some issues that could use some attention
in the implementers guide.  The SCSI reference for this is
Section 5.9.1 of SAM-2.  NOTE: This message is not written
in my role as WG Chair.

A quick introduction is that ACA is an alternative behavior
for error handling (CHECK CONDITION) to the more familiar
behavior of CA (Contingent Allegiance) that is immediately
exited via Autosense.  ACA is requested on a per command
basis via the NACA bit in the CDB.  The Autosense transmission
of sense data still occurs as a result of CHECK CONDITION
(Autosense is required by iSCSI), but unlike CA, the ACA
condition persists until it is cleared by a CLEAR ACA task
management function.  During ACA, the initiator uses commands
with the ACA attribute (cf Section 10.3 of RFC 3720) to
deal with the situation.  One ACA command at a time is
permitted, and non ACA commands are rejected with an "ACA
ACTIVE" status.

The change in command processing behavior when entering ACA
raises a number of concurrency issues, as SAM-2 is specified
as if the initiator and target interact synchronously, which
is not the case for iSCSI.  SAM-2 contains the following
somewhat cryptic text in Section 5.9.1.2 whose consequences
the implementers guide could help explain:

	If the SCSI transport protocol does not enforce state
	synchronization as described in 4.6.2, there may be a
	time delay between the occurrence of the CA or ACA
	condition and the time at which the application client
	becomes aware of the condition.

iSCSI does not enforce state synchronization.  Further, in a
multi-connection session, iSCSI does not support status
sequencing (order of delivery of status/responses) across
connections.  So, for a multi-connection, session, there are
(at least) 4 interesting potential concurrency conditions:

(1) The SCSI response indicating that CHECK CONDITION has
	caused establishment of ACA could get ahead of a response
	to a command completed prior to establishment of ACA.

(2) An ACA ACTIVE status response could get ahead of the SCSI
	response that indicates establishment of ACA.

(3) A command issued prior to establishment of ACA could
	arrive after ACA is established.

(4) The CLEAR ACA task management function could get ahead of
	a command that is dealing with the ACA condition.

Here are some initial thoughts on how to deal with these
situations:

-- (1) The SCSI response indicating that CHECK CONDITION has
	caused establishment of ACA could get ahead of a response
	to a command completed prior to establishment of ACA.

This is only a concern in multi-connection sessions, as in a
single-connection session, the response indicating ACA
establishment will come after responses to all prior commands.
This behavior can be preserved for multi-connection sessions
by saying that the target MUST wait for acknowledgement of all
responses outstanding on other connections at the time of ACA
establishment before sending the response that indicates ACA
has been established.  This "MUST" would be an additional
requirement to RFC 3720 for multi-connection targets.

This seems like a useful thing to require, as one of the first
things an initiator will probably want to do on learning
that ACA has happened is figure out what commands completed
successfully prior to ACA (vs. are still at the target, and
hence have been blocked by the ACA), and only the target knows
what statuses are outstanding against the other connections.

OTOH, it causes delays, so the alternative is to leave the
initiator to sort this out, which may entail issuing NOPs
to determine command status on other connections.  That
would have the advantage of limiting the impact of ACA
support to multi-connection initiators that actually want
to use ACA, but the need to use the NOPs is unpleasant,
leading me to favor having the target get this right
(initiators who don't like the resulting delay in entering
ACA shouldn't use it).

I don't think ignoring the issue causes any SCSI specification
violations, but it may make ACA error handling behave badly
as command completions will be unexpectedly received during ACA.

-- (2) An ACA ACTIVE status response could get ahead of the SCSI
	response that indicates establishment of ACA.

Again, this is only a concern in multi-connection sessions, as
in a single-connection session, ACA ACTIVE responses will come
after the response indicating that ACA has been entered.  The
approach to this should probably match (1) - if the target is
required to wait for outstanding responses on other connections
in (1), we should require that the target MUST receive
acknowledgement of the response indicating establishment of ACA
before issuing any ACA ACTIVE status responses on any connection
other than the one that response used.  This "MUST" would be an
additional requirement to RFC 3720 for multi-connection targets.

The resulting delay in issuing ACA ACTIVE responses seems to be
less of a concern, as the initiator can figure out what's
going to happen:
- Based on (1), the initiator has responses to the completed
	commands,
- Uncompleted commands prior to ExpCmdSN in the response that
	established ACA were delivered to SCSI and have been
	blocked by the ACA.
- All other commands will receive ACA ACTIVE status responses,
	as they were not delivered to SCSI when the ACA occurred.

If we don't require the wait in (1), initiator use of NOP on
other connections will flush out delayed ACA ACTIVE responses,
but still leave a multi-connection initiator who wants to use
ACA with the surprise that ACA ACTIVE responses can show up
before the response indicating that an ACA has occurred.  This
will result in a requirement on initiators to hold ACA ACTIVE
status responses until the SCSI response indicating that ACA
has occurred is delivered.  This is an additional requirement
to RFC 3720, and may require initiators to track NACA on all
outstanding commands to determine whether an Autosense response
caused ACA or not.  This is probably better left to SCSI.

IMHO, something needs to be done here, as delivery of an ACA
ACTIVE response to SCSI before the response indicating ACA
establishment is pretty clearly wrong from a SCSI perspective.

Between (1) and (2) it's probably a good idea to advise
initiator implementers that the synchronous nature of ACA
makes it a poor fit with the concurrency of multi-connection
iSCSI sessions.

-- (3) A command issued prior to establishment of ACA could
	arrive after ACA is established.

For a command without the ACA attribute, this is not an issue -
such a command will be rejected with ACA ACTIVE status if ACA
is in effect when it is due to be delivered to SCSI at the
target.

For a command with the ACA attribute, the situation is less
clear, courtesy of the text quoted from SAM-2 above.  I talked
with at least one other SCSI expert at T10 last week, and the
two of us concur that this initiator behavior (initiator issues
a command with the ACA attribute without knowing that ACA is
in effect at the target) is questionable at best and probably
wrong (and hence if the target unexpectedly executes the
command because an ACA occurred, the initiator got what it
deserved).

Hence I suggest guidance (for both single and multi-connection
sessions) that an initiator SHOULD NOT issue commands with the
ACA attribute unless it knows that ACA is in effect at a target,
because targets will process all commands with the ACA attribute
if they are received while ACA is in effect, irrespective of
whether an initiator may have issued such a command prior to
ACA being established.  I believe this target behavior is
permitted by the text quoted from SAM-2 above.  This is a
general SCSI matter, and is not a change from RFC 3720.

One of the reasons for taking this approach is that determining
what ACA command to issue could well depend on what went wrong
to cause the CHECK CONDITION in the first place, and an
initiator that thinks it knows all the possible ways in which a
target could get into a CHECK CONDITION is probably kidding
itself in most cases.  It's better in general to wait for the
ACA, look at the sense data and figure out what to do rather
than blindly fire an ACA command into the dark based on a guess
about what will cause the ACA.

-- (4) The CLEAR ACA task management function could get ahead of
	a command that is dealing with the ACA condition.

The corresponding race for exiting ACA - issue CLEAR ACA while a
command with the ACA attribute is outstanding - seems less of a
concern. An initiator who has done this clearly doesn't care
whether that command (and there can only be one) executes or not.

SAM-2 says that CLEAR ACA has the side effect of aborting a task
with the ACA attribute.  iSCSI's logical ordering of command (and
task management function) delivery to SCSI at the target ensures
that this abort side effect will take place, but it's probably
worth pointing out that the ordering responsibilities in Section
10.5.1 apply to this situation:
- The target MUST wait for all tasks prior to the CLEAR ACA
	function to arrive in order to issue the ACA ACTIVE response
	(non ACA task) or abort them (ACA task).
- The initiator MUST NOT deliver responses from affected
	tasks (all tasks prior to the CLEAR ACA function) to
	SCSI after the response to CLEAR ACA is delivered.
An initiator that wishes to deal with ACA as expeditiously as
possible should (lower case):
- Issue all commands with the ACA attribute as well as the
	CLEAR ACA task management function on the same connection
	as the SCSI response that indicated establishment of ACA.
- Not issue any commands without the ACA attribute prior to
	the CLEAR ACA task management function.

Comments? (and sorry for the length)

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------


_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips



From ips-bounces@ietf.org Sun Jan 15 13:59:21 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EyD61-0006mp-6V; Sun, 15 Jan 2006 13:59:21 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EyD3C-0004NV-UU
	for ips@megatron.ietf.org; Sun, 15 Jan 2006 13:56:27 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21248
	for <ips@ietf.org>; Sun, 15 Jan 2006 10:52:07 -0500 (EST)
Received: from mx2.netapp.com ([216.240.18.37])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExvOH-0000Wq-TI
	for ips@ietf.org; Sat, 14 Jan 2006 19:05:04 -0500
Received: from smtp2.corp.netapp.com ([10.57.159.114])
	by mx2.netapp.com with ESMTP; 14 Jan 2006 15:56:44 -0800
X-IronPort-AV: i="3.99,367,1131350400"; 
	d="scan'208,217"; a="344759221:sNHT6682576500"
Received: from [10.30.24.87] ([10.30.24.87])
	by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id
	k0ENuY80013881; Sat, 14 Jan 2006 15:56:35 -0800 (PST)
Message-ID: <43C98FB1.7050107@netapp.com>
Date: Sat, 14 Jan 2006 18:56:33 -0500
From: Dave Wysochanski <davidw@netapp.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Eddy Quicksall <eddy_quicksall_iVivity_iSCSI@comcast.net>
Subject: Re: [Ips] iSER API's
References: <D4F8F0B3820E754C887699BEF26A8940D7A990@taurus.voltaire.com>
	<002601c6152e$51419810$08031eac@ivivity.com>
In-Reply-To: <002601c6152e$51419810$08031eac@ivivity.com>
X-Spam-Score: 0.9 (/)
X-Scan-Signature: 4cbeb0f20efb229aa93fae1468d20275
Cc: snia-ips@snia.org, ips@ietf.org, John Hufferd <jhufferd@Brocade.COM>
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0972022082=="
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org

This is a multi-part message in MIME format.
--===============0972022082==
Content-Type: multipart/alternative;
	boundary="------------080704060402020005050808"

This is a multi-part message in MIME format.
--------------080704060402020005050808
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

This might be a good work item for SNIA IPS WG, provided there was 
enough interest.



Eddy Quicksall wrote:

> Here is an example of what I mean when I say API:
>  
>
> ISER_SendControl is used to send SCSI commands, SCSI TMF's, 
> unsolicited SCSI Data-out, SCSI Responses and iSCSI Asyncronous Message.
>
>  
>
> ISER_RC_T ISER_SendControl(
>
> ISER_CONNECTION_HANDLE_T connectionHandle,
>
> pISCSI_HEADER pHeader,
>
> pISER_PDU_QUALIFIERS pPDUQualifiers );
>
>  
>
> Returns: ISER_GOOD or ISER_FAILED
>
>  
>
> connectionHandle The connection handle returned by ISER_Connect
>
> pHeader              A pointer to an iSCSI header.
>
> pPDUQualifiers     A pointer to a set of qualifiers. The only 
> qualifiers that need to be actually set are the ones relevant to the 
> iSCSI header.
>
>     ----- Original Message -----
>     From: Dan Bar Dov <mailto:danb@voltaire.com>
>     To: John Hufferd <mailto:jhufferd@Brocade.COM> ; Eddy Quicksall
>     <mailto:eddy_quicksall_iVivity_iSCSI@comcast.net> ; ips@ietf.org
>     <mailto:ips@ietf.org>
>     Sent: Sunday, January 08, 2006 8:50 PM
>     Subject: RE: [Ips] iSER API's
>
>     Indeed on Linux the direction is towards a generic RDMA interface.
>     CMA provides a generic CM abstraction, and the ib_verbs API is
>     planned to extend over iWARP one way or another.
>     The DM was deemed unnecessary, the API between iSCSI & SCSI and
>     the underlying iSER enforced redesign of the iSER API to conform
>     with iSCSI and SCSI rather then implement yet another layer
>     between iSER and iSCSI/SCSI (namely DM).
>      
>     Dan
>
>         ------------------------------------------------------------------------
>         From: ips-bounces@ietf.org <mailto:ips-bounces@ietf.org>
>         [mailto:ips-bounces@ietf.org] On Behalf Of John Hufferd
>         Sent: Friday, January 06, 2006 11:18 PM
>         To: Eddy Quicksall; ips@ietf.org
>         Subject: RE: [Ips] iSER API's
>
>         Eddy,
>
>         What APIs are you asking about?  The SCSI CLASS Driver to the
>         Device Driver (Mini Port Driver) should have the same
>         interfaces for iSER as it is available for iSCSI.  If you mean
>         between the Device Driver (Mini Port Driver) and the RNIC,
>         that will probably be the RNIC vendors interface if they have
>         implemented all or part of the iSER or Data Mover in the RNIC
>         itself, or the RNIC vendor's interfaces to their version of
>         the verbs (at least until the OS implements its own RDMA
>         interfaces that implement the RDMA verbs).
>
>          
>
>         I believe that, over time, most OSs will have generic RDMA
>         interfaces, which can be use by all certified RNIC hardware,
>         and any application (user space or kernel space); in that case
>         the iSER module will probably interface to that OS's RDMA
>         interfaces.
>
>          
>
>         .
>
>         .
>
>         .
>
>         John L Hufferd
>
>         Sr. Executive Director of Technology
>
>         Brocade Communications Systems, Inc
>
>         jhufferd@brocade.com <mailto:jhufferd@brocade.com>
>
>         Office Phone: (408) 333-5244; eFAX: (408) 904-4688
>
>         Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606
>
>          
>
>         ------------------------------------------------------------------------
>
>         From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On
>         Behalf Of Eddy Quicksall
>         Sent: Friday, January 06, 2006 11:42 AM
>         To: ips@ietf.org
>         Subject: [Ips] iSER API's
>
>          
>
>         Is there any work afoot to design some standard iSER API's?
>
>          
>
>         Eddy
>


--------------080704060402020005050808
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
This might be a good work item for SNIA IPS WG, provided there was
enough interest.<br>
<br>
<br>
<br>
Eddy Quicksall wrote:<br>
<blockquote cite="mid002601c6152e$51419810$08031eac@ivivity.com"
 type="cite">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta content="MSHTML 6.00.2900.2802" name="GENERATOR">
<!--[if !mso]>
<STYLE>v\:* {
	BEHAVIOR: url(#default#VML)
}
o\:* {
	BEHAVIOR: url(#default#VML)
}
w\:* {
	BEHAVIOR: url(#default#VML)
}
.shape {
	BEHAVIOR: url(#default#VML)
}
</STYLE>
<![endif]--><o:SmartTagType
 namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="City"></o:SmartTagType><o:SmartTagType
 namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="place"></o:SmartTagType><!--[if !mso]>
<STYLE>st1\:* {
	BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<![endif]-->
  <style>@font-face {
	font-family: Tahoma;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.EmailStyle17 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
DIV.Section1 {
	page: Section1
}
  </style><!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
  <div><font size="2">Here is an example of what I mean when I say API:</font></div>
  <div>&nbsp;</div>
  <div>
  <p class="MsoNormal" style="margin: 0in 0in 0pt;"><font face="Verdana"
 size="2">ISER_SendControl is used to send SCSI commands, SCSI TMF&#8217;s,
unsolicited SCSI Data-out, SCSI Responses and iSCSI Asyncronous Message.</font></p>
  <p class="MsoNormal" style="margin: 0in 0in 0pt;"><o:p><font
 face="Verdana" size="2">&nbsp;</font></o:p></p>
  <p class="MsoNormal" style="margin: 0in 0in 0pt;"><font face="Verdana"
 size="2">ISER_RC_T ISER_SendControl( </font></p>
  <p class="MsoNormal" style="margin: 0in 0in 0pt; text-indent: 0.5in;"><font
 face="Verdana" size="2">ISER_CONNECTION_HANDLE_T connectionHandle,</font></p>
  <p class="MsoNormal" style="margin: 0in 0in 0pt; text-indent: 0.5in;"><font
 face="Verdana" size="2">pISCSI_HEADER pHeader,</font></p>
  <p class="MsoNormal" style="margin: 0in 0in 0pt; text-indent: 0.5in;"><font
 face="Verdana" size="2">pISER_PDU_QUALIFIERS pPDUQualifiers );</font></p>
  <p class="MsoNormal" style="margin: 0in 0in 0pt; text-indent: 0.5in;"><o:p><font
 face="Verdana" size="2">&nbsp;</font></o:p></p>
  <p class="MsoNormal" style="margin: 0in 0in 0pt;"><font size="2"><font
 face="Verdana">Returns: ISER_GOOD or ISER_FAILED</font></font></p>
  <p class="MsoNormal" style="margin: 0in 0in 0pt;"><o:p><font
 face="Verdana" size="2">&nbsp;</font></o:p></p>
  <p class="MsoNormal" style="margin: 0in 0in 0pt;"><font face="Verdana"
 size="2">connectionHandle The connection handle returned by
ISER_Connect</font></p>
  <p class="MsoNormal" style="margin: 0in 0in 0pt;"><font face="Verdana"
 size="2">pHeader&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A pointer to an iSCSI header.</font></p>
  <p class="MsoNormal"
 style="margin: 0in 0in 0pt 1.5in; text-indent: -1.5in;"><font
 face="Verdana" size="2">pPDUQualifiers<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>A
pointer to a set of qualifiers. The only qualifiers that need to be
actually set are the ones relevant to the iSCSI header.</font></p>
  </div>
  <blockquote
 style="border-left: 2px solid rgb(0, 0, 0); padding-right: 0px; padding-left: 5px; margin-left: 5px; margin-right: 0px;"
 dir="ltr">
    <div
 style="font-family: arial; font-style: normal; font-variant: normal; font-weight: normal; font-size: 10pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">-----
Original Message ----- </div>
    <div
 style="background: rgb(228, 228, 228) none repeat scroll 0%; -moz-background-clip: initial; -moz-background-origin: initial; -moz-background-inline-policy: initial; font-family: arial; font-style: normal; font-variant: normal; font-weight: normal; font-size: 10pt; line-height: normal; font-size-adjust: none; font-stretch: normal;"><b>From:</b>
    <a title="danb@voltaire.com" href="mailto:danb@voltaire.com">Dan
Bar Dov</a> </div>
    <div
 style="font-family: arial; font-style: normal; font-variant: normal; font-weight: normal; font-size: 10pt; line-height: normal; font-size-adjust: none; font-stretch: normal;"><b>To:</b>
    <a title="jhufferd@Brocade.COM" href="mailto:jhufferd@Brocade.COM">John
Hufferd</a> ; <a title="eddy_quicksall_iVivity_iSCSI@comcast.net"
 href="mailto:eddy_quicksall_iVivity_iSCSI@comcast.net">Eddy Quicksall</a>
; <a title="ips@ietf.org" href="mailto:ips@ietf.org">ips@ietf.org</a> </div>
    <div
 style="font-family: arial; font-style: normal; font-variant: normal; font-weight: normal; font-size: 10pt; line-height: normal; font-size-adjust: none; font-stretch: normal;"><b>Sent:</b>
Sunday, January 08, 2006 8:50 PM</div>
    <div
 style="font-family: arial; font-style: normal; font-variant: normal; font-weight: normal; font-size: 10pt; line-height: normal; font-size-adjust: none; font-stretch: normal;"><b>Subject:</b>
RE: [Ips] iSER API's</div>
    <div><br>
    </div>
    <div align="left" dir="ltr"><span class="650424501-09012006"><font
 color="#0000ff" face="Arial" size="2">Indeed on Linux the direction is
towards a generic RDMA interface. CMA provides a generic CM
abstraction, and the ib_verbs API is planned to extend over iWARP one
way or another. </font></span></div>
    <div align="left" dir="ltr"><span class="650424501-09012006"><font
 color="#0000ff" face="Arial" size="2">The DM was deemed unnecessary,
the API between iSCSI &amp; SCSI and the underlying iSER enforced
redesign of the iSER API to conform with iSCSI and SCSI rather then
implement yet another layer between iSER and iSCSI/SCSI (namely DM).</font></span></div>
    <div align="left" dir="ltr"><span class="650424501-09012006"></span>&nbsp;</div>
    <div align="left" dir="ltr"><span class="650424501-09012006"><font
 color="#0000ff" face="Arial" size="2">Dan</font></span></div>
    <br>
    <blockquote
 style="border-left: 2px solid rgb(0, 0, 255); padding-left: 5px; margin-left: 5px; margin-right: 0px;"
 dir="ltr">
      <div class="OutlookMessageHeader" align="left" dir="ltr"
 lang="en-us">
      <hr tabindex="-1"> <font face="Tahoma" size="2"><b>From:</b> <a
 href="mailto:ips-bounces@ietf.org">ips-bounces@ietf.org</a>
[<a class="moz-txt-link-freetext" href="mailto:ips-bounces@ietf.org">mailto:ips-bounces@ietf.org</a>] <b>On Behalf Of </b>John Hufferd<br>
      <b>Sent:</b> Friday, January 06, 2006 11:18 PM<br>
      <b>To:</b> Eddy Quicksall; <a class="moz-txt-link-abbreviated" href="mailto:ips@ietf.org">ips@ietf.org</a><br>
      <b>Subject:</b> RE: [Ips] iSER API's<br>
      </font><br>
      </div>
      <div class="Section1">
      <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
 style="font-size: 10pt; color: navy; font-family: Arial;">Eddy,<o:p></o:p></span></font></p>
      <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
 style="font-size: 10pt; color: navy; font-family: Arial;">What APIs
are you asking about? &nbsp;The SCSI CLASS Driver to the Device Driver (Mini
Port Driver) should have the same interfaces for iSER as it is
available for iSCSI.&nbsp; If you mean between the Device Driver (Mini Port
Driver) and the RNIC, that will probably be the RNIC vendors interface
if they have implemented all or part of the iSER or Data Mover in the
RNIC itself, or the RNIC vendor&#8217;s interfaces to their version of the
verbs (at least until the OS implements its own RDMA interfaces that
implement the RDMA verbs). <o:p></o:p></span></font></p>
      <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
 style="font-size: 10pt; color: navy; font-family: Arial;"><o:p>&nbsp;</o:p></span></font></p>
      <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
 style="font-size: 10pt; color: navy; font-family: Arial;">I believe
that, over time, most <st1:City w:st="on"><st1:place w:st="on">OSs</st1:place></st1:City>
will have generic RDMA interfaces, which can be use by all certified
RNIC hardware, and any application (user space or kernel space); in
that case the iSER module will probably interface to that OS&#8217;s RDMA
interfaces.<o:p></o:p></span></font></p>
      <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
 style="font-size: 10pt; color: navy; font-family: Arial;"><o:p>&nbsp;</o:p></span></font></p>
      <div>
      <p class="MsoNormal"><font color="navy" face="Times New Roman"
 size="2"><span style="font-size: 10pt; color: navy;">.</span></font><font
 color="navy"><span style="color: navy;"><o:p></o:p></span></font></p>
      <p class="MsoNormal"><font color="navy" face="Times New Roman"
 size="2"><span style="font-size: 10pt; color: navy;">.</span></font><font
 color="navy"><span style="color: navy;"><o:p></o:p></span></font></p>
      <p class="MsoNormal"><font color="navy" face="Times New Roman"
 size="2"><span style="font-size: 10pt; color: navy;">.</span></font><font
 color="navy"><span style="color: navy;"><o:p></o:p></span></font></p>
      <p class="MsoNormal"><font color="navy" face="Times New Roman"
 size="2"><span style="font-size: 10pt; color: navy;">John L Hufferd</span></font><font
 color="navy"><span style="color: navy;"><o:p></o:p></span></font></p>
      <p class="MsoNormal"><font color="navy" face="Times New Roman"
 size="2"><span style="font-size: 10pt; color: navy;">Sr. Executive
Director of Technology</span></font><font color="navy"><span
 style="color: navy;"><o:p></o:p></span></font></p>
      <p class="MsoNormal"><font color="navy" face="Times New Roman"
 size="2"><span style="font-size: 10pt; color: navy;">Brocade
Communications Systems, Inc</span></font><font color="navy"><span
 style="color: navy;"><o:p></o:p></span></font></p>
      <p class="MsoNormal"><font color="navy" face="Times New Roman"
 size="2"><span style="font-size: 10pt; color: navy;"><a
 title="mailto:jhufferd@brocade.com" href="mailto:jhufferd@brocade.com">jhufferd@brocade.com</a></span></font><font
 color="navy"><span style="color: navy;"><o:p></o:p></span></font></p>
      <p class="MsoNormal"><font color="navy" face="Times New Roman"
 size="2"><span style="font-size: 10pt; color: navy;">Office Phone:
(408) 333-5244; eFAX: (408) 904-4688</span></font><font color="navy"><span
 style="color: navy;"><o:p></o:p></span></font></p>
      <p class="MsoNormal"><font color="navy" face="Times New Roman"
 size="2"><span style="font-size: 10pt; color: navy;">Alt Office Phone:
(408) 997-6136; Cell: (408) 627-9606</span></font><font color="navy"><span
 style="color: navy;"><o:p></o:p></span></font></p>
      </div>
      <p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
 style="font-size: 10pt; color: navy; font-family: Arial;"><o:p>&nbsp;</o:p></span></font></p>
      <div>
      <div class="MsoNormal" style="text-align: center;" align="center"><font
 face="Times New Roman" size="3"><span style="font-size: 12pt;">
      <hr tabindex="-1" align="center" size="2" width="100%"> </span></font></div>
      <p class="MsoNormal"><b><font face="Tahoma" size="2"><span
 style="font-weight: bold; font-size: 10pt; font-family: Tahoma;">From:</span></font></b><font
 face="Tahoma" size="2"><span
 style="font-size: 10pt; font-family: Tahoma;"> <a class="moz-txt-link-abbreviated" href="mailto:ips-bounces@ietf.org">ips-bounces@ietf.org</a>
[<a class="moz-txt-link-freetext" href="mailto:ips-bounces@ietf.org">mailto:ips-bounces@ietf.org</a>] <b><span style="font-weight: bold;">On
Behalf Of </span></b>Eddy Quicksall<br>
      <b><span style="font-weight: bold;">Sent:</span></b> Friday,
January 06, 2006 11:42 AM<br>
      <b><span style="font-weight: bold;">To:</span></b> <a class="moz-txt-link-abbreviated" href="mailto:ips@ietf.org">ips@ietf.org</a><br>
      <b><span style="font-weight: bold;">Subject:</span></b> [Ips]
iSER API's</span></font><o:p></o:p></p>
      </div>
      <p class="MsoNormal"><font face="Times New Roman" size="3"><span
 style="font-size: 12pt;"><o:p>&nbsp;</o:p></span></font></p>
      <div>
      <p class="MsoNormal"><font face="Times New Roman" size="2"><span
 style="font-size: 10pt;">Is there any work afoot to design some
standard&nbsp;iSER API's?</span></font><o:p></o:p></p>
      </div>
      <div>
      <p class="MsoNormal"><font face="Times New Roman" size="3"><span
 style="font-size: 12pt;">&nbsp;<o:p></o:p></span></font></p>
      </div>
      <div>
      <p class="MsoNormal"><font face="Times New Roman" size="2"><span
 style="font-size: 10pt;">Eddy</span></font><o:p></o:p></p>
      </div>
      </div>
    </blockquote>
  </blockquote>
</blockquote>
<br>
</body>
</html>

--------------080704060402020005050808--


--===============0972022082==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--===============0972022082==--




From ips-bounces@ietf.org Mon Jan 16 14:52:01 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EyaOX-0006PL-02; Mon, 16 Jan 2006 14:52:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EyaOW-0006PG-2Y
	for ips@megatron.ietf.org; Mon, 16 Jan 2006 14:52:00 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10663
	for <ips@ietf.org>; Mon, 16 Jan 2006 14:50:34 -0500 (EST)
Received: from rwcrmhc13.comcast.net ([204.127.198.39]
	helo=rwcrmhc12.comcast.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyaWU-0007s9-OX
	for ips@ietf.org; Mon, 16 Jan 2006 15:00:15 -0500
Received: from ivvtdkv0981 (c-66-177-56-218.hsd1.fl.comcast.net[66.177.56.218])
	by comcast.net (rwcrmhc13) with SMTP
	id <2006011619514601500af1jle>; Mon, 16 Jan 2006 19:51:46 +0000
Message-ID: <000301c61ad6$48a03420$08031eac@ivivity.com>
From: "Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>
To: <Black_David@emc.com>, <ips@ietf.org>
References: <F222151D3323874393F83102D614E055013E904A@CORPUSMX20A.corp.emc.com>
Subject: Re: [Ips] iSCSI ACA - Implementers Guide (long, sorry)
Date: Mon, 16 Jan 2006 14:51:45 -0500
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="Windows-1252";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9
Content-Transfer-Encoding: 7bit
Cc: 
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=subscribe>
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org

I only read about 3/4 of this but one there thing that I would like to 
comment on:

If the target is going to have wait for acknowledgement of all responses 
outstanding on other connections  then wouldn't it have to use a NOP-in to 
solicit the next ExpStatSN?  (because it can't be guaranteed that the 
initiator will be sending another command). I don't see any big deal in the 
but just thought it would be worth mentioning.

I would think that the delay mentioned would not be much of a concern 
because this would only happen if there is a check condition followed by 
recovery action in which case performance would be suffering anyway.

Also I think that the delay we introduce with this proposal is consistent 
with the sentence in SAM-2 you have mentioned.

Eddy

----- Original Message ----- 
From: <Black_David@emc.com>
To: <ips@ietf.org>
Sent: Saturday, January 14, 2006 7:38 PM
Subject: [Ips] iSCSI ACA - Implementers Guide (long, sorry)


> An Implementer working on ACA (Auto-Contingent Allegiance)
> has pointed out some issues that could use some attention
> in the implementers guide.  The SCSI reference for this is
> Section 5.9.1 of SAM-2.  NOTE: This message is not written
> in my role as WG Chair.
>
> A quick introduction is that ACA is an alternative behavior
> for error handling (CHECK CONDITION) to the more familiar
> behavior of CA (Contingent Allegiance) that is immediately
> exited via Autosense.  ACA is requested on a per command
> basis via the NACA bit in the CDB.  The Autosense transmission
> of sense data still occurs as a result of CHECK CONDITION
> (Autosense is required by iSCSI), but unlike CA, the ACA
> condition persists until it is cleared by a CLEAR ACA task
> management function.  During ACA, the initiator uses commands
> with the ACA attribute (cf Section 10.3 of RFC 3720) to
> deal with the situation.  One ACA command at a time is
> permitted, and non ACA commands are rejected with an "ACA
> ACTIVE" status.
>
> The change in command processing behavior when entering ACA
> raises a number of concurrency issues, as SAM-2 is specified
> as if the initiator and target interact synchronously, which
> is not the case for iSCSI.  SAM-2 contains the following
> somewhat cryptic text in Section 5.9.1.2 whose consequences
> the implementers guide could help explain:
>
> If the SCSI transport protocol does not enforce state
> synchronization as described in 4.6.2, there may be a
> time delay between the occurrence of the CA or ACA
> condition and the time at which the application client
> becomes aware of the condition.
>
> iSCSI does not enforce state synchronization.  Further, in a
> multi-connection session, iSCSI does not support status
> sequencing (order of delivery of status/responses) across
> connections.  So, for a multi-connection, session, there are
> (at least) 4 interesting potential concurrency conditions:
>
> (1) The SCSI response indicating that CHECK CONDITION has
> caused establishment of ACA could get ahead of a response
> to a command completed prior to establishment of ACA.
>
> (2) An ACA ACTIVE status response could get ahead of the SCSI
> response that indicates establishment of ACA.
>
> (3) A command issued prior to establishment of ACA could
> arrive after ACA is established.
>
> (4) The CLEAR ACA task management function could get ahead of
> a command that is dealing with the ACA condition.
>
> Here are some initial thoughts on how to deal with these
> situations:
>
> -- (1) The SCSI response indicating that CHECK CONDITION has
> caused establishment of ACA could get ahead of a response
> to a command completed prior to establishment of ACA.
>
> This is only a concern in multi-connection sessions, as in a
> single-connection session, the response indicating ACA
> establishment will come after responses to all prior commands.
> This behavior can be preserved for multi-connection sessions
> by saying that the target MUST wait for acknowledgement of all
> responses outstanding on other connections at the time of ACA
> establishment before sending the response that indicates ACA
> has been established.  This "MUST" would be an additional
> requirement to RFC 3720 for multi-connection targets.
>
> This seems like a useful thing to require, as one of the first
> things an initiator will probably want to do on learning
> that ACA has happened is figure out what commands completed
> successfully prior to ACA (vs. are still at the target, and
> hence have been blocked by the ACA), and only the target knows
> what statuses are outstanding against the other connections.
>
> OTOH, it causes delays, so the alternative is to leave the
> initiator to sort this out, which may entail issuing NOPs
> to determine command status on other connections.  That
> would have the advantage of limiting the impact of ACA
> support to multi-connection initiators that actually want
> to use ACA, but the need to use the NOPs is unpleasant,
> leading me to favor having the target get this right
> (initiators who don't like the resulting delay in entering
> ACA shouldn't use it).
>
> I don't think ignoring the issue causes any SCSI specification
> violations, but it may make ACA error handling behave badly
> as command completions will be unexpectedly received during ACA.
>
> -- (2) An ACA ACTIVE status response could get ahead of the SCSI
> response that indicates establishment of ACA.
>
> Again, this is only a concern in multi-connection sessions, as
> in a single-connection session, ACA ACTIVE responses will come
> after the response indicating that ACA has been entered.  The
> approach to this should probably match (1) - if the target is
> required to wait for outstanding responses on other connections
> in (1), we should require that the target MUST receive
> acknowledgement of the response indicating establishment of ACA
> before issuing any ACA ACTIVE status responses on any connection
> other than the one that response used.  This "MUST" would be an
> additional requirement to RFC 3720 for multi-connection targets.
>
> The resulting delay in issuing ACA ACTIVE responses seems to be
> less of a concern, as the initiator can figure out what's
> going to happen:
> - Based on (1), the initiator has responses to the completed
> commands,
> - Uncompleted commands prior to ExpCmdSN in the response that
> established ACA were delivered to SCSI and have been
> blocked by the ACA.
> - All other commands will receive ACA ACTIVE status responses,
> as they were not delivered to SCSI when the ACA occurred.
>
> If we don't require the wait in (1), initiator use of NOP on
> other connections will flush out delayed ACA ACTIVE responses,
> but still leave a multi-connection initiator who wants to use
> ACA with the surprise that ACA ACTIVE responses can show up
> before the response indicating that an ACA has occurred.  This
> will result in a requirement on initiators to hold ACA ACTIVE
> status responses until the SCSI response indicating that ACA
> has occurred is delivered.  This is an additional requirement
> to RFC 3720, and may require initiators to track NACA on all
> outstanding commands to determine whether an Autosense response
> caused ACA or not.  This is probably better left to SCSI.
>
> IMHO, something needs to be done here, as delivery of an ACA
> ACTIVE response to SCSI before the response indicating ACA
> establishment is pretty clearly wrong from a SCSI perspective.
>
> Between (1) and (2) it's probably a good idea to advise
> initiator implementers that the synchronous nature of ACA
> makes it a poor fit with the concurrency of multi-connection
> iSCSI sessions.
>
> -- (3) A command issued prior to establishment of ACA could
> arrive after ACA is established.
>
> For a command without the ACA attribute, this is not an issue -
> such a command will be rejected with ACA ACTIVE status if ACA
> is in effect when it is due to be delivered to SCSI at the
> target.
>
> For a command with the ACA attribute, the situation is less
> clear, courtesy of the text quoted from SAM-2 above.  I talked
> with at least one other SCSI expert at T10 last week, and the
> two of us concur that this initiator behavior (initiator issues
> a command with the ACA attribute without knowing that ACA is
> in effect at the target) is questionable at best and probably
> wrong (and hence if the target unexpectedly executes the
> command because an ACA occurred, the initiator got what it
> deserved).
>
> Hence I suggest guidance (for both single and multi-connection
> sessions) that an initiator SHOULD NOT issue commands with the
> ACA attribute unless it knows that ACA is in effect at a target,
> because targets will process all commands with the ACA attribute
> if they are received while ACA is in effect, irrespective of
> whether an initiator may have issued such a command prior to
> ACA being established.  I believe this target behavior is
> permitted by the text quoted from SAM-2 above.  This is a
> general SCSI matter, and is not a change from RFC 3720.
>
> One of the reasons for taking this approach is that determining
> what ACA command to issue could well depend on what went wrong
> to cause the CHECK CONDITION in the first place, and an
> initiator that thinks it knows all the possible ways in which a
> target could get into a CHECK CONDITION is probably kidding
> itself in most cases.  It's better in general to wait for the
> ACA, look at the sense data and figure out what to do rather
> than blindly fire an ACA command into the dark based on a guess
> about what will cause the ACA.
>
> -- (4) The CLEAR ACA task management function could get ahead of
> a command that is dealing with the ACA condition.
>
> The corresponding race for exiting ACA - issue CLEAR ACA while a
> command with the ACA attribute is outstanding - seems less of a
> concern. An initiator who has done this clearly doesn't care
> whether that command (and there can only be one) executes or not.
>
> SAM-2 says that CLEAR ACA has the side effect of aborting a task
> with the ACA attribute.  iSCSI's logical ordering of command (and
> task management function) delivery to SCSI at the target ensures
> that this abort side effect will take place, but it's probably
> worth pointing out that the ordering responsibilities in Section
> 10.5.1 apply to this situation:
> - The target MUST wait for all tasks prior to the CLEAR ACA
> function to arrive in order to issue the ACA ACTIVE response
> (non ACA task) or abort them (ACA task).
> - The initiator MUST NOT deliver responses from affected
> tasks (all tasks prior to the CLEAR ACA function) to
> SCSI after the response to CLEAR ACA is delivered.
> An initiator that wishes to deal with ACA as expeditiously as
> possible should (lower case):
> - Issue all commands with the ACA attribute as well as the
> CLEAR ACA task management function on the same connection
> as the SCSI response that indicated establishment of ACA.
> - Not issue any commands without the ACA attribute prior to
> the CLEAR ACA task management function.
>
> Comments? (and sorry for the length)
>
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> black_david@emc.com        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
>
>
> _______________________________________________
> Ips mailing list
> Ips@ietf.org
> https://www1.ietf.org/mailman/listinfo/ips 


_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips



From ips-bounces@ietf.org Tue Jan 17 11:03:56 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EytJM-0001PK-DZ; Tue, 17 Jan 2006 11:03:56 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EytJJ-0001Oy-6N; Tue, 17 Jan 2006 11:03:55 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26711;
	Tue, 17 Jan 2006 11:02:28 -0500 (EST)
From: Black_David@emc.com
Received: from mexforward.lss.emc.com ([168.159.213.200])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EytRR-0005d4-JS; Tue, 17 Jan 2006 11:12:19 -0500
Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13])
	by mexforward.lss.emc.com (Switch-3.1.0/Switch-3.1.7) with ESMTP id
	k0HG3ED4014279; Tue, 17 Jan 2006 11:03:14 -0500 (EST)
Received: from MAHO3MSX2.corp.emc.com (maho3msx2.corp.emc.com [128.221.11.32])
	by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id
	k0HG2sOo011857; Tue, 17 Jan 2006 11:02:54 -0500 (EST)
Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19)
	id <CKRHW82J>; Tue, 17 Jan 2006 11:02:50 -0500
Message-ID: <F222151D3323874393F83102D614E055013E906C@CORPUSMX20A.corp.emc.com>
To: harald@alvestrand.no, gen-art@ietf.org
Date: Tue, 17 Jan 2006 11:02:36 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0,
	Antispam-Data: 2006.01.17.073105
X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, EMC_FROM_00+ -3,
	IP_HTTP_ADDR 0, NO_REAL_NAME 0, __C230066_P5 0, __CT 0,
	__CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0,
	__IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0,
	__SANE_MSGID 0, __STOCK_CRUFT 0'
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250
Cc: mbakke@cisco.com, marjorie_krueger@hp.com, mankin@psg.com,
	yaronled@bezeqint.net, ips@ietf.org, michele@sanrad.com,
	kzm@cisco.com, Black_David@emc.com
Subject: [Ips] RE: Gen-ART review of draft-ietf-ips-scsi-mib-08
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=subscribe>
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org

Harald,

Thanks for the review.  We clearly need to respin the document.  Let
me try to deal with your comments, as I'm the responsible WG chair:

> [SAM-2] and [SPC2] are normative references (defines format for ScsiLUN
and 
> other things), but are listed as Working Drafts in the REFERENCE clauses
of 
> multiple MIB objects. (In the references section, the draftness seems 
> implied by the URL only)
> Is this stable enough for an IETF standard reference?
> Or are the references in the MIB wrong?

The answer to both questions is "yes", and there are two issues here:

(1) The REFERENCE clauses are wrong, even though the content of the
	referenced document is the same as what should have been referenced,
	and that content is stable.  The correct references are those given
	in the normative references section, namely ANSI INCITS 366-2003
	and ANSI INCITS 351-2001, and those need to be used in the REFERENCE
	clauses.

(2) For the normative references, the actual references are to the real
	standards (ANSI INCITS), which one is expected to pay for.  T10
	makes the final working drafts available at the URLs given in the
	references, with the following disclaimer:

  This page includes the T10 working draft documents. There are no approved
  (official) standards here. Once a standard is approved, you should buy it
  from ANSI (+1-212-642-4900). Your payment insures that you receive the
  actual standard with all the final changes and it supports the standards
  process. In most cases, the final T10 committee working draft revision
  for a project is retained here. The drafts are used by T10 Committee
  members for reference. In case of any conflict, the published ANSI
  standard prevails.

Issue (1) is sufficient to require a respin of the document - IMHO, any
change to MIB content requires a respin, lest the RFC Editor do something
that prevents the MIB from compiling, and there's an actual change to
MIB content needed to deal with something else you found.

Issue (2) is more subtle.  The URLs are in the draft in order to
facilitate development and technical review of the MIB.  They should
stay there until at least completion of IESG review (and T10 has no
problem with this), but probably should be introduced as "final draft
available at <URL>".

I suggest use of a note to the RFC Editor (in the revised draft) to
remove the URLs, so that they remain available for IESG review purposes.
A quick check of other IETF documents (published RFCs and drafts in
the RFC Editor queue) suggests that we have not included URLs for
these sorts of references in the past.

This URL issue also affects some of the informative reference.
Thanks for catching this.

> The term "running at high speed" is a gating criterion for whether or not 
> the HS counters are mandatory, but I can't see that it's defined in a 
> testable way. Might have missed it - it would logically seem to belong in 
> section 7.5.

Unfortunately, it's fuzzy and not testable in all cases.  Here's what
RFC 4181 (Section 4.6.1.2) has to say about this issue:

   Henceforth "standard" MIB modules MAY
   use the Counter64 type when it makes sense to do so, and MUST use
   Counter64 if the information being modelled would wrap in less than
   one hour if the Counter32 type was used instead.

It clearly "makes sense" to use the Counter64 type, as there are SCSI
implementations that clearly need it based on the "would wrap in less
than one hour" criterion.  Would adapting the quoted RFC 4181 text
(with a reference to RFC 4181) be sufficient to satisfy your concern?

> The scsiDscTgtTable and scsiAuthorizedIntr table seem to form "access 
> lists". They seem to be read-write via SNMP. Should this be explicitly 
> mentioned in the intro in section 5?
> The security considerations for these objects are very good, and make it 
> very clear that they're writable!

It wouldn't hurt to add statements that they are potentially writable
- note that the compliance section contains numerous statements saying
that write access is not required.

> SAS (Serial Attached SCSI) is not mentioned at all. Is it irrelevant, or 
> "just another transport"? Or is this what's called "scsiTransportSBP"?

None of the above - SBP is SCSI over IEEE 1394 (Firewire).  SAS is
different, important and definitely should be added - one more reason
for a respin.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: Harald Tveit Alvestrand [mailto:harald@alvestrand.no] 
> Sent: Tuesday, January 17, 2006 10:03 AM
> To: gen-art@ietf.org
> Cc: mankin@psg.com; Black, David; ips@ietf.org; 
> michele@sanrad.com; mbakke@cisco.com; yaronled@bezeqint.net; 
> marjorie_krueger@hp.com; kzm@cisco.com
> Subject: Gen-ART review of draft-ietf-ips-scsi-mib-08
> 
> This is a Gen-ART review.
> For Gen-ART info, see this 
> URL:<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>
> 
> Document: draft-ietf-ips-scsi-mib-08.txt
> Reviewer: Harald Alvestrand
> Date: Jan 17, 2006
> Summary: Excellent document, two important comments.
> 
> I enjoyed reading this document! - the intro to SCSI and its history was 
> fun to read!
> ----------------------------------------------------------
> Two important questions, that may warrant a respin of the document if I'm 
> right that there's a problem here:
> 
> [SAM-2] and [SPC2] are normative references (defines format for ScsiLUN
and 
> other things), but are listed as Working Drafts in the REFERENCE clauses
of 
> multiple MIB objects. (In the references section, the draftness seems 
> implied by the URL only)
> Is this stable enough for an IETF standard reference?
> Or are the references in the MIB wrong?
> 
> The term "running at high speed" is a gating criterion for whether or not 
> the HS counters are mandatory, but I can't see that it's defined in a 
> testable way. Might have missed it - it would logically seem to belong in 
> section 7.5.
> -------------------------------------------------------------
> Questions, that I'd like to have answered in email, but don't warrant a 
> respin in my opinion:
> 
> The scsiDscTgtTable and scsiAuthorizedIntr table seem to form "access 
> lists". They seem to be read-write via SNMP. Should this be explicitly 
> mentioned in the intro in section 5?
> The security considerations for these objects are very good, and make it 
> very clear that they're writable!
> 
> SAS (Serial Attached SCSI) is not mentioned at all. Is it irrelevant, or 
> "just another transport"? Or is this what's called "scsiTransportSBP"?
> -------------------------------------------------------------
> Nits, which IMHO you can fix or not as you feel like:
> 
> Some byzantine sentences...
> 
> 7.3 "another logical unit changes its status to from available" is missing

> something
> 
> 7.4 "at 10GBit/second with 512 read/write operations" seems to be missing
a 
> byte :-)
> 
> RFC 2119 is listed as an informative reference. I think it needs to be 
> normative.
> 

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips



From ips-bounces@ietf.org Tue Jan 17 12:47:00 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Eyuv6-0005RD-Ef; Tue, 17 Jan 2006 12:47:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Eyuv3-0005Qt-Pc; Tue, 17 Jan 2006 12:46:58 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04269;
	Tue, 17 Jan 2006 12:45:32 -0500 (EST)
From: Black_David@emc.com
Received: from mexforward.lss.emc.com ([168.159.213.200])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Eyv3E-0000SP-Cn; Tue, 17 Jan 2006 12:55:24 -0500
Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13])
	by mexforward.lss.emc.com (Switch-3.1.0/Switch-3.1.7) with ESMTP id
	k0HHkXD4000974; Tue, 17 Jan 2006 12:46:33 -0500 (EST)
Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9])
	by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id
	k0HHkD8H029381; Tue, 17 Jan 2006 12:46:19 -0500 (EST)
Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19)
	id <ZJ2GB6NM>; Tue, 17 Jan 2006 12:40:33 -0500
Message-ID: <F222151D3323874393F83102D614E055013E906F@CORPUSMX20A.corp.emc.com>
To: harald@alvestrand.no, gen-art@ietf.org
Date: Tue, 17 Jan 2006 12:40:28 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0,
	Antispam-Data: 2006.01.17.085105
X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, EMC_FROM_00+ -3,
	IP_HTTP_ADDR 0, NO_REAL_NAME 0, __C230066_P5 0, __CT 0,
	__CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0,
	__IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0,
	__SANE_MSGID 0, __STOCK_CRUFT 0'
X-Spam-Score: 0.3 (/)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024
Cc: mbakke@cisco.com, marjorie_krueger@hp.com, mankin@psg.com,
	yaronled@bezeqint.net, ips@ietf.org, michele@sanrad.com,
	kzm@cisco.com, Black_David@emc.com
Subject: [Ips] RE: [Gen-art] RE: Gen-ART review of draft-ietf-ips-scsi-mib-08
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=subscribe>
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org

Harald,

Ok, there's some text in Section 7.5 that's already headed in
that direction, so we'll see about writing a "MUST implement"
requirement for the Counter64 items based on interface speed.

Thanks,
--David 
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: gen-art-bounces@ietf.org 
> [mailto:gen-art-bounces@ietf.org] On Behalf Of Harald Tveit Alvestrand
> Sent: Tuesday, January 17, 2006 11:17 AM
> To: Black, David; gen-art@ietf.org
> Cc: mbakke@cisco.com; marjorie_krueger@hp.com; 
> mankin@psg.com; yaronled@bezeqint.net; ips@ietf.org; 
> michele@sanrad.com; kzm@cisco.com
> Subject: [Gen-art] RE: Gen-ART review of draft-ietf-ips-scsi-mib-08
> 
> Thanks for the quick feedback, David!
> 
> I'm happy to leave this in your hands - one comment only:
> 
> --On tirsdag, januar 17, 2006 11:02:36 -0500 
> Black_David@emc.com wrote:
> 
> >> The term "running at high speed" is a gating criterion for whether or
> >> not  the HS counters are mandatory, but I can't see that it's defined
in
> >> a  testable way. Might have missed it - it would logically seem to
> >> belong in  section 7.5.
> >
> > Unfortunately, it's fuzzy and not testable in all cases.  Here's what
> > RFC 4181 (Section 4.6.1.2) has to say about this issue:
> >
> >    Henceforth "standard" MIB modules MAY
> >    use the Counter64 type when it makes sense to do so, and MUST use
> >    Counter64 if the information being modelled would wrap in less than
> >    one hour if the Counter32 type was used instead.
> >
> > It clearly "makes sense" to use the Counter64 type, as there are SCSI
> > implementations that clearly need it based on the "would wrap in less
> > than one hour" criterion.  Would adapting the quoted RFC 4181 text
> > (with a reference to RFC 4181) be sufficient to satisfy your concern?
> 
> What I'd like to see is something that makes it a complete no-brainer 
> whether or not the HC counters are needed, for instance:
> 
>   If the interconnect speed is higher than 4 Gbits/second, the HC counters
>   MUST be implemented, since that makes it possible to spin the counters
>   in one hour (see [RFC4181]).
> 
> I wouldn't like someone to say "but... my implementation has a 10G 
> interface, but it's so badly implemented that I can't possibly get more 
> than 1 million operations per second through it, so I don't need to 
> implement the HC counters, do I?"
> 
> (4G is picked out of thin air, but illustrates the problem... if The
Number 
> is 3G, then 4G FC needs to implement it; if The Number is 9G, then only 
> people with 10GE and Infiniband interfaces need bother...)
> 
> But you know this stuff, I don't....
> 
>                      Harald
> 
> 
> 
> 
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www1.ietf.org/mailman/listinfo/gen-art
> 

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips



From ips-bounces@ietf.org Wed Jan 18 11:13:30 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzFwA-0007kx-Cx; Wed, 18 Jan 2006 11:13:30 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EysMk-0007EM-2Y; Tue, 17 Jan 2006 10:03:22 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21889;
	Tue, 17 Jan 2006 10:01:56 -0500 (EST)
Received: from eikenes.alvestrand.no ([158.38.152.233])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EysUs-0003cr-3M; Tue, 17 Jan 2006 10:11:47 -0500
Received: from localhost (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id D02522596CD;
	Tue, 17 Jan 2006 16:02:06 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1])
	by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 23729-08; Tue, 17 Jan 2006 16:02:01 +0100 (CET)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no
	[127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 35BBE2596C7;
	Tue, 17 Jan 2006 16:01:59 +0100 (CET)
Date: Tue, 17 Jan 2006 16:02:41 +0100
From: Harald Tveit Alvestrand <harald@alvestrand.no>
To: gen-art@ietf.org
Message-ID: <869996B830DFB7EE29B738B5@B50854F0A9192E8EC6CDA126>
X-Mailer: Mulberry/4.0.3 (Win32)
MIME-Version: 1.0
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
X-Mailman-Approved-At: Wed, 18 Jan 2006 11:13:28 -0500
Cc: mbakke@cisco.com, marjorie_krueger@hp.com, mankin@psg.com,
	yaronled@bezeqint.net, ips@ietf.org, michele@sanrad.com,
	black_david@emc.com, kzm@cisco.com
Subject: [Ips] Gen-ART review of draft-ietf-ips-scsi-mib-08
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0787059097=="
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org

--===============0787059097==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="==========BFCB5F40EE1F452DBAC1=========="

--==========BFCB5F40EE1F452DBAC1==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

This is a Gen-ART review.
For Gen-ART info, see this=20
URL:<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>

Document: draft-ietf-ips-scsi-mib-08.txt
Reviewer: Harald Alvestrand
Date: Jan 17, 2006
Summary: Excellent document, two important comments.

I enjoyed reading this document! - the intro to SCSI and its history was=20
fun to read!
----------------------------------------------------------
Two important questions, that may warrant a respin of the document if I'm=20
right that there's a problem here:

[SAM-2] and [SPC2] are normative references (defines format for ScsiLUN and =

other things), but are listed as Working Drafts in the REFERENCE clauses of =

multiple MIB objects. (In the references section, the draftness seems=20
implied by the URL only)
Is this stable enough for an IETF standard reference?
Or are the references in the MIB wrong?

The term "running at high speed" is a gating criterion for whether or not=20
the HS counters are mandatory, but I can't see that it's defined in a=20
testable way. Might have missed it - it would logically seem to belong in=20
section 7.5.
-------------------------------------------------------------
Questions, that I'd like to have answered in email, but don't warrant a=20
respin in my opinion:

The scsiDscTgtTable and scsiAuthorizedIntr table seem to form "access=20
lists". They seem to be read-write via SNMP. Should this be explicitly=20
mentioned in the intro in section 5?
The security considerations for these objects are very good, and make it=20
very clear that they're writable!

SAS (Serial Attached SCSI) is not mentioned at all. Is it irrelevant, or=20
"just another transport"? Or is this what's called "scsiTransportSBP"?
-------------------------------------------------------------
Nits, which IMHO you can fix or not as you feel like:

Some byzantine sentences...

7.3 "another logical unit changes its status to from available" is missing=20
something

7.4 "at 10GBit/second with 512 read/write operations" seems to be missing a =

byte :-)

RFC 2119 is listed as an informative reference. I think it needs to be=20
normative.

--==========BFCB5F40EE1F452DBAC1==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)

iD8DBQFDzQcROMj+2+WY0F4RAhkDAJ9wmZnt/ag/r6jvn/+PHqYVsBBVaACcDfiT
93kehJRN22/qAAqiy3QXnRU=
=oqn6
-----END PGP SIGNATURE-----

--==========BFCB5F40EE1F452DBAC1==========--



--===============0787059097==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--===============0787059097==--





From ips-bounces@ietf.org Wed Jan 18 11:13:30 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzFwA-0007lM-Rd; Wed, 18 Jan 2006 11:13:30 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EytWL-0003ke-4R; Tue, 17 Jan 2006 11:17:21 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27745;
	Tue, 17 Jan 2006 11:15:56 -0500 (EST)
Received: from eikenes.alvestrand.no ([158.38.152.233])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EyteU-00064s-PG; Tue, 17 Jan 2006 11:25:47 -0500
Received: from localhost (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 7B5082596E0;
	Tue, 17 Jan 2006 17:16:05 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1])
	by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 25614-07; Tue, 17 Jan 2006 17:15:59 +0100 (CET)
Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 5AB3A2596DF;
	Tue, 17 Jan 2006 17:15:59 +0100 (CET)
Date: Tue, 17 Jan 2006 17:17:03 +0100
From: Harald Tveit Alvestrand <harald@alvestrand.no>
To: Black_David@emc.com, gen-art@ietf.org
Message-ID: <D7F64900FC87FC28C1F68B20@svartdal.hjemme.alvestrand.no>
In-Reply-To: <F222151D3323874393F83102D614E055013E906C@CORPUSMX20A.corp.emc.com>
References: <F222151D3323874393F83102D614E055013E906C@CORPUSMX20A.corp.emc.c
	om>
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Wed, 18 Jan 2006 11:13:28 -0500
Cc: mbakke@cisco.com, marjorie_krueger@hp.com, mankin@psg.com,
	yaronled@bezeqint.net, ips@ietf.org, michele@sanrad.com, kzm@cisco.com
Subject: [Ips] RE: Gen-ART review of draft-ietf-ips-scsi-mib-08
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=subscribe>
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org

Thanks for the quick feedback, David!

I'm happy to leave this in your hands - one comment only:

--On tirsdag, januar 17, 2006 11:02:36 -0500 Black_David@emc.com wrote:

>> The term "running at high speed" is a gating criterion for whether or
>> not  the HS counters are mandatory, but I can't see that it's defined in
>> a  testable way. Might have missed it - it would logically seem to
>> belong in  section 7.5.
>
> Unfortunately, it's fuzzy and not testable in all cases.  Here's what
> RFC 4181 (Section 4.6.1.2) has to say about this issue:
>
>    Henceforth "standard" MIB modules MAY
>    use the Counter64 type when it makes sense to do so, and MUST use
>    Counter64 if the information being modelled would wrap in less than
>    one hour if the Counter32 type was used instead.
>
> It clearly "makes sense" to use the Counter64 type, as there are SCSI
> implementations that clearly need it based on the "would wrap in less
> than one hour" criterion.  Would adapting the quoted RFC 4181 text
> (with a reference to RFC 4181) be sufficient to satisfy your concern?

What I'd like to see is something that makes it a complete no-brainer 
whether or not the HC counters are needed, for instance:

  If the interconnect speed is higher than 4 Gbits/second, the HC counters
  MUST be implemented, since that makes it possible to spin the counters
  in one hour (see [RFC4181]).

I wouldn't like someone to say "but... my implementation has a 10G 
interface, but it's so badly implemented that I can't possibly get more 
than 1 million operations per second through it, so I don't need to 
implement the HC counters, do I?"

(4G is picked out of thin air, but illustrates the problem... if The Number 
is 3G, then 4G FC needs to implement it; if The Number is 9G, then only 
people with 10GE and Infiniband interfaces need bother...)

But you know this stuff, I don't....

                     Harald




_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips



From ips-bounces@ietf.org Thu Jan 19 17:00:56 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ezhpw-00020n-O3; Thu, 19 Jan 2006 17:00:56 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezhpv-00020i-33
	for ips@megatron.ietf.org; Thu, 19 Jan 2006 17:00:55 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01054
	for <ips@ietf.org>; Thu, 19 Jan 2006 16:59:27 -0500 (EST)
Received: from mx2.netapp.com ([216.240.18.37])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzhyU-0007GV-NQ
	for ips@ietf.org; Thu, 19 Jan 2006 17:09:49 -0500
Received: from smtp2.corp.netapp.com ([10.57.159.114])
	by mx2.netapp.com with ESMTP; 19 Jan 2006 14:00:43 -0800
X-IronPort-AV: i="4.01,201,1136188800"; 
	d="txt'?scan'208"; a="345965854:sNHT22155092"
Received: from [10.61.17.57] ([10.61.17.57])
	by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id
	k0JM0g0e013467
	for <ips@ietf.org>; Thu, 19 Jan 2006 14:00:42 -0800 (PST)
Message-ID: <43D009A0.9070201@netapp.com>
Date: Thu, 19 Jan 2006 16:50:24 -0500
From: David Wysochanski <davidw@netapp.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ips@ietf.org
Content-Type: multipart/mixed; boundary="------------010002050604000606090509"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87
Subject: [Ips] Solciting feedback on submission of iSCSI public extension
 key, X#NodeArchitecture, for March '06 IETF meeting
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=subscribe>
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org

This is a multi-part message in MIME format.
--------------010002050604000606090509
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Last year I submitted an earlier revision of this proposal
for an iSCSI public extension key to enhance supportability.
Attached is the latest revision and I would solicit candid
feedback from the iSCSI authors and the group.  In particular,
do you have any major concerns about this proposal?  Do you
view this as a useful addition to the iSCSI protocol, and
a viable work item the group might sponsor?

I believe the main usefulness of the proposal is seen when
considering iSCSI in support situations (though there may be
other valid uses).  The idea behind the support efficiency is
that one may avoid at least some of the "Which version of X is
running on the other side?" back and forth iterations.  Avoiding
even one of these iterations is not insignificant, because each
iteration may take hours or even days.  In this way, this
small extension to the iSCSI protocol has the potential to
make iSCSI more supportable, and thus, more sellable.

There are of course downsides to the proposal, and new
potential problems.  I believe I have thought through and
tried to address at least some of the major ones, and we
can discuss if/when concerns arise.

Provided there are no major concerns or objections, I
would like to submit an IPS WG Internet Draft based on
this proposal in time for the March '06 IETF meeting,
and drive this towards Informational RFC status in '06.

Thanks for your consideration.

--------------010002050604000606090509
Content-Type: text/plain;
	name="X-keys-for-enhanced-iscsi-supportability-ietf-v0.6.txt"
Content-Disposition: inline;
	filename="X-keys-for-enhanced-iscsi-supportability-ietf-v0.6.txt"
Content-Transfer-Encoding: 7bit

      Declarative Public Extension Key to Enhance iSCSI Supportability

This proposal identifies a declarative Public Extension Key as defined by
section 12.22 of RFC 3720 that may be used to communicate additional iSCSI
node information to the opposite node in a session.  The information carried
in the proposed key has been found to be valuable in real iSCSI customer 
environments as initiator and target vendors collaborate to resolve technical
issues and better understand the evolving iSCSI market.

The key has been modelled after the "Server" and "User-Agent" header fields as
specified in sections 14.38 and 14.43 of RFC 2616 [1], with the text-values
of the key roughly equivalent to Product Tokens in section 3.8 of RFC 2616.

The following proposed Public Extension Key is sent during the login phase
of an iSCSI normal session.  It is important to note that the intent of
providing this key is for better understanding of customer environments.
The key MUST NOT be used by iSCSI nodes for things such as interoperability,
performance, exclusion or deception of other nodes, or other uses not defined
by this proposal.  To enforce proper use, iSCSI nodes MUST NOT allow user
modification of the key value(s), but MUST set the value automatically based
on standard internal interfaces.

In certain environments where security is a primary concern, the use of this
key MAY NOT be appropriate as it reveals specific details about an iSCSI node.
For these environments, nodes implementing this public extension key SHOULD
provide a method to disable sending the key.

The definition of the proposed key is as follows, with example text-values
conforming to section 5.1 of RFC 3720.

X#NodeArchitecture

   Use: IO, Declarative, Any-Stage
   Senders: Initiator and Target
   Scope: SW

   X#NodeArchitecture=<list-of-values>

   Examples:

      X#NodeArchitecture="os/1.2.3.4,iscsi-vendor-software/1.2.3.4"
      X#NodeArchitecture="os/1.2.3.4,cpu-type-x,cpu-speed/2.0ghz,
                          iscsi-vendor-hardware/1.2.3.4,
                          iscsi-vendor-firmware/1.2.3.4"

   The initiator or target declares the details of its iSCSI node architecture
   to the remote endpoint.  These details may include, but are not limited to,
   the OS version, CPU or hardware architecture, iSCSI vendor software and/or 
   firmware version, iSCSI vendor hardware revision, and so on.

   NodeArchitecture MUST NOT be redeclared.



[1] Hypertext Transfer Protocol -- HTTP/1.1;
http://www.faqs.org/rfcs/rfc2616.html
--------------010002050604000606090509
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--------------010002050604000606090509--




From ips-bounces@ietf.org Thu Jan 19 17:41:35 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EziTH-0001X9-Rx; Thu, 19 Jan 2006 17:41:35 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EziTG-0001Ww-DU
	for ips@megatron.ietf.org; Thu, 19 Jan 2006 17:41:34 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04538
	for <ips@ietf.org>; Thu, 19 Jan 2006 17:40:06 -0500 (EST)
Received: from sadr.equallogic.com ([66.155.203.134])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezibp-0000G8-Ld
	for ips@ietf.org; Thu, 19 Jan 2006 17:50:28 -0500
Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1])
	by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id k0JMfFpC020754
	for <ips@ietf.org>; Thu, 19 Jan 2006 17:41:15 -0500
Received: from M31.equallogic.com (M31.equallogic.com [172.16.1.31])
	by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id k0JMfFih020749;
	Thu, 19 Jan 2006 17:41:15 -0500
Received: from pkoning.equallogic.com ([172.16.1.169]) by M31.equallogic.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 19 Jan 2006 17:41:15 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17360.5513.785317.434043@gargle.gargle.HOWL>
Date: Thu, 19 Jan 2006 17:41:13 -0500
From: Paul Koning <pkoning@equallogic.com>
To: davidw@netapp.com
Subject: Re: [Ips] Solciting feedback on submission of iSCSI public extension
	key, X#NodeArchitecture, for March '06 IETF meeting
References: <43D009A0.9070201@netapp.com>
X-Mailer: VM 7.17 under 21.5  (beta23) "daikon" XEmacs Lucid
X-OriginalArrivalTime: 19 Jan 2006 22:41:15.0521 (UTC)
	FILETIME=[74C03710:01C61D49]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Content-Transfer-Encoding: 7bit
Cc: ips@ietf.org
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=subscribe>
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org

Would this be a per session or a per connection value?  It isnt' all
that clear what component(s) of the system are being identified, but
depending on the answer, the values might not be the same for all
connections. 

If the system uses HBAs, would this key describe the HBA, or the host?
(Or both?)

Nit: "MAY NOT" should be "may not".

     paul


_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips



From ips-bounces@ietf.org Thu Jan 19 22:51:07 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EznIp-0007K5-7N; Thu, 19 Jan 2006 22:51:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EznIn-0007Jw-GO
	for ips@megatron.ietf.org; Thu, 19 Jan 2006 22:51:05 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00630
	for <ips@ietf.org>; Thu, 19 Jan 2006 22:49:38 -0500 (EST)
Received: from mx2.netapp.com ([216.240.18.37])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EznRR-0002Xz-Hd
	for ips@ietf.org; Thu, 19 Jan 2006 23:00:03 -0500
Received: from smtp2.corp.netapp.com ([10.57.159.114])
	by mx2.netapp.com with ESMTP; 19 Jan 2006 19:50:54 -0800
X-IronPort-AV: i="4.01,203,1136188800"; 
	d="scan'208,217"; a="346032871:sNHT24053360"
Received: from [10.30.24.96] ([10.30.24.96])
	by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id
	k0K3oh3n014099; Thu, 19 Jan 2006 19:50:53 -0800 (PST)
Message-ID: <43D05E13.8050800@netapp.com>
Date: Thu, 19 Jan 2006 22:50:43 -0500
From: Dave Wysochanski <davidw@netapp.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Koning <pkoning@equallogic.com>
Subject: Re: [Ips] Solciting feedback on submission of iSCSI public extension
	key, X#NodeArchitecture, for March '06 IETF meeting
References: <43D009A0.9070201@netapp.com>
	<17360.5513.785317.434043@gargle.gargle.HOWL>
In-Reply-To: <17360.5513.785317.434043@gargle.gargle.HOWL>
X-Spam-Score: 1.4 (+)
X-Scan-Signature: f66b12316365a3fe519e75911daf28a8
Cc: ips@ietf.org
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1636527990=="
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org

This is a multi-part message in MIME format.
--===============1636527990==
Content-Type: multipart/alternative;
	boundary="------------060203090504090901060506"

This is a multi-part message in MIME format.
--------------060203090504090901060506
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Paul Koning wrote:

> Would this be a per session or a per connection value?  It isnt' all
> that clear what component(s) of the system are being identified, but
> depending on the answer, the values might not be the same for all
> connections.
>
Per session.

> If the system uses HBAs, would this key describe the HBA, or the host?
> (Or both?)
>
Possibly both since the intent is to assist support.  This
is of course subject to implementation and what information
is deemed most important.  Gut feel is that at the very least,
the key values should contain information that uniquely identifies
a node's iSCSI implementation (driver version, firmware version,
etc).

> Nit: "MAY NOT" should be "may not".
>
>      paul
>
Ok thanks.

--------------060203090504090901060506
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Paul Koning wrote:<br>
<blockquote cite="mid17360.5513.785317.434043@gargle.gargle.HOWL"
 type="cite">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta name="Generator" content="MS Exchange Server version 6.0.6603.0">
  <title>Re: [Ips] Solciting feedback on submission of iSCSI public
extension key, X#NodeArchitecture, for March '06 IETF meeting</title>
<!-- Converted from text/plain format -->
  <p><font size="2">Would this be a per session or a per connection
value?&nbsp; It isnt' all</font>
  <br>
  <font size="2">that clear what component(s) of the system are being
identified, but</font>
  <br>
  <font size="2">depending on the answer, the values might not be the
same for all</font>
  <br>
  <font size="2">connections. </font>
  </p>
</blockquote>
Per session.<br>
<br>
<blockquote cite="mid17360.5513.785317.434043@gargle.gargle.HOWL"
 type="cite">
  <p><font size="2">If the system uses HBAs, would this key describe
the HBA, or the host?</font>
  <br>
  <font size="2">(Or both?)</font>
  </p>
</blockquote>
Possibly both since the intent is to assist support.&nbsp; This<br>
is of course subject to implementation and what information<br>
is deemed most important.&nbsp; Gut feel is that at the very least,<br>
the key values should contain information that uniquely identifies<br>
a node's iSCSI implementation (driver version, firmware version,<br>
etc).<br>
<br>
<blockquote cite="mid17360.5513.785317.434043@gargle.gargle.HOWL"
 type="cite">
  <p><font size="2">Nit: "MAY NOT" should be "may not".</font>
  </p>
  <p><font size="2">&nbsp;&nbsp;&nbsp;&nbsp; paul</font>
  </p>
</blockquote>
Ok thanks.<br>
</body>
</html>

--------------060203090504090901060506--


--===============1636527990==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--===============1636527990==--




From ips-bounces@ietf.org Fri Jan 20 11:09:25 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzypI-0002sp-VU; Fri, 20 Jan 2006 11:09:24 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EzypH-0002sf-BB
	for ips@megatron.ietf.org; Fri, 20 Jan 2006 11:09:23 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25939
	for <ips@ietf.org>; Fri, 20 Jan 2006 11:07:55 -0500 (EST)
Received: from mx2.netapp.com ([216.240.18.37])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezyy1-0001Nl-Pg
	for ips@ietf.org; Fri, 20 Jan 2006 11:18:27 -0500
Received: from smtp2.corp.netapp.com ([10.57.159.114])
	by mx2.netapp.com with ESMTP; 20 Jan 2006 08:09:02 -0800
X-IronPort-AV: i="4.01,206,1136188800"; 
	d="scan'208"; a="346177017:sNHT17329800"
Received: from [10.61.17.57] ([10.61.17.57])
	by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id
	k0KG90bx012673; Fri, 20 Jan 2006 08:09:01 -0800 (PST)
Message-ID: <43D108AC.2020405@netapp.com>
Date: Fri, 20 Jan 2006 10:58:36 -0500
From: David Wysochanski <davidw@netapp.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Wysochanski, David" <David.Wysochanski@netapp.com>,
	Paul Koning <pkoning@equallogic.com>
Subject: Re: [Ips] Proposed Declarative Public Extension Key
	-X#NodeArchitecture
References: <42320691.7090703@netapp.com><16947.4176.564000.560597@gargle.gargle.HOWL>
	<423339CE.7010708@netapp.com>
In-Reply-To: <423339CE.7010708@netapp.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Content-Transfer-Encoding: 7bit
Cc: ips@ietf.org
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=subscribe>
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org

> 
>  > Should it be legal prior to the conclusion of the security negotiation
>  > stage?  I think yes, because it is defined to have no effect on any
>  > actions or negotiations.  It is helpful to identify what is at the
>  > other end, and that information is potentially useful when
>  > troubleshooting security negotiation failures.
>  >
> I definately agree.  I originally had a more broad Use,
> but then pared it down (too much it seems). This would
> make the use statement: IO, Declarative, Any-Stage.
> 

This is actually an incorrect statement.  Section 11 of
RFC 3720 gives an explicit list of keys that can be used in
security negotiation, and states other keys MUST NOT be
used.  So I will go back to what I originally had and
drop the Any-Stage from the Use statement.

Thanks.

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips



From ips-bounces@ietf.org Fri Jan 20 12:11:24 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EzznI-0007Nk-3M; Fri, 20 Jan 2006 12:11:24 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EzznG-0007NM-Va
	for ips@megatron.ietf.org; Fri, 20 Jan 2006 12:11:22 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01255
	for <ips@ietf.org>; Fri, 20 Jan 2006 12:09:52 -0500 (EST)
From: Black_David@emc.com
Received: from mexforward.lss.emc.com ([168.159.213.200])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezzvw-0003aM-Kz
	for ips@ietf.org; Fri, 20 Jan 2006 12:20:22 -0500
Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14])
	by mexforward.lss.emc.com (Switch-3.1.0/Switch-3.1.7) with ESMTP id
	k0KHB3D4022722
	for <ips@ietf.org>; Fri, 20 Jan 2006 12:11:03 -0500 (EST)
Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9])
	by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id
	k0KHAre3006496
	for <ips@ietf.org>; Fri, 20 Jan 2006 12:11:01 -0500 (EST)
Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19)
	id <ZJ2GJNFT>; Fri, 20 Jan 2006 12:10:48 -0500
Message-ID: <F222151D3323874393F83102D614E055013E90A2@CORPUSMX20A.corp.emc.com>
To: ips@ietf.org
Date: Fri, 20 Jan 2006 12:10:40 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0,
	Antispam-Data: 2006.01.20.085106
X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, EMC_FROM_00+ -3,
	EMC_FROM_0+ -0, NO_REAL_NAME 0, __C230066_P5 0, __CT 0,
	__CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0,
	__IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0,
	__SANE_MSGID 0, __STOCK_CRUFT 0'
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Subject: [Ips] SCSI MIB update
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=subscribe>
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org

There is one more version of the SCSI MIB coming (-09).

In addition to the revised security considerations text
that was previously posted to the list, and a bunch of
editorial changes (mostly reference cleanup), there are
two additional technical changes that will be made:

- A MIB object will be added to represent SAS as a
	SCSI transport.  This was an oversight that the
	GenART reviewer caught.
- Implementation of the 64-bit counter objects for SCSI
	commands will be mandatory for speeds of 4
	Gigabits/sec and above because it is theoretically
	possible to roll over a 32 bit counter in about
	an hour at 5 Gigabits/sec with back-to-back 512
	byte operations.

If there are any concerns about these items, please
post them ASAP.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------


_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips



From ips-bounces@ietf.org Fri Jan 20 13:12:33 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F00kT-0004Pn-CW; Fri, 20 Jan 2006 13:12:33 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F00kR-0004Pf-Fo
	for ips@megatron.ietf.org; Fri, 20 Jan 2006 13:12:31 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06952
	for <ips@ietf.org>; Fri, 20 Jan 2006 13:11:03 -0500 (EST)
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F00tD-0005vK-6l
	for ips@ietf.org; Fri, 20 Jan 2006 13:21:36 -0500
Received: from sj-core-3.cisco.com ([171.68.223.137])
	by sj-iport-5.cisco.com with ESMTP; 20 Jan 2006 10:12:21 -0800
X-IronPort-AV: i="4.01,206,1136188800"; 
	d="scan'208"; a="250354808:sNHT31627328"
Received: from cisco.com (cypher.cisco.com [171.69.11.142])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k0KICKc1001643;
	Fri, 20 Jan 2006 10:12:20 -0800 (PST)
Received: (from kzm@localhost)
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA25631;
	Fri, 20 Jan 2006 10:12:20 -0800 (PST)
From: Keith McCloghrie <kzm@cisco.com>
Message-Id: <200601201812.KAA25631@cisco.com>
Subject: Re: [Ips] SCSI MIB update
To: Black_David@emc.com
Date: Fri, 20 Jan 2006 10:12:20 -0800 (PST)
In-Reply-To: <no.id> from "Black_David@emc.com" at Jan 20, 2006 12:10:40 PM
X-Mailer: ELM [version 2.5 PL5]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Content-Transfer-Encoding: 7bit
Cc: ips@ietf.org
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=subscribe>
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org

> There is one more version of the SCSI MIB coming (-09).
> 
> In addition to the revised security considerations text
> that was previously posted to the list, and a bunch of
> editorial changes (mostly reference cleanup), there are
> two additional technical changes that will be made:
> 
> - A MIB object will be added to represent SAS as a
> 	SCSI transport.  This was an oversight that the
> 	GenART reviewer caught.

At the risk of being overly pedantic, the addition (as I understand it)
will be an OBJECT-IDENTITY, which is the assignment of a new OID for
use as the *value* of a MIB object such as the existing scsiTransportType.

Keith.


> - Implementation of the 64-bit counter objects for SCSI
> 	commands will be mandatory for speeds of 4
> 	Gigabits/sec and above because it is theoretically
> 	possible to roll over a 32 bit counter in about
> 	an hour at 5 Gigabits/sec with back-to-back 512
> 	byte operations.
> 
> If there are any concerns about these items, please
> post them ASAP.
> 
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> black_david@emc.com        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
> 
> 
> _______________________________________________
> Ips mailing list
> Ips@ietf.org
> https://www1.ietf.org/mailman/listinfo/ips
> 

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips



From ips-bounces@ietf.org Mon Jan 23 21:54:12 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F1EJw-0001gj-3M; Mon, 23 Jan 2006 21:54:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F1EJu-0001gc-Qi
	for ips@megatron.ietf.org; Mon, 23 Jan 2006 21:54:10 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28001
	for <ips@ietf.org>; Mon, 23 Jan 2006 21:52:37 -0500 (EST)
Received: from mononoke.wasabisystems.com ([66.173.145.228])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1ETL-00055Q-AG
	for ips@ietf.org; Mon, 23 Jan 2006 22:03:56 -0500
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by mononoke.wasabisystems.com (Postfix) with ESMTP
	id B8EB5870A3; Mon, 23 Jan 2006 21:53:53 -0500 (EST)
In-Reply-To: <F222151D3323874393F83102D614E055013E904A@CORPUSMX20A.corp.emc.com>
References: <F222151D3323874393F83102D614E055013E904A@CORPUSMX20A.corp.emc.com>
Mime-Version: 1.0 (Apple Message framework v623)
Message-Id: <49c5d0a77e844abb892d64e7fa5be98f@wasabisystems.com>
From: William Studenmund <wrstuden@wasabisystems.com>
Subject: Re: [Ips] iSCSI ACA - Implementers Guide (long, sorry)
Date: Mon, 23 Jan 2006 21:53:45 -0500
To: Black_David@emc.com
X-Pgp-Agent: GPGMail 1.0 (v30, 10.3)
X-Mailer: Apple Mail (2.623)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fe105289edd72640d9f392da880eefa2
Cc: ips@ietf.org
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0173656825=="
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org


--===============0173656825==
Content-Type: multipart/signed; protocol="application/pgp-signature";
	micalg=pgp-sha1; boundary="Apple-Mail-4-850235579"
Content-Transfer-Encoding: 7bit


--Apple-Mail-4-850235579
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit

On Jan 14, 2006, at 4:38 PM, Black_David@emc.com wrote:

> An Implementer working on ACA (Auto-Contingent Allegiance)
> has pointed out some issues that could use some attention
> in the implementers guide.  The SCSI reference for this is
> Section 5.9.1 of SAM-2.  NOTE: This message is not written
> in my role as WG Chair.

Ugh.

> A quick introduction is that ACA is an alternative behavior
> for error handling (CHECK CONDITION) to the more familiar
> behavior of CA (Contingent Allegiance) that is immediately
> exited via Autosense.  ACA is requested on a per command
> basis via the NACA bit in the CDB.  The Autosense transmission
> of sense data still occurs as a result of CHECK CONDITION
> (Autosense is required by iSCSI), but unlike CA, the ACA
> condition persists until it is cleared by a CLEAR ACA task
> management function.  During ACA, the initiator uses commands
> with the ACA attribute (cf Section 10.3 of RFC 3720) to
> deal with the situation.  One ACA command at a time is
> permitted, and non ACA commands are rejected with an "ACA
> ACTIVE" status.
>
> The change in command processing behavior when entering ACA
> raises a number of concurrency issues, as SAM-2 is specified
> as if the initiator and target interact synchronously, which
> is not the case for iSCSI.  SAM-2 contains the following
> somewhat cryptic text in Section 5.9.1.2 whose consequences
> the implementers guide could help explain:
>
> 	If the SCSI transport protocol does not enforce state
> 	synchronization as described in 4.6.2, there may be a
> 	time delay between the occurrence of the CA or ACA
> 	condition and the time at which the application client
> 	becomes aware of the condition.

Well, the first question that comes to my mind in these cases is what 
does Fibre Channel do in these cases on a large SAN? Or what is FC 
doing on SANs that are bridged over IP? :-)

We shouldn't beat ourselves up to do stuff the FC doesn't. :-)

> iSCSI does not enforce state synchronization.  Further, in a
> multi-connection session, iSCSI does not support status
> sequencing (order of delivery of status/responses) across
> connections.  So, for a multi-connection, session, there are
> (at least) 4 interesting potential concurrency conditions:
>
> (1) The SCSI response indicating that CHECK CONDITION has
> 	caused establishment of ACA could get ahead of a response
> 	to a command completed prior to establishment of ACA.
>
> (2) An ACA ACTIVE status response could get ahead of the SCSI
> 	response that indicates establishment of ACA.
>
> (3) A command issued prior to establishment of ACA could
> 	arrive after ACA is established.
>
> (4) The CLEAR ACA task management function could get ahead of
> 	a command that is dealing with the ACA condition.
>
> Here are some initial thoughts on how to deal with these
> situations:
>
> -- (1) The SCSI response indicating that CHECK CONDITION has
> 	caused establishment of ACA could get ahead of a response
> 	to a command completed prior to establishment of ACA.
>
> This is only a concern in multi-connection sessions, as in a
> single-connection session, the response indicating ACA
> establishment will come after responses to all prior commands.
> This behavior can be preserved for multi-connection sessions
> by saying that the target MUST wait for acknowledgement of all
> responses outstanding on other connections at the time of ACA
> establishment before sending the response that indicates ACA
> has been established.  This "MUST" would be an additional
> requirement to RFC 3720 for multi-connection targets.
>
> This seems like a useful thing to require, as one of the first
> things an initiator will probably want to do on learning
> that ACA has happened is figure out what commands completed
> successfully prior to ACA (vs. are still at the target, and
> hence have been blocked by the ACA), and only the target knows
> what statuses are outstanding against the other connections.

I was going to suggest a bit of a tangent here by suggesting we pull in 
a post-SAM-2 feature and add support for the Query Task Task Management 
Function. However I think that that function only indicates if a task 
is in the task set or not. Hmmm... Maybe that is enough.

> OTOH, it causes delays, so the alternative is to leave the
> initiator to sort this out, which may entail issuing NOPs
> to determine command status on other connections.  That
> would have the advantage of limiting the impact of ACA
> support to multi-connection initiators that actually want
> to use ACA, but the need to use the NOPs is unpleasant,
> leading me to favor having the target get this right
> (initiators who don't like the resulting delay in entering
> ACA shouldn't use it).
>
> I don't think ignoring the issue causes any SCSI specification
> violations, but it may make ACA error handling behave badly
> as command completions will be unexpectedly received during ACA.

I really have all of these delays we are building into the target. If 
we are in a MC/S situation, shouldn't we expect the initiator to carry 
some of the load?

Put another way, if the initiator can't handle ACA cleanup, maybe it 
shouldn't issue commands with NACA set. :-)

I think it'd be fine for the ACA-status go through immediately as it 
would tell the initiator that we have entered an error condition and it 
should, for instance, immediately stop issuing commands to the target. 
:-) It should also take steps to see what the outstanding status events 
are on other connections.

The problem is that there is no way to indicate target status across 
the whole session; status is a per-connection thing (which is usually 
great!).

The only other thing I can think of is to add a new async event 
indicating we entered ACA and that all status messages with StatSN less 
than this one were completed before the event.

> -- (2) An ACA ACTIVE status response could get ahead of the SCSI
> 	response that indicates establishment of ACA.
>
> Again, this is only a concern in multi-connection sessions, as
> in a single-connection session, ACA ACTIVE responses will come
> after the response indicating that ACA has been entered.  The
> approach to this should probably match (1) - if the target is
> required to wait for outstanding responses on other connections
> in (1), we should require that the target MUST receive
> acknowledgement of the response indicating establishment of ACA
> before issuing any ACA ACTIVE status responses on any connection
> other than the one that response used.  This "MUST" would be an
> additional requirement to RFC 3720 for multi-connection targets.

Is this issue really a special worry?

As I understand SAM-2, this can always happen. In table 25, if QErr is 
00b and TST is 000b, some OTHER initiator triggering ACA can put our 
port into ACA ("all enabled tasks from all SCSI initiator ports"). So 
there may not even be a status event with the CHECK CONDITION on any of 
our connections. Thus we can suddenly find ourselves in ACA. :-|

> The resulting delay in issuing ACA ACTIVE responses seems to be
> less of a concern, as the initiator can figure out what's
> going to happen:
> - Based on (1), the initiator has responses to the completed
> 	commands,
> - Uncompleted commands prior to ExpCmdSN in the response that
> 	established ACA were delivered to SCSI and have been
> 	blocked by the ACA.
> - All other commands will receive ACA ACTIVE status responses,
> 	as they were not delivered to SCSI when the ACA occurred.
>
> If we don't require the wait in (1), initiator use of NOP on
> other connections will flush out delayed ACA ACTIVE responses,
> but still leave a multi-connection initiator who wants to use
> ACA with the surprise that ACA ACTIVE responses can show up
> before the response indicating that an ACA has occurred.  This
> will result in a requirement on initiators to hold ACA ACTIVE
> status responses until the SCSI response indicating that ACA
> has occurred is delivered.  This is an additional requirement
> to RFC 3720, and may require initiators to track NACA on all
> outstanding commands to determine whether an Autosense response
> caused ACA or not.  This is probably better left to SCSI.
>
> IMHO, something needs to be done here, as delivery of an ACA
> ACTIVE response to SCSI before the response indicating ACA
> establishment is pretty clearly wrong from a SCSI perspective.
>
> Between (1) and (2) it's probably a good idea to advise
> initiator implementers that the synchronous nature of ACA
> makes it a poor fit with the concurrency of multi-connection
> iSCSI sessions.

Indeed. Consider the further wrinkle of a slow initiator (or slow 
connections) in a QErr 00b/TST 000b scenario. Another initiator could 
have cleared ACA and RETRIGGERED ACA before the one initiator could 
have cleared it. :-)

> -- (3) A command issued prior to establishment of ACA could
> 	arrive after ACA is established.
>
> For a command without the ACA attribute, this is not an issue -
> such a command will be rejected with ACA ACTIVE status if ACA
> is in effect when it is due to be delivered to SCSI at the
> target.
>
> For a command with the ACA attribute, the situation is less
> clear, courtesy of the text quoted from SAM-2 above.  I talked
> with at least one other SCSI expert at T10 last week, and the
> two of us concur that this initiator behavior (initiator issues
> a command with the ACA attribute without knowing that ACA is
> in effect at the target) is questionable at best and probably
> wrong (and hence if the target unexpectedly executes the
> command because an ACA occurred, the initiator got what it
> deserved).

I agree it's wrong and the initiator deserves to get its command 
killed. :-)

> Hence I suggest guidance (for both single and multi-connection
> sessions) that an initiator SHOULD NOT issue commands with the
> ACA attribute unless it knows that ACA is in effect at a target,
> because targets will process all commands with the ACA attribute
> if they are received while ACA is in effect, irrespective of
> whether an initiator may have issued such a command prior to
> ACA being established.  I believe this target behavior is
> permitted by the text quoted from SAM-2 above.  This is a
> general SCSI matter, and is not a change from RFC 3720.
>
> One of the reasons for taking this approach is that determining
> what ACA command to issue could well depend on what went wrong
> to cause the CHECK CONDITION in the first place, and an
> initiator that thinks it knows all the possible ways in which a
> target could get into a CHECK CONDITION is probably kidding
> itself in most cases.  It's better in general to wait for the
> ACA, look at the sense data and figure out what to do rather
> than blindly fire an ACA command into the dark based on a guess
> about what will cause the ACA.
>
> -- (4) The CLEAR ACA task management function could get ahead of
> 	a command that is dealing with the ACA condition.
>
> The corresponding race for exiting ACA - issue CLEAR ACA while a
> command with the ACA attribute is outstanding - seems less of a
> concern. An initiator who has done this clearly doesn't care
> whether that command (and there can only be one) executes or not.
>
> SAM-2 says that CLEAR ACA has the side effect of aborting a task
> with the ACA attribute.  iSCSI's logical ordering of command (and
> task management function) delivery to SCSI at the target ensures
> that this abort side effect will take place, but it's probably
> worth pointing out that the ordering responsibilities in Section
> 10.5.1 apply to this situation:
> - The target MUST wait for all tasks prior to the CLEAR ACA
> 	function to arrive in order to issue the ACA ACTIVE response
> 	(non ACA task) or abort them (ACA task).
> - The initiator MUST NOT deliver responses from affected
> 	tasks (all tasks prior to the CLEAR ACA function) to
> 	SCSI after the response to CLEAR ACA is delivered.
> An initiator that wishes to deal with ACA as expeditiously as
> possible should (lower case):
> - Issue all commands with the ACA attribute as well as the
> 	CLEAR ACA task management function on the same connection
> 	as the SCSI response that indicated establishment of ACA.
> - Not issue any commands without the ACA attribute prior to
> 	the CLEAR ACA task management function.
>
> Comments? (and sorry for the length)

I think this is a mess. For ACA to work well, it really needs the SCSI 
world to be different than it is normally for iSCSI. :-(

Take care,

Bill

--Apple-Mail-4-850235579
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iD8DBQFD1ZbADJT2Egh26K0RAo7sAJ9aXFsW4O48vhvYdd5kgj0PiKUOcgCfcs5X
Aewk1v2QNeOCESPPyVp35EU=
=Yo5I
-----END PGP SIGNATURE-----

--Apple-Mail-4-850235579--



--===============0173656825==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--===============0173656825==--





From ips-bounces@ietf.org Fri Jan 27 18:50:58 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2dMo-00049L-Pt; Fri, 27 Jan 2006 18:50:58 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F2dLy-0003uX-UY; Fri, 27 Jan 2006 18:50:07 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27061;
	Fri, 27 Jan 2006 18:48:32 -0500 (EST)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F2dWB-0003uo-2x; Fri, 27 Jan 2006 19:00:40 -0500
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1F2dLu-00069E-C6; Fri, 27 Jan 2006 18:50:02 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1F2dLu-00069E-C6@newodin.ietf.org>
Date: Fri, 27 Jan 2006 18:50:02 -0500
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 386e0819b1192672467565a524848168
Cc: ips@ietf.org
Subject: [Ips] I-D ACTION:draft-ietf-ips-isns-mib-08.txt 
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=subscribe>
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org

--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 iSNS 
                          (Internet Storage Name Service)
	Author(s)	: K. Gibbons, et al.
	Filename	: draft-ietf-ips-isns-mib-08.txt
	Pages		: 68
	Date		: 2006-1-27
	
The iSNS protocol [RFC4171] provides storage name service 
   functionality on an IP network that is being used for iSCSI 
   [RFC3720] or iFCP [RFC4172] storage. This draft provides a 
   mechanism to monitor and control multiple iSNS Client and 
   Servers, including information about registered objects in an 
   iSNS Server. 
    
   This memo is a product of the IP Storage (IPS) working group 
   within the Internet Engineering Task Force.  Comments are 
   solicited and should be addressed to the working group's mailing 
   list at ips@ietf.org and/or the authors.

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

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


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-isns-mib-08.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-isns-mib-08.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: <2006-1-27164007.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ips-isns-mib-08.txt

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

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


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--NextPart--




From ips-bounces@ietf.org Mon Jan 30 15:51:08 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F3fzQ-0004Z8-Cw; Mon, 30 Jan 2006 15:51:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F3fyT-0004F0-PG; Mon, 30 Jan 2006 15:50:09 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26385;
	Mon, 30 Jan 2006 15:48:33 -0500 (EST)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F3g9D-0001Zx-PY; Mon, 30 Jan 2006 16:01:16 -0500
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1F3fyM-0007Zp-MW; Mon, 30 Jan 2006 15:50:02 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1F3fyM-0007Zp-MW@newodin.ietf.org>
Date: Mon, 30 Jan 2006 15:50:02 -0500
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Cc: ips@ietf.org
Subject: [Ips] I-D ACTION:draft-ietf-ips-scsi-mib-09.txt 
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=subscribe>
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org

--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		: Definition of Managed Objects for SCSI Entities
	Author(s)	: M. Hallak, et al.
	Filename	: draft-ietf-ips-scsi-mib-09.txt
	Pages		: 97
	Date		: 2006-1-30
	
This memo defines a portion of the Management Information Base (MIB),
   for use with network management protocols in the Internet community.
   In particular it describes managed objects for Small Computer System
   Interface (SCSI) entities, independently of the interconnect
   subsystem layer.

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

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


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-scsi-mib-09.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-scsi-mib-09.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: <2006-1-30122918.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ips-scsi-mib-09.txt

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

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


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--NextPart--