From ips-bounces@ietf.org Mon Oct 03 00:37:13 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EMI4f-0003XT-3J; Mon, 03 Oct 2005 00:37:13 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EMI4d-0003UF-JE
	for ips@megatron.ietf.org; Mon, 03 Oct 2005 00:37:11 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17559
	for <ips@ietf.org>; Mon, 3 Oct 2005 00:37:08 -0400 (EDT)
Received: from gwjordan.dsi.a-star.edu.sg ([137.132.27.226]
	helo=mailgw.dsinet.lan) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EMID0-0002Fg-Sl for ips@ietf.org; Mon, 03 Oct 2005 00:45:53 -0400
Received: from unknown (HELO dsi.a-star.edu.sg) ([192.168.9.20])
	by mailgw.dsinet.lan with ESMTP; 03 Oct 2005 12:36:58 +0800
X-IronPort-AV: i="3.97,166,1125849600"; d="scan'208"; a="28501:sNHT28729236"
Received: from GWIADM-MTA by dsi.a-star.edu.sg
	with Novell_GroupWise; Mon, 03 Oct 2005 12:36:59 +0800
Message-Id: <s34125ea.011@dsi.a-star.edu.sg>
X-Mailer: Novell GroupWise Internet Agent 6.5.1 
Date: Mon, 03 Oct 2005 12:36:40 +0800
From: "Santos Kumar Das" <Santos_Kumar_DAS@dsi.a-star.edu.sg>
To: <ips@ietf.org>
Mime-Version: 1.0
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Content-Transfer-Encoding: 7bit
Subject: [Ips] Direct SCSI disk drive access without iSCSI
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

Hi All,

Can anyone please mention me about the principle pf iSCSI protocol. I felt,
it is a software link from the user (initiator) to the target (SCSI disk
drive). Is there any other way to access directly the SCSI disk drive without
this soft link by the user.

Thanks & Regards,
Santos

==============================================================================
This email is confidential and may be privileded. If you are no the intended
recipent, please delete it and notify us immediately. Please do not copy or use
it for any purpose, or disclose its contents to any other person. Thank you.

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



From ips-bounces@ietf.org Mon Oct 03 12:31:38 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EMTE2-00032a-Q5; Mon, 03 Oct 2005 12:31:38 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EMTE1-00031w-LG
	for ips@megatron.ietf.org; Mon, 03 Oct 2005 12:31:37 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16244
	for <ips@ietf.org>; Mon, 3 Oct 2005 12:31:35 -0400 (EDT)
From: Black_David@emc.com
Received: from mailhub.lss.emc.com ([168.159.2.31])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMTMW-0004wk-Ax
	for ips@ietf.org; Mon, 03 Oct 2005 12:40:25 -0400
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.6) with ESMTP id
	j93GUdkE008185; Mon, 3 Oct 2005 12:30:40 -0400 (EDT)
Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19)
	id <RT6AKASQ>; Mon, 3 Oct 2005 12:30:31 -0400
Message-ID: <F222151D3323874393F83102D614E0557A6F31@CORPUSMX20A.corp.emc.com>
To: Santos_Kumar_DAS@dsi.a-star.edu.sg, ips@ietf.org
Subject: RE: [Ips] Direct SCSI disk drive access without iSCSI
Date: Mon, 3 Oct 2005 12:30:27 -0400 
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: 2005.10.3.16
X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, EMC_FROM_00+ 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: f60d0f7806b0c40781eee6b9cd0b2135
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

Santos,

First of all, on IETF mailing lists, **DO NOT USE EMAIL FOOTERS LIKE THIS**:

>
============================================================================
==
> This email is confidential and may be privileded. If you are no the
intended
> recipent, please delete it and notify us immediately. Please do not copy
or use
> it for any purpose, or disclose its contents to any other person. Thank
you.

That sort of footer is null and void on a public mailing list such as
this IETF list.  It is your responsibility to not send confidential material
to a public mailing list.

> Can anyone please mention me about the principle pf iSCSI protocol. I
felt,
> it is a software link from the user (initiator) to the target (SCSI disk
> drive). Is there any other way to access directly the SCSI disk drive
without
> this soft link by the user.

iSCSI as a physical disk drive interface is unlikely.  I suggest spending
some time to understand disk arrays and tape libraries, and how Storage
Area Networks (the most common technology today is Fibre Channel) are used
to provide networked access to them from multiple hosts.  iSCSI is roughly
in this space of applying Internet technology to storage area networks.

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: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On 
> Behalf Of Santos Kumar Das
> Sent: Monday, October 03, 2005 12:37 AM
> To: ips@ietf.org
> Subject: [Ips] Direct SCSI disk drive access without iSCSI
> 
> Hi All,
> 
> Can anyone please mention me about the principle pf iSCSI 
> protocol. I felt,
> it is a software link from the user (initiator) to the target 
> (SCSI disk
> drive). Is there any other way to access directly the SCSI 
> disk drive without
> this soft link by the user.
> 
> Thanks & Regards,
> Santos
> 
> ==============================================================
> ================
> This email is confidential and may be privileded. If you are 
> no the intended
> recipent, please delete it and notify us immediately. Please 
> do not copy or use
> it for any purpose, or disclose its contents to any other 
> person. Thank you.

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



From ips-bounces@ietf.org Mon Oct 03 22:53:15 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EMcvb-0001Ap-GJ; Mon, 03 Oct 2005 22:53:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EMcvZ-0001Ak-UW
	for ips@megatron.ietf.org; Mon, 03 Oct 2005 22:53:14 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06543
	for <ips@ietf.org>; Mon, 3 Oct 2005 22:53:11 -0400 (EDT)
Received: from sccrmhc14.comcast.net ([204.127.202.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMd4A-0001yR-2S
	for ips@ietf.org; Mon, 03 Oct 2005 23:02:07 -0400
Received: from [67.188.98.5] (c-67-188-98-5.hsd1.ca.comcast.net[67.188.98.5])
	by comcast.net (sccrmhc14) with SMTP
	id <2005100402525601400q1uaae>; Tue, 4 Oct 2005 02:53:02 +0000
In-Reply-To: <s34125ea.011@dsi.a-star.edu.sg>
References: <s34125ea.011@dsi.a-star.edu.sg>
Mime-Version: 1.0 (Apple Message framework v734)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <B284A90F-9661-450E-A5BF-9BD885F33B22@ieee.org>
Content-Transfer-Encoding: 7bit
From: Pat LaVarre <p.lavarre@ieee.org>
Subject: Re: [Ips] Direct SCSI disk drive access without iSCSI
Date: Mon, 3 Oct 2005 06:56:57 -0700
To: "Santos Kumar Das" <Santos_Kumar_DAS@dsi.a-star.edu.sg>
X-Mailer: Apple Mail (2.734)
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4
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

>  any other way to access directly the SCSI disk drive without
> this soft link by the user.

Lots.

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



From ips-bounces@ietf.org Wed Oct 05 01:30:33 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EN1rM-0003zj-Fu; Wed, 05 Oct 2005 01:30:32 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EN1rI-0003y8-0i
	for ips@megatron.ietf.org; Wed, 05 Oct 2005 01:30:30 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29794
	for <ips@ietf.org>; Wed, 5 Oct 2005 01:30:27 -0400 (EDT)
Received: from mailgate.mcdata.com ([208.47.132.224]
	helo=MC4GATE02out.mcdata.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EN206-0007AN-7j
	for ips@ietf.org; Wed, 05 Oct 2005 01:39:35 -0400
Received: from MC4GATE02.mcdata.com ([172.16.11.207]) by
	MC4GATE02out.mcdata.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 4 Oct 2005 23:30:17 -0600
Received: from MC4EXCH01.mcdata.com ([172.16.11.123]) by 
	MC4GATE02.mcdata.com with InterScan Messaging Security Suite;
	Tue, 04 Oct 2005 23:30:16 -0600
Received: from SCEXCH01.mcdata.com ([172.19.161.171]) by 
	MC4EXCH01.mcdata.com with Microsoft SMTPSVC(6.0.3790.1830);
	Tue, 4 Oct 2005 23:30:16 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Date: Tue, 4 Oct 2005 22:29:38 -0700
Message-ID: <D7E79BEF459E8E45A1CBE5BC56F22C04763191@SCEXCH01.mcdata.com>
Thread-Topic: iSNS MIB Revision Plans
Thread-Index: AcXJbcd+Li2IVrkoR3S2dXLsAy9r8A==
From: "Kevin Gibbons" <kevin.gibbons@mcdata.com>
To: <ips@ietf.org>
X-OriginalArrivalTime: 05 Oct 2005 05:30:16.0525 (UTC) 
	FILETIME=[DE20FFD0:01C5C96D]
X-imss-version: 2.031
X-imss-result: Passed
X-imss-approveListMatch: *@mcdata.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Content-Transfer-Encoding: quoted-printable
Cc: kgibbons@yahoo.com, Josh Tseng <joshtseng@yahoo.com>, tommcs@us.ibm.com,
	Scott Kipp <scott.kipp@mcdata.com>
Subject: [Ips] iSNS MIB Revision Plans
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 initial iSNS MIB draft versions were designed to fully configure,
monitor and manage multiple iSNS clients and servers.  This may have
been too much to expect in a single standard MIB.

It has been discussed that the draft iSNS MIB would be more easily
ratified, and easier to implement, if it was not as extensive and large
as the current draft.

Because of this, it is propose to make the iSNS MIB smaller.  The
updated MIB would not provide for configuration of iSNS Clients and
Servers.  Rather, it will monitor the contents and status of iSNS
Clients and Servers.  Configuration settings would be done in enterprise
MIBs for a specific server implementation.  This would be more efficient
and resilient to industry changes.  The draft standard could then
support iSNS server HA configurations not currently envisioned.

Because of the reduction in size, and layout changes, it will need to go
through last call again.  However, due to the underlying iSNS begin
close to ratification, and the MIB being smaller, it should make it
through more easily.

I plan to have a draft out for review shortly.

If there are suggestions for changes to the MIB, please reply to the
reflector or to me directly.

Regards, Kevin


---------------------------------
Kevin Gibbons
McDATA Corporation
(408)567-5765
kevin.gibbons@mcdata.com
---------------------------------
(gate01)

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



From ips-bounces@ietf.org Thu Oct 06 15:50:15 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ENbkt-0006br-8Q; Thu, 06 Oct 2005 15:50:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ENbkg-0006U9-Jw; Thu, 06 Oct 2005 15:50:02 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26654;
	Thu, 6 Oct 2005 15:50:00 -0400 (EDT)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1ENbtp-0007tb-GY; Thu, 06 Oct 2005 15:59:29 -0400
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1ENbkf-0002oQ-FH; Thu, 06 Oct 2005 15:50:01 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1ENbkf-0002oQ-FH@newodin.ietf.org>
Date: Thu, 06 Oct 2005 15:50:01 -0400
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43
Cc: ips@ietf.org
Subject: [Ips] I-D ACTION:draft-ietf-ips-ifcp-mib-07.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 iFCP
	Author(s)	: K. Gibbons, et al.
	Filename	: draft-ietf-ips-ifcp-mib-07.txt
	Pages		: 27
	Date		: 2005-10-6
	
The iFCP protocol [RFC4172] provides Fibre Channel fabric 
   functionality on an IP network in which TCP/IP switching and routing 
   elements replace Fibre Channel components.  The iFCP protocol is 
   used between iFCP Gateways.  This draft provides a mechanism to 
   monitor and control iFCP Gateway instances, and their associated 
   sessions, using SNMP. 
    
   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-ifcp-mib-07.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-ifcp-mib-07.txt".

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


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

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

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

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

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

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

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

Content-Type: text/plain
Content-ID: <2005-10-6113058.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 Oct 10 08:39:32 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EOwwG-00013h-Ow; Mon, 10 Oct 2005 08:39:32 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EOwwF-00013c-JY
	for ips@megatron.ietf.org; Mon, 10 Oct 2005 08:39:31 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06343
	for <ips@ietf.org>; Mon, 10 Oct 2005 08:39:30 -0400 (EDT)
From: Yackey_Steve@emc.com
Received: from mailhub.lss.emc.com ([168.159.2.31])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOx68-0003gi-Oz
	for ips@ietf.org; Mon, 10 Oct 2005 08:49:46 -0400
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.6) with ESMTP id
	j9ACdGHO011798
	for <ips@ietf.org>; Mon, 10 Oct 2005 08:39:18 -0400 (EDT)
Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19)
	id <RT6AYRDF>; Mon, 10 Oct 2005 08:39:15 -0400
Message-ID: <CEF7DE8455A91D42A0435A42956403293FF777@CORPUSMX40B.corp.emc.com>
To: ips@ietf.org
Date: Mon, 10 Oct 2005 08:39:13 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0,
	Antispam-Data: 2005.10.10.9
X-PerlMx-Spam: Gauge=, SPAM=7%, Reasons='EMC_FROM_00+ -0, NO_REAL_NAME 0,
	__C230066_P5 0, __CT 0, __CTYPE_HAS_BOUNDARY 0,
	__CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __HAS_MSGID 0,
	__HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_HTML 0,
	__MIME_VERSION 0, __SANE_MSGID 0, __TAG_EXISTS_HTML 0'
X-Spam-Score: 1.2 (+)
X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632
Subject: [Ips] configuration and location mechanisms
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="===============2061316223=="
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============2061316223==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C5CD97.9E8FF727"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C5CD97.9E8FF727
Content-Type: text/plain


I am trying to understand where some of the iSCSI 'configuration and
location' mechanisms fit into an iSCSI deployment, including security
information. Particularly, SLP and iSNS.

It is my sense that:

- SLP is an older mechanism utilized as a means to locate targets and
optionally as: a means to identify initiators allowed access; a repository
of CHAP credentials. A much more limited set of information than iSNS.

- iSNS, on the other hand, ala rfc4171, seems to comprehensively specify
iSCSI operational configuration information; target/initiator, CHAP and
IPSec settings. Being more complete, iSNS would then offer the greater
opportunity for interoperabiltiy among iSCSI implementations.

So in looking at these two it seems that SLP is where the industry has been;
iSNS is where its going. 

Is this the general sense of things ??

Thanks in advance,
Steve


Steve Yackey
EMC2 Corporation
1401 Main Street, Suite 350
Columbia, SC 29201
803-231-2632



------_=_NextPart_001_01C5CD97.9E8FF727
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>configuration and location mechanisms</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">I am trying to =
understand where some of the iSCSI 'configuration and location' =
mechanisms fit into an iSCSI deployment, including security =
information. Particularly, SLP and iSNS.</FONT></P>

<P><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">It is my sense =
that:</FONT>
</P>

<P><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">- SLP is an older =
mechanism utilized as a means to locate targets and optionally as: a =
means to identify initiators allowed access; a repository of CHAP =
credentials. A much more limited set of information than =
iSNS.</FONT></P>

<P><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">- iSNS, on the =
other hand, ala rfc4171, seems to comprehensively specify iSCSI =
operational configuration information; target/initiator, CHAP and IPSec =
settings. Being more complete, iSNS would then offer the greater =
opportunity for interoperabiltiy among iSCSI =
implementations.</FONT></P>

<P><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">So in looking at =
these two it seems that SLP is where the industry has been; iSNS is =
where its going. </FONT>
</P>

<P><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">Is this the =
general sense of things ??</FONT>
</P>

<P><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">Thanks in =
advance,</FONT>
<BR><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">Steve</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Verdana">Steve Yackey</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Verdana">EMC<SUP>2</SUP> Corporation</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Verdana">1401 Main Street, Suite 350</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Verdana">Columbia, SC 29201</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Verdana">803-</FONT><FONT SIZE=3D2 =
FACE=3D"Verdana">231-2632</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C5CD97.9E8FF727--


--===============2061316223==
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

--===============2061316223==--




From ips-bounces@ietf.org Mon Oct 10 09:01:14 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EOxHG-0004ZH-TL; Mon, 10 Oct 2005 09:01:14 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EOxHF-0004Ys-Ey
	for ips@megatron.ietf.org; Mon, 10 Oct 2005 09:01:13 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07430
	for <ips@ietf.org>; Mon, 10 Oct 2005 09:01:11 -0400 (EDT)
From: Black_David@emc.com
Received: from mailhub.lss.emc.com ([168.159.2.31])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOxR8-0004FM-MH
	for ips@ietf.org; Mon, 10 Oct 2005 09:11:28 -0400
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.6) with ESMTP id
	j9AD18SR002439
	for <ips@ietf.org>; Mon, 10 Oct 2005 09:01:09 -0400 (EDT)
Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19)
	id <RT6AYTDP>; Mon, 10 Oct 2005 09:01:08 -0400
Message-ID: <F222151D3323874393F83102D614E0557A6F83@CORPUSMX20A.corp.emc.com>
To: Yackey_Steve@emc.com, ips@ietf.org
Subject: RE: [Ips] configuration and location mechanisms
Date: Mon, 10 Oct 2005 09:01:06 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0,
	Antispam-Data: 2005.10.10.11
X-PerlMx-Spam: Gauge=, SPAM=4%, Reasons='EMC_BODY_1+ -1, EMC_FROM_00+ -0,
	HTML_50_70 0.1, NO_REAL_NAME 0, __C230066_P5 0, __CT 0,
	__CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0,
	__CTYPE_MULTIPART_ALT 0, __HAS_MSGID 0, __HAS_X_MAILER 0,
	__IMS_MSGID 0, __IMS_MUA 0, __MIME_HTML 0, __MIME_VERSION 0,
	__SANE_MSGID 0, __STOCK_CRUFT 0, __TAG_EXISTS_HTML 0'
X-Spam-Score: 0.9 (/)
X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c
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="===============0448055773=="
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============0448055773==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C5CD99.93944FF1"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C5CD99.93944FF1
Content-Type: text/plain

Steve,
 
Your sense of the functionality difference between SLP and iSNS is
correct, but your inference of their history is not.  All three of
the iSCSI discovery (aka 'configuration and location') mechanisms,
Send Targets, SLP, and iSNS, were developed in parallel around the
same time.
 
The rationale for specifying both iSNS and SLP is that SLP is a
discovery-only basic configuration mechanism that reuses an existing
protocol (SLP) and hence may involve less infrastructure deployment
than iSNS's more comprehensive functionality that involves a new
protocol.
 
At the moment, I believe there is more interest in iSNS than SLP,
but the most important factor is what the implementation(s) you
want to work with support and intend to support.
 
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 
---------------------------------------------------- 


  _____  

From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of
Yackey, Steve
Sent: Monday, October 10, 2005 8:39 AM
To: ips@ietf.org
Subject: [Ips] configuration and location mechanisms




I am trying to understand where some of the iSCSI 'configuration and
location' mechanisms fit into an iSCSI deployment, including security
information. Particularly, SLP and iSNS.

It is my sense that: 

- SLP is an older mechanism utilized as a means to locate targets and
optionally as: a means to identify initiators allowed access; a repository
of CHAP credentials. A much more limited set of information than iSNS.

- iSNS, on the other hand, ala rfc4171, seems to comprehensively specify
iSCSI operational configuration information; target/initiator, CHAP and
IPSec settings. Being more complete, iSNS would then offer the greater
opportunity for interoperabiltiy among iSCSI implementations.

So in looking at these two it seems that SLP is where the industry has been;
iSNS is where its going. 

Is this the general sense of things ?? 

Thanks in advance, 
Steve 


Steve Yackey 
EMC2 Corporation 
1401 Main Street, Suite 350 
Columbia, SC 29201 
803-231-2632 



------_=_NextPart_001_01C5CD99.93944FF1
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE>configuration and location mechanisms</TITLE>

<META content="MSHTML 6.00.2800.1515" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=337005312-10102005><FONT face="Courier New" 
size=2>Steve,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=337005312-10102005><FONT face="Courier New" 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=337005312-10102005><FONT face="Courier New" 
size=2>Your sense of the functionality difference between SLP and iSNS 
is</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=337005312-10102005><FONT face="Courier New" 
size=2>correct, but your inference of their history is not.&nbsp; All three 
of</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=337005312-10102005><FONT face="Courier New" 
size=2>the iSCSI discovery (aka 'configuration and location') 
mechanisms,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=337005312-10102005><FONT face="Courier New" 
size=2>Send Targets, SLP, and iSNS, were developed in parallel around 
the</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=337005312-10102005><FONT face="Courier New" 
size=2>same time.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=337005312-10102005><FONT face="Courier New" 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=337005312-10102005><FONT face="Courier New" 
size=2>The rationale for specifying both iSNS and SLP is that SLP is 
a</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=337005312-10102005><FONT face="Courier New" 
size=2>discovery-only basic configuration mechanism </FONT></SPAN><SPAN 
class=337005312-10102005><FONT face="Courier New" size=2>that reuses an 
existing</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=337005312-10102005><FONT face="Courier New" 
size=2>protocol (SLP) </FONT></SPAN><SPAN class=337005312-10102005><FONT 
face="Courier New" size=2>and hence may involve less </FONT></SPAN><SPAN 
class=337005312-10102005><FONT face="Courier New" size=2>infrastructure 
deployment</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=337005312-10102005><FONT face="Courier New" 
size=2>than&nbsp;iSNS's&nbsp;more comprehensive&nbsp;</FONT></SPAN><SPAN 
class=337005312-10102005><FONT face="Courier New" size=2>functionality that 
</FONT></SPAN><SPAN class=337005312-10102005><FONT face="Courier New" 
size=2>involves </FONT></SPAN><SPAN class=337005312-10102005><FONT 
face="Courier New" size=2>a new</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=337005312-10102005><FONT face="Courier New" 
size=2>protocol.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=337005312-10102005><FONT face="Courier New" 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=337005312-10102005><FONT face="Courier New" 
size=2>At the moment, I believe there is more interest in iSNS than 
SLP,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=337005312-10102005><FONT face="Courier New" 
size=2>but the most important factor is what the implementation(s) 
you</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=337005312-10102005><FONT face="Courier New" 
size=2>want to work with support and intend to support.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=337005312-10102005><FONT face="Courier New" 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=337005312-10102005><FONT face="Courier New" 
size=2>Thanks,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=337005312-10102005><FONT face="Courier New" 
size=2>--David</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=337005312-10102005></SPAN><SPAN 
class=337005312-10102005><SPAN lang=en-us><FONT face="Courier New" 
size=2>----------------------------------------------------</FONT></SPAN> 
<BR><SPAN lang=en-us><FONT face="Courier New" size=2>David L. Black, Senior 
Technologist</FONT></SPAN> <BR><SPAN lang=en-us><FONT face="Courier New" 
size=2>EMC Corporation, 176 South St., Hopkinton, MA&nbsp; 01748</FONT></SPAN> 
<BR><SPAN lang=en-us><FONT face="Courier New" size=2>+1 (508) 
293-7953&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
FAX: +1 (508) 293-7786</FONT></SPAN> <BR><SPAN lang=en-us><FONT 
face="Courier New" 
size=2>black_david@emc.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Mobile: +1 
(978) 394-7754</FONT></SPAN> <BR><SPAN lang=en-us><FONT face="Courier New" 
size=2>----------------------------------------------------</FONT></SPAN> 
</DIV></SPAN><BR>
<BLOCKQUOTE 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
  <HR tabIndex=-1>
  <FONT face=Tahoma size=2><B>From:</B> ips-bounces@ietf.org 
  [mailto:ips-bounces@ietf.org] <B>On Behalf Of </B>Yackey, 
  Steve<BR><B>Sent:</B> Monday, October 10, 2005 8:39 AM<BR><B>To:</B> 
  ips@ietf.org<BR><B>Subject:</B> [Ips] configuration and location 
  mechanisms<BR></FONT><BR></DIV>
  <DIV></DIV><BR>
  <P><FONT face=Verdana color=#800000 size=2>I am trying to understand where 
  some of the iSCSI 'configuration and location' mechanisms fit into an iSCSI 
  deployment, including security information. Particularly, SLP and 
  iSNS.</FONT></P>
  <P><FONT face=Verdana color=#800000 size=2>It is my sense that:</FONT> </P>
  <P><FONT face=Verdana color=#800000 size=2>- SLP is an older mechanism 
  utilized as a means to locate targets and optionally as: a means to identify 
  initiators allowed access; a repository of CHAP credentials. A much more 
  limited set of information than iSNS.</FONT></P>
  <P><FONT face=Verdana color=#800000 size=2>- iSNS, on the other hand, ala 
  rfc4171, seems to comprehensively specify iSCSI operational configuration 
  information; target/initiator, CHAP and IPSec settings. Being more complete, 
  iSNS would then offer the greater opportunity for interoperabiltiy among iSCSI 
  implementations.</FONT></P>
  <P><FONT face=Verdana color=#800000 size=2>So in looking at these two it seems 
  that SLP is where the industry has been; iSNS is where its going. </FONT></P>
  <P><FONT face=Verdana color=#800000 size=2>Is this the general sense of things 
  ??</FONT> </P>
  <P><FONT face=Verdana color=#800000 size=2>Thanks in advance,</FONT> <BR><FONT 
  face=Verdana color=#800000 size=2>Steve</FONT> </P><BR>
  <P><FONT face=Verdana size=2>Steve Yackey</FONT> <BR><FONT face=Verdana 
  size=2>EMC<SUP>2</SUP> Corporation</FONT> <BR><FONT face=Verdana size=2>1401 
  Main Street, Suite 350</FONT> <BR><FONT face=Verdana size=2>Columbia, SC 
  29201</FONT> <BR><FONT face=Verdana size=2>803-</FONT><FONT face=Verdana 
  size=2>231-2632</FONT> </P><BR></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C5CD99.93944FF1--


--===============0448055773==
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

--===============0448055773==--




From ips-bounces@ietf.org Mon Oct 10 11:07:59 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EOzFv-0004Ur-L8; Mon, 10 Oct 2005 11:07:59 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EOzFt-0004Tu-Dh; Mon, 10 Oct 2005 11:07:58 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19662;
	Mon, 10 Oct 2005 11:07:54 -0400 (EDT)
Received: from mtagate3.de.ibm.com ([195.212.29.152])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EOzPi-0000Ta-S2; Mon, 10 Oct 2005 11:18:09 -0400
Received: from d12nrmr1607.megacenter.de.ibm.com
	(d12nrmr1607.megacenter.de.ibm.com [9.149.167.49])
	by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id j9AF7ZTZ177728; 
	Mon, 10 Oct 2005 15:07:35 GMT
Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com
	[9.149.165.228])
	by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP
	id j9AF7ZkI166350; Mon, 10 Oct 2005 17:07:35 +0200
Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1])
	by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id
	j9AF7Zwa009360; Mon, 10 Oct 2005 17:07:35 +0200
Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com
	[9.149.166.138])
	by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id
	j9AF7YLd009357; Mon, 10 Oct 2005 17:07:34 +0200
In-Reply-To: <CEF7DE8455A91D42A0435A42956403293FF777@CORPUSMX40B.corp.emc.com>
To: Yackey_Steve@emc.com
Subject: Re: [Ips] configuration and location mechanisms
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 7.0 August 18, 2005
From: Julian Satran <Julian_Satran@il.ibm.com>
Message-ID: <OFACEEE81F.34623A69-ONC2257096.0051FD4C-C2257096.005316A0@il.ibm.com>
Date: Mon, 10 Oct 2005 17:07:34 +0200
X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5,
	2004) at 10/10/2005 17:07:34,
	Serialize complete at 10/10/2005 17:07:34
X-Spam-Score: 0.6 (/)
X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7
Cc: ips@ietf.org, ips-bounces@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="===============0216936099=="
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org

This is a multipart message in MIME format.
--===============0216936099==
Content-Type: multipart/alternative;
	boundary="=_alternative 0052D656C2257096_="

This is a multipart message in MIME format.
--=_alternative 0052D656C2257096_=
Content-Type: text/plain; charset="US-ASCII"

Regarding storage and the present status your statement about completeness 
is probably correct. And iSNS AFAIK covers both iSCSI and FCP. However SLP 
has broader coverage (covers many types of service) and stands a good 
chance to get updated as people use it in many areas. So I would not jump 
on categorizing SLP as "where the industry has been". Combined with other 
widely deployed technologies it may offer those aiming at a "common" 
solution for Networking and Storage in the Data Center exactly what they 
are looking for. On the other hand if  your interest is limited to storage 
iSNS is probably a good match.

Now place your bets :-)

Julo



Yackey_Steve@emc.com 
Sent by: ips-bounces@ietf.org
10-10-05 14:39

To
ips@ietf.org
cc

Subject
[Ips] configuration and location mechanisms







I am trying to understand where some of the iSCSI 'configuration and 
location' mechanisms fit into an iSCSI deployment, including security 
information. Particularly, SLP and iSNS.
It is my sense that: 
- SLP is an older mechanism utilized as a means to locate targets and 
optionally as: a means to identify initiators allowed access; a repository 
of CHAP credentials. A much more limited set of information than iSNS.
- iSNS, on the other hand, ala rfc4171, seems to comprehensively specify 
iSCSI operational configuration information; target/initiator, CHAP and 
IPSec settings. Being more complete, iSNS would then offer the greater 
opportunity for interoperabiltiy among iSCSI implementations.
So in looking at these two it seems that SLP is where the industry has 
been; iSNS is where its going. 
Is this the general sense of things ?? 
Thanks in advance, 
Steve 

Steve Yackey 
EMC2 Corporation 
1401 Main Street, Suite 350 
Columbia, SC 29201 
803-231-2632 
_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips


--=_alternative 0052D656C2257096_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">Regarding storage and the present status
your statement about completeness is probably correct. And iSNS AFAIK covers
both iSCSI and FCP. However SLP has broader coverage (covers many types
of service) and stands a good chance to get updated as people use it in
many areas. So I would not jump on categorizing SLP as &quot;where the
industry has been&quot;. Combined with other widely deployed technologies
it may offer those aiming at a &quot;common&quot; solution for Networking
and Storage in the Data Center exactly what they are looking for. On the
other hand if &nbsp;your interest is limited to storage iSNS is probably
a good match.</font>
<br>
<br><font size=2 face="sans-serif">Now place your bets :-)</font>
<br>
<br><font size=2 face="sans-serif">Julo</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Yackey_Steve@emc.com</b>
</font>
<br><font size=1 face="sans-serif">Sent by: ips-bounces@ietf.org</font>
<p><font size=1 face="sans-serif">10-10-05 14:39</font>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">ips@ietf.org</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">[Ips] configuration and location mechanisms</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br>
<p><font size=2 color=#800000 face="Verdana">I am trying to understand
where some of the iSCSI 'configuration and location' mechanisms fit into
an iSCSI deployment, including security information. Particularly, SLP
and iSNS.</font>
<p><font size=2 color=#800000 face="Verdana">It is my sense that:</font><font size=3>
</font>
<p><font size=2 color=#800000 face="Verdana">- SLP is an older mechanism
utilized as a means to locate targets and optionally as: a means to identify
initiators allowed access; a repository of CHAP credentials. A much more
limited set of information than iSNS.</font>
<p><font size=2 color=#800000 face="Verdana">- iSNS, on the other hand,
ala rfc4171, seems to comprehensively specify iSCSI operational configuration
information; target/initiator, CHAP and IPSec settings. Being more complete,
iSNS would then offer the greater opportunity for interoperabiltiy among
iSCSI implementations.</font>
<p><font size=2 color=#800000 face="Verdana">So in looking at these two
it seems that SLP is where the industry has been; iSNS is where its going.
</font>
<p><font size=2 color=#800000 face="Verdana">Is this the general sense
of things ??</font><font size=3> </font>
<p><font size=2 color=#800000 face="Verdana">Thanks in advance,</font><font size=3>
</font><font size=2 color=#800000 face="Verdana"><br>
Steve</font><font size=3> </font>
<p>
<p><font size=2 face="Verdana">Steve Yackey</font><font size=3> </font><font size=2 face="Verdana"><br>
EMC<sup>2</sup> Corporation</font><font size=3> </font><font size=2 face="Verdana"><br>
1401 Main Street, Suite 350</font><font size=3> </font><font size=2 face="Verdana"><br>
Columbia, SC 29201</font><font size=3> </font><font size=2 face="Verdana"><br>
803-231-2632</font><font size=3> </font>
<p><tt><font size=2>_______________________________________________<br>
Ips mailing list<br>
Ips@ietf.org<br>
https://www1.ietf.org/mailman/listinfo/ips<br>
</font></tt>
<p>
--=_alternative 0052D656C2257096_=--


--===============0216936099==
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

--===============0216936099==--




From ips-bounces@ietf.org Mon Oct 10 11:50:51 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EOzvP-0005mg-Kk; Mon, 10 Oct 2005 11:50:51 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EOzvL-0005k0-HV
	for ips@megatron.ietf.org; Mon, 10 Oct 2005 11:50:49 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01121
	for <ips@ietf.org>; Mon, 10 Oct 2005 11:50:43 -0400 (EDT)
Received: from mailgate.mcdata.com ([208.47.132.224]
	helo=MC4GATE02out.mcdata.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOzz8-00063y-Q4
	for ips@ietf.org; Mon, 10 Oct 2005 11:54:45 -0400
Received: from MC4GATE02.mcdata.com ([172.16.11.207]) by
	MC4GATE02out.mcdata.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 10 Oct 2005 09:44:08 -0600
Received: from MC4EXCH01.mcdata.com ([172.16.11.123]) by 
	MC4GATE02.mcdata.com with InterScan Messaging Security Suite;
	Mon, 10 Oct 2005 09:44:07 -0600
Received: from SCEXCH01.mcdata.com ([172.19.161.171]) by 
	MC4EXCH01.mcdata.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Oct 
	2005 09:44:03 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Ips] configuration and location mechanisms
Date: Mon, 10 Oct 2005 08:44:02 -0700
Message-ID: <D7E79BEF459E8E45A1CBE5BC56F22C04763204@SCEXCH01.mcdata.com>
Thread-Topic: [Ips] configuration and location mechanisms
Thread-Index: AcXNmx234gGIwG6rSH6TPrgg4BHhxwAEp2ug
From: "Kevin Gibbons" <kevin.gibbons@mcdata.com>
To: <Yackey_Steve@emc.com>, <ips@ietf.org>
X-OriginalArrivalTime: 10 Oct 2005 15:44:03.0847 (UTC) 
	FILETIME=[70FD2170:01C5CDB1]
X-imss-version: 2.032
X-imss-result: Passed
X-imss-approveListMatch: *@mcdata.com
X-Spam-Score: 0.7 (/)
X-Scan-Signature: db284e046c8702920c1c6125bc4d0b7a
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="===============0452700808=="
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0452700808==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C5CDB1.7076B14A"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C5CDB1.7076B14A
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable


Steve,
=0D
David did a good job of summarizing the background of each method.
=0D
The iSNS protocol was developed to provide mechanisms for iSCSI storage
management that are similar to what, over time, were found to be useful
for fibre channel based storage area network fabrics.
=0D
Regards, Kevin

________________________________

From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of
Black_David@emc.com
Sent: Monday, October 10, 2005 6:01 AM
To: Yackey_Steve@emc.com; ips@ietf.org
Subject: RE: [Ips] configuration and location mechanisms


Steve,
=0D
Your sense of the functionality difference between SLP and iSNS is
correct, but your inference of their history is not.  All three of
the iSCSI discovery (aka 'configuration and location') mechanisms,
Send Targets, SLP, and iSNS, were developed in parallel around the
same time.
=0D
The rationale for specifying both iSNS and SLP is that SLP is a
discovery-only basic configuration mechanism that reuses an existing
protocol (SLP) and hence may involve less infrastructure deployment
than iSNS's more comprehensive functionality that involves a new
protocol.
=0D
At the moment, I believe there is more interest in iSNS than SLP,
but the most important factor is what the implementation(s) you
want to work with support and intend to support.
=0D
Thanks,
--David
----------------------------------------------------=0D
David L. Black, Senior Technologist=0D
EMC Corporation, 176 South St., Hopkinton, MA  01748=0D
+1 (508) 293-7953             FAX: +1 (508) 293-7786=0D
black_david@emc.com        Mobile: +1 (978) 394-7754=0D
----------------------------------------------------=0D


________________________________

	From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On
Behalf Of Yackey, Steve
	Sent: Monday, October 10, 2005 8:39 AM
	To: ips@ietf.org
	Subject: [Ips] configuration and location mechanisms
=0D
=0D


	I am trying to understand where some of the iSCSI 'configuration
and location' mechanisms fit into an iSCSI deployment, including
security information. Particularly, SLP and iSNS.

	It is my sense that:=0D

	- SLP is an older mechanism utilized as a means to locate
targets and optionally as: a means to identify initiators allowed
access; a repository of CHAP credentials. A much more limited set of
information than iSNS.

	- iSNS, on the other hand, ala rfc4171, seems to comprehensively
specify iSCSI operational configuration information; target/initiator,
CHAP and IPSec settings. Being more complete, iSNS would then offer the
greater opportunity for interoperabiltiy among iSCSI implementations.

	So in looking at these two it seems that SLP is where the
industry has been; iSNS is where its going.=0D

	Is this the general sense of things ??=0D

	Thanks in advance,=0D
	Steve=0D


	Steve Yackey=0D
	EMC2 Corporation=0D
	1401 Main Street, Suite 350=0D
	Columbia, SC 29201=0D
	803-231-2632=0D




SPECIAL NOTICE=0D

All information transmitted hereby is intended only for the use of the
addressee(s) named above and may contain confidential and privileged
information. Any unauthorized review, use, disclosure or distribution
of confidential and privileged information is prohibited. If the reader
of this message is not the intended recipient(s) or the employee or agent
responsible for delivering the message to the intended recipient, you are
hereby notified that you must not read this transmission and that=
 disclosure,
copying, printing, distribution or use of any of the information contained
in or attached to this transmission is STRICTLY PROHIBITED.

Anyone who receives confidential and privileged information in error should
notify us immediately by telephone and mail the original message to us at
the above address and destroy all copies.  To the extent any portion of=
 this
communication contains public information, no such restrictions apply to=
 that
information. (gate02)
------_=_NextPart_001_01C5CDB1.7076B14A
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>configuration and location mechanisms</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1515" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff size=
=3D2><SPAN=0D
class=3D693301715-10102005>Steve,</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff size=
=3D2><SPAN=0D
class=3D693301715-10102005></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff size=
=3D2><SPAN=0D
class=3D693301715-10102005>David did a good job of summarizing the=
 background of=0D
each method.</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff size=
=3D2><SPAN=0D
class=3D693301715-10102005><SPAN=0D
class=3D693301715-10102005></SPAN></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff size=
=3D2><SPAN=0D
class=3D693301715-10102005><SPAN class=3D693301715-10102005>The iSNS=
 protocol was=0D
developed to provide mechanisms for iSCSI storage management that are=
 similar to=0D
what, over time, were found to be useful for fibre channel based storage=
 area=0D
network fabrics.</SPAN></SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff size=
=3D2><SPAN=0D
class=3D693301715-10102005><SPAN=0D
class=3D693301715-10102005></SPAN></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff size=
=3D2><SPAN=0D
class=3D693301715-10102005><SPAN class=3D693301715-10102005>Regards,=0D
Kevin</SPAN></SPAN></FONT></DIV><BR>
<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=0D
[mailto:ips-bounces@ietf.org] <B>On Behalf Of=0D
</B>Black_David@emc.com<BR><B>Sent:</B> Monday, October 10, 2005 6:01=0D
AM<BR><B>To:</B> Yackey_Steve@emc.com; ips@ietf.org<BR><B>Subject:</B> RE:=
 [Ips]=0D
configuration and location mechanisms<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D337005312-10102005><FONT face=
=3D"Courier New"=0D
size=3D2>Steve,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D337005312-10102005><FONT face=
=3D"Courier New"=0D
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D337005312-10102005><FONT face=
=3D"Courier New"=0D
size=3D2>Your sense of the functionality difference between SLP and iSNS=0D
is</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D337005312-10102005><FONT face=
=3D"Courier New"=0D
size=3D2>correct, but your inference of their history is not.&nbsp; All=
 three=0D
of</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D337005312-10102005><FONT face=
=3D"Courier New"=0D
size=3D2>the iSCSI discovery (aka 'configuration and location')=0D
mechanisms,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D337005312-10102005><FONT face=
=3D"Courier New"=0D
size=3D2>Send Targets, SLP, and iSNS, were developed in parallel around=0D
the</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D337005312-10102005><FONT face=
=3D"Courier New"=0D
size=3D2>same time.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D337005312-10102005><FONT face=
=3D"Courier New"=0D
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D337005312-10102005><FONT face=
=3D"Courier New"=0D
size=3D2>The rationale for specifying both iSNS and SLP is that SLP is=0D
a</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D337005312-10102005><FONT face=
=3D"Courier New"=0D
size=3D2>discovery-only basic configuration mechanism </FONT></SPAN><SPAN=0D
class=3D337005312-10102005><FONT face=3D"Courier New" size=3D2>that reuses=
 an=0D
existing</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D337005312-10102005><FONT face=
=3D"Courier New"=0D
size=3D2>protocol (SLP) </FONT></SPAN><SPAN class=
=3D337005312-10102005><FONT=0D
face=3D"Courier New" size=3D2>and hence may involve less=
 </FONT></SPAN><SPAN=0D
class=3D337005312-10102005><FONT face=3D"Courier New" size=
=3D2>infrastructure=0D
deployment</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D337005312-10102005><FONT face=
=3D"Courier New"=0D
size=3D2>than&nbsp;iSNS's&nbsp;more comprehensive&nbsp;</FONT></SPAN><SPAN=
=0D
class=3D337005312-10102005><FONT face=3D"Courier New" size=
=3D2>functionality that=0D
</FONT></SPAN><SPAN class=3D337005312-10102005><FONT face=3D"Courier New"=0D
size=3D2>involves </FONT></SPAN><SPAN class=3D337005312-10102005><FONT=0D
face=3D"Courier New" size=3D2>a new</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D337005312-10102005><FONT face=
=3D"Courier New"=0D
size=3D2>protocol.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D337005312-10102005><FONT face=
=3D"Courier New"=0D
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D337005312-10102005><FONT face=
=3D"Courier New"=0D
size=3D2>At the moment, I believe there is more interest in iSNS than=0D
SLP,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D337005312-10102005><FONT face=
=3D"Courier New"=0D
size=3D2>but the most important factor is what the implementation(s)=0D
you</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D337005312-10102005><FONT face=
=3D"Courier New"=0D
size=3D2>want to work with support and intend to=
 support.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D337005312-10102005><FONT face=
=3D"Courier New"=0D
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D337005312-10102005><FONT face=
=3D"Courier New"=0D
size=3D2>Thanks,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D337005312-10102005><FONT face=
=3D"Courier New"=0D
size=3D2>--David</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D337005312-10102005></SPAN><SPAN=0D
class=3D337005312-10102005><SPAN lang=3Den-us><FONT face=3D"Courier New"=0D
size=3D2>----------------------------------------------------</FONT></SPAN>=
=0D
<BR><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>David L. Black,=
 Senior=0D
Technologist</FONT></SPAN> <BR><SPAN lang=3Den-us><FONT face=3D"Courier=
 New"=0D
size=3D2>EMC Corporation, 176 South St., Hopkinton, MA&nbsp;=
 01748</FONT></SPAN>=0D
<BR><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>+1 (508)=0D
293-7953&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;=0D
FAX: +1 (508) 293-7786</FONT></SPAN> <BR><SPAN lang=3Den-us><FONT=0D
face=3D"Courier New"=0D
size=3D2>black_david@emc.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 Mobile: +1=0D
(978) 394-7754</FONT></SPAN> <BR><SPAN lang=3Den-us><FONT face=3D"Courier=
 New"=0D
size=3D2>----------------------------------------------------</FONT></SPAN>=
=0D
</DIV></SPAN><BR>
<BLOCKQUOTE=0D
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 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=0D
  [mailto:ips-bounces@ietf.org] <B>On Behalf Of </B>Yackey,=0D
  Steve<BR><B>Sent:</B> Monday, October 10, 2005 8:39 AM<BR><B>To:</B>=0D
  ips@ietf.org<BR><B>Subject:</B> [Ips] configuration and location=0D
  mechanisms<BR></FONT><BR></DIV>
  <DIV></DIV><BR>
  <P><FONT face=3DVerdana color=3D#800000 size=3D2>I am trying to=
 understand where=0D
  some of the iSCSI 'configuration and location' mechanisms fit into an=
 iSCSI=0D
  deployment, including security information. Particularly, SLP and=0D
  iSNS.</FONT></P>
  <P><FONT face=3DVerdana color=3D#800000 size=3D2>It is my sense=
 that:</FONT> </P>
  <P><FONT face=3DVerdana color=3D#800000 size=3D2>- SLP is an older=
 mechanism=0D
  utilized as a means to locate targets and optionally as: a means to=
 identify=0D
  initiators allowed access; a repository of CHAP credentials. A much more=
=0D
  limited set of information than iSNS.</FONT></P>
  <P><FONT face=3DVerdana color=3D#800000 size=3D2>- iSNS, on the other=
 hand, ala=0D
  rfc4171, seems to comprehensively specify iSCSI operational configuration=
=0D
  information; target/initiator, CHAP and IPSec settings. Being more=
 complete,=0D
  iSNS would then offer the greater opportunity for interoperabiltiy among=
 iSCSI=0D
  implementations.</FONT></P>
  <P><FONT face=3DVerdana color=3D#800000 size=3D2>So in looking at these=
 two it seems=0D
  that SLP is where the industry has been; iSNS is where its going.=
 </FONT></P>
  <P><FONT face=3DVerdana color=3D#800000 size=3D2>Is this the general=
 sense of things=0D
  ??</FONT> </P>
  <P><FONT face=3DVerdana color=3D#800000 size=3D2>Thanks in=
 advance,</FONT> <BR><FONT=0D
  face=3DVerdana color=3D#800000 size=3D2>Steve</FONT> </P><BR>
  <P><FONT face=3DVerdana size=3D2>Steve Yackey</FONT> <BR><FONT face=
=3DVerdana=0D
  size=3D2>EMC<SUP>2</SUP> Corporation</FONT> <BR><FONT face=3DVerdana size=
=3D2>1401=0D
  Main Street, Suite 350</FONT> <BR><FONT face=3DVerdana size=3D2>Columbia,=
 SC=0D
  29201</FONT> <BR><FONT face=3DVerdana size=3D2>803-</FONT><FONT face=
=3DVerdana=0D
  size=3D2>231-2632</FONT> </P><BR></BLOCKQUOTE></BODY></HTML>

<table><tr><td bgcolor=3D#ffffff><font color=3D#000000>SPECIAL NOTICE <br>
<br>
All information transmitted hereby is intended only for the use of the<br>
addressee(s) named above and may contain confidential and privileged<br>
information. Any unauthorized review, use, disclosure or distribution<br>
of confidential and privileged information is prohibited. If the reader<br>
of this message is not the intended recipient(s) or the employee or=
 agent<br>
responsible for delivering the message to the intended recipient, you=
 are<br>
hereby notified that you must not read this transmission and that=
 disclosure,<br>
copying, printing, distribution or use of any of the information=
 contained<br>
in or attached to this transmission is STRICTLY PROHIBITED.<br>
<br>
Anyone who receives confidential and privileged information in error=
 should<br>
notify us immediately by telephone and mail the original message to us=
 at<br>
the above address and destroy all copies.  To the extent any portion of=
 this<br>
communication contains public information, no such restrictions apply to=
 that<br>
information. (gate02)<br>
</font></td></tr></table>
------_=_NextPart_001_01C5CDB1.7076B14A--


--===============0452700808==
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

--===============0452700808==--




From ips-bounces@ietf.org Tue Oct 11 10:50:39 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EPLSh-0003Ji-E7; Tue, 11 Oct 2005 10:50:39 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EPLS7-00037T-Ns; Tue, 11 Oct 2005 10:50:03 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29265;
	Tue, 11 Oct 2005 10:50:00 -0400 (EDT)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EPLcE-0002w9-63; Tue, 11 Oct 2005 11:00:31 -0400
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1EPLS5-0005d5-Gg; Tue, 11 Oct 2005 10:50:01 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1EPLS5-0005d5-Gg@newodin.ietf.org>
Date: Tue, 11 Oct 2005 10:50:01 -0400
X-Spam-Score: 0.4 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Cc: ips@ietf.org
Subject: [Ips] I-D ACTION:draft-ietf-ips-iscsi-mib-11.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 iSCSI
	Author(s)	: M. Bakke, et al.
	Filename	: draft-ietf-ips-iscsi-mib-11.txt
	Pages		: 83
	Date		: 2005-10-11
	
This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in TCP/IP based internets.
   In particular it defines objects for managing a client using the
   iSCSI (SCSI over TCP) protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-mib-11.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-iscsi-mib-11.txt".

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


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

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ips-iscsi-mib-11.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: <2005-10-11101934.I-D@ietf.org>

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

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

Content-Type: text/plain
Content-ID: <2005-10-11101934.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 Tue Oct 11 11:50:36 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EPMOi-0002pX-14; Tue, 11 Oct 2005 11:50:36 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EPMOg-0002pC-HH
	for ips@megatron.ietf.org; Tue, 11 Oct 2005 11:50:34 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10672
	for <ips@ietf.org>; Tue, 11 Oct 2005 11:50:31 -0400 (EDT)
From: Black_David@emc.com
Received: from mailhub.lss.emc.com ([168.159.2.31])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPMYm-0007ZT-Nk
	for ips@ietf.org; Tue, 11 Oct 2005 12:01:03 -0400
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.6) with ESMTP id
	j9BFoLQv024086
	for <ips@ietf.org>; Tue, 11 Oct 2005 11:50:29 -0400 (EDT)
Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19)
	id <RT6A691A>; Tue, 11 Oct 2005 11:49:24 -0400
Message-ID: <F222151D3323874393F83102D614E0557A6FBA@CORPUSMX20A.corp.emc.com>
To: ips@ietf.org
Date: Tue, 11 Oct 2005 11:49:08 -0400
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: 2005.10.11.16
X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, EMC_FROM_00+ -3,
	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: 0fa76816851382eb71b0a882ccdc29ac
Subject: [Ips] Internet-Draft announcements
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

If you work for Emulex or Maxtor, you're not receiving
Internet-Draft announcements, because your email server has
decided that URL attachments are not allowed, and is sending
an annoying message back to the IETF (see below).  Would
someone at Emulex and Maxtor please enlighten the appropriate
email administrators?

Also, for anyone else who's not getting Internet-Draft
announcements, this is a possible reason why - some clueless
email filter may have decided that URL attachments are
possible threats ... and is helpfully bit-bucketing them
for you ...

FYI,
--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: PostMaster@Emulex.Com [mailto:PostMaster@Emulex.Com] 
Sent: Tuesday, October 11, 2005 11:16 AM
To: ips-bounces@ietf.org
Subject: [MailServer Notification]To Sender file blocking settings matched
and action taken.

ScanMail for Microsoft Exchange has blocked an attachment.

Sender = ips-bounces@ietf.org
Recipient(s) = i-d-announce@ietf.org; ips@ietf.org
Subject = [Ips] I-D ACTION:draft-ietf-ips-iscsi-mib-11.txt 
Scanning time = 10/11/2005 11:15:38 AM

Action on file blocking:
The attachment draft-ietf-ips-iscsi-mib-11.URL matches the file blocking
settings. ScanMail has Quarantined it.  The attachment was quarantined to
C:\Program
Files\Trend\Smex\Alert\draft-ietf-ips-iscsi-mib-11434bd71a14.URL_.

An attachment was sent by your address that violates Emulex Corporation's
e-mail security policy regarding attachments.
The attachment was removed and will not be delivered.
	
Restricted attachment file types include: 
Exe, vbs, shs, js, bat, com, ade, adp, bas, chm, cmd, cpl, crt, hlp, hta,
inf, ins, isp, jse, lnk, mdb, mde, msc, msi, msp, mst, pcd, pif, reg, scr,
sct, shb, shs, url, vb, vbe, wsc, wsf, wsh

To send your business related attachment into Emulex Corporation:
Please compress the file into a .ZIP archive before sending.  You may use
WinZip or another comparable program.

Possible Reasons For You Receiving This Notification (If Email Was Not Sent
By You.):
 - Your computer has been infected by a virus.
 - Someone else's computer whom you correspond with has been infected by a
virus and is now using your address, without your knowledge or consent.
   
Please send questions to postmaster@Emulex.com.  

-----Original Message-----
From: PureMessage Admin [mailto:pmx4_admin@maxtor.com] 
Sent: Tuesday, October 11, 2005 11:25 AM
Subject: Maxtor Attachment Policy Violation 

Due to viruses and malicious code found in email attachments your email was
blocked. Maxtor does not accept the transfer of files or attachments that do
not meet Maxtor's acceptable attachment policy. For example: ZIP, EXE, SCR,
COM, BAT, VBS, RAR, CMD, PIF, etc...

Maxtor does accept some ZIP attachments that meet certain criteria. For more
information please call or email your Maxtor contact.

PureMessage Admin <pmx4_admin@maxtor.com>

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



From ips-bounces@ietf.org Tue Oct 11 12:06:05 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EPMdh-0006W6-U3; Tue, 11 Oct 2005 12:06:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EPMdh-0006W0-28
	for ips@megatron.ietf.org; Tue, 11 Oct 2005 12:06:05 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11522
	for <ips@ietf.org>; Tue, 11 Oct 2005 12:06:02 -0400 (EDT)
From: Black_David@emc.com
Received: from mailhub.lss.emc.com ([168.159.2.31])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPMnp-00081U-Iz
	for ips@ietf.org; Tue, 11 Oct 2005 12:16:33 -0400
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.6) with ESMTP id
	j9BG5t8L027642
	for <ips@ietf.org>; Tue, 11 Oct 2005 12:05:58 -0400 (EDT)
Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19)
	id <RT6A7ACH>; Tue, 11 Oct 2005 12:05:50 -0400
Message-ID: <F222151D3323874393F83102D614E0557A6FBB@CORPUSMX20A.corp.emc.com>
To: ips@ietf.org
Date: Tue, 11 Oct 2005 12:05:46 -0400
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: 2005.10.11.16
X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, EMC_FROM_00+ -3,
	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: 5d7a7e767f20255fce80fa0b77fb2433
Subject: [Ips] IPS WG Last Call Complete: iSER revisions
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

First of all, this message announces the conclusion of the WG Last
Call on the iSER changes to support non-iWARP RDMA transports,
such as InfiniBand.  I have a number of editorial changes below
that will require further editing, but not another WG Last Call.

Also, the proposed editing changes to iSER introduced some
technical changes:
- RDMA Read after an RDMA Write on the same stream must be
	strictly ordered by the RDMA protocol.  (Section 4.1,
	3rd item)
- Generalization of login phase description to allow use of
	a non-byte-stream messaging protocol. (Section 4.1, next
	to last item, and a few other places).
- Failure to negotiate iSER may cause connection close in
	order to restart traditional iSCSI over TCP/IP (Section
	5.1, end of 2nd paragraph).
While I believe all of these changes have been discussed in
the past, for process purposes, as WG chair, I believe that
it is the rough consensus of the IP Storage WG that these
technical changes should be made to the iSER draft.  See:
http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iser-05_candidate.txt

Anyone who disagrees needs to post to the list ASAP with a
technical rationale for their disagreement.

On to the editorial changes that are needed:

-- (1) Motivation text has a gap --

The generalization of the iSER text to support InfiniBand
has exposed a problem in the Motivation section (2.1) of
the iSER draft - the discussion jumps from SNIC to generic
RDMA capable controller without explaining why.  To address
this, the following text:

   With these defined techniques in [RFC3720], a Network Interface
   Controller customized for iSCSI (SNIC) could offload the TCP/IP
   processing and support direct data placement.

   Supporting direct data placement is the main function of an
   RDMA Capable Protocol (RCP).

should be changed to:

   With these defined techniques in [RFC3720], a Network Interface
   Controller customized for iSCSI (SNIC) could offload the TCP/IP
   processing and support direct data placement, but most iSCSI
   implementations do not support iSCSI "markers", making SNIC
   marker-based direct data placement unusable in practice.

   The iWARP protocol stack provides direct data placement functionality
   that is usable in practice, and in addition, there is also interest
   in using iSCSI with other RDMA protocol stacks that support direct
   data placement, such as the one provided by InfiniBand.  The generic
   term RDMA-Capable Protocol is used to refer to the RDMA functionality
   provided by such protocol stacks.

-- (2) RCP acronym is a problem --

While the acronym RCP for RDMA-Capable Protocol is correct, it
detracts from readability.  A lot of people will initially
mis-read it as the Unix remote copy utility (e.g., see item 6. in
Section 2.2, Architectural Goals).  The generic term "RDMA" should
be substituted for "RCP" in phrases such as "RDMA functionality",
"RDMA messages", "RDMA services", "RDMA layer" etc. to eliminate
the RCP acronym, or at least greatly reduce its use.

-- (3) RDMA Capable Protocol needs to be generic ---

There are several issues here, all of which revolve around the fact
that RDMA Capable Protocols are not specified by iSER, and the iSER
draft needs to accommodate new ones that haven't been designed, yet.

- Section 2.3, item 6.  Change "RCP guarantees data integrity." to
"The RCP MUST ensure data integrity." or "The RCP is responsible for
ensuring data integrity."  This draft does not specify any RCP.

Section 5.1, top of p.33.  Same problem: "RCP provides error detection
based on 32-bit CRC for all iSER Messages."  This needs to be generalized
to say that the RCP MUST or is responsible for providing error detection
that is at least as good as a 32-bit CRC.

RCP or whatever wording replaces it needs to be generic - go over the
draft and pretend that there was an RDMA over carrier pigeon protocol
and make sure that none of the wording would need to change to support
trying to run iSER over that ... well, maybe not RDMA over carrier pigeon,
but perhaps something like RDMA over MPEG (not as ridiculous as it
sounds, as MPEG is the link format for some satellite links).

-- (4) Other minor stuff --

The text describing InfiniBand seems to be ok, even the use of
InfiniBand in Figure 1.  Section 14.4 comes closest to the line,
but it's probably ok.

Section 7.3.9 needs to explain the else case for "If the underlying
transport is TCP,"  The byte-stream requirement is applicable only
to TCP, but the location of this phrase at the start of this section
could make the entire paragraph or section applicable only to TCP.
The other places that use this phrasing don't appear to have analogous
problems, but should be double-checked.

Delete the [VERBS] reference, as that draft has expired and will
not become an RFC.  If that's not acceptable, reference an RDMAC
verbs draft in a publicly available place.

-- Next Step --

The iSER authors should prepare and submit a -05 draft in accordance
with the above guidance (including the rough consensus of the RDDP WG
on the technical changes).  Please make sure the draft passes the
draft checker at http://tools.ietf.org/tools/idnits/idnits.pyht
before submitting.

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 Tue Oct 11 14:30:09 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EPOt7-0002ee-FI; Tue, 11 Oct 2005 14:30:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EPOt5-0002eS-Dg
	for ips@megatron.ietf.org; Tue, 11 Oct 2005 14:30:07 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20450
	for <ips@ietf.org>; Tue, 11 Oct 2005 14:30:05 -0400 (EDT)
Received: from palrel10.hp.com ([156.153.255.245])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPP3E-0003wO-NX
	for ips@ietf.org; Tue, 11 Oct 2005 14:40:37 -0400
Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160])
	by palrel10.hp.com (Postfix) with ESMTP id 5B9E71C55
	for <ips@ietf.org>; Tue, 11 Oct 2005 11:28:58 -0700 (PDT)
Received: from [127.0.0.1] (sindhu.americas.hpqcorp.net [16.93.44.172])
	by rosemail.rose.hp.com (Postfix) with ESMTP id C1A938050
	for <ips@ietf.org>; Tue, 11 Oct 2005 11:17:02 -0700 (PDT)
Message-ID: <434C0468.1060705@rose.hp.com>
Date: Tue, 11 Oct 2005 11:28:56 -0700
From: "Mallikarjun C." <cbm@rose.hp.com>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ips@ietf.org
Subject: Re: [Ips] IPS WG Last Call Complete: iSER revisions
References: <F222151D3323874393F83102D614E0557A6FBB@CORPUSMX20A.corp.emc.com>
In-Reply-To: <F222151D3323874393F83102D614E0557A6FBB@CORPUSMX20A.corp.emc.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f
Content-Transfer-Encoding: 7bit
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

 > While the acronym RCP for RDMA-Capable Protocol is correct, it
 > detracts from readability.  A lot of people will initially
 > mis-read it as the Unix remote copy utility (e.g., see item 6. in
 > Section 2.2, Architectural Goals).  The generic term "RDMA" should
 > be substituted for "RCP" in phrases such as "RDMA functionality",
 > "RDMA messages", "RDMA services", "RDMA layer" etc. to eliminate
 > the RCP acronym, or at least greatly reduce its use.

I suggest considering "RCAP" as an alterantive in that case.

I have some concern with a generic "RDMA" substitution because such a 
usage doesn't distinguish the "iSER-required" (as defined in section 
4.1) RCAP protocol stack from the general RDMA concept.  And "RDMA" 
itself is a sufficiently general term that doesn't lend itself to 
redefinition in the iSER draft.

Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
StorageWorks Division
Hewlett-Packard MS 5668
Roseville CA 95747
cbm [at] rose.hp.com


Black_David@emc.com wrote:
> First of all, this message announces the conclusion of the WG Last
> Call on the iSER changes to support non-iWARP RDMA transports,
> such as InfiniBand.  I have a number of editorial changes below
> that will require further editing, but not another WG Last Call.
> 
> Also, the proposed editing changes to iSER introduced some
> technical changes:
> - RDMA Read after an RDMA Write on the same stream must be
> 	strictly ordered by the RDMA protocol.  (Section 4.1,
> 	3rd item)
> - Generalization of login phase description to allow use of
> 	a non-byte-stream messaging protocol. (Section 4.1, next
> 	to last item, and a few other places).
> - Failure to negotiate iSER may cause connection close in
> 	order to restart traditional iSCSI over TCP/IP (Section
> 	5.1, end of 2nd paragraph).
> While I believe all of these changes have been discussed in
> the past, for process purposes, as WG chair, I believe that
> it is the rough consensus of the IP Storage WG that these
> technical changes should be made to the iSER draft.  See:
> http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iser-05_candidate.txt
> 
> Anyone who disagrees needs to post to the list ASAP with a
> technical rationale for their disagreement.
> 
> On to the editorial changes that are needed:
> 
> -- (1) Motivation text has a gap --
> 
> The generalization of the iSER text to support InfiniBand
> has exposed a problem in the Motivation section (2.1) of
> the iSER draft - the discussion jumps from SNIC to generic
> RDMA capable controller without explaining why.  To address
> this, the following text:
> 
>    With these defined techniques in [RFC3720], a Network Interface
>    Controller customized for iSCSI (SNIC) could offload the TCP/IP
>    processing and support direct data placement.
> 
>    Supporting direct data placement is the main function of an
>    RDMA Capable Protocol (RCP).
> 
> should be changed to:
> 
>    With these defined techniques in [RFC3720], a Network Interface
>    Controller customized for iSCSI (SNIC) could offload the TCP/IP
>    processing and support direct data placement, but most iSCSI
>    implementations do not support iSCSI "markers", making SNIC
>    marker-based direct data placement unusable in practice.
> 
>    The iWARP protocol stack provides direct data placement functionality
>    that is usable in practice, and in addition, there is also interest
>    in using iSCSI with other RDMA protocol stacks that support direct
>    data placement, such as the one provided by InfiniBand.  The generic
>    term RDMA-Capable Protocol is used to refer to the RDMA functionality
>    provided by such protocol stacks.
> 
> -- (2) RCP acronym is a problem --
> 
> While the acronym RCP for RDMA-Capable Protocol is correct, it
> detracts from readability.  A lot of people will initially
> mis-read it as the Unix remote copy utility (e.g., see item 6. in
> Section 2.2, Architectural Goals).  The generic term "RDMA" should
> be substituted for "RCP" in phrases such as "RDMA functionality",
> "RDMA messages", "RDMA services", "RDMA layer" etc. to eliminate
> the RCP acronym, or at least greatly reduce its use.
> 
> -- (3) RDMA Capable Protocol needs to be generic ---
> 
> There are several issues here, all of which revolve around the fact
> that RDMA Capable Protocols are not specified by iSER, and the iSER
> draft needs to accommodate new ones that haven't been designed, yet.
> 
> - Section 2.3, item 6.  Change "RCP guarantees data integrity." to
> "The RCP MUST ensure data integrity." or "The RCP is responsible for
> ensuring data integrity."  This draft does not specify any RCP.
> 
> Section 5.1, top of p.33.  Same problem: "RCP provides error detection
> based on 32-bit CRC for all iSER Messages."  This needs to be generalized
> to say that the RCP MUST or is responsible for providing error detection
> that is at least as good as a 32-bit CRC.
> 
> RCP or whatever wording replaces it needs to be generic - go over the
> draft and pretend that there was an RDMA over carrier pigeon protocol
> and make sure that none of the wording would need to change to support
> trying to run iSER over that ... well, maybe not RDMA over carrier pigeon,
> but perhaps something like RDMA over MPEG (not as ridiculous as it
> sounds, as MPEG is the link format for some satellite links).
> 
> -- (4) Other minor stuff --
> 
> The text describing InfiniBand seems to be ok, even the use of
> InfiniBand in Figure 1.  Section 14.4 comes closest to the line,
> but it's probably ok.
> 
> Section 7.3.9 needs to explain the else case for "If the underlying
> transport is TCP,"  The byte-stream requirement is applicable only
> to TCP, but the location of this phrase at the start of this section
> could make the entire paragraph or section applicable only to TCP.
> The other places that use this phrasing don't appear to have analogous
> problems, but should be double-checked.
> 
> Delete the [VERBS] reference, as that draft has expired and will
> not become an RFC.  If that's not acceptable, reference an RDMAC
> verbs draft in a publicly available place.
> 
> -- Next Step --
> 
> The iSER authors should prepare and submit a -05 draft in accordance
> with the above guidance (including the rough consensus of the RDDP WG
> on the technical changes).  Please make sure the draft passes the
> draft checker at http://tools.ietf.org/tools/idnits/idnits.pyht
> before submitting.
> 
> 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 Oct 11 15:43:05 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EPQ1h-0008Nx-39; Tue, 11 Oct 2005 15:43:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EPQ1f-0008NR-Hn
	for ips@megatron.ietf.org; Tue, 11 Oct 2005 15:43:03 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24706
	for <ips@ietf.org>; Tue, 11 Oct 2005 15:43:01 -0400 (EDT)
From: Black_David@emc.com
Received: from mailhub.lss.emc.com ([168.159.2.31])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPQBp-0005y7-1p
	for ips@ietf.org; Tue, 11 Oct 2005 15:53:34 -0400
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.6) with ESMTP id
	j9BJgtup020394; Tue, 11 Oct 2005 15:42:56 -0400 (EDT)
Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19)
	id <RT6A7V4G>; Tue, 11 Oct 2005 15:42:55 -0400
Message-ID: <F222151D3323874393F83102D614E0557A6FC9@CORPUSMX20A.corp.emc.com>
To: cbm@rose.hp.com, ips@ietf.org
Subject: RE: [Ips] IPS WG Last Call Complete: iSER revisions
Date: Tue, 11 Oct 2005 15:42:45 -0400
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: 2005.10.11.22
X-PerlMx-Spam: Gauge=, SPAM=1%, Reasons='EMC_FROM_00+ -3, EMC_BODY_1+ -1,
	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: bb8f917bb6b8da28fc948aeffb74aa17
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 think this may make for a sensible approach, specifically for every
current use of RCP:
- Determine if the reference really needs to be to an RDMA protocol
	stack.  Use RCAP if that's the case (e.g., to express iSER
	requirements on an RDMA protocol stack that it uses).
- Else use the generic RDMA acronym.
RCAP is definitely better than RCP, but where it can be validly
used, RDMA is superior to both.

>  > While the acronym RCP for RDMA-Capable Protocol is correct, it
>  > detracts from readability.  A lot of people will initially
>  > mis-read it as the Unix remote copy utility (e.g., see item 6. in
>  > Section 2.2, Architectural Goals).  The generic term "RDMA" should
>  > be substituted for "RCP" in phrases such as "RDMA functionality",
>  > "RDMA messages", "RDMA services", "RDMA layer" etc. to eliminate
>  > the RCP acronym, or at least greatly reduce its use.
> 
> I suggest considering "RCAP" as an alternative in that case.
> 
> I have some concern with a generic "RDMA" substitution because such a 
> usage doesn't distinguish the "iSER-required" (as defined in section 
> 4.1) RCAP protocol stack from the general RDMA concept.  And "RDMA" 
> itself is a sufficiently general term that doesn't lend itself to 
> redefinition in the iSER draft.
> 
> Mallikarjun

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 Oct 14 15:50:39 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EQVZf-0005bn-25; Fri, 14 Oct 2005 15:50:39 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EQVZ6-0005Oh-MZ; Fri, 14 Oct 2005 15:50:05 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07112;
	Fri, 14 Oct 2005 15:49:58 -0400 (EDT)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1EQVjq-0007n0-QY; Fri, 14 Oct 2005 16:01:11 -0400
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1EQVZ3-0000lF-Kz; Fri, 14 Oct 2005 15:50:01 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1EQVZ3-0000lF-Kz@newodin.ietf.org>
Date: Fri, 14 Oct 2005 15:50:01 -0400
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Cc: ips@ietf.org
Subject: [Ips] I-D ACTION:draft-ietf-ips-fcip-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 FCIP
	Author(s)	: R. Natarajan, A. Rijhsinghani
	Filename	: draft-ietf-ips-fcip-mib-08.txt
	Pages		: 31
	Date		: 2005-10-14
	
This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in TCP/IP based internets.
   In particular it defines objects for managing FCIP entities, which
   are used to interconnect FC fabrics with IP networks.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ips-fcip-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-fcip-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-fcip-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: <2005-10-14104256.I-D@ietf.org>

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

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

Content-Type: text/plain
Content-ID: <2005-10-14104256.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 Sun Oct 16 21:03:08 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERJPA-00044j-MZ; Sun, 16 Oct 2005 21:03:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ERJP9-00044K-64
	for ips@megatron.ietf.org; Sun, 16 Oct 2005 21:03:07 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05956
	for <ips@ietf.org>; Sun, 16 Oct 2005 21:03:00 -0400 (EDT)
Received: from ihemail2.lucent.com ([192.11.222.163])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERJaN-0003BH-Ci
	for ips@ietf.org; Sun, 16 Oct 2005 21:14:43 -0400
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com
	[135.85.76.62])
	by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j9H12su2022448; 
	Sun, 16 Oct 2005 20:02:54 -0500 (CDT)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service
	(5.5.2657.72) id <SQW8XYBJ>; Mon, 17 Oct 2005 03:02:53 +0200
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550856815D@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: Black_David@emc.com
Date: Mon, 17 Oct 2005 03:02:53 +0200
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: 33cc095b503da4365ce57c727e553cf1
Cc: "Ipswg \(E-mail\)" <ips@ietf.org>, mankin@psg.com
Subject: [Ips] MIB Doctor reviews for: draft-ietf-ips-scsi-mib-07.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

Blush... I am really kind of ashamed to often take so long on
the review of these MIB documents. But at the other hand, we as
MIB doctors have quite a few coming at us over the last year,
and the MIB doctors are less eager as a year ago (to say it
nicely).

Oh well, here we go.

------- Compilation/synax issues:

    C:\bwijnen\smicng\work>smicng scsi.inc
    W: f(scsi.mi2), (69,19) The first revision should match the
       last update for MODULE-IDENTITY scsiMIB
    *** 0 errors and 1 warning in parsing

  easy to fix. And I guess you want to use a more current date
  anyways.

------- More or less serious concerns:

- scsiInstAlias
  I would like to see (in DESCIPTION clause) what the persistency 
  behaviour is of this read-write object. Further, it is unclear to
  me what this means:
       After reset, the value of this object should remain unchanged."
  What is a "reset"?

  Same for scsiInstScsiNotificationsEnable

  And probably so for other read-write and read-create objects
  in this MIB Module. Pls check them all.

------- I wonder about:

- The  ScsiIdentifier ::= TEXTUAL-CONVENTION
       DISPLAY-HINT  "223a"
  Is that 223a valif? I doubt it given the DESCRIPTION clause.
  Or maybe I do not understand that description clause well enough?
  I am confused by 223a while the max length is 262.
  I am confused by 223a, because it does not look like the octets
  are guaranteed to be ascii (or are they?)

- Same fo ScsiName

- I am a bit surprised by the ScsiName to be (0-262) length and
  ScsiNameIdOrZero to be (0 | 8) length. It looks like ScsiName is
  diffferent than ScsiNameId (which is not defined). I guess it
  is OK, but I can't say it is very crisp and clear.

- I think I would not do:
    scsiAdmin      OBJECT IDENTIFIER ::= { scsiMIB  1 }
    scsiObjects       OBJECT IDENTIFIER ::= { scsiMIB  2 }
    scsiNotifications OBJECT IDENTIFIER ::= { scsiMIB  3 }
    scsiConformance   OBJECT IDENTIFIER ::= { scsiMIB  4 }
    scsiNotificationsPrefix OBJECT IDENTIFIER ::= { scsiNotifications 0 }
  but instead
    scsiNotifications OBJECT IDENTIFIER ::= { scsiMIB  0 }
    scsiAdmin         OBJECT IDENTIFIER ::= { scsiMIB  1 }
    scsiObjects       OBJECT IDENTIFIER ::= { scsiMIB  2 }
    scsiConformance   OBJECT IDENTIFIER ::= { scsiMIB  4 }

- I see:
    scsiDeviceTable  OBJECT-TYPE
      SYNTAX           SEQUENCE OF ScsiDeviceEntry
      MAX-ACCESS       not-accessible
      STATUS           current
      DESCRIPTION
        "A list of SCSI Devices contained in each instance this agent is
        reporting."
  Is it indeed in "each instance"? The way I read that it means that one
  device is (must be?) contained in each instance. 
  Or did you mean "contained in an instance" ??
  I guess my ignorance of SCSI implementations shows.

- I really wonder why you use scsiTrnsptTable and why you do not
  use scsiTransportTable instead. It makes it so much clearer.
  In fact I do wonder so about all the abbreviations you use in
  the MIB module.

------- nits:

- abstract states:

   This memo defines a Management Information Base (MIB), namely managed
   objects for Small Computer System Interface (SCSI) entities,
   independently of the interconnect subsystem layer.

  while its is only a portion of the MIB (we have only one MIB composed
  of many MIB modules). The way we normally express that is:

   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.

- it seems to me that the 2nd para in section 1 is redundant (all of that
  is also in the 3rd pare) and so I would remove 2nd para.

- When you use text (like on page 5)
     "... SCSI-related MIBs."
  I would rather see:
     "... SCSI-related MIB modules."
  This to express that we have a single MIB which is composed of many
  MIB modules. I am not too much hung up on it. You may want to check
  for consistency. Sometimes you nicely use MIB Module, other times not.
  I have by the way no issue if you use "MIB" in the figure.

- I think I would use "TCP-MIB" (the real module name) instead of "TCP MIB"
  i.e. add a hyphen. You may want to check several other MIB module names
  for such consistency of use of MIB names too.

- You may want to update the copyright in the MODULE DESCRIPTION clause
  to be for 2005. Honestly, I believe/hope we can approve this doc this 
  year!

- Please add an IANA considerations section

- I would move sect 11 into an appendix (I think).
  I also wonder why you do:
        Note that "-NA-" means zero-length string.
  While I would think that a notation of "" would work fine.

  Note that I have not checked the example in detail.

------- for completeness (for you to check/evaluate):

  $ idnits draft-ietf-ips-scsi-mib-07.txt
  idnits 1.77 (21 Aug 2005)

  draft-ietf-ips-scsi-mib-07.txt:


  Checking nits according to http://www.ietf.org/ID-Checklist.html:
  * The document seems to lack an IANA Considerations section.
  * Looks like you're using RFC 2026 boilerplate. Better change to RFC
    3978/3979.

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
  - It seems as if not all pages are separated by form feeds - found 0 form
    feeds but 81 pages

  Miscellaneous warnings:
  - Line 3328 has weird spacing: '...ntation  is ru...'
  - Line 3642 has weird spacing: '...sEnable  true...'

    Run idnits with the --verbose option for more detailed information.

------- for completeness, for you to evaluate:

  !! Missing citation for Normative reference:
     P078 L008:    [RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "Architecture


  RFC2012 has been obsoleted by RFC4022. You may want to update your ref/citations.
Bert
> -----Original Message-----
> From: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Tuesday, October 11, 2005 21:00
> To: bwijnen@lucent.com
> Cc: mankin@psg.com; Black_David@emc.com
> Subject: SCSI MIB re-review comments
> Importance: High
> 
> 
> Bert,
> 
> I'm still looking for your MIB Doctor expert (re)-review
> comments on the IP Storage SCSI MIB:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-ips-scsi-mib-07.txt
> 
> I may be out of runway to get a revised draft prior to
> the Vancouver IETF (I think you were originally going
> to re-review this a month ago), so would it make sense to
> send this MIB to IETF Last Call, and deal with any re-review
> comments from you as IETF Last Call comments?
> 
> Thanks,
> --David

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



From ips-bounces@ietf.org Sun Oct 16 22:01:56 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERKK4-00033o-Or; Sun, 16 Oct 2005 22:01:56 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ERKK3-00033h-EN
	for ips@megatron.ietf.org; Sun, 16 Oct 2005 22:01:55 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07867
	for <ips@ietf.org>; Sun, 16 Oct 2005 22:01:48 -0400 (EDT)
Received: from ihemail2.lucent.com ([192.11.222.163])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERKVI-0004L2-5E
	for ips@ietf.org; Sun, 16 Oct 2005 22:13:32 -0400
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com
	[135.85.76.62])
	by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j9H21fLB017668; 
	Sun, 16 Oct 2005 21:01:42 -0500 (CDT)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service
	(5.5.2657.72) id <SQW8XYHD>; Mon, 17 Oct 2005 04:01:41 +0200
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15508568167@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: "'ravin@lightsand.com'" <ravin@lightsand.com>
Date: Mon, 17 Oct 2005 04:01:38 +0200
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: e8a67952aa972b528dd04570d58ad8fe
Cc: "'Ipswg \(E-mail\)'" <ips@ietf.org>
Subject: [Ips] MIB Doctor review: draft-ietf-ips-fcip-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

OK, I have re-checked the new revision (08) of this document.

Here are my findings:

When you revise a MIB module, then both the LAST-UPDATED
and REVISION clauses must be kept in sync.

  C:\bwijnen\smicng\work>smicng fcip.inc
  W: f(fcip.mi2), (39,21) The first revision should match the
     last update for MODULE-IDENTITY fcipMIB


There still seem to be citation/reference issues:

  !! Missing citation for Normative reference:
  P029 L052: [FC-SW-3]   Fibre Channel Switch Fabric -3 (FC-SW-3), T11/03-018v4,

I see it is used in a REFERENCE clause in the MIB
See below at problem with RFC2571

  !! Missing citation for Normative reference:
  P030 L030: [RFC2474]   Nichols, K., Blake, S., Baker, F., and D. Black, "Definition

  !! Missing citation for Normative reference:
  P030 L018: [RFC2571]   Harrington, D., Presuhn, R., and B. Wijnen, "An

RFC2571 has been obsoleted by the way by RFC3411.
I think you IMPORT from RFC3411
Further your IMPORT from RFC4001, which causes a normative reference
that I am missing.

Normally you add some text just before the MIB module starts aka

  The following MIB modules has IMPORTS from [RFC3411] and [RFC4001]
  and refers  to [FC-SW-3] in REFERENCE clauses.


Below is my revision 7 review, and I am commenting on the ones that
have (as far as I can tell) not been addressed yet:

Following has not been addressed.
> - Table fcipLinkErrorsTable contains a lot of Counter32 columns. 
>   Each of the DESCRIPTION clauses is supposed to describe if there
>   can be discontinuity situations, and if so, which timer is to
>   be used to detect that.
> 
I know Keith has some disagreement with me, but I prefer that
it is made clear to the readers/implementors as to do/expect.
At least I'd like to see in the Table or Entry DESCRIPTION clause
that all counters have "xxx as discontinuity indicator"

> - I think the Security COnsiderations section is weak.
>   It lists sensitive objects, but it does not describe much about
>   why they are sensitive and what kind of damage can happen if 
>   improperly changed.
>   The security guidelines on www.ops.ietf.org  explains how it
>   should be done in an acceptable manenr
> 

I don't think I see any change to the security considerations.
Oh well... we'll see what security ADs will have to day about it.

Bert

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



From ips-bounces@ietf.org Mon Oct 17 11:30:31 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERWwZ-0004YS-7Y; Mon, 17 Oct 2005 11:30:31 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ERWwX-0004YL-Eo
	for ips@megatron.ietf.org; Mon, 17 Oct 2005 11:30:29 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19427
	for <ips@ietf.org>; Mon, 17 Oct 2005 11:30:21 -0400 (EDT)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1ERX7t-0001Mi-Ff for ips@ietf.org; Mon, 17 Oct 2005 11:42:13 -0400
Received: from sj-core-5.cisco.com ([171.71.177.238])
	by sj-iport-2.cisco.com with ESMTP; 17 Oct 2005 08:30:20 -0700
Received: from cisco.com (cypher.cisco.com [171.69.11.142])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9HFUI94001643;
	Mon, 17 Oct 2005 08:30:18 -0700 (PDT)
Received: (from kzm@localhost)
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA01438;
	Mon, 17 Oct 2005 08:30:18 -0700 (PDT)
From: Keith McCloghrie <kzm@cisco.com>
Message-Id: <200510171530.IAA01438@cisco.com>
Subject: [Ips] MIB Doctor review: draft-ietf-ips-fcip-mib-08.txt (fwd)
To: bwijnen@lucent.com
Date: Mon, 17 Oct 2005 08:30:18 -0700 (PDT)
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: ff03b0075c3fc728d7d60a15b4ee1ad2
Content-Transfer-Encoding: 7bit
Cc: ips@ietf.org, anil@charter.net, ravin@lightsand.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

Bert,

You mention several nits which can be fixed by minor edits.  You also
point out this issue:

> > - Table fcipLinkErrorsTable contains a lot of Counter32 columns.
> >   Each of the DESCRIPTION clauses is supposed to describe if there
> >   can be discontinuity situations, and if so, which timer is to
> >   be used to detect that.
>
> I know Keith has some disagreement with me, but I prefer that
> it is made clear to the readers/implementors as to do/expect.
> At least I'd like to see in the Table or Entry DESCRIPTION clause
> that all counters have "xxx as discontinuity indicator"

In reviewing the issue for this particular MIB, I do agree with you
because the Counter32's are in a table INDEX-ed by fcipLinkIndex, and
the values of fcipLinkIndex are controlled by fcipLinkStatus which has
a syntax of RowStatus.  Thus, there is a potential for the re-use of a
previously-used value of fcipLinkIndex to apply to a different link.
So, these counters definitely need a discontinuity timestamp. 
I suggest a xxxCreateTime object needs be added in the fcipLinkTable,
e.g.,:

    fcipLinkCreateTime OBJECT-TYPE
        SYNTAX      TimeStamp
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
               "The value of sysUpTime when this entry was last created."
        ::= { fcipLinkEntry 12 }

so that each of the DESCRIPTIONs for the Counter32's in the
fcipLinkErrorsTable can include this sentence:

           The last discontinuity of this counter is indicated by
           fcipLinkCreateTime.

(and TimeStamp will need to be IMPORTed from SNMPv2-TC.)

My apologies to Anil & Ravi that I didn't catch this earlier.
Also, while the document is being updated, can I suggest that the Authors'
Addresses section be checked to ensure it has correct email addresses.

Keith.
-------------
Forwarded message:
> From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
> Date: Mon, 17 Oct 2005 04:01:38 +0200
> To: "'ravin@lightsand.com'" <ravin@lightsand.com>
> Cc: "'Ipswg \(E-mail\)'" <ips@ietf.org>
> Subject: [Ips] MIB Doctor review: draft-ietf-ips-fcip-mib-08.txt
> Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15508568167@nl0006exch001u.nl.lucent.com>
> 
> OK, I have re-checked the new revision (08) of this document.
> 
> Here are my findings:
> 
> When you revise a MIB module, then both the LAST-UPDATED
> and REVISION clauses must be kept in sync.
> 
>   C:\bwijnen\smicng\work>smicng fcip.inc
>   W: f(fcip.mi2), (39,21) The first revision should match the
>      last update for MODULE-IDENTITY fcipMIB
> 
> 
> There still seem to be citation/reference issues:
> 
>   !! Missing citation for Normative reference:
>   P029 L052: [FC-SW-3]   Fibre Channel Switch Fabric -3 (FC-SW-3), T11/03-018v4,
> 
> I see it is used in a REFERENCE clause in the MIB
> See below at problem with RFC2571
> 
>   !! Missing citation for Normative reference:
>   P030 L030: [RFC2474]   Nichols, K., Blake, S., Baker, F., and D. Black, "Definition
> 
>   !! Missing citation for Normative reference:
>   P030 L018: [RFC2571]   Harrington, D., Presuhn, R., and B. Wijnen, "An
> 
> RFC2571 has been obsoleted by the way by RFC3411.
> I think you IMPORT from RFC3411
> Further your IMPORT from RFC4001, which causes a normative reference
> that I am missing.
> 
> Normally you add some text just before the MIB module starts aka
> 
>   The following MIB modules has IMPORTS from [RFC3411] and [RFC4001]
>   and refers  to [FC-SW-3] in REFERENCE clauses.
> 
> 
> Below is my revision 7 review, and I am commenting on the ones that
> have (as far as I can tell) not been addressed yet:
> 
> Following has not been addressed.
> > - Table fcipLinkErrorsTable contains a lot of Counter32 columns. 
> >   Each of the DESCRIPTION clauses is supposed to describe if there
> >   can be discontinuity situations, and if so, which timer is to
> >   be used to detect that.
> > 
> I know Keith has some disagreement with me, but I prefer that
> it is made clear to the readers/implementors as to do/expect.
> At least I'd like to see in the Table or Entry DESCRIPTION clause
> that all counters have "xxx as discontinuity indicator"
> 
> > - I think the Security COnsiderations section is weak.
> >   It lists sensitive objects, but it does not describe much about
> >   why they are sensitive and what kind of damage can happen if 
> >   improperly changed.
> >   The security guidelines on www.ops.ietf.org  explains how it
> >   should be done in an acceptable manenr
> > 
> 
> I don't think I see any change to the security considerations.
> Oh well... we'll see what security ADs will have to day about it.
> 
> Bert
> 
> _______________________________________________
> 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 Oct 18 09:43:15 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERrkJ-0006d3-VL; Tue, 18 Oct 2005 09:43:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ERrkI-0006cm-A3
	for ips@megatron.ietf.org; Tue, 18 Oct 2005 09:43:14 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00260
	for <ips@ietf.org>; Tue, 18 Oct 2005 09:43:06 -0400 (EDT)
Received: from ihemail2.lucent.com ([192.11.222.163])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERrvp-0005VZ-Sa
	for ips@ietf.org; Tue, 18 Oct 2005 09:55:10 -0400
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com
	[135.85.76.62])
	by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j9IDguXP003397; 
	Tue, 18 Oct 2005 08:43:00 -0500 (CDT)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service
	(5.5.2657.72) id <SQW8Y0WY>; Tue, 18 Oct 2005 15:42:56 +0200
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15508568621@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: Keith McCloghrie <kzm@cisco.com>
Subject: RE: [Ips] MIB Doctor review: draft-ietf-ips-fcip-mib-08.txt (fwd)
Date: Tue, 18 Oct 2005 15:42:52 +0200
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: 42e3ed3f10a1d8bef690f09da16f507a
Cc: anil@charter.net, ips@ietf.org,
	"Allison Mankin \(E-mail\)" <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

OK, so it sounds Allison can mark this doc as "REvised ID needed"

I think I now used the correct email address for ravi

Bert

> -----Original Message-----
> From: Keith McCloghrie [mailto:kzm@cisco.com]
> Sent: Monday, October 17, 2005 11:30
> To: bwijnen@lucent.com
> Cc: ips@ietf.org; ravin@lightsand.com; anil@charter.net
> Subject: [Ips] MIB Doctor review: draft-ietf-ips-fcip-mib-08.txt (fwd)
> 
> 
> Bert,
> 
> You mention several nits which can be fixed by minor edits.  You also
> point out this issue:
> 
> > > - Table fcipLinkErrorsTable contains a lot of Counter32 columns.
> > >   Each of the DESCRIPTION clauses is supposed to describe if there
> > >   can be discontinuity situations, and if so, which timer is to
> > >   be used to detect that.
> >
> > I know Keith has some disagreement with me, but I prefer that
> > it is made clear to the readers/implementors as to do/expect.
> > At least I'd like to see in the Table or Entry DESCRIPTION clause
> > that all counters have "xxx as discontinuity indicator"
> 
> In reviewing the issue for this particular MIB, I do agree with you
> because the Counter32's are in a table INDEX-ed by fcipLinkIndex, and
> the values of fcipLinkIndex are controlled by fcipLinkStatus which has
> a syntax of RowStatus.  Thus, there is a potential for the re-use of a
> previously-used value of fcipLinkIndex to apply to a different link.
> So, these counters definitely need a discontinuity timestamp. 
> I suggest a xxxCreateTime object needs be added in the fcipLinkTable,
> e.g.,:
> 
>     fcipLinkCreateTime OBJECT-TYPE
>         SYNTAX      TimeStamp
>         MAX-ACCESS  read-only
>         STATUS      current
>         DESCRIPTION
>                "The value of sysUpTime when this entry was 
> last created."
>         ::= { fcipLinkEntry 12 }
> 
> so that each of the DESCRIPTIONs for the Counter32's in the
> fcipLinkErrorsTable can include this sentence:
> 
>            The last discontinuity of this counter is indicated by
>            fcipLinkCreateTime.
> 
> (and TimeStamp will need to be IMPORTed from SNMPv2-TC.)
> 
> My apologies to Anil & Ravi that I didn't catch this earlier.
> Also, while the document is being updated, can I suggest that 
> the Authors'
> Addresses section be checked to ensure it has correct email addresses.
> 
> Keith.
> -------------
> Forwarded message:
> > From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
> > Date: Mon, 17 Oct 2005 04:01:38 +0200
> > To: "'ravin@lightsand.com'" <ravin@lightsand.com>
> > Cc: "'Ipswg \(E-mail\)'" <ips@ietf.org>
> > Subject: [Ips] MIB Doctor review: draft-ietf-ips-fcip-mib-08.txt
> > Message-ID: 
> <7D5D48D2CAA3D84C813F5B154F43B15508568167@nl0006exch001u.nl.lu
> cent.com>
> > 
> > OK, I have re-checked the new revision (08) of this document.
> > 
> > Here are my findings:
> > 
> > When you revise a MIB module, then both the LAST-UPDATED
> > and REVISION clauses must be kept in sync.
> > 
> >   C:\bwijnen\smicng\work>smicng fcip.inc
> >   W: f(fcip.mi2), (39,21) The first revision should match the
> >      last update for MODULE-IDENTITY fcipMIB
> > 
> > 
> > There still seem to be citation/reference issues:
> > 
> >   !! Missing citation for Normative reference:
> >   P029 L052: [FC-SW-3]   Fibre Channel Switch Fabric -3 
> (FC-SW-3), T11/03-018v4,
> > 
> > I see it is used in a REFERENCE clause in the MIB
> > See below at problem with RFC2571
> > 
> >   !! Missing citation for Normative reference:
> >   P030 L030: [RFC2474]   Nichols, K., Blake, S., Baker, F., 
> and D. Black, "Definition
> > 
> >   !! Missing citation for Normative reference:
> >   P030 L018: [RFC2571]   Harrington, D., Presuhn, R., and 
> B. Wijnen, "An
> > 
> > RFC2571 has been obsoleted by the way by RFC3411.
> > I think you IMPORT from RFC3411
> > Further your IMPORT from RFC4001, which causes a normative reference
> > that I am missing.
> > 
> > Normally you add some text just before the MIB module starts aka
> > 
> >   The following MIB modules has IMPORTS from [RFC3411] and [RFC4001]
> >   and refers  to [FC-SW-3] in REFERENCE clauses.
> > 
> > 
> > Below is my revision 7 review, and I am commenting on the ones that
> > have (as far as I can tell) not been addressed yet:
> > 
> > Following has not been addressed.
> > > - Table fcipLinkErrorsTable contains a lot of Counter32 columns. 
> > >   Each of the DESCRIPTION clauses is supposed to describe if there
> > >   can be discontinuity situations, and if so, which timer is to
> > >   be used to detect that.
> > > 
> > I know Keith has some disagreement with me, but I prefer that
> > it is made clear to the readers/implementors as to do/expect.
> > At least I'd like to see in the Table or Entry DESCRIPTION clause
> > that all counters have "xxx as discontinuity indicator"
> > 
> > > - I think the Security COnsiderations section is weak.
> > >   It lists sensitive objects, but it does not describe much about
> > >   why they are sensitive and what kind of damage can happen if 
> > >   improperly changed.
> > >   The security guidelines on www.ops.ietf.org  explains how it
> > >   should be done in an acceptable manenr
> > > 
> > 
> > I don't think I see any change to the security considerations.
> > Oh well... we'll see what security ADs will have to day about it.
> > 
> > Bert
> > 
> > _______________________________________________
> > 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 Oct 18 12:58:13 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERumz-0005Gw-CV; Tue, 18 Oct 2005 12:58:13 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERumq-0005Bn-JX; Tue, 18 Oct 2005 12:58:07 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14345;
	Tue, 18 Oct 2005 12:57:55 -0400 (EDT)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1ERuyQ-0003PD-2h; Tue, 18 Oct 2005 13:10:02 -0400
Received: from apache by newodin.ietf.org with local (Exim 4.43)
	id 1ERump-0003W5-T5; Tue, 18 Oct 2005 12:58:03 -0400
X-test-idtracker: no
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Message-Id: <E1ERump-0003W5-T5@newodin.ietf.org>
Date: Tue, 18 Oct 2005 12:58:03 -0400
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5
Cc: ips mailing list <ips@ietf.org>, Internet Architecture Board <iab@iab.org>,
	ips chair <black_david@emc.com>, RFC Editor <rfc-editor@rfc-editor.org>
Subject: [Ips] Protocol Action: 'Definitions of Managed Objects for iFCP' to
 Proposed Standard 
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 IESG has approved the following document:

- 'Definitions of Managed Objects for iFCP '
   <draft-ietf-ips-ifcp-mib-07.txt> as a Proposed Standard

This document is the product of the IP Storage Working Group. 

The IESG contact persons are Allison Mankin and Jon Peterson.

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

Technical Summary

   The iFCP protocol can be used by FC to IP based storage gateways for 
   FCP storage interconnects.

   The iFCP MIB Module is designed to allow SNMP to be used to monitor 
   and manage local iFCP gateway instances, including the configuration 
   of iFCP sessions between gateways.
 
 
Working Group Summary
 
 The working group and the FC standards organization supported
  this MIB development, as well as the revisions under review.
 
Protocol Quality
 
 Keith McLoghrie is the MIB Advisor for the IPS working group and
 gave guidance in the document's development.  Bert Wijnen was the MIB
 Doctor and gave intensive reviews.  The FC industry makes use 
 of this technology, so there has been interim implementation.

 The Responsible Area Director was Allison Mankin.  David Black was
 the WG Chair shepherd.

Notes to RFC Editor

Please make the following two changes to:
  http://www.ietf.org/internet-drafts/draft-ietf-ips-ifcp-mib-07.txt

1) On page 11, Section 4, change FROM:

    "An entry in the session table."
        INDEX { ifcpLclGtwyInstIndex, ifcpSessionIndex }
        ::= {ifcpSessionAttributesTable 1}

TO:

    "Each entry contains information about one iFCP session consisting
    of a pair of N_PORTs joined by a single TCP/IP connection.  This
    table's INDEX includes ifcpLclGtwyInstIndex which identifies the
    local iFCP Gateway instance which created the session for the
    entry.

    Soon after an entry is created in this table for an iFCP session, it
    will correspond to an entry in the tcpConnectionTable of the TCP-MIB
    (RFC 4022).  The corresponding entry might represent a pre-existing
    TCP connection, or it might be a newly-created entry.  (Note that if
    IPv4 is being used, an entry in RFC 2012's tcpConnTable may also
    correspond.)  The values of ifcpSessionLclPrtlAddrType and
    ifcpSessionRmtPrtlIfAddrType in this table and the values of
    tcpConnectionLocalAddressType and tcpConnectionRemAddressType used
    as INDEX values for the corresponding entry in the tcpConnectionTable
    should be the same; this makes it simpler to locate a session's TCP
    connection in the TCP-MIB.  (Of course, all four values need to be
    'ipv4' if there's a corresponding entry in the tcpConnTable.)

    If an entry is created in this table for a session, prior to
    knowing which local and/or remote port numbers will be used for
    the TCP connection, then ifcpSessionLclPrtlTcpPort and/or
    ifcpSessionRmtPrtlTcpPort have the value zero until such time as
    they can be updated to the port numbers (to be) used for the
    connection.  (Thus, a port value of zero should not be used to
    locate a session's TCP connection in the TCP-MIB.)

    When the TCP connection terminates, the entry in the
    tcpConnectionTable and the entry in this table both get deleted
    (and, if applicable, so does the entry in the tcpConnTable)."
        INDEX { ifcpLclGtwyInstIndex, ifcpSessionIndex }
        ::= {ifcpSessionAttributesTable 1}

2) On page 21, Section 4, change FROM:

                        } 
       ::= {ifcpCompliances 1} 

TO: 

                        } 

           OBJECT      ifcpSessionLclPrtlAddrType
           SYNTAX      InetAddressType { ipv4(1), ipv6(2) }
           DESCRIPTION
                  "Support is only required for global IPv4
                  and IPv6 address types."

           OBJECT      ifcpSessionRmtPrtlIfAddrType
           SYNTAX      InetAddressType { ipv4(1), ipv6(2) }
           DESCRIPTION
                  "Support is only required for global IPv4
                  and IPv6 address types."

       ::= {ifcpCompliances 1}


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



From ips-bounces@ietf.org Thu Oct 20 15:50:59 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ESgRH-0001Uz-3C; Thu, 20 Oct 2005 15:50:59 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ESgQQ-00019u-Pf; Thu, 20 Oct 2005 15:50:06 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09923;
	Thu, 20 Oct 2005 15:49:54 -0400 (EDT)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1ESgcN-0006Sw-5P; Thu, 20 Oct 2005 16:02:28 -0400
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1ESgQL-0000tj-R8; Thu, 20 Oct 2005 15:50:01 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1ESgQL-0000tj-R8@newodin.ietf.org>
Date: Thu, 20 Oct 2005 15:50:01 -0400
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Cc: ips@ietf.org
Subject: [Ips] I-D ACTION:draft-ietf-ips-iser-05.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		: iSCSI Extensions for RDMA Specification
	Author(s)	: M. Ko, et al.
	Filename	: draft-ietf-ips-iser-05.txt,.pdf
	Pages		: 95
	Date		: 2005-10-20
	
iSCSI Extensions for RDMA provides the RDMA data transfer capability 
   to iSCSI by layering iSCSI on top of an RDMA-Capable Protocol such 
   as the iWARP protocol suite.  An RDMA-Capable Protocol provides RDMA 
   Read and Write services, which enable data to be transferred 
   directly into SCSI I/O Buffers without intermediate data copies.  
   This document describes the extensions to the iSCSI protocol to 
   support RDMA services as provided by an RDMA-Capable Protocol such 
   as the iWARP protocol suite.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ips-iser-05.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-iser-05.txt".

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ips-iser-05.txt

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

Content-Type: text/plain
Content-ID: <2005-10-20113041.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 Fri Oct 21 10:50:12 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ESyDk-0002Pk-0Y; Fri, 21 Oct 2005 10:50:12 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ESyDb-0002L2-6n; Fri, 21 Oct 2005 10:50:03 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25768;
	Fri, 21 Oct 2005 10:49:51 -0400 (EDT)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1ESyPk-0003qx-BY; Fri, 21 Oct 2005 11:02:36 -0400
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1ESyDZ-0008DP-Ev; Fri, 21 Oct 2005 10:50:01 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1ESyDZ-0008DP-Ev@newodin.ietf.org>
Date: Fri, 21 Oct 2005 10:50:01 -0400
X-Spam-Score: 0.4 (/)
X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1
Cc: ips@ietf.org
Subject: [Ips] I-D ACTION:draft-ietf-ips-auth-mib-07.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 User Identity Authorization
	Author(s)	: M. Bakke, J. Muchow
	Filename	: draft-ietf-ips-auth-mib-07.txt
	Pages		: 37
	Date		: 2005-10-21
	
This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in TCP/IP based internets.
   In particular it defines objects for managing user identities and the
   names, addresses, and credentials required manage access control, for
   use with various protocols.  This draft was motivated by the need for
   the configuration of authorized user identities for the iSCSI
   protocol, but has been extended to be useful for other protocols that
   have similar requirements.  It is important to note that this MIB
   module provides only the set of identities to be used within access
   lists; it is the responsibility of other MIB modules making use of
   this one to tie them to their own access lists or other authorization
   control methods.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ips-auth-mib-07.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-auth-mib-07.txt".

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


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

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

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

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

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

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

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

Content-Type: text/plain
Content-ID: <2005-10-21085751.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 Fri Oct 21 10:50:33 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ESyE5-0002af-Ui; Fri, 21 Oct 2005 10:50:33 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ESyDc-0002M8-Ku; Fri, 21 Oct 2005 10:50:04 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25790;
	Fri, 21 Oct 2005 10:49:53 -0400 (EDT)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1ESyPk-0003rB-Qs; Fri, 21 Oct 2005 11:02:37 -0400
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1ESyDZ-0008EC-Pp; Fri, 21 Oct 2005 10:50:01 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1ESyDZ-0008EC-Pp@newodin.ietf.org>
Date: Fri, 21 Oct 2005 10:50:01 -0400
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Cc: ips@ietf.org
Subject: [Ips] I-D ACTION:draft-ietf-ips-fcip-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		: Definitions of Managed Objects for FCIP
	Author(s)	: R. Natarajan, A. Rijhsinghani
	Filename	: draft-ietf-ips-fcip-mib-09.txt
	Pages		: 32
	Date		: 2005-10-21
	
This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in TCP/IP based internets.
   In particular it defines objects for managing FCIP entities, which
   are used to interconnect FC fabrics with IP networks.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ips-fcip-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-fcip-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-fcip-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: <2005-10-21093252.I-D@ietf.org>

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

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

Content-Type: text/plain
Content-ID: <2005-10-21093252.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 Fri Oct 21 12:20:58 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ESzda-000117-DK; Fri, 21 Oct 2005 12:20:58 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ESzdY-0000uS-8Q
	for ips@megatron.ietf.org; Fri, 21 Oct 2005 12:20:56 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16750
	for <ips@ietf.org>; Fri, 21 Oct 2005 12:20:44 -0400 (EDT)
From: Black_David@emc.com
Received: from mailhub.lss.emc.com ([168.159.2.31])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESzph-0004Se-Ee
	for ips@ietf.org; Fri, 21 Oct 2005 12:33:31 -0400
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.6) with ESMTP id
	j9LGKj0Q004154
	for <ips@ietf.org>; Fri, 21 Oct 2005 12:20:49 -0400 (EDT)
Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19)
	id <RT6B423D>; Fri, 21 Oct 2005 12:20:44 -0400
Message-ID: <F222151D3323874393F83102D614E0557A70AB@CORPUSMX20A.corp.emc.com>
To: ips@ietf.org
Date: Fri, 21 Oct 2005 12:20:39 -0400
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: 2005.10.21.14
X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, EMC_FROM_00+ -3,
	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: 8de5f93cb2b4e3bee75302e9eacc33db
Cc: Black_David@emc.com
Subject: [Ips] DA Publication Requested
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

Publication as an RFC has just been requested on the DA draft.
The PROTO process (cf. draft-ietf-proto-wgchair-doc-shepherding-05.txt)
is being used.  Here is the PROTO writeup:
 
               Datamover Architecture for iSCSI (DA) 
                 draft-ietf-ips-iwarp-da-03.txt

Requested Publication Status: Informational
PROTO shepherd: David L. Black (IPS WG Chair)
------------------------------------------------------------------------

   1.a) Have the chairs personally reviewed this version of the Internet
        Draft (ID), and in particular, do they believe this ID is ready
        to forward to the IESG for publication?

Yes.

   1.b) Has the document had adequate review from both key WG members
        and key non-WG members?

Yes.

        Do you have any concerns about the
        depth or breadth of the reviews that have been performed?

No.

   1.c) Do you have concerns that the document needs more review from a
        particular (broader) perspective (e.g., security, operational
        complexity, someone familiar with AAA, etc.)?

No.

   1.d) Do you have any specific concerns/issues with this document that
        you believe the ADs and/or IESG should be aware of?  For
        example, perhaps you are uncomfortable with certain parts of the
        document, or have concerns whether there really is a need for
        it.  In any event, if your issues have been discussed in the WG
        and the WG has indicated it that it still wishes to advance the
        document, detail those concerns in the write-up.

No.  The presence of "iwarp" in the draft name is an historical artifact
- the described architecture has more general applicability beyond the
iWARP protocol suite.

   1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

The portion of the WG interested in RDMA understands and agrees with
this document.

   1.f) [... not sent to the WG ...]

   1.g) Have the chairs verified that the document adheres to all of the
        ID nits? (see http://www.ietf.org/ID-Checklist.html).

There are minor boilerplate issues, plus several dozen non-ASCII and
control characters.  All of these problems will be corrected if a
revised draft is required as part of the publication process, otherwise
the RFC Editor will deal with them as part of editing for publication.

   1.h) Is the document split into normative and informative references?

Yes.

        Are there normative references to IDs, where the IDs are not
        also ready for advancement or are otherwise in an unclear state?
        (note here that the RFC editor will not publish an RFC with
        normative references to IDs, it will delay publication until all
        such IDs are also ready for publication as RFCs.)

No.

   1.i) For Standards Track and BCP documents, the IESG approval
        announcement includes a write-up section with the following
        sections:

        *    Technical Summary

        *    Working Group Summary

        *    Protocol Quality

   1.j) Please provide such a write-up.  Recent examples can be found in
        the "protocol action" announcements for approved documents.

N/A - this is to be published as an Informational RFC.

----------------------------------------------------
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 Oct 21 12:21:21 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ESzdx-00020U-NI; Fri, 21 Oct 2005 12:21:21 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ESzdw-000202-6D
	for ips@megatron.ietf.org; Fri, 21 Oct 2005 12:21:20 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16769
	for <ips@ietf.org>; Fri, 21 Oct 2005 12:21:08 -0400 (EDT)
From: Black_David@emc.com
Received: from mailhub.lss.emc.com ([168.159.2.31])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESzq6-0004TH-RE
	for ips@ietf.org; Fri, 21 Oct 2005 12:33:55 -0400
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.6) with ESMTP id
	j9LGKnXW029833
	for <ips@ietf.org>; Fri, 21 Oct 2005 12:21:12 -0400 (EDT)
Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19)
	id <RT6B42MC>; Fri, 21 Oct 2005 12:20:12 -0400
Message-ID: <F222151D3323874393F83102D614E0557A70AA@CORPUSMX20A.corp.emc.com>
To: ips@ietf.org
Date: Fri, 21 Oct 2005 12:20:07 -0400
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: 2005.10.21.14
X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, EMC_FROM_00+ -3,
	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: 6ffdee8af20de249c24731d8414917d3
Cc: Black_David@emc.com
Subject: [Ips] iSER Publication Requested
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

Publication as an RFC has just been requested on the iSER draft.
The PROTO process (cf. draft-ietf-proto-wgchair-doc-shepherding-05.txt)
is being used.  Here is the PROTO writeup:

             iSCSI Extensions for RDMA Specification 
                    draft-ietf-ips-iser-05.txt

Requested Publication Status: Proposed Standard
PROTO shepherd: David L. Black (IPS WG Chair)
------------------------------------------------------------------------

   1.a) Have the chairs personally reviewed this version of the Internet
        Draft (ID), and in particular, do they believe this ID is ready
        to forward to the IESG for publication?

Yes.

   1.b) Has the document had adequate review from both key WG members
        and key non-WG members?

Yes.

        Do you have any concerns about the
        depth or breadth of the reviews that have been performed?

No.

   1.c) Do you have concerns that the document needs more review from a
        particular (broader) perspective (e.g., security, operational
        complexity, someone familiar with AAA, etc.)?

The Security Considerations includes a brief discussion of iSER usage
on non-IP networks.  This discussion (Section 11, p.78) should be fine,
but the Security Area should double-check it.

   1.d) Do you have any specific concerns/issues with this document that
        you believe the ADs and/or IESG should be aware of?  For
        example, perhaps you are uncomfortable with certain parts of the
        document, or have concerns whether there really is a need for
        it.  In any event, if your issues have been discussed in the WG
        and the WG has indicated it that it still wishes to advance the
        document, detail those concerns in the write-up.

No.

   1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

The portion of the WG interested in RDMA understands and agrees with
this document.

   1.f) [... not sent to the WG ...]

   1.g) Have the chairs verified that the document adheres to all of the
        ID nits? (see http://www.ietf.org/ID-Checklist.html).

The online checker says everything is fine.

   1.h) Is the document split into normative and informative references?

Yes.

        Are there normative references to IDs, where the IDs are not
        also ready for advancement or are otherwise in an unclear state?
        (note here that the RFC editor will not publish an RFC with
        normative references to IDs, it will delay publication until all
        such IDs are also ready for publication as RFCs.)

There are three normative references to RDDP WG drafts:
	- draft-ietf-rddp-rdmap
	- draft-ietf-rddp-ddp
	- draft-ietf-rddp-mpa
Publication has been requested for all three of these drafts.

There is an informative reference to an expired VERBS draft:
	- draft-hilland-iwarp-verbs
This reference is not cited in the body of this (iSER) draft.
That VERBS draft has expired and will not be published as an RFC.
An RFC Editor Note should be used to remove this reference.

   1.i) For Standards Track and BCP documents, the IESG approval
        announcement includes a write-up section with the following
        sections:

        *    Technical Summary

        *    Working Group Summary

        *    Protocol Quality

   1.j) Please provide such a write-up.  Recent examples can be found in
        the "protocol action" announcements for approved documents.

-- Technical Summary
 
   iSCSI Extensions for RDMA provides the RDMA data transfer capability 
   to iSCSI by layering iSCSI on top of an RDMA-Capable Protocol such 
   as the iWARP protocol suite.  An RDMA-Capable Protocol provides RDMA 
   Read and Write services, which enable data to be transferred 
   directly into SCSI I/O Buffers without intermediate data copies.  
   This document describes the extensions to the iSCSI protocol to 
   support RDMA services as provided by an RDMA-Capable Protocol such 
   as the iWARP protocol suite. 

-- Working Group Summary

   Interest in using iSER to support iSCSI on non-IP networks has
   been accommodated by a careful revision of terminology, including a
   WG last call on the revised terminology.  Any actual protocol
   specification work for non-IP networks (e.g., for InfiniBand) will
   be conducted outside the IETF (e.g., in the InfiniBand Trade
   Association).

-- Protocol Quality

This protocol has been reviewed for the IPS WG by David L. Black.

----------------------------------------------------
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 Mon Oct 24 14:25:03 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EU70J-0003N3-GR; Mon, 24 Oct 2005 14:25:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EU70I-0003Mg-Hu
	for ips@megatron.ietf.org; Mon, 24 Oct 2005 14:25:02 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24729
	for <ips@ietf.org>; Mon, 24 Oct 2005 14:24:48 -0400 (EDT)
From: Yackey_Steve@emc.com
Received: from mailhub.lss.emc.com ([168.159.2.31])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU7D6-0004te-4X
	for ips@ietf.org; Mon, 24 Oct 2005 14:38:16 -0400
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.6) with ESMTP id
	j9OIOv0F005711
	for <ips@ietf.org>; Mon, 24 Oct 2005 14:24:58 -0400 (EDT)
Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19)
	id <RT6BYN2J>; Mon, 24 Oct 2005 14:24:56 -0400
Message-ID: <CEF7DE8455A91D42A0435A429564032956C046@CORPUSMX40B.corp.emc.com>
To: ips@ietf.org
Date: Mon, 24 Oct 2005 14:24:47 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0,
	Antispam-Data: 2005.10.24.20
X-PerlMx-Spam: Gauge=, SPAM=1%, Reasons='EMC_FROM_00+ -3, HTML_50_70 0.1,
	IP_HTTP_ADDR 0, NO_REAL_NAME 0, __C230066_P5 0, __CT 0,
	__CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0,
	__CTYPE_MULTIPART_ALT 0, __HAS_MSGID 0, __HAS_X_MAILER 0,
	__IMS_MSGID 0, __IMS_MUA 0, __MIME_HTML 0, __MIME_VERSION 0,
	__RATWARE_SIGNATURE_3_N1 0, __SANE_MSGID 0, __TAG_EXISTS_HTML 0'
X-Spam-Score: 1.2 (+)
X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841
Subject: [Ips] iSCSI Names and Addresses
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="===============0063937425=="
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============0063937425==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C5D8C8.39AF2077"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C5D8C8.39AF2077
Content-Type: text/plain



I have a novice question.

When rfc3721 says that iscsi names are associated with iscsi nodes (relevant
portion at the end), what does that mean exactly for a host with multiple
network adapter cards ?

For example, a Win2K03 host might have an initiator named

- iqn.1991-05.com.microsoft:hosta

- if there are two network adapters, say, 172.20.4.67 and 172.21.4.67

How would/should the two paths be represented and/or utilized by the
'outside' world ?
I do not see how the single initiator name is sufficient for what is
described in 3721.

Thanks in advance,
Steve


[portion of 3721 follows]

RFC 3721 iSCSI Naming and Discovery April 2004

1. iSCSI Names and Addresses

The main addressable, discoverable entity in iSCSI is an iSCSI Node.
An iSCSI node can be either an initiator, a target, or both. The
rules for constructing an iSCSI name are specified in [RFC3720].
This document provides examples of name construction that might be
used by a naming authority.

Both targets and initiators require names for the purpose of
identification, so that iSCSI storage resources can be managed
regardless of location (address). An iSCSI name is the unique
identifier for an iSCSI node, and is also the SCSI device name [SAM2]
of an iSCSI device. The iSCSI name is the principal object used in
authentication of targets to initiators and initiators to targets.
This name is also used to identify and manage iSCSI storage
resources.

Furthermore, iSCSI names are associated with iSCSI nodes instead of
with network adapter cards to ensure the free movement of network
HBAs between hosts without loss of SCSI state information
(reservations, mode page settings etc) and authorization
configuration.

An iSCSI node also has one or more addresses. An iSCSI address
specifies a single path to an iSCSI node and consists of the iSCSI
name, plus a transport (TCP) address which uses the following format:
<domain-name>[:<port>]
Where <domain-name> is one of:
- IPv4 address, in dotted decimal notation. Assumed if the name
contains exactly four numbers, separated by dots (.), where each
number is in the range 0..255.
- IPv6 address, in colon-separated hexadecimal notation, as
specified in [RFC3513] and enclosed in "[" and "]" characters, as
specified in [RFC2732].
- Fully Qualified Domain Name (host name). Assumed if the <domainname>
is neither an IPv4 nor an IPv6 address.
For iSCSI targets, the <port> in the address is optional; if
specified, it is the TCP port on which the target is listening for
connections. If the <port> is not specified, the default port 3260,
assigned by IANA, will be assumed. For iSCSI initiators, the <port>
is omitted.

Bakke, et al. Informational [Page 3]




Steve Yackey
EMC2 Corporation
1401 Main Street, Suite 350
Columbia, SC 29201
803-231-2632



Steve Yackey
EMC2 Corporation
1401 Main Street, Suite 350
Columbia, SC 29201
803-231-2632



------_=_NextPart_001_01C5D8C8.39AF2077
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>iSCSI Names and Addresses</TITLE>
</HEAD>
<BODY>
<BR>
<BR>

<P><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">I have a novice =
question.</FONT>
</P>

<P><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">When rfc3721 says =
that iscsi names are associated with iscsi nodes (relevant portion at =
the end), what does that mean exactly for a host with multiple network =
adapter cards ?</FONT></P>

<P><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">For example, a =
Win2K03 host might have an initiator named</FONT>
</P>

<P><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">- =
iqn.1991-05.com.microsoft:hosta</FONT>
</P>

<P><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">- if there are two =
network adapters, say, 172.20.4.67 and 172.21.4.67</FONT>
</P>

<P><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">How would/should =
the two paths be represented and/or utilized by the 'outside' world =
?</FONT>
<BR><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">I do not see how =
the single initiator name is sufficient for what is described in =
3721.</FONT>
</P>

<P><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">Thanks in =
advance,</FONT>
<BR><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">Steve</FONT>
</P>
<BR>

<P><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">[portion of 3721 =
follows]</FONT>
</P>

<P><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">RFC 3721 iSCSI =
Naming and Discovery April 2004</FONT>
</P>

<P><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">1. iSCSI Names and =
Addresses</FONT>
</P>

<P><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">The main =
addressable, discoverable entity in iSCSI is an iSCSI Node.</FONT>
<BR><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">An iSCSI node can =
be either an initiator, a target, or both. The</FONT>
<BR><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">rules for =
constructing an iSCSI name are specified in [RFC3720].</FONT>
<BR><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">This document =
provides examples of name construction that might be</FONT>
<BR><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">used by a naming =
authority.</FONT>
</P>

<P><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">Both targets and =
initiators require names for the purpose of</FONT>
<BR><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">identification, =
so that iSCSI storage resources can be managed</FONT>
<BR><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">regardless of =
location (address). An iSCSI name is the unique</FONT>
<BR><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">identifier for an =
iSCSI node, and is also the SCSI device name [SAM2]</FONT>
<BR><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">of an iSCSI =
device. The iSCSI name is the principal object used in</FONT>
<BR><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">authentication of =
targets to initiators and initiators to targets.</FONT>
<BR><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">This name is also =
used to identify and manage iSCSI storage</FONT>
<BR><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">resources.</FONT>
</P>

<P><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">Furthermore,<U><B> =
iSCSI names are associated with iSCSI nodes instead of</B></U></FONT>
<BR><U><B><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">with =
network adapter cards</FONT></B></U><B></B><FONT COLOR=3D"#800000" =
SIZE=3D2 FACE=3D"Verdana"> to ensure the free movement of =
network</FONT>
<BR><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">HBAs between =
hosts without loss of SCSI state information</FONT>
<BR><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">(reservations, =
mode page settings etc) and authorization</FONT>
<BR><FONT COLOR=3D"#800000" SIZE=3D2 =
FACE=3D"Verdana">configuration.</FONT>
</P>

<P><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">An iSCSI node also =
has one or more addresses. An iSCSI address</FONT>
<BR><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">specifies a =
single path to an iSCSI node and consists of the iSCSI</FONT>
<BR><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">name, plus a =
transport (TCP) address which uses the following format:</FONT>
<BR><FONT COLOR=3D"#800000" SIZE=3D2 =
FACE=3D"Verdana">&lt;domain-name&gt;[:&lt;port&gt;]</FONT>
<BR><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">Where =
&lt;domain-name&gt; is one of:</FONT>
<BR><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">- IPv4 address, =
in dotted decimal notation. Assumed if the name</FONT>
<BR><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">contains exactly =
four numbers, separated by dots (.), where each</FONT>
<BR><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">number is in the =
range 0..255.</FONT>
<BR><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">- IPv6 address, =
in colon-separated hexadecimal notation, as</FONT>
<BR><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">specified in =
[RFC3513] and enclosed in &quot;[&quot; and &quot;]&quot; characters, =
as</FONT>
<BR><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">specified in =
[RFC2732].</FONT>
<BR><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">- Fully Qualified =
Domain Name (host name). Assumed if the &lt;domainname&gt;</FONT>
<BR><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">is neither an =
IPv4 nor an IPv6 address.</FONT>
<BR><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">For iSCSI =
targets, the &lt;port&gt; in the address is optional; if</FONT>
<BR><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">specified, it is =
the TCP port on which the target is listening for</FONT>
<BR><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">connections. If =
the &lt;port&gt; is not specified, the default port 3260,</FONT>
<BR><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">assigned by IANA, =
will be assumed. For iSCSI initiators, the &lt;port&gt;</FONT>
<BR><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">is =
omitted.</FONT>
</P>

<P><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Verdana">Bakke, et al. =
Informational [Page 3]</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Verdana">Steve Yackey</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Verdana">EMC<SUP>2</SUP> Corporation</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Verdana">1401 Main Street, Suite 350</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Verdana">Columbia, SC 29201</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Verdana">803-</FONT><FONT SIZE=3D2 =
FACE=3D"Verdana">231-2632</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Verdana">Steve Yackey</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Verdana">EMC<SUP>2</SUP> Corporation</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Verdana">1401 Main Street, Suite 350</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Verdana">Columbia, SC 29201</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Verdana">803-</FONT><FONT SIZE=3D2 =
FACE=3D"Verdana">231-2632</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C5D8C8.39AF2077--


--===============0063937425==
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

--===============0063937425==--




From ips-bounces@ietf.org Mon Oct 24 15:49:26 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EU8Jy-0002Ud-HZ; Mon, 24 Oct 2005 15:49:26 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EU8Jx-0002UX-0C
	for ips@megatron.ietf.org; Mon, 24 Oct 2005 15:49:25 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28504
	for <ips@ietf.org>; Mon, 24 Oct 2005 15:49:10 -0400 (EDT)
Received: from atlrel8.hp.com ([156.153.255.206])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU8Wk-0007aP-Lb
	for ips@ietf.org; Mon, 24 Oct 2005 16:02:39 -0400
Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160])
	by atlrel8.hp.com (Postfix) with ESMTP id 54BCD2ABF
	for <ips@ietf.org>; Mon, 24 Oct 2005 15:49:22 -0400 (EDT)
Received: from [127.0.0.1] (sindhu.americas.hpqcorp.net [16.93.44.63])
	by rosemail.rose.hp.com (Postfix) with ESMTP id F2FF781FA
	for <ips@ietf.org>; Mon, 24 Oct 2005 12:49:21 -0700 (PDT)
Message-ID: <435D3ABF.1060506@rose.hp.com>
Date: Mon, 24 Oct 2005 12:49:19 -0700
From: "Mallikarjun C." <cbm@rose.hp.com>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: IPS <ips@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Content-Transfer-Encoding: 7bit
Subject: [Ips] Clearing the outstanding TTTs 
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

Based on the recent list discussion, the implementer's draft requires 
the task set target behavior also for LU and target resets.  IOW, the 
new draft requires that the target must wait for all outstanding TTTs to 
be retired before the TMF is acted on.

Bill Galloway has pointed out to me that this language appears to 
conflict with RFC 3720 clearing effects table.  The RFC table (page 250, 
bottom of the table) currently says that all incomplete TTTs are cleared 
on any of the reset flavors.

I believe that this is a consistency issue that needs to be addressed in 
the new draft (sigh....), so in the absence of any objections, I would 
like to change the cell entries (in the IT column) for the three reset 
rows to "N", meaning TTTs are *not* automatically cleared.  They will 
however be "cleared" by regular means, i.e. on initiator's Data-Out 
sequence.

FYI.
-- 
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
StorageWorks Division
Hewlett-Packard MS 5668
Roseville CA 95747
cbm [at] rose.hp.com


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



From ips-bounces@ietf.org Mon Oct 24 15:54:45 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EU8P6-0004Wm-W2; Mon, 24 Oct 2005 15:54:45 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EU8P5-0004WK-91
	for ips@megatron.ietf.org; Mon, 24 Oct 2005 15:54:43 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29251
	for <ips@ietf.org>; Mon, 24 Oct 2005 15:54:28 -0400 (EDT)
From: Black_David@emc.com
Received: from mailhub.lss.emc.com ([168.159.2.31])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU8bt-0007uQ-De
	for ips@ietf.org; Mon, 24 Oct 2005 16:07:58 -0400
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.6) with ESMTP id
	j9OJsZ66027189
	for <ips@ietf.org>; Mon, 24 Oct 2005 15:54:37 -0400 (EDT)
Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19)
	id <RT6BYWYQ>; Mon, 24 Oct 2005 15:54:32 -0400
Message-ID: <F222151D3323874393F83102D614E0557A70D6@CORPUSMX20A.corp.emc.com>
To: Yackey_Steve@emc.com, ips@ietf.org
Subject: RE: [Ips] iSCSI Names and Addresses
Date: Mon, 24 Oct 2005 15:54:07 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0,
	Antispam-Data: 2005.10.24.24
X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, EMC_FROM_00+ -3,
	HTML_50_70 0.1, IP_HTTP_ADDR 0, NO_REAL_NAME 0, __C230066_P5 0,
	__CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0,
	__CTYPE_MULTIPART_ALT 0, __HAS_MSGID 0, __HAS_X_MAILER 0,
	__IMS_MSGID 0, __IMS_MUA 0, __MIME_HTML 0, __MIME_VERSION 0,
	__SANE_MSGID 0, __STOCK_CRUFT 0, __TAG_EXISTS_HTML 0'
X-Spam-Score: 0.9 (/)
X-Scan-Signature: fe105289edd72640d9f392da880eefa2
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="===============0960280982=="
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============0960280982==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C5D8D4.61B2C1F4"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C5D8D4.61B2C1F4
Content-Type: text/plain

Steve,
 
DNS names are associated with hosts, and a host may have
multiple IP addresses.  While an iSCSI name is not the
same as a Ensnare, the same principle applies.  What
may be more interesting is that if a host has multiple
OS images (e.g., courtesy of hardware partitioning or
virtualization), each OS image should have its own
iSCSI name.
 
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 
---------------------------------------------------- 


  _____  

From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of
Yackey, Steve
Sent: Monday, October 24, 2005 2:25 PM
To: ips@ietf.org
Subject: [Ips] iSCSI Names and Addresses





I have a novice question. 

When rfc3721 says that iscsi names are associated with iscsi nodes (relevant
portion at the end), what does that mean exactly for a host with multiple
network adapter cards ?

For example, a Win2K03 host might have an initiator named 

- iqn.1991-05.com.microsoft:hosta 

- if there are two network adapters, say, 172.20.4.67 and 172.21.4.67 

How would/should the two paths be represented and/or utilized by the
'outside' world ? 
I do not see how the single initiator name is sufficient for what is
described in 3721. 

Thanks in advance, 
Steve 


[portion of 3721 follows] 

RFC 3721 iSCSI Naming and Discovery April 2004 

1. iSCSI Names and Addresses 

The main addressable, discoverable entity in iSCSI is an iSCSI Node. 
An iSCSI node can be either an initiator, a target, or both. The 
rules for constructing an iSCSI name are specified in [RFC3720]. 
This document provides examples of name construction that might be 
used by a naming authority. 

Both targets and initiators require names for the purpose of 
identification, so that iSCSI storage resources can be managed 
regardless of location (address). An iSCSI name is the unique 
identifier for an iSCSI node, and is also the SCSI device name [SAM2] 
of an iSCSI device. The iSCSI name is the principal object used in 
authentication of targets to initiators and initiators to targets. 
This name is also used to identify and manage iSCSI storage 
resources. 

Furthermore, iSCSI names are associated with iSCSI nodes instead of 
with network adapter cards to ensure the free movement of network 
HBAs between hosts without loss of SCSI state information 
(reservations, mode page settings etc) and authorization 
configuration. 

An iSCSI node also has one or more addresses. An iSCSI address 
specifies a single path to an iSCSI node and consists of the iSCSI 
name, plus a transport (TCP) address which uses the following format: 
<domain-name>[:<port>] 
Where <domain-name> is one of: 
- IPv4 address, in dotted decimal notation. Assumed if the name 
contains exactly four numbers, separated by dots (.), where each 
number is in the range 0..255. 
- IPv6 address, in colon-separated hexadecimal notation, as 
specified in [RFC3513] and enclosed in "[" and "]" characters, as 
specified in [RFC2732]. 
- Fully Qualified Domain Name (host name). Assumed if the <domainname> 
is neither an IPv4 nor an IPv6 address. 
For iSCSI targets, the <port> in the address is optional; if 
specified, it is the TCP port on which the target is listening for 
connections. If the <port> is not specified, the default port 3260, 
assigned by IANA, will be assumed. For iSCSI initiators, the <port> 
is omitted. 

Bakke, et al. Informational [Page 3] 




Steve Yackey 
EMC2 Corporation 
1401 Main Street, Suite 350 
Columbia, SC 29201 
803-231-2632 



Steve Yackey 
EMC2 Corporation 
1401 Main Street, Suite 350 
Columbia, SC 29201 
803-231-2632 



------_=_NextPart_001_01C5D8D4.61B2C1F4
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE>iSCSI Names and Addresses</TITLE>

<META content="MSHTML 6.00.2800.1522" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=275085219-24102005><FONT face="Courier New" 
size=2>Steve,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=275085219-24102005><FONT face="Courier New" 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=275085219-24102005><FONT face="Courier New" 
size=2>DNS names are associated with hosts, and a host&nbsp;may 
have</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=275085219-24102005><FONT face="Courier New" 
size=2>multiple </FONT></SPAN><SPAN class=275085219-24102005><FONT 
face="Courier New" size=2>IP addresses.&nbsp; While an iSCSI name is not 
the</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=275085219-24102005><FONT face="Courier New" 
size=2>same as a Ensnare</FONT></SPAN><SPAN class=275085219-24102005><FONT 
face="Courier New" size=2>, the same principle applies.&nbsp; 
What</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=275085219-24102005><FONT face="Courier New" 
size=2>may be </FONT></SPAN><SPAN class=275085219-24102005><FONT 
face="Courier New" size=2>more interesting is that if a host has 
multiple</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=275085219-24102005><FONT face="Courier New" 
size=2>OS </FONT></SPAN><SPAN class=275085219-24102005><FONT face="Courier New" 
size=2>images (e.g., courtesy of hardware partitioning or</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=275085219-24102005><FONT face="Courier New" 
size=2>virtualization), each OS image should have its own</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=275085219-24102005><FONT face="Courier New" 
size=2>iSCSI name.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=275085219-24102005><FONT face="Courier New" 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=275085219-24102005><FONT face="Courier New" 
size=2>Thanks,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=275085219-24102005><FONT face="Courier New" 
size=2>--David</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=275085219-24102005></SPAN><SPAN 
class=275085219-24102005><SPAN lang=en-us><FONT face="Courier New" 
size=2>----------------------------------------------------</FONT></SPAN> 
<BR><SPAN lang=en-us><FONT face="Courier New" size=2>David L. Black, Senior 
Technologist</FONT></SPAN> <BR><SPAN lang=en-us><FONT face="Courier New" 
size=2>EMC Corporation, 176 South St., Hopkinton, MA&nbsp; 01748</FONT></SPAN> 
<BR><SPAN lang=en-us><FONT face="Courier New" size=2>+1 (508) 
293-7953&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
FAX: +1 (508) 293-7786</FONT></SPAN> <BR><SPAN lang=en-us><FONT 
face="Courier New" 
size=2>black_david@emc.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Mobile: +1 
(978) 394-7754</FONT></SPAN> <BR><SPAN lang=en-us><FONT face="Courier New" 
size=2>----------------------------------------------------</FONT></SPAN> 
</DIV></SPAN><BR>
<BLOCKQUOTE 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
  <HR tabIndex=-1>
  <FONT face=Tahoma size=2><B>From:</B> ips-bounces@ietf.org 
  [mailto:ips-bounces@ietf.org] <B>On Behalf Of </B>Yackey, 
  Steve<BR><B>Sent:</B> Monday, October 24, 2005 2:25 PM<BR><B>To:</B> 
  ips@ietf.org<BR><B>Subject:</B> [Ips] iSCSI Names and 
  Addresses<BR></FONT><BR></DIV>
  <DIV></DIV><BR><BR>
  <P><FONT face=Verdana color=#800000 size=2>I have a novice question.</FONT> 
  </P>
  <P><FONT face=Verdana color=#800000 size=2>When rfc3721 says that iscsi names 
  are associated with iscsi nodes (relevant portion at the end), what does that 
  mean exactly for a host with multiple network adapter cards ?</FONT></P>
  <P><FONT face=Verdana color=#800000 size=2>For example, a Win2K03 host might 
  have an initiator named</FONT> </P>
  <P><FONT face=Verdana color=#800000 size=2>- 
  iqn.1991-05.com.microsoft:hosta</FONT> </P>
  <P><FONT face=Verdana color=#800000 size=2>- if there are two network 
  adapters, say, 172.20.4.67 and 172.21.4.67</FONT> </P>
  <P><FONT face=Verdana color=#800000 size=2>How would/should the two paths be 
  represented and/or utilized by the 'outside' world ?</FONT> <BR><FONT 
  face=Verdana color=#800000 size=2>I do not see how the single initiator name 
  is sufficient for what is described in 3721.</FONT> </P>
  <P><FONT face=Verdana color=#800000 size=2>Thanks in advance,</FONT> <BR><FONT 
  face=Verdana color=#800000 size=2>Steve</FONT> </P><BR>
  <P><FONT face=Verdana color=#800000 size=2>[portion of 3721 follows]</FONT> 
  </P>
  <P><FONT face=Verdana color=#800000 size=2>RFC 3721 iSCSI Naming and Discovery 
  April 2004</FONT> </P>
  <P><FONT face=Verdana color=#800000 size=2>1. iSCSI Names and Addresses</FONT> 
  </P>
  <P><FONT face=Verdana color=#800000 size=2>The main addressable, discoverable 
  entity in iSCSI is an iSCSI Node.</FONT> <BR><FONT face=Verdana color=#800000 
  size=2>An iSCSI node can be either an initiator, a target, or both. The</FONT> 
  <BR><FONT face=Verdana color=#800000 size=2>rules for constructing an iSCSI 
  name are specified in [RFC3720].</FONT> <BR><FONT face=Verdana color=#800000 
  size=2>This document provides examples of name construction that might 
  be</FONT> <BR><FONT face=Verdana color=#800000 size=2>used by a naming 
  authority.</FONT> </P>
  <P><FONT face=Verdana color=#800000 size=2>Both targets and initiators require 
  names for the purpose of</FONT> <BR><FONT face=Verdana color=#800000 
  size=2>identification, so that iSCSI storage resources can be managed</FONT> 
  <BR><FONT face=Verdana color=#800000 size=2>regardless of location (address). 
  An iSCSI name is the unique</FONT> <BR><FONT face=Verdana color=#800000 
  size=2>identifier for an iSCSI node, and is also the SCSI device name 
  [SAM2]</FONT> <BR><FONT face=Verdana color=#800000 size=2>of an iSCSI device. 
  The iSCSI name is the principal object used in</FONT> <BR><FONT face=Verdana 
  color=#800000 size=2>authentication of targets to initiators and initiators to 
  targets.</FONT> <BR><FONT face=Verdana color=#800000 size=2>This name is also 
  used to identify and manage iSCSI storage</FONT> <BR><FONT face=Verdana 
  color=#800000 size=2>resources.</FONT> </P>
  <P><FONT face=Verdana color=#800000 size=2>Furthermore,<U><B> iSCSI names are 
  associated with iSCSI nodes instead of</B></U></FONT> <BR><U><B><FONT 
  face=Verdana color=#800000 size=2>with network adapter 
  cards</FONT></B></U><B></B><FONT face=Verdana color=#800000 size=2> to ensure 
  the free movement of network</FONT> <BR><FONT face=Verdana color=#800000 
  size=2>HBAs between hosts without loss of SCSI state information</FONT> 
  <BR><FONT face=Verdana color=#800000 size=2>(reservations, mode page settings 
  etc) and authorization</FONT> <BR><FONT face=Verdana color=#800000 
  size=2>configuration.</FONT> </P>
  <P><FONT face=Verdana color=#800000 size=2>An iSCSI node also has one or more 
  addresses. An iSCSI address</FONT> <BR><FONT face=Verdana color=#800000 
  size=2>specifies a single path to an iSCSI node and consists of the 
  iSCSI</FONT> <BR><FONT face=Verdana color=#800000 size=2>name, plus a 
  transport (TCP) address which uses the following format:</FONT> <BR><FONT 
  face=Verdana color=#800000 size=2>&lt;domain-name&gt;[:&lt;port&gt;]</FONT> 
  <BR><FONT face=Verdana color=#800000 size=2>Where &lt;domain-name&gt; is one 
  of:</FONT> <BR><FONT face=Verdana color=#800000 size=2>- IPv4 address, in 
  dotted decimal notation. Assumed if the name</FONT> <BR><FONT face=Verdana 
  color=#800000 size=2>contains exactly four numbers, separated by dots (.), 
  where each</FONT> <BR><FONT face=Verdana color=#800000 size=2>number is in the 
  range 0..255.</FONT> <BR><FONT face=Verdana color=#800000 size=2>- IPv6 
  address, in colon-separated hexadecimal notation, as</FONT> <BR><FONT 
  face=Verdana color=#800000 size=2>specified in [RFC3513] and enclosed in "[" 
  and "]" characters, as</FONT> <BR><FONT face=Verdana color=#800000 
  size=2>specified in [RFC2732].</FONT> <BR><FONT face=Verdana color=#800000 
  size=2>- Fully Qualified Domain Name (host name). Assumed if the 
  &lt;domainname&gt;</FONT> <BR><FONT face=Verdana color=#800000 size=2>is 
  neither an IPv4 nor an IPv6 address.</FONT> <BR><FONT face=Verdana 
  color=#800000 size=2>For iSCSI targets, the &lt;port&gt; in the address is 
  optional; if</FONT> <BR><FONT face=Verdana color=#800000 size=2>specified, it 
  is the TCP port on which the target is listening for</FONT> <BR><FONT 
  face=Verdana color=#800000 size=2>connections. If the &lt;port&gt; is not 
  specified, the default port 3260,</FONT> <BR><FONT face=Verdana color=#800000 
  size=2>assigned by IANA, will be assumed. For iSCSI initiators, the 
  &lt;port&gt;</FONT> <BR><FONT face=Verdana color=#800000 size=2>is 
  omitted.</FONT> </P>
  <P><FONT face=Verdana color=#800000 size=2>Bakke, et al. Informational [Page 
  3]</FONT> </P><BR><BR><BR>
  <P><FONT face=Verdana size=2>Steve Yackey</FONT> <BR><FONT face=Verdana 
  size=2>EMC<SUP>2</SUP> Corporation</FONT> <BR><FONT face=Verdana size=2>1401 
  Main Street, Suite 350</FONT> <BR><FONT face=Verdana size=2>Columbia, SC 
  29201</FONT> <BR><FONT face=Verdana size=2>803-</FONT><FONT face=Verdana 
  size=2>231-2632</FONT> </P><BR><BR>
  <P><FONT face=Verdana size=2>Steve Yackey</FONT> <BR><FONT face=Verdana 
  size=2>EMC<SUP>2</SUP> Corporation</FONT> <BR><FONT face=Verdana size=2>1401 
  Main Street, Suite 350</FONT> <BR><FONT face=Verdana size=2>Columbia, SC 
  29201</FONT> <BR><FONT face=Verdana size=2>803-</FONT><FONT face=Verdana 
  size=2>231-2632</FONT> </P><BR></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C5D8D4.61B2C1F4--


--===============0960280982==
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

--===============0960280982==--




From ips-bounces@ietf.org Mon Oct 24 15:59:42 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EU8Tu-000671-4m; Mon, 24 Oct 2005 15:59:42 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EU8Tt-00066u-9G
	for ips@megatron.ietf.org; Mon, 24 Oct 2005 15:59:41 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00562
	for <ips@ietf.org>; Mon, 24 Oct 2005 15:59:26 -0400 (EDT)
From: Black_David@emc.com
Received: from mailhub.lss.emc.com ([168.159.2.31])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU8gh-0008Pf-LT
	for ips@ietf.org; Mon, 24 Oct 2005 16:12:56 -0400
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.6) with ESMTP id
	j9OJxBZc004922
	for <ips@ietf.org>; Mon, 24 Oct 2005 15:59:13 -0400 (EDT)
Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19)
	id <RT6BYXK8>; Mon, 24 Oct 2005 15:58:34 -0400
Message-ID: <F222151D3323874393F83102D614E0557A70D7@CORPUSMX20A.corp.emc.com>
To: Yackey_Steve@emc.com, ips@ietf.org
Subject: RE: [Ips] iSCSI Names and Addresses
Date: Mon, 24 Oct 2005 15:58:08 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0,
	Antispam-Data: 2005.10.20.2
X-PerlMx-Spam: Gauge=, SPAM=1%, Reasons='EMC_FROM_00+ -3, EMC_BODY_1+ -1,
	HTML_50_70 0.1, IP_HTTP_ADDR 0, NO_REAL_NAME 0, __C230066_P5 0,
	__CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0,
	__CTYPE_MULTIPART_ALT 0, __HAS_MSGID 0, __HAS_X_MAILER 0,
	__IMS_MSGID 0, __IMS_MUA 0, __MIME_HTML 0, __MIME_VERSION 0,
	__SANE_MSGID 0, __STOCK_CRUFT 0, __TAG_EXISTS_HTML 0'
X-Spam-Score: 0.9 (/)
X-Scan-Signature: cbb41f2dbf0f142369614756642005e3
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="===============1438752146=="
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============1438752146==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C5D8D5.14759BC0"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C5D8D5.14759BC0
Content-Type: text/plain

Steve,
 
Trying again, as the <expletive deleted> spelling corrector
mangled the first attempt:
 
DNS names are associated with hosts, each of which may have
multiple IP addresses.  While iSCSI names are not the same
as DNS names, the same principle applies.  In the reverse
direction, if there are multiple OS images on a host (e.g.,
courtesy of hardware partitioning or virtualization), each
one that uses iSCSI should have its own iSCSI name.
 
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 
---------------------------------------------------- 
 


  _____  

From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of
Yackey, Steve
Sent: Monday, October 24, 2005 2:25 PM
To: ips@ietf.org
Subject: [Ips] iSCSI Names and Addresses





I have a novice question. 

When rfc3721 says that iscsi names are associated with iscsi nodes (relevant
portion at the end), what does that mean exactly for a host with multiple
network adapter cards ?

For example, a Win2K03 host might have an initiator named 

- iqn.1991-05.com.microsoft:hosta 

- if there are two network adapters, say, 172.20.4.67 and 172.21.4.67 

How would/should the two paths be represented and/or utilized by the
'outside' world ? 
I do not see how the single initiator name is sufficient for what is
described in 3721. 

Thanks in advance, 
Steve 


[portion of 3721 follows] 

RFC 3721 iSCSI Naming and Discovery April 2004 

1. iSCSI Names and Addresses 

The main addressable, discoverable entity in iSCSI is an iSCSI Node. 
An iSCSI node can be either an initiator, a target, or both. The 
rules for constructing an iSCSI name are specified in [RFC3720]. 
This document provides examples of name construction that might be 
used by a naming authority. 

Both targets and initiators require names for the purpose of 
identification, so that iSCSI storage resources can be managed 
regardless of location (address). An iSCSI name is the unique 
identifier for an iSCSI node, and is also the SCSI device name [SAM2] 
of an iSCSI device. The iSCSI name is the principal object used in 
authentication of targets to initiators and initiators to targets. 
This name is also used to identify and manage iSCSI storage 
resources. 

Furthermore, iSCSI names are associated with iSCSI nodes instead of 
with network adapter cards to ensure the free movement of network 
HBAs between hosts without loss of SCSI state information 
(reservations, mode page settings etc) and authorization 
configuration. 

An iSCSI node also has one or more addresses. An iSCSI address 
specifies a single path to an iSCSI node and consists of the iSCSI 
name, plus a transport (TCP) address which uses the following format: 
<domain-name>[:<port>] 
Where <domain-name> is one of: 
- IPv4 address, in dotted decimal notation. Assumed if the name 
contains exactly four numbers, separated by dots (.), where each 
number is in the range 0..255. 
- IPv6 address, in colon-separated hexadecimal notation, as 
specified in [RFC3513] and enclosed in "[" and "]" characters, as 
specified in [RFC2732]. 
- Fully Qualified Domain Name (host name). Assumed if the <domainname> 
is neither an IPv4 nor an IPv6 address. 
For iSCSI targets, the <port> in the address is optional; if 
specified, it is the TCP port on which the target is listening for 
connections. If the <port> is not specified, the default port 3260, 
assigned by IANA, will be assumed. For iSCSI initiators, the <port> 
is omitted. 

Bakke, et al. Informational [Page 3] 




Steve Yackey 
EMC2 Corporation 
1401 Main Street, Suite 350 
Columbia, SC 29201 
803-231-2632 



Steve Yackey 
EMC2 Corporation 
1401 Main Street, Suite 350 
Columbia, SC 29201 
803-231-2632 



------_=_NextPart_001_01C5D8D5.14759BC0
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE>iSCSI Names and Addresses</TITLE>

<META content="MSHTML 6.00.2800.1522" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=213175619-24102005><FONT face="Courier New" 
size=2>Steve,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=213175619-24102005><FONT face="Courier New" 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=213175619-24102005><FONT face="Courier New" 
size=2>Trying again, as the &lt;expletive deleted&gt; spelling 
corrector</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=213175619-24102005><FONT face="Courier New" 
size=2>mangled the first attempt:</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=213175619-24102005><FONT face="Courier New" 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=213175619-24102005><FONT face="Courier New" 
size=2>DNS names are associated with hosts, each of which may 
have</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=213175619-24102005><FONT face="Courier New" 
size=2>multiple IP addresses.&nbsp; While iSCSI names are not the 
same</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=213175619-24102005><FONT face="Courier New" 
size=2>as DNS names, the same principle applies.&nbsp; In the 
reverse</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=213175619-24102005><FONT face="Courier New" 
size=2>direction, if there are multiple OS images on a host 
(e.g.,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=213175619-24102005><FONT face="Courier New" 
size=2>courtesy of hardware partitioning or virtualization), 
each</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=213175619-24102005><FONT face="Courier New" 
size=2>one that uses iSCSI should have its own iSCSI name.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=213175619-24102005><FONT face="Courier New" 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=213175619-24102005><FONT face="Courier New" 
size=2>Thanks,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=213175619-24102005><FONT face="Courier New" 
size=2>--David</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=213175619-24102005></SPAN><SPAN 
class=213175619-24102005><SPAN lang=en-us><FONT face="Courier New" 
size=2>----------------------------------------------------</FONT></SPAN> 
<BR><SPAN lang=en-us><FONT face="Courier New" size=2>David L. Black, Senior 
Technologist</FONT></SPAN> <BR><SPAN lang=en-us><FONT face="Courier New" 
size=2>EMC Corporation, 176 South St., Hopkinton, MA&nbsp; 01748</FONT></SPAN> 
<BR><SPAN lang=en-us><FONT face="Courier New" size=2>+1 (508) 
293-7953&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
FAX: +1 (508) 293-7786</FONT></SPAN> <BR><SPAN lang=en-us><FONT 
face="Courier New" 
size=2>black_david@emc.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Mobile: +1 
(978) 394-7754</FONT></SPAN> <BR><SPAN lang=en-us><FONT face="Courier New" 
size=2>----------------------------------------------------</FONT></SPAN> 
</DIV></SPAN>
<DIV dir=ltr align=left><SPAN class=213175619-24102005><FONT face="Courier New" 
size=2></FONT></SPAN>&nbsp;</DIV><BR>
<BLOCKQUOTE 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
  <HR tabIndex=-1>
  <FONT face=Tahoma size=2><B>From:</B> ips-bounces@ietf.org 
  [mailto:ips-bounces@ietf.org] <B>On Behalf Of </B>Yackey, 
  Steve<BR><B>Sent:</B> Monday, October 24, 2005 2:25 PM<BR><B>To:</B> 
  ips@ietf.org<BR><B>Subject:</B> [Ips] iSCSI Names and 
  Addresses<BR></FONT><BR></DIV>
  <DIV></DIV><BR><BR>
  <P><FONT face=Verdana color=#800000 size=2>I have a novice question.</FONT> 
  </P>
  <P><FONT face=Verdana color=#800000 size=2>When rfc3721 says that iscsi names 
  are associated with iscsi nodes (relevant portion at the end), what does that 
  mean exactly for a host with multiple network adapter cards ?</FONT></P>
  <P><FONT face=Verdana color=#800000 size=2>For example, a Win2K03 host might 
  have an initiator named</FONT> </P>
  <P><FONT face=Verdana color=#800000 size=2>- 
  iqn.1991-05.com.microsoft:hosta</FONT> </P>
  <P><FONT face=Verdana color=#800000 size=2>- if there are two network 
  adapters, say, 172.20.4.67 and 172.21.4.67</FONT> </P>
  <P><FONT face=Verdana color=#800000 size=2>How would/should the two paths be 
  represented and/or utilized by the 'outside' world ?</FONT> <BR><FONT 
  face=Verdana color=#800000 size=2>I do not see how the single initiator name 
  is sufficient for what is described in 3721.</FONT> </P>
  <P><FONT face=Verdana color=#800000 size=2>Thanks in advance,</FONT> <BR><FONT 
  face=Verdana color=#800000 size=2>Steve</FONT> </P><BR>
  <P><FONT face=Verdana color=#800000 size=2>[portion of 3721 follows]</FONT> 
  </P>
  <P><FONT face=Verdana color=#800000 size=2>RFC 3721 iSCSI Naming and Discovery 
  April 2004</FONT> </P>
  <P><FONT face=Verdana color=#800000 size=2>1. iSCSI Names and Addresses</FONT> 
  </P>
  <P><FONT face=Verdana color=#800000 size=2>The main addressable, discoverable 
  entity in iSCSI is an iSCSI Node.</FONT> <BR><FONT face=Verdana color=#800000 
  size=2>An iSCSI node can be either an initiator, a target, or both. The</FONT> 
  <BR><FONT face=Verdana color=#800000 size=2>rules for constructing an iSCSI 
  name are specified in [RFC3720].</FONT> <BR><FONT face=Verdana color=#800000 
  size=2>This document provides examples of name construction that might 
  be</FONT> <BR><FONT face=Verdana color=#800000 size=2>used by a naming 
  authority.</FONT> </P>
  <P><FONT face=Verdana color=#800000 size=2>Both targets and initiators require 
  names for the purpose of</FONT> <BR><FONT face=Verdana color=#800000 
  size=2>identification, so that iSCSI storage resources can be managed</FONT> 
  <BR><FONT face=Verdana color=#800000 size=2>regardless of location (address). 
  An iSCSI name is the unique</FONT> <BR><FONT face=Verdana color=#800000 
  size=2>identifier for an iSCSI node, and is also the SCSI device name 
  [SAM2]</FONT> <BR><FONT face=Verdana color=#800000 size=2>of an iSCSI device. 
  The iSCSI name is the principal object used in</FONT> <BR><FONT face=Verdana 
  color=#800000 size=2>authentication of targets to initiators and initiators to 
  targets.</FONT> <BR><FONT face=Verdana color=#800000 size=2>This name is also 
  used to identify and manage iSCSI storage</FONT> <BR><FONT face=Verdana 
  color=#800000 size=2>resources.</FONT> </P>
  <P><FONT face=Verdana color=#800000 size=2>Furthermore,<U><B> iSCSI names are 
  associated with iSCSI nodes instead of</B></U></FONT> <BR><U><B><FONT 
  face=Verdana color=#800000 size=2>with network adapter 
  cards</FONT></B></U><B></B><FONT face=Verdana color=#800000 size=2> to ensure 
  the free movement of network</FONT> <BR><FONT face=Verdana color=#800000 
  size=2>HBAs between hosts without loss of SCSI state information</FONT> 
  <BR><FONT face=Verdana color=#800000 size=2>(reservations, mode page settings 
  etc) and authorization</FONT> <BR><FONT face=Verdana color=#800000 
  size=2>configuration.</FONT> </P>
  <P><FONT face=Verdana color=#800000 size=2>An iSCSI node also has one or more 
  addresses. An iSCSI address</FONT> <BR><FONT face=Verdana color=#800000 
  size=2>specifies a single path to an iSCSI node and consists of the 
  iSCSI</FONT> <BR><FONT face=Verdana color=#800000 size=2>name, plus a 
  transport (TCP) address which uses the following format:</FONT> <BR><FONT 
  face=Verdana color=#800000 size=2>&lt;domain-name&gt;[:&lt;port&gt;]</FONT> 
  <BR><FONT face=Verdana color=#800000 size=2>Where &lt;domain-name&gt; is one 
  of:</FONT> <BR><FONT face=Verdana color=#800000 size=2>- IPv4 address, in 
  dotted decimal notation. Assumed if the name</FONT> <BR><FONT face=Verdana 
  color=#800000 size=2>contains exactly four numbers, separated by dots (.), 
  where each</FONT> <BR><FONT face=Verdana color=#800000 size=2>number is in the 
  range 0..255.</FONT> <BR><FONT face=Verdana color=#800000 size=2>- IPv6 
  address, in colon-separated hexadecimal notation, as</FONT> <BR><FONT 
  face=Verdana color=#800000 size=2>specified in [RFC3513] and enclosed in "[" 
  and "]" characters, as</FONT> <BR><FONT face=Verdana color=#800000 
  size=2>specified in [RFC2732].</FONT> <BR><FONT face=Verdana color=#800000 
  size=2>- Fully Qualified Domain Name (host name). Assumed if the 
  &lt;domainname&gt;</FONT> <BR><FONT face=Verdana color=#800000 size=2>is 
  neither an IPv4 nor an IPv6 address.</FONT> <BR><FONT face=Verdana 
  color=#800000 size=2>For iSCSI targets, the &lt;port&gt; in the address is 
  optional; if</FONT> <BR><FONT face=Verdana color=#800000 size=2>specified, it 
  is the TCP port on which the target is listening for</FONT> <BR><FONT 
  face=Verdana color=#800000 size=2>connections. If the &lt;port&gt; is not 
  specified, the default port 3260,</FONT> <BR><FONT face=Verdana color=#800000 
  size=2>assigned by IANA, will be assumed. For iSCSI initiators, the 
  &lt;port&gt;</FONT> <BR><FONT face=Verdana color=#800000 size=2>is 
  omitted.</FONT> </P>
  <P><FONT face=Verdana color=#800000 size=2>Bakke, et al. Informational [Page 
  3]</FONT> </P><BR><BR><BR>
  <P><FONT face=Verdana size=2>Steve Yackey</FONT> <BR><FONT face=Verdana 
  size=2>EMC<SUP>2</SUP> Corporation</FONT> <BR><FONT face=Verdana size=2>1401 
  Main Street, Suite 350</FONT> <BR><FONT face=Verdana size=2>Columbia, SC 
  29201</FONT> <BR><FONT face=Verdana size=2>803-</FONT><FONT face=Verdana 
  size=2>231-2632</FONT> </P><BR><BR>
  <P><FONT face=Verdana size=2>Steve Yackey</FONT> <BR><FONT face=Verdana 
  size=2>EMC<SUP>2</SUP> Corporation</FONT> <BR><FONT face=Verdana size=2>1401 
  Main Street, Suite 350</FONT> <BR><FONT face=Verdana size=2>Columbia, SC 
  29201</FONT> <BR><FONT face=Verdana size=2>803-</FONT><FONT face=Verdana 
  size=2>231-2632</FONT> </P><BR></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C5D8D5.14759BC0--


--===============1438752146==
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

--===============1438752146==--




From ips-bounces@ietf.org Mon Oct 24 16:26:37 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EU8tx-0007Hb-3j; Mon, 24 Oct 2005 16:26:37 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EU8tv-0007FP-3X
	for ips@megatron.ietf.org; Mon, 24 Oct 2005 16:26:35 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11908
	for <ips@ietf.org>; Mon, 24 Oct 2005 16:26:20 -0400 (EDT)
Received: from mononoke.wasabisystems.com ([66.173.145.228])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU96g-0004Qz-RR
	for ips@ietf.org; Mon, 24 Oct 2005 16:39:49 -0400
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 857F687081; Mon, 24 Oct 2005 16:26:19 -0400 (EDT)
In-Reply-To: <CEF7DE8455A91D42A0435A429564032956C046@CORPUSMX40B.corp.emc.com>
References: <CEF7DE8455A91D42A0435A429564032956C046@CORPUSMX40B.corp.emc.com>
Mime-Version: 1.0 (Apple Message framework v623)
Message-Id: <58aabd15f2c0bce58bf8693e98748753@wasabisystems.com>
From: William Studenmund <wrstuden@wasabisystems.com>
Subject: Re: [Ips] iSCSI Names and Addresses
Date: Mon, 24 Oct 2005 13:26:13 -0700
To: Yackey_Steve@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: 0a7aa2e6e558383d84476dc338324fab
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="===============1331555101=="
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org


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


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

On Oct 24, 2005, at 11:24 AM, Yackey_Steve@emc.com wrote:

> I have a novice question.
>
> When rfc3721 says that iscsi names are associated with iscsi nodes 
> (relevant portion at the end), what does that mean exactly for a host 
> with multiple network adapter cards ?
>
> For example, a Win2K03 host might have an initiator named
>
> - iqn.1991-05.com.microsoft:hosta
>
> - if there are two network adapters, say, 172.20.4.67 and 172.21.4.67
>
> How would/should the two paths be represented and/or utilized by the 
> 'outside' world ?
> I do not see how the single initiator name is sufficient for what is 
> described in 3721.

Paths and TCP connections, which involve IP addresses, are different 
from sessions, which involve initiator names. Yes, multiple connections 
can make up a session, but connections are a TCP thing and sessions are 
a SCSI thing (the I_T nexus from SAM).

I think part of the problem is that you are asking about the source 
ports for a TCP connection. They really aren't used much outside of the 
box. The only standard way a target would care about them is if an AUTH 
entry were limited to being used only from certain source port ranges.

It would be quite reasonable for one iSCSI session to be handled by 
connections coming from both of the addresses you list above. That 
would give you a measure of multipath support.

Take care,

Bill

--Apple-Mail-4--592965414
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)

iD8DBQFDXUNqDJT2Egh26K0RAt7xAJ9/D6u4LyfB7KBDIo796FhFeqHbMQCfRRsh
T1yfnEPRkmbhdf18Rxc5eQw=
=gjzY
-----END PGP SIGNATURE-----

--Apple-Mail-4--592965414--



--===============1331555101==
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

--===============1331555101==--





From ips-bounces@ietf.org Tue Oct 25 17:13:34 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EUW6w-00082d-NG; Tue, 25 Oct 2005 17:13:34 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EUW6u-00082P-58
	for ips@megatron.ietf.org; Tue, 25 Oct 2005 17:13:32 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15035
	for <ips@ietf.org>; Tue, 25 Oct 2005 17:13:16 -0400 (EDT)
Received: from mononoke.wasabisystems.com ([66.173.145.228])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUWJv-0002GQ-TY
	for ips@ietf.org; Tue, 25 Oct 2005 17:27:00 -0400
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 A4529870A2; Tue, 25 Oct 2005 17:13:22 -0400 (EDT)
In-Reply-To: <435D3ABF.1060506@rose.hp.com>
References: <435D3ABF.1060506@rose.hp.com>
Mime-Version: 1.0 (Apple Message framework v623)
Message-Id: <2ce6df540c2cb3cd3b8d17b3beb58569@wasabisystems.com>
From: William Studenmund <wrstuden@wasabisystems.com>
Subject: Re: [Ips] Clearing the outstanding TTTs 
Date: Tue, 25 Oct 2005 14:13:04 -0700
To: "Mallikarjun C." <cbm@rose.hp.com>
X-Pgp-Agent: GPGMail 1.0 (v30, 10.3)
X-Mailer: Apple Mail (2.623)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f66b12316365a3fe519e75911daf28a8
Cc: IPS <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="===============0866624299=="
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org


--===============0866624299==
Content-Type: multipart/signed; protocol="application/pgp-signature";
	micalg=pgp-sha1; boundary="Apple-Mail-2--503754408"
Content-Transfer-Encoding: 7bit


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

On Oct 24, 2005, at 12:49 PM, Mallikarjun C. wrote:

> Based on the recent list discussion, the implementer's draft requires 
> the task set target behavior also for LU and target resets.  IOW, the 
> new draft requires that the target must wait for all outstanding TTTs 
> to be retired before the TMF is acted on.

To be honest, I am still concerned about this behavior. I don't fully 
see how a sudden abort will severely disrupt an initiator. Yes, there 
will be confusion, but the initiator should be able to cope.

My main concern is that I see the reset operations as being mostly used 
when something is wrong. Be it either failover or where something VERY 
ODD has happened and the initiator wants to reset everything to a known 
state.

As such, there may not be an initiator to retire these TTTs. In the 
case of failover, the initiator(s) other than the one issuing the TMF 
may be off-line or be suffering from a network partition issue. In the 
case of great confusion, an initiator may not know it needs to issue 
data to retire a TTT as it and the target are not on the same page 
anymore.

We have spoken of using timeouts as a way to address this. However this 
case would need timeouts to function correctly in what I see as a 
common use case, which we really haven't done before.

I do see one way a sudden abort could confuse a target, and I can offer 
text to address it. The case I see is where the sudden abort triggers 
SCSI status, the SCSI task is retired at the target, and then all of 
the in-flight Data-Out PDUs generate Rejects. If the SCSI status also 
cleared the task at the initiator, then the initiator will see rejects 
for Data-Outs for a task that has ended. Or worse yet, the ITT will get 
reused, and the initiator will see rejects for the old task and think 
they are for the new one.

My suggestion is that if a target immediately aborts a task (doesn't 
wait for TTT retirement) and there were any outstanding Target Tasks, 
the target MUST NOT consider the ITT unused until the initiator 
acknowledges receipt of the SCSI Command Response. Further, the target 
SHALL ignore all Data-Out PDUs for the task received after the abort. 
The initiator MUST NOT acknowledge receipt of status until it has 
stopped sending data to the target.

The biggest thing I see this text doing is it disentangles servicing 
the TMF and cleaning up state with the initiators. All the tasks will 
be aborted before the TMF is responded to, but the TMF need not wait 
for retirement of the TTTs.

> Bill Galloway has pointed out to me that this language appears to 
> conflict with RFC 3720 clearing effects table.  The RFC table (page 
> 250, bottom of the table) currently says that all incomplete TTTs are 
> cleared on any of the reset flavors.
>
> I believe that this is a consistency issue that needs to be addressed 
> in the new draft (sigh....), so in the absence of any objections, I 
> would like to change the cell entries (in the IT column) for the three 
> reset rows to "N", meaning TTTs are *not* automatically cleared.  They 
> will however be "cleared" by regular means, i.e. on initiator's 
> Data-Out sequence.

I agree that the two should agree. If the wg doesn't like what I 
suggest above, please make this change.

Take care,

Bill

--Apple-Mail-2--503754408
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)

iD8DBQFDXp/wDJT2Egh26K0RAuYWAJ4kq5HXyeca9huDbiU87zr6Mx4engCeIjm4
4XDLmJL53oYp1bHYOWwD5BI=
=x9aX
-----END PGP SIGNATURE-----

--Apple-Mail-2--503754408--



--===============0866624299==
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

--===============0866624299==--





From ips-bounces@ietf.org Tue Oct 25 20:21:01 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EUZ2L-0003Or-RB; Tue, 25 Oct 2005 20:21:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EUZ2K-0003Mw-0e
	for ips@megatron.ietf.org; Tue, 25 Oct 2005 20:21:00 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09016
	for <ips@ietf.org>; Tue, 25 Oct 2005 20:20:45 -0400 (EDT)
Received: from atlrel6.hp.com ([156.153.255.205])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUZFM-00042Y-Bi
	for ips@ietf.org; Tue, 25 Oct 2005 20:34:29 -0400
Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160])
	by atlrel6.hp.com (Postfix) with ESMTP id 66217C90A
	for <ips@ietf.org>; Tue, 25 Oct 2005 20:20:57 -0400 (EDT)
Received: from [127.0.0.1] (sindhu.americas.hpqcorp.net [16.93.44.228])
	by rosemail.rose.hp.com (Postfix) with ESMTP id F33918007
	for <ips@ietf.org>; Tue, 25 Oct 2005 17:20:56 -0700 (PDT)
Message-ID: <435ECBDF.2090108@rose.hp.com>
Date: Tue, 25 Oct 2005 17:20:47 -0700
From: "Mallikarjun C." <cbm@rose.hp.com>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: IPS <ips@ietf.org>
Subject: Re: [Ips] Clearing the outstanding TTTs
References: <435D3ABF.1060506@rose.hp.com>
	<2ce6df540c2cb3cd3b8d17b3beb58569@wasabisystems.com>
In-Reply-To: <2ce6df540c2cb3cd3b8d17b3beb58569@wasabisystems.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a
Content-Transfer-Encoding: 7bit
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

Bill,

Thanks for the feedback.

 > My suggestion is that if a target immediately aborts a task (doesn't
 > wait for TTT retirement) and there were any outstanding Target Tasks,
 > the target MUST NOT consider the ITT unused until the initiator
 > acknowledges receipt of the SCSI Command Response.

That assumes though that there would be a Response.  In fact, the 
default in the case of task set aborts (unless the TAS bit is set to 1) 
is not to return a status for the aborted tasks.

 >Further, the target
 > SHALL ignore all Data-Out PDUs for the task received after the abort.

The problem is that targets cannot really ignore the PDUs per se.  They 
have to be received, parsed and then discarded and/or rejected. In the 
case of iSCSI/iSER, a Data-Out  PDU (i.e. RDMA Read Response)to an 
invalid TTT (i.e. STag) will take the connection down.  Even in 
iSCSI-aware NICs, I assume receiving large Data-Out PDUs with stale TTTs 
is very disruptive to the buffer management.

 > The initiator MUST NOT acknowledge receipt of status until it has
 > stopped sending data to the target.

The problem we are grappling with is not so much the sending of data on 
the initiator end, but of the data in flight.  In multi-connection 
sessions (or worse, in multi-session TMF situations - consider Clear 
Task Set or LU Reset), there is really no good way to account for all 
Data-Out PDUs in flight unless the last PDU in each sequence is received.

Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
StorageWorks Division
Hewlett-Packard MS 5668
Roseville CA 95747
cbm [at] rose.hp.com


William Studenmund wrote:
> On Oct 24, 2005, at 12:49 PM, Mallikarjun C. wrote:
> 
>> Based on the recent list discussion, the implementer's draft requires 
>> the task set target behavior also for LU and target resets.  IOW, the 
>> new draft requires that the target must wait for all outstanding TTTs 
>> to be retired before the TMF is acted on.
> 
> 
> To be honest, I am still concerned about this behavior. I don't fully 
> see how a sudden abort will severely disrupt an initiator. Yes, there 
> will be confusion, but the initiator should be able to cope.
> 
> My main concern is that I see the reset operations as being mostly used 
> when something is wrong. Be it either failover or where something VERY 
> ODD has happened and the initiator wants to reset everything to a known 
> state.
> 
> As such, there may not be an initiator to retire these TTTs. In the case 
> of failover, the initiator(s) other than the one issuing the TMF may be 
> off-line or be suffering from a network partition issue. In the case of 
> great confusion, an initiator may not know it needs to issue data to 
> retire a TTT as it and the target are not on the same page anymore.
> 
> We have spoken of using timeouts as a way to address this. However this 
> case would need timeouts to function correctly in what I see as a common 
> use case, which we really haven't done before.
> 
> I do see one way a sudden abort could confuse a target, and I can offer 
> text to address it. The case I see is where the sudden abort triggers 
> SCSI status, the SCSI task is retired at the target, and then all of the 
> in-flight Data-Out PDUs generate Rejects. If the SCSI status also 
> cleared the task at the initiator, then the initiator will see rejects 
> for Data-Outs for a task that has ended. Or worse yet, the ITT will get 
> reused, and the initiator will see rejects for the old task and think 
> they are for the new one.
> 
> My suggestion is that if a target immediately aborts a task (doesn't 
> wait for TTT retirement) and there were any outstanding Target Tasks, 
> the target MUST NOT consider the ITT unused until the initiator 
> acknowledges receipt of the SCSI Command Response. Further, the target 
> SHALL ignore all Data-Out PDUs for the task received after the abort. 
> The initiator MUST NOT acknowledge receipt of status until it has 
> stopped sending data to the target.
> 
> The biggest thing I see this text doing is it disentangles servicing the 
> TMF and cleaning up state with the initiators. All the tasks will be 
> aborted before the TMF is responded to, but the TMF need not wait for 
> retirement of the TTTs.
> 
>> Bill Galloway has pointed out to me that this language appears to 
>> conflict with RFC 3720 clearing effects table.  The RFC table (page 
>> 250, bottom of the table) currently says that all incomplete TTTs are 
>> cleared on any of the reset flavors.
>>
>> I believe that this is a consistency issue that needs to be addressed 
>> in the new draft (sigh....), so in the absence of any objections, I 
>> would like to change the cell entries (in the IT column) for the three 
>> reset rows to "N", meaning TTTs are *not* automatically cleared.  They 
>> will however be "cleared" by regular means, i.e. on initiator's 
>> Data-Out sequence.
> 
> 
> I agree that the two should agree. If the wg doesn't like what I suggest 
> above, please make this change.
> 
> Take care,
> 
> Bill


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



From ips-bounces@ietf.org Wed Oct 26 17:09:58 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EUsX0-0003NZ-A2; Wed, 26 Oct 2005 17:09:58 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EUsWy-0003NH-Ju
	for ips@megatron.ietf.org; Wed, 26 Oct 2005 17:09:57 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25149
	for <ips@ietf.org>; Wed, 26 Oct 2005 17:09:40 -0400 (EDT)
Received: from mononoke.wasabisystems.com ([66.173.145.228])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUsk9-0004iz-9J
	for ips@ietf.org; Wed, 26 Oct 2005 17:23:36 -0400
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 7AFCC8708B; Wed, 26 Oct 2005 17:09:39 -0400 (EDT)
In-Reply-To: <435ECBDF.2090108@rose.hp.com>
References: <435D3ABF.1060506@rose.hp.com>
	<2ce6df540c2cb3cd3b8d17b3beb58569@wasabisystems.com>
	<435ECBDF.2090108@rose.hp.com>
Mime-Version: 1.0 (Apple Message framework v623)
Message-Id: <c0d4019c597a6100833ad43562af3cf8@wasabisystems.com>
From: William Studenmund <wrstuden@wasabisystems.com>
Subject: Re: [Ips] Clearing the outstanding TTTs
Date: Wed, 26 Oct 2005 14:09:30 -0700
To: "Mallikarjun C." <cbm@rose.hp.com>
X-Pgp-Agent: GPGMail 1.0 (v30, 10.3)
X-Mailer: Apple Mail (2.623)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 31247fb3be228bb596db9127becad0bc
Cc: IPS <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="===============0793995345=="
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org


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


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

On Oct 25, 2005, at 5:20 PM, Mallikarjun C. wrote:

> Bill,
>
> Thanks for the feedback.
>
> > My suggestion is that if a target immediately aborts a task (doesn't
> > wait for TTT retirement) and there were any outstanding Target Tasks,
> > the target MUST NOT consider the ITT unused until the initiator
> > acknowledges receipt of the SCSI Command Response.
>
> That assumes though that there would be a Response.  In fact, the 
> default in the case of task set aborts (unless the TAS bit is set to 
> 1) is not to return a status for the aborted tasks.

Ahhh.. Yes. I was assuming a response. In the case of TAS set to 0, 
what you describe is probably best.

> >Further, the target
> > SHALL ignore all Data-Out PDUs for the task received after the abort.
>
> The problem is that targets cannot really ignore the PDUs per se.  
> They have to be received, parsed and then discarded and/or rejected. 
> In the case of iSCSI/iSER, a Data-Out  PDU (i.e. RDMA Read Response)to 
> an invalid TTT (i.e. STag) will take the connection down.  Even in 
> iSCSI-aware NICs, I assume receiving large Data-Out PDUs with stale 
> TTTs is very disruptive to the buffer management.

Discarded is another way to say what I had in mind for ignore. All of 
the TTTs are flagged to discard arriving data, and do so either until 
the task is done or the initiator acknowledges the task has been 
aborted.

> > The initiator MUST NOT acknowledge receipt of status until it has
> > stopped sending data to the target.
>
> The problem we are grappling with is not so much the sending of data 
> on the initiator end, but of the data in flight.  In multi-connection 
> sessions (or worse, in multi-session TMF situations - consider Clear 
> Task Set or LU Reset), there is really no good way to account for all 
> Data-Out PDUs in flight unless the last PDU in each sequence is 
> received.

Agreed. My thought though is that with the "MUST" above is that 
acknowledging the abort is a definite, implicit acknowledgement of the 
termination of all TTTs on the original task.

For non-iSER, since the data are processed in-order, the 
acknowledgement serves as a barrier in the TCP stream. No data are 
in-flight for that task after the ack.

I'm glad you mentioned multi-session TMF situations as they are what 
drives my thoughts and concerns. :-)

I'm glad to keep talking. There may be another way to address my 
concerns, and I'd love to find it.

Take care,

Bill

--Apple-Mail-4--417568516
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)

iD8DBQFDX/CQDJT2Egh26K0RAm07AJ0QaolvEBWwWMJFtvrY99oIqbxn6wCfSei9
wZ22J0MdMzmtP2AJqteEWeU=
=1JJN
-----END PGP SIGNATURE-----

--Apple-Mail-4--417568516--



--===============0793995345==
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

--===============0793995345==--





From ips-bounces@ietf.org Mon Oct 31 18:27:50 2005
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 1EWj4A-0000MI-DD; Mon, 31 Oct 2005 18:27:50 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EWj48-0000MD-PM
	for ips@megatron.ietf.org; Mon, 31 Oct 2005 18:27:48 -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 SAA19681
	for <ips@ietf.org>; Mon, 31 Oct 2005 18:27:27 -0500 (EST)
Received: from atlrel7.hp.com ([156.153.255.213])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWjIP-0004Qv-IR
	for ips@ietf.org; Mon, 31 Oct 2005 18:42:33 -0500
Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160])
	by atlrel7.hp.com (Postfix) with ESMTP id 0C152180F
	for <ips@ietf.org>; Mon, 31 Oct 2005 18:27:17 -0500 (EST)
Received: from [127.0.0.1] (sindhu.americas.hpqcorp.net [16.93.44.228])
	by rosemail.rose.hp.com (Postfix) with ESMTP id AA48F8007
	for <ips@ietf.org>; Mon, 31 Oct 2005 15:27:16 -0800 (PST)
Message-ID: <4366A84B.7070700@rose.hp.com>
Date: Mon, 31 Oct 2005 15:27:07 -0800
From: "Mallikarjun C." <cbm@rose.hp.com>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: IPS <ips@ietf.org>
Subject: Re: [Ips] Clearing the outstanding TTTs
References: <435D3ABF.1060506@rose.hp.com>
	<2ce6df540c2cb3cd3b8d17b3beb58569@wasabisystems.com>
	<435ECBDF.2090108@rose.hp.com>
	<c0d4019c597a6100833ad43562af3cf8@wasabisystems.com>
In-Reply-To: <c0d4019c597a6100833ad43562af3cf8@wasabisystems.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 34d35111647d654d033d58d318c0d21a
Content-Transfer-Encoding: 7bit
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

Bill,

I hope you are not suggesting conditioning iSCSI protocol behavior based 
on SCSI TAS bit setting.

Also, the process of discarding the Data-out PDUs itself transiently 
consumes some buffers.  And bad things happen for iSCSI/iSER if the 
tagged buffers are not available.  I do not want us to spec different 
task set behaviors for iSCSI-3720 and iSCSI/iSER.

Finally, we have to specify an approach that works for multi-connection 
sessions (where a Response/Ack etc. on one connection says nothing about 
data in flight on others), as well as with operations affecting SCSI 
objects accessible via multiple sessions (clear task set, LU reset etc.).

I would be willing to consider any proposal that meets these 
requirements.  The Implementers' guide details one such (arrived at 
after a lot of discussion on the list).  I am however not sure I 
understand your concerns per se.

Thanks.

Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
StorageWorks Division
Hewlett-Packard MS 5668
Roseville CA 95747
cbm [at] rose.hp.com


William Studenmund wrote:
> On Oct 25, 2005, at 5:20 PM, Mallikarjun C. wrote:
> 
>> Bill,
>>
>> Thanks for the feedback.
>>
>> > My suggestion is that if a target immediately aborts a task (doesn't
>> > wait for TTT retirement) and there were any outstanding Target Tasks,
>> > the target MUST NOT consider the ITT unused until the initiator
>> > acknowledges receipt of the SCSI Command Response.
>>
>> That assumes though that there would be a Response.  In fact, the 
>> default in the case of task set aborts (unless the TAS bit is set to 
>> 1) is not to return a status for the aborted tasks.
> 
> 
> Ahhh.. Yes. I was assuming a response. In the case of TAS set to 0, what 
> you describe is probably best.
> 
>> >Further, the target
>> > SHALL ignore all Data-Out PDUs for the task received after the abort.
>>
>> The problem is that targets cannot really ignore the PDUs per se.  
>> They have to be received, parsed and then discarded and/or rejected. 
>> In the case of iSCSI/iSER, a Data-Out  PDU (i.e. RDMA Read Response)to 
>> an invalid TTT (i.e. STag) will take the connection down.  Even in 
>> iSCSI-aware NICs, I assume receiving large Data-Out PDUs with stale 
>> TTTs is very disruptive to the buffer management.
> 
> 
> Discarded is another way to say what I had in mind for ignore. All of 
> the TTTs are flagged to discard arriving data, and do so either until 
> the task is done or the initiator acknowledges the task has been aborted.
> 
>> > The initiator MUST NOT acknowledge receipt of status until it has
>> > stopped sending data to the target.
>>
>> The problem we are grappling with is not so much the sending of data 
>> on the initiator end, but of the data in flight.  In multi-connection 
>> sessions (or worse, in multi-session TMF situations - consider Clear 
>> Task Set or LU Reset), there is really no good way to account for all 
>> Data-Out PDUs in flight unless the last PDU in each sequence is received.
> 
> 
> Agreed. My thought though is that with the "MUST" above is that 
> acknowledging the abort is a definite, implicit acknowledgement of the 
> termination of all TTTs on the original task.
> 
> For non-iSER, since the data are processed in-order, the acknowledgement 
> serves as a barrier in the TCP stream. No data are in-flight for that 
> task after the ack.
> 
> I'm glad you mentioned multi-session TMF situations as they are what 
> drives my thoughts and concerns. :-)
> 
> I'm glad to keep talking. There may be another way to address my 
> concerns, and I'd love to find it.
> 
> Take care,
> 
> Bill


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



From ips-bounces@ietf.org Mon Oct 31 20:21:29 2005
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 1EWkq9-0003ku-QQ; Mon, 31 Oct 2005 20:21:29 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EWkq8-0003kn-1j
	for ips@megatron.ietf.org; Mon, 31 Oct 2005 20:21:28 -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 UAA01350
	for <ips@ietf.org>; Mon, 31 Oct 2005 20:21:08 -0500 (EST)
Received: from mononoke.wasabisystems.com ([66.173.145.228])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWl4M-0006J5-Ki
	for ips@ietf.org; Mon, 31 Oct 2005 20:36:14 -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 DC909870C0; Mon, 31 Oct 2005 20:21:10 -0500 (EST)
In-Reply-To: <4366A84B.7070700@rose.hp.com>
References: <435D3ABF.1060506@rose.hp.com>
	<2ce6df540c2cb3cd3b8d17b3beb58569@wasabisystems.com>
	<435ECBDF.2090108@rose.hp.com>
	<c0d4019c597a6100833ad43562af3cf8@wasabisystems.com>
	<4366A84B.7070700@rose.hp.com>
Mime-Version: 1.0 (Apple Message framework v623)
Message-Id: <6813935e5bbd5c7511a9d4b311932b81@wasabisystems.com>
From: William Studenmund <wrstuden@wasabisystems.com>
Subject: Re: [Ips] Clearing the outstanding TTTs
Date: Mon, 31 Oct 2005 17:21:01 -0800
To: "Mallikarjun C." <cbm@rose.hp.com>
X-Pgp-Agent: GPGMail 1.0 (v30, 10.3)
X-Mailer: Apple Mail (2.623)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365
Cc: IPS <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="===============1743958701=="
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org


--===============1743958701==
Content-Type: multipart/signed; protocol="application/pgp-signature";
	micalg=pgp-sha1; boundary="Apple-Mail-3-29522541"
Content-Transfer-Encoding: 7bit


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

On Oct 31, 2005, at 3:27 PM, Mallikarjun C. wrote:

> Bill,
>
> I hope you are not suggesting conditioning iSCSI protocol behavior 
> based on SCSI TAS bit setting.

I am proposing a MAY. The main condition for the MAY is that there be a 
way to know if the initiator is aware of the abort. I do not see how it 
is onerous that TAS bit setting, which is one of the controls dictating 
if the initiator is aware of the abort, comes into play. iSCSI has 
spoken about things that SCSI has to support, such as autosense, so we 
have a precedent of one layer influencing another.

Since iSCSI is, strictly speaking, following SAM-2, we could use an 
Asynchronous Event containing a Unit Attention of COMMANDS CLEARED BY 
ANOTHER INITIATOR. We then use acknowelgement of the Async Event as 
indicating that all tasks on all sessions have stopped; unfortunately I 
doubt this will work for MC/S.

We already say you MUST use autosense and you SHOULD use ACA, maybe 
this discussion indicates LUs SHOULD initialize TAS to 1 on reset.

> Also, the process of discarding the Data-out PDUs itself transiently 
> consumes some buffers.  And bad things happen for iSCSI/iSER if the 
> tagged buffers are not available.  I do not want us to spec different 
> task set behaviors for iSCSI-3720 and iSCSI/iSER.

I don't think iSCSI-3720 and iSCSI/iSER will have different task set 
behaviors with this proposal. I agree we should not lightly do that...

The idea is to give the initiator a second way to indicate that it 
agrees the task is dead. The motivation is that it is a way that does 
not require the Task Management Function to wait for the initiator to 
agree the task is dead; between the TMF deciding the task is dead and 
this acknowledgement, any received data will be discarded.

As for non-TCP transports, I think I can think of a few ways to make 
this work. These thoughts are still very rough. They would depend on 
the target's behavior, but since this is a MAY that the target can 
choose, it just avoids the choice if it can't make things work.

> Finally, we have to specify an approach that works for 
> multi-connection sessions (where a Response/Ack etc. on one connection 
> says nothing about data in flight on others), as well as with 
> operations affecting SCSI objects accessible via multiple sessions 
> (clear task set, LU reset etc.).

The multiple sessions case is EXACTLY why I want this.

As for MC/S, I agree that one connection says nothing about data in 
flight on others. But a given command is supposed to be allegiant to 
only one connection at a time, so that the target receiving StatSN 
acknowledgement of a tasks's (aborted) status will say something about 
all of the data for that given task. Iterate over all the tasks, and we 
will know that no data are in flight.

> I would be willing to consider any proposal that meets these 
> requirements.  The Implementers' guide details one such (arrived at 
> after a lot of discussion on the list).  I am however not sure I 
> understand your concerns per se.

If initiator 2 is using TMF LU Reset to clean up after initiator 1 
because initiator 1 caught on fire and exploded, how will initiator 1 
ever clear its outstanding TTTs?

That's my concern - waiting for the TTTs to clear assumes that they 
will actually clear.

I feel that these TMF actions are exactly the thing you want to use 
when things are broken and the TTTs WON'T clear, yet making them wait 
for clearing actually makes that impossible.

To fix this, we either depend on the target timing out the TTTs, the 
target does something we don't talk about yet (like close all the 
connections, thus terminating in-flight data), or the TMF LU reset 
waits forever (or until the repair person comes out and replaces 
initiator 1). We give no guidelines to targets or initiators about 
timeouts (which I think is a fine thing), yet I think this is a case 
where sanity and interoperability would really need it.

My desire is to provide a way, within the spec, to permit the TMF 
actions to complete in a timely manner and also maintain the 
requirement that no status for these aborted commands be generated 
after the TMF completes. And for all of this to happen when one or more 
of the initiators is slow or dead.

Another case where this can arise is when the iSCSI session goes over 
the public internet. We have had a few inter-continental deployments, 
and they give a different view on what exactly is timely behavior.


If we are in a data center, with good connectivity and active hosts, I 
agree that what you have proposed in this document is very nice. It's 
politer than just aborting, and if TAS is 0, it can be very important. 
My concern is what do we do if we have inactive hosts and/or bad 
connectivity.


Thank you for continuing to respond even when you don't understand why 
I'm making a fuss. I appreciate it. Also, you are more clever about 
these issues than I am, and a solution to this issue with your input 
will probably be much better than any without. ;-)

Take care,

Bill

--Apple-Mail-3-29522541
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)

iD8DBQFDZsMCDJT2Egh26K0RAowBAJwMnZAucaMRpxrqs4MAyb73ybMGNQCgkfFj
bB8b4+aLWwwUJkiIfsRcfdM=
=78FX
-----END PGP SIGNATURE-----

--Apple-Mail-3-29522541--



--===============1743958701==
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

--===============1743958701==--