From ips-bounces@ietf.org Sun Jul 01 17:36:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I575J-000577-8G; Sun, 01 Jul 2007 17:35:57 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1I575I-00056x-7h for ips-confirm+ok@megatron.ietf.org; Sun, 01 Jul 2007 17:35:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I575H-00055s-H3 for ips@ietf.org; Sun, 01 Jul 2007 17:35:55 -0400 Received: from mail-gw3.adaptec.com ([216.52.22.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I575C-0006c8-Gp for ips@ietf.org; Sun, 01 Jul 2007 17:35:55 -0400 Received: from aime2k302.adaptec.com (aime2k302.adaptec.com [10.25.8.48]) by mail-gw3.adaptec.com (Spam Firewall) with ESMTP id BDF4214ADE4; Sun, 1 Jul 2007 14:35:48 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ips] iSCSI protocol - use of SendTargets Date: Sun, 1 Jul 2007 14:35:36 -0700 Message-ID: <368FBF3D8437A748BA8222526BF9309901FE5CCC@aime2k302.adaptec.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] iSCSI protocol - use of SendTargets Thread-Index: Ace69Z4XznDzO9BNR+WaSrqqCbF1fwBLmX7Q References: <002601c7ba48$6ec14500$05faa8c0@ivivity.com> From: "Sandars, Ken" To: "Julian Satran" , "Eddy Quicksall" X-Spam-Score: 0.3 (/) X-Scan-Signature: fec852dbea6d068499ed3250edf328e2 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1917894667==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1917894667== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7BC27.C48C4D98" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7BC27.C48C4D98 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Julo, =20 I don't know how many third party iSCSI 'Big Dummies' guides are out there, however, since RFC3720 succinctly describes the fundamentals of the iSCSI model I recommended that as the first choice. =20 I'd have no objection if the author of RFC3720 wanted to advertise his publication here! ;-) =20 Cheers Ken =20 ________________________________ From: Julian Satran [mailto:Julian_Satran@il.ibm.com]=20 Sent: Saturday, 30 June 2007 19:04 To: Eddy Quicksall Cc: ips@ietf.org; Sandars, Ken; Parav Pandit Subject: Re: [Ips] iSCSI protocol - use of SendTargets Ken - what exactly does "Before any author shamelessly plugs their iSCSI publications, I suggest you have a quick re-read of RFC3720. " reffer to? - Julo=20 "Eddy Quicksall" =20 29/06/07 15:24=20 To "Sandars, Ken" , "Parav Pandit" , =20 cc Subject Re: [Ips] iSCSI protocol - use of SendTargets =09 I agree with Ken on the reading below. You may have alredy figured this out but just to try to give a simple answer to your question ... suppose you have built a box that has several targets each with different ip addresses; the user at the initiator could just give one of the ip addresses as the "discovery address"; this could be the address of only one of the targets; the initiator can then log on as a discovery session using that address and use SendTargets to find the names and addresses of all targets.=20 =20 Eddy=20 ----- Original Message -----=20 From: Sandars, Ken =20 To: Parav Pandit ; ips@ietf.org =20 Sent: Thursday, June 07, 2007 5:58 PM=20 Subject: RE: [Ips] iSCSI protocol - use of SendTargets=20 Hi Parav,=20 =20 Before any author shamelessly plugs their iSCSI publications, I suggest you have a quick re-read of RFC3720.=20 =20 In particular, section 3.4 pages 37-40 cover some really important concepts that I think will help your understanding. Then jump to the start of section 3, page 17 for more concepts and definitions.=20 =20 The specifics of the SendTargets command are in Appendix D.=20 =20 HTH=20 Ken=20 ________________________________ From: Parav Pandit [mailto:paravpandit@yahoo.com]=20 Sent: Thursday, 7 June 2007 22:41 To: ips@ietf.org Subject: [Ips] iSCSI protocol - use of SendTargets Hi, I am new to iSCSI protocol and gearing up. Is this the right mailing list to ask questions related to iSCSI protocol? if yes, 1. iSCSI target is identified by the network portal (IP + port). So once the iSCSI target is identified by the network portal and Login to it is successful, why do we need to ask for SendTargets command? TargetName and TargetAddress returned are immaterial (because we already know the target address to which we have logged-in), unless there are multiple addresses for them and failover is required used. Or it is used for communicating different TCP port on which initiators can send TUR, Inquiry, Read, Write commands? What is the expected information from the target in response to SendTargets command? Regards, Parav Pandit ________________________________ It's here! Your new message! Get new email alerts with the free Yahoo! Toolbar. =20 ________________________________ _______________________________________________ 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 ------_=_NextPart_001_01C7BC27.C48C4D98 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Julo,
 
I don't know how many third party = iSCSI 'Big=20 Dummies' guides are out there, however, since RFC3720 succinctly = describes the=20 fundamentals of the iSCSI model I recommended that as the first=20 choice.
 
I'd have no objection if the author of RFC3720 = wanted to=20 advertise his publication here! ;-)
 
Cheers
Ken
 

From: Julian Satran=20 [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, 30 June = 2007=20 19:04
To: Eddy Quicksall
Cc: ips@ietf.org; Sandars, = Ken;=20 Parav Pandit
Subject: Re: [Ips] iSCSI protocol - use of=20 SendTargets


Ken - what exactly does "Before any author shamelessly plugs their iSCSI = publications,=20 I suggest you have a quick re-read of RFC3720. " reffer to? - Julo


"Eddy = Quicksall"=20 <Quicksall_iSCSI@Bellsouth.net>

29/06/07 15:24

To
"Sandars, Ken"=20 <ken_sandars@adaptec.com>, "Parav Pandit"=20 <paravpandit@yahoo.com>, <ips@ietf.org>=20
cc
Subject
Re: [Ips] iSCSI protocol = - use of=20 SendTargets

=




I=20 agree with Ken on the reading below. You may have alredy figured this = out but=20 just to try to give a simple answer to your question ... suppose you = have built=20 a box that has several targets each with different ip addresses; the = user at the=20 initiator could just give one of the ip addresses as the "discovery = address";=20 this could be the address of only one of the targets; the initiator can = then log=20 on as a discovery session using that address and use SendTargets to find = the=20 names and addresses of all targets.
 =20
Eddy
----- Original Message = -----=20
From: Sandars,=20 Ken
To: = Parav=20 Pandit ; ips@ietf.org =
Sent: Thursday, June 07, 2007 5:58 PM
Subject: RE: [Ips] iSCSI protocol - use of = SendTargets=20

Hi Parav, =
 
Before any author=20 shamelessly plugs their iSCSI publications, I suggest you have a quick = re-read=20 of RFC3720.
 
In particular, section 3.4 pages 37-40 cover some = really=20 important concepts that I think will help your understanding. Then jump = to the=20 start of section 3, page 17 for more concepts and definitions. =
 
The = specifics of the=20 SendTargets command are in Appendix D.
 =20
HTH
Ken

From: Parav Pandit=20 [mailto:paravpandit@yahoo.com]
Sent: Thursday, 7 June 2007=20 22:41
To: ips@ietf.org
Subject: [Ips] iSCSI protocol = - use=20 of SendTargets

Hi,

I am=20 new to iSCSI protocol and gearing up.
Is this the right mailing list = to ask=20 questions related to  iSCSI protocol?

if yes,

1. =  iSCSI=20 target is identified by the network portal (IP + port).
So once the = iSCSI=20 target is identified by the network portal and Login to it is = successful, why do=20 we need to ask for SendTargets command?
TargetName and TargetAddress = returned=20 are immaterial (because we already know the target address to which we = have=20 logged-in), unless there are multiple addresses for them and failover is = required used.
Or it is used for communicating different TCP port on = which=20 initiators can send TUR, Inquiry, Read, Write commands?

What is = the=20 expected information from the target in response to SendTargets=20 command?

Regards,
Parav Pandit

It's here! Your new message!
Get new email alerts = with the free=20 Yahoo! Toolbar. =

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

------_=_NextPart_001_01C7BC27.C48C4D98-- --===============1917894667== 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 --===============1917894667==-- From ips-bounces@ietf.org Mon Jul 02 01:54:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5Es8-000331-FK; Mon, 02 Jul 2007 01:54:52 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1I5Es6-0002ep-93 for ips-confirm+ok@megatron.ietf.org; Mon, 02 Jul 2007 01:54:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5Es5-0002cT-NC for ips@ietf.org; Mon, 02 Jul 2007 01:54:49 -0400 Received: from mtagate7.de.ibm.com ([195.212.29.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5Es0-0006hB-QC for ips@ietf.org; Mon, 02 Jul 2007 01:54:49 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate7.de.ibm.com (8.13.8/8.13.8) with ESMTP id l625sit0057948 for ; Mon, 2 Jul 2007 05:54:44 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l625shgp2174990 for ; Mon, 2 Jul 2007 07:54:43 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l625shCD020354 for ; Mon, 2 Jul 2007 07:54:43 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l625shxa020351; Mon, 2 Jul 2007 07:54:43 +0200 In-Reply-To: <368FBF3D8437A748BA8222526BF9309901FE5CCC@aime2k302.adaptec.com> To: "Sandars, Ken" MIME-Version: 1.0 Subject: RE: [Ips] iSCSI protocol - use of SendTargets X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Julian Satran Message-ID: Date: Mon, 2 Jul 2007 08:54:42 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 02/07/2007 08:54:42, Serialize complete at 02/07/2007 08:54:42 X-Spam-Score: 0.1 (/) X-Scan-Signature: 913ee11e7c554f7d4da75d500826397e Cc: ips@ietf.org, Eddy Quicksall X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0595774361==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============0595774361== Content-Type: multipart/alternative; boundary="=_alternative 002077E7C225730C_=" This is a multipart message in MIME format. --=_alternative 002077E7C225730C_= Content-Type: text/plain; charset="US-ASCII" Hard to comment on your statement. Sounds more like a group "denigration" of the authors - and I don't know about any of us doing what you suggest. I am a bit uneasy about this statement - to say the least. Julo "Sandars, Ken" 02/07/07 00:35 To Julian Satran/Haifa/IBM@IBMIL, "Eddy Quicksall" cc , "Parav Pandit" Subject RE: [Ips] iSCSI protocol - use of SendTargets Hi Julo, I don't know how many third party iSCSI 'Big Dummies' guides are out there, however, since RFC3720 succinctly describes the fundamentals of the iSCSI model I recommended that as the first choice. I'd have no objection if the author of RFC3720 wanted to advertise his publication here! ;-) Cheers Ken From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, 30 June 2007 19:04 To: Eddy Quicksall Cc: ips@ietf.org; Sandars, Ken; Parav Pandit Subject: Re: [Ips] iSCSI protocol - use of SendTargets Ken - what exactly does "Before any author shamelessly plugs their iSCSI publications, I suggest you have a quick re-read of RFC3720. " reffer to? - Julo "Eddy Quicksall" 29/06/07 15:24 To "Sandars, Ken" , "Parav Pandit" , cc Subject Re: [Ips] iSCSI protocol - use of SendTargets I agree with Ken on the reading below. You may have alredy figured this out but just to try to give a simple answer to your question ... suppose you have built a box that has several targets each with different ip addresses; the user at the initiator could just give one of the ip addresses as the "discovery address"; this could be the address of only one of the targets; the initiator can then log on as a discovery session using that address and use SendTargets to find the names and addresses of all targets. Eddy ----- Original Message ----- From: Sandars, Ken To: Parav Pandit ; ips@ietf.org Sent: Thursday, June 07, 2007 5:58 PM Subject: RE: [Ips] iSCSI protocol - use of SendTargets Hi Parav, Before any author shamelessly plugs their iSCSI publications, I suggest you have a quick re-read of RFC3720. In particular, section 3.4 pages 37-40 cover some really important concepts that I think will help your understanding. Then jump to the start of section 3, page 17 for more concepts and definitions. The specifics of the SendTargets command are in Appendix D. HTH Ken From: Parav Pandit [mailto:paravpandit@yahoo.com] Sent: Thursday, 7 June 2007 22:41 To: ips@ietf.org Subject: [Ips] iSCSI protocol - use of SendTargets Hi, I am new to iSCSI protocol and gearing up. Is this the right mailing list to ask questions related to iSCSI protocol? if yes, 1. iSCSI target is identified by the network portal (IP + port). So once the iSCSI target is identified by the network portal and Login to it is successful, why do we need to ask for SendTargets command? TargetName and TargetAddress returned are immaterial (because we already know the target address to which we have logged-in), unless there are multiple addresses for them and failover is required used. Or it is used for communicating different TCP port on which initiators can send TUR, Inquiry, Read, Write commands? What is the expected information from the target in response to SendTargets command? Regards, Parav Pandit It's here! Your new message! Get new email alerts with the free Yahoo! Toolbar. _______________________________________________ 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 --=_alternative 002077E7C225730C_= Content-Type: text/html; charset="US-ASCII"
Hard to comment on your statement. Sounds more like a group "denigration" of the authors - and I don't know about any of us doing what you suggest.
I am a bit uneasy about this statement - to say the least.

Julo


"Sandars, Ken" <ken_sandars@adaptec.com>

02/07/07 00:35

To
Julian Satran/Haifa/IBM@IBMIL, "Eddy Quicksall" <Quicksall_iSCSI@Bellsouth.net>
cc
<ips@ietf.org>, "Parav Pandit" <paravpandit@yahoo.com>
Subject
RE: [Ips] iSCSI protocol - use of SendTargets





Hi Julo,
 
I don't know how many third party iSCSI 'Big Dummies' guides are out there, however, since RFC3720 succinctly describes the fundamentals of the iSCSI model I recommended that as the first choice.
 
I'd have no objection if the author of RFC3720 wanted to advertise his publication here! ;-)
 
Cheers
Ken
 

From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, 30 June 2007 19:04
To: Eddy Quicksall
Cc: ips@ietf.org; Sandars, Ken; Parav Pandit
Subject: Re: [Ips] iSCSI protocol - use of SendTargets

Ken - what exactly does "Before any author shamelessly plugs their iSCSI publications, I suggest you have a quick re-read of RFC3720. " reffer to? - Julo

"Eddy Quicksall" <Quicksall_iSCSI@Bellsouth.net>

29/06/07 15:24


To
"Sandars, Ken" <ken_sandars@adaptec.com>, "Parav Pandit" <paravpandit@yahoo.com>, <ips@ietf.org>
cc
Subject
Re: [Ips] iSCSI protocol - use of SendTargets







I agree with Ken on the reading below. You may have alredy figured this out but just to try to give a simple answer to your question ... suppose you have built a box that has several targets each with different ip addresses; the user at the initiator could just give one of the ip addresses as the "discovery address"; this could be the address of only one of the targets; the initiator can then log on as a discovery session using that address and use SendTargets to find the names and addresses of all targets.
 
Eddy
----- Original Message -----
From: Sandars, Ken
To: Parav Pandit ; ips@ietf.org
Sent: Thursday, June 07, 2007 5:58 PM
Subject: RE: [Ips] iSCSI protocol - use of SendTargets

Hi Parav,
 
Before any author shamelessly plugs their iSCSI publications, I suggest you have a quick re-read of RFC3720.
 
In particular, section 3.4 pages 37-40 cover some really important concepts that I think will help your understanding. Then jump to the start of section 3, page 17 for more concepts and definitions.
 
The specifics of the SendTargets command are in Appendix D.
 
HTH
Ken

From: Parav Pandit [mailto:paravpandit@yahoo.com]
Sent: Thursday, 7 June 2007 22:41
To: ips@ietf.org
Subject: [Ips] iSCSI protocol - use of SendTargets

Hi,

I am new to iSCSI protocol and gearing up.
Is this the right mailing list to ask questions related to  iSCSI protocol?

if yes,

1.  iSCSI target is identified by the network portal (IP + port).
So once the iSCSI target is identified by the network portal and Login to it is successful, why do we need to ask for SendTargets command?
TargetName and TargetAddress returned are immaterial (because we already know the target address to which we have logged-in), unless there are multiple addresses for them and failover is required used.
Or it is used for communicating different TCP port on which initiators can send TUR, Inquiry, Read, Write commands?

What is the expected information from the target in response to SendTargets command?

Regards,
Parav Pandit

It's here! Your new message!
Get new email alerts with the free Yahoo! Toolbar.

_______________________________________________
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

--=_alternative 002077E7C225730C_=-- --===============0595774361== 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 --===============0595774361==-- From ips-bounces@ietf.org Mon Jul 02 02:21:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5FHQ-0001pC-AP; Mon, 02 Jul 2007 02:21:00 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1I5FHO-0001ov-B3 for ips-confirm+ok@megatron.ietf.org; Mon, 02 Jul 2007 02:20:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5FHO-0001on-0l for ips@ietf.org; Mon, 02 Jul 2007 02:20:58 -0400 Received: from web30103.mail.mud.yahoo.com ([209.191.69.35]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I5FH8-0003cQ-RH for ips@ietf.org; Mon, 02 Jul 2007 02:20:58 -0400 Received: (qmail 94101 invoked by uid 60001); 2 Jul 2007 06:20:42 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=kOq2oFWK/qlokkZa2MEzdDWvXivApMgtWQ8chCsYv98vUpSKZengiDRrR1pkWIFi+W8n1X61TIHLf69CRIl3GoZ5pmbHDZWlgeCeK7inOrgoQcaO6Nerua8evV7PrTSKNroPwSeLIPmNgjcK+MvlikO3hL1uSt+Tgqan+IQ5nY8=; X-YMail-OSG: WJE0OYYVM1mk75RfatVwctJNzN3GG8Ul3YvBtWjBDqqD6INIdOFmG2bDfwgz6dXVYlDowWt9nIxBsDkAisz2jLQd4gzkeUyHgSwEwFs_7mMugRGCSiZ_I8Z4Uto3Zw-- Received: from [61.12.16.156] by web30103.mail.mud.yahoo.com via HTTP; Sun, 01 Jul 2007 23:20:41 PDT Date: Sun, 1 Jul 2007 23:20:41 -0700 (PDT) From: Parav Pandit Subject: RE: [Ips] iSCSI protocol - use of SendTargets To: Julian Satran , "Sandars, Ken" In-Reply-To: MIME-Version: 1.0 Message-ID: <230506.93285.qm@web30103.mail.mud.yahoo.com> X-Spam-Score: 0.3 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: ips@ietf.org, Eddy Quicksall X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2098074971==" Errors-To: ips-bounces@ietf.org --===============2098074971== Content-Type: multipart/alternative; boundary="0-565612337-1183357241=:93285" Content-Transfer-Encoding: 8bit --0-565612337-1183357241=:93285 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi all, I apologize for asking such basic question on this mailing list. I would read the iSCSI RFC 3720 by myself. I thought of sharing and gaining knowledge through this mailing list faster, but now I understand it may not be the perfect for starters. Thanks a lot for your the kind support, suggestions and information. Regards, Parav Pandit Julian Satran wrote: Hard to comment on your statement. Sounds more like a group "denigration" of the authors - and I don't know about any of us doing what you suggest. I am a bit uneasy about this statement - to say the least. Julo "Sandars, Ken" 02/07/07 00:35 To Julian Satran/Haifa/IBM@IBMIL, "Eddy Quicksall" cc , "Parav Pandit" Subject RE: [Ips] iSCSI protocol - use of SendTargets Hi Julo, I don't know how many third party iSCSI 'Big Dummies' guides are out there, however, since RFC3720 succinctly describes the fundamentals of the iSCSI model I recommended that as the first choice. I'd have no objection if the author of RFC3720 wanted to advertise his publication here! ;-) Cheers Ken --------------------------------- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, 30 June 2007 19:04 To: Eddy Quicksall Cc: ips@ietf.org; Sandars, Ken; Parav Pandit Subject: Re: [Ips] iSCSI protocol - use of SendTargets Ken - what exactly does "Before any author shamelessly plugs their iSCSI publications, I suggest you have a quick re-read of RFC3720. " reffer to? - Julo "Eddy Quicksall" 29/06/07 15:24 To "Sandars, Ken" , "Parav Pandit" , cc Subject Re: [Ips] iSCSI protocol - use of SendTargets I agree with Ken on the reading below. You may have alredy figured this out but just to try to give a simple answer to your question ... suppose you have built a box that has several targets each with different ip addresses; the user at the initiator could just give one of the ip addresses as the "discovery address"; this could be the address of only one of the targets; the initiator can then log on as a discovery session using that address and use SendTargets to find the names and addresses of all targets. Eddy ----- Original Message ----- From: Sandars, Ken To: Parav Pandit ; ips@ietf.org Sent: Thursday, June 07, 2007 5:58 PM Subject: RE: [Ips] iSCSI protocol - use of SendTargets Hi Parav, Before any author shamelessly plugs their iSCSI publications, I suggest you have a quick re-read of RFC3720. In particular, section 3.4 pages 37-40 cover some really important concepts that I think will help your understanding. Then jump to the start of section 3, page 17 for more concepts and definitions. The specifics of the SendTargets command are in Appendix D. HTH Ken --------------------------------- From: Parav Pandit [mailto:paravpandit@yahoo.com] Sent: Thursday, 7 June 2007 22:41 To: ips@ietf.org Subject: [Ips] iSCSI protocol - use of SendTargets Hi, I am new to iSCSI protocol and gearing up. Is this the right mailing list to ask questions related to iSCSI protocol? if yes, 1. iSCSI target is identified by the network portal (IP + port). So once the iSCSI target is identified by the network portal and Login to it is successful, why do we need to ask for SendTargets command? TargetName and TargetAddress returned are immaterial (because we already know the target address to which we have logged-in), unless there are multiple addresses for them and failover is required used. Or it is used for communicating different TCP port on which initiators can send TUR, Inquiry, Read, Write commands? What is the expected information from the target in response to SendTargets command? Regards, Parav Pandit --------------------------------- It's here! Your new message! Get new email alerts with the free Yahoo! Toolbar. --------------------------------- _______________________________________________ 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 --------------------------------- Need a vacation? Get great deals to amazing places on Yahoo! Travel. --0-565612337-1183357241=:93285 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi all,

I apologize for asking such basic question on this mailing list. I would read the iSCSI RFC 3720 by myself.

I thought of sharing and gaining knowledge through this mailing list faster, but now I understand it may not be the perfect for starters.

Thanks a lot for your the kind support, suggestions and information.

Regards,
Parav Pandit




Julian Satran <Julian_Satran@il.ibm.com> wrote:


Hard to comment on your statement. Sounds more like a group "denigration" of the authors - and I don't know about any of us doing what you suggest.
I am a bit uneasy about this statement - to say the least.

Julo


"Sandars, Ken" <ken_sandars@adaptec.com>
02/07/07 00:35
To
Julian Satran/Haifa/IBM@IBMIL, "Eddy Quicksall" <Quicksall_iSCSI@Bellsouth.net>
cc
<ips@ietf.org>, "Parav Pandit" <paravpandit@yahoo.com>
Subject
RE: [Ips] iSCSI protocol - use of SendTargets







Hi Julo,
 
I don't know how many third party iSCSI 'Big Dummies' guides are out there, however, since RFC3720 succinctly describes the fundamentals of the iSCSI model I recommended that as the first choice.
 
I'd have no objection if the author of RFC3720 wanted to advertise his publication here! ;-)
 
Cheers
Ken
 

From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, 30 June 2007 19:04
To: Eddy Quicksall
Cc: ips@ietf.org; Sandars, Ken; Parav Pandit
Subject: Re: [Ips] iSCSI protocol - use of SendTargets

Ken - what exactly does "Before any author shamelessly plugs their iSCSI publications, I suggest you have a quick re-read of RFC3720. " reffer to? - Julo

"Eddy Quicksall" <Quicksall_iSCSI@Bellsouth.net>
29/06/07 15:24

To
"Sandars, Ken" <ken_sandars@adaptec.com>, "Parav Pandit" <paravpandit@yahoo.com>, <ips@ietf.org>
cc
Subject
Re: [Ips] iSCSI protocol - use of SendTargets









I agree with Ken on the reading below. You may have alredy figured this out but just to try to give a simple answer to your question ... suppose you have built a box that has several targets each with different ip addresses; the user at the initiator could just give one of the ip addresses as the "discovery address"; this could be the address of only one of the targets; the initiator can then log on as a discovery session using that address and use SendTargets to find the names and addresses of all targets.
 
Eddy
----- Original Message -----
From: Sandars, Ken
To: Parav Pandit ; ips@ietf.org
Sent: Thursday, June 07, 2007 5:58 PM
Subject: RE: [Ips] iSCSI protocol - use of SendTargets

Hi Parav,
 
Before any author shamelessly plugs their iSCSI publications, I suggest you have a quick re-read of RFC3720.
 
In particular, section 3.4 pages 37-40 cover some really important concepts that I think will help your understanding. Then jump to the start of section 3, page 17 for more concepts and definitions.
 
The specifics of the SendTargets command are in Appendix D.
 
HTH
Ken

From: Parav Pandit [mailto:paravpandit@yahoo.com]
Sent: Thursday, 7 June 2007 22:41
To: ips@ietf.org
Subject: [Ips] iSCSI protocol - use of SendTargets

Hi,

I am new to iSCSI protocol and gearing up.
Is this the right mailing list to ask questions related to  iSCSI protocol?

if yes,

1.  iSCSI target is identified by the network portal (IP + port).
So once the iSCSI target is identified by the network portal and Login to it is successful, why do we need to ask for SendTargets command?
TargetName and TargetAddress returned are immaterial (because we already know the target address to which we have logged-in), unless there are multiple addresses for them and failover is required used.
Or it is used for communicating different TCP port on which initiators can send TUR, Inquiry, Read, Write commands?

What is the expected information from the target in response to SendTargets command?

Regards,
Parav Pandit
It's here! Your new message!
Get new email alerts with the free Yahoo! Toolbar.
_______________________________________________
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

Need a vacation? Get great deals to amazing places on Yahoo! Travel. --0-565612337-1183357241=:93285-- --===============2098074971== 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 --===============2098074971==-- From ips-bounces@ietf.org Mon Jul 02 08:47:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5LJf-00087J-Mc; Mon, 02 Jul 2007 08:47:43 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1I5LJe-00085t-SH for ips-confirm+ok@megatron.ietf.org; Mon, 02 Jul 2007 08:47:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5LJe-00085l-IQ for ips@ietf.org; Mon, 02 Jul 2007 08:47:42 -0400 Received: from imf22aec.mail.bellsouth.net ([205.152.59.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5LJ2-0000Hv-82 for ips@ietf.org; Mon, 02 Jul 2007 08:47:42 -0400 Received: from ibm65aec.bellsouth.net ([74.234.39.159]) by imf22aec.mail.bellsouth.net with ESMTP id <20070702124704.VNUY8445.imf22aec.mail.bellsouth.net@ibm65aec.bellsouth.net> for ; Mon, 2 Jul 2007 08:47:04 -0400 Received: from IVVTDKV0981 ([74.234.39.159]) by ibm65aec.bellsouth.net with SMTP id <20070702124703.XQSP7077.ibm65aec.bellsouth.net@IVVTDKV0981>; Mon, 2 Jul 2007 08:47:03 -0400 Message-ID: <001e01c7bca7$16a65bb0$05faa8c0@ivivity.com> From: "Eddy Quicksall" To: "Parav Pandit" , "Julian Satran" , "Sandars, Ken" References: <230506.93285.qm@web30103.mail.mud.yahoo.com> Subject: Re: [Ips] iSCSI protocol - use of SendTargets Date: Mon, 2 Jul 2007 08:47:02 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.3 (/) X-Scan-Signature: 233de1b21593fc0f4cdf285406dca0da Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1787289648==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1787289648== Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01C7BC85.8F69DB20" This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C7BC85.8F69DB20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable For myself, I don't mind such questions. In this case I think your basic = question was "why" not "how". Eddy ----- Original Message -----=20 From: Parav Pandit=20 To: Julian Satran ; Sandars, Ken=20 Cc: ips@ietf.org ; Parav Pandit ; Eddy Quicksall=20 Sent: Monday, July 02, 2007 2:20 AM Subject: RE: [Ips] iSCSI protocol - use of SendTargets Hi all, I apologize for asking such basic question on this mailing list. I = would read the iSCSI RFC 3720 by myself.=20 I thought of sharing and gaining knowledge through this mailing list = faster, but now I understand it may not be the perfect for starters. Thanks a lot for your the kind support, suggestions and information. Regards, Parav Pandit Julian Satran wrote: Hard to comment on your statement. Sounds more like a group = "denigration" of the authors - and I don't know about any of us doing = what you suggest.=20 I am a bit uneasy about this statement - to say the least.=20 Julo=20 "Sandars, Ken" =20 02/07/07 00:35 To Julian Satran/Haifa/IBM@IBMIL, "Eddy = Quicksall" =20 cc , "Parav Pandit" = =20 Subject RE: [Ips] iSCSI protocol - use of SendTargets=20 =20 =20 =20 Hi Julo,=20 =20 I don't know how many third party iSCSI 'Big Dummies' guides are out = there, however, since RFC3720 succinctly describes the fundamentals of = the iSCSI model I recommended that as the first choice.=20 =20 I'd have no objection if the author of RFC3720 wanted to advertise = his publication here! ;-)=20 =20 Cheers=20 Ken=20 =20 -------------------------------------------------------------------------= --- From: Julian Satran [mailto:Julian_Satran@il.ibm.com]=20 Sent: Saturday, 30 June 2007 19:04 To: Eddy Quicksall Cc: ips@ietf.org; Sandars, Ken; Parav Pandit Subject: Re: [Ips] iSCSI protocol - use of SendTargets Ken - what exactly does "Before any author shamelessly plugs their = iSCSI publications, I suggest you have a quick re-read of RFC3720. " = reffer to? - Julo=20 "Eddy Quicksall" =20 29/06/07 15:24 =20 To "Sandars, Ken" , "Parav = Pandit" , =20 cc=20 =20 Subject Re: [Ips] iSCSI protocol - use of SendTargets=20 =20 =20 =20 I agree with Ken on the reading below. You may have alredy figured = this out but just to try to give a simple answer to your question ... = suppose you have built a box that has several targets each with = different ip addresses; the user at the initiator could just give one of = the ip addresses as the "discovery address"; this could be the address = of only one of the targets; the initiator can then log on as a discovery = session using that address and use SendTargets to find the names and = addresses of all targets.=20 =20 Eddy=20 ----- Original Message -----=20 From: Sandars, Ken=20 To: Parav Pandit ; ips@ietf.org=20 Sent: Thursday, June 07, 2007 5:58 PM=20 Subject: RE: [Ips] iSCSI protocol - use of SendTargets=20 Hi Parav,=20 =20 Before any author shamelessly plugs their iSCSI publications, I = suggest you have a quick re-read of RFC3720.=20 =20 In particular, section 3.4 pages 37-40 cover some really important = concepts that I think will help your understanding. Then jump to the = start of section 3, page 17 for more concepts and definitions.=20 =20 The specifics of the SendTargets command are in Appendix D.=20 =20 HTH=20 Ken=20 -------------------------------------------------------------------------= --- From: Parav Pandit [mailto:paravpandit@yahoo.com]=20 Sent: Thursday, 7 June 2007 22:41 To: ips@ietf.org Subject: [Ips] iSCSI protocol - use of SendTargets Hi, I am new to iSCSI protocol and gearing up. Is this the right mailing list to ask questions related to iSCSI = protocol? if yes, 1. iSCSI target is identified by the network portal (IP + port). So once the iSCSI target is identified by the network portal and = Login to it is successful, why do we need to ask for SendTargets = command? TargetName and TargetAddress returned are immaterial (because we = already know the target address to which we have logged-in), unless = there are multiple addresses for them and failover is required used. Or it is used for communicating different TCP port on which = initiators can send TUR, Inquiry, Read, Write commands? What is the expected information from the target in response to = SendTargets command? Regards, Parav Pandit=20 -------------------------------------------------------------------------= --- It's here! Your new message! Get new email alerts with the free Yahoo! Toolbar.=20 -------------------------------------------------------------------------= --- _______________________________________________ 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=20 -------------------------------------------------------------------------= ----- Need a vacation? Get great deals to amazing places on Yahoo! Travel. ------=_NextPart_000_001B_01C7BC85.8F69DB20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
For myself, I don't mind such questions. In this = case I think=20 your basic question was "why" not "how".
 
Eddy
----- Original Message -----
From:=20 Parav=20 Pandit
To: Julian Satran ; Sandars,=20 Ken
Cc: ips@ietf.org ; Parav Pandit ; Eddy Quicksall =
Sent: Monday, July 02, 2007 = 2:20 AM
Subject: RE: [Ips] iSCSI = protocol - use=20 of SendTargets

Hi all,

I apologize for asking such basic = question on=20 this mailing list. I would read the iSCSI RFC 3720 by myself. =

I=20 thought of sharing and gaining knowledge through this mailing list = faster, but=20 now I understand it may not be the perfect for starters.

Thanks = a lot=20 for your the kind support, suggestions and=20 information.

Regards,
Parav Pandit




Julian=20 Satran <Julian_Satran@il.ibm.com>= =20 wrote:

Hard to comment on your statement. Sounds = more like a=20 group "denigration" of the authors - and I don't know about any of = us doing=20 what you suggest.
I am a = bit uneasy=20 about this statement - to say the least.

Julo


"Sandars, = Ken" <ken_sandars@adaptec.com>=20
02/07/07 00:35 =
To
 Julian = Satran/Haifa/IBM@IBMIL,=20 "Eddy Quicksall" = <Quicksall_iSCSI@Bellsouth.net>=20
cc
 <ips@ietf.org>, = "Parav=20 Pandit" <paravpandit@yahoo.com>
Subject
 RE: [Ips] iSCSI = protocol - use=20 of SendTargets

=





<= BR>Hi Julo,
 =20
I don't know how many = third party=20 iSCSI 'Big Dummies' guides are out there, however, since RFC3720 = succinctly=20 describes the fundamentals of the iSCSI model I recommended that as = the=20 first choice.
 
I'd have no objection if the author of RFC3720 = wanted to=20 advertise his publication here! ;-)
 =20
Cheers
Ken
  =

From: Julian Satran=20 [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, 30 June = 2007=20 19:04
To: Eddy Quicksall
Cc: ips@ietf.org; = Sandars, Ken;=20 Parav Pandit
Subject: Re: [Ips] iSCSI protocol - use of=20 SendTargets


Ken - what exactly does "Before any author shamelessly plugs their iSCSI = publications, I=20 suggest you have a quick re-read of RFC3720. " reffer to? - Julo





I agree with Ken on the = reading=20 below. You may have alredy figured this out but just to try to give = a simple=20 answer to your question ... suppose you have built a box that has = several=20 targets each with different ip addresses; the user at the initiator = could=20 just give one of the ip addresses as the "discovery address"; this = could be=20 the address of only one of the targets; the initiator can then log = on as a=20 discovery session using that address and use SendTargets to find the = names=20 and addresses of all targets. =
 
Eddy
----- Original Message = -----=20
From: Sandars, Ken =
To:=20 Parav Pandit ; ips@ietf.org =
Sent:=20 Thursday, June 07, 2007 5:58 PM
Subject: RE: [Ips] iSCSI = protocol=20 - use of SendTargets

Hi=20 Parav,
 
Before any author shamelessly plugs their iSCSI = publications, I=20 suggest you have a quick re-read of RFC3720.
 
In=20 particular, section 3.4 pages 37-40 cover some really important = concepts=20 that I think will help your understanding. Then jump to the start of = section=20 3, page 17 for more concepts and definitions.=20
 
The = specifics of the=20 SendTargets command are in Appendix D.=20
 
HTH
Ken

From: Parav Pandit=20 [mailto:paravpandit@yahoo.com]
Sent: Thursday, 7 June = 2007=20 22:41
To: ips@ietf.org
Subject: [Ips] iSCSI = protocol -=20 use of SendTargets

Hi,

I am new = to iSCSI=20 protocol and gearing up.
Is this the right mailing list to ask = questions=20 related to  iSCSI protocol?

if yes,

1. =  iSCSI target=20 is identified by the network portal (IP + port).
So once the = iSCSI target=20 is identified by the network portal and Login to it is successful, = why do we=20 need to ask for SendTargets command?
TargetName and TargetAddress = returned are immaterial (because we already know the target address = to which=20 we have logged-in), unless there are multiple addresses for them and = failover is required used.
Or it is used for communicating = different TCP=20 port on which initiators can send TUR, Inquiry, Read, Write=20 commands?

What is the expected information from the target in = response to SendTargets command?

Regards,
Parav = Pandit=20
It's here! Your new message!
Get new email alerts with the=20 free Yahoo! Toolbar.
_______________________________________________
Ips=20 mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips= _______________________________________________
Ips = mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips= =20

Need a vacation? Get=20 great deals to amazing places on Yahoo! Travel. = ------=_NextPart_000_001B_01C7BC85.8F69DB20-- --===============1787289648== 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 --===============1787289648==-- From ips-bounces@ietf.org Mon Jul 02 10:03:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5MUj-0002ho-M3; Mon, 02 Jul 2007 10:03:13 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1I5MUi-0002dv-4X for ips-confirm+ok@megatron.ietf.org; Mon, 02 Jul 2007 10:03:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5MUh-0002dn-Of for ips@ietf.org; Mon, 02 Jul 2007 10:03:11 -0400 Received: from mtagate2.de.ibm.com ([195.212.29.151]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I5MUg-0007vS-TI for ips@ietf.org; Mon, 02 Jul 2007 10:03:11 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.13.8/8.13.8) with ESMTP id l62E11in085464 for ; Mon, 2 Jul 2007 14:01:01 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l62E118E1773794 for ; Mon, 2 Jul 2007 16:01:01 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l62E11YT024049 for ; Mon, 2 Jul 2007 16:01:01 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l62E10tU024046; Mon, 2 Jul 2007 16:01:01 +0200 In-Reply-To: <230506.93285.qm@web30103.mail.mud.yahoo.com> To: Parav Pandit MIME-Version: 1.0 Subject: RE: [Ips] iSCSI protocol - use of SendTargets X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Julian Satran Message-ID: Date: Mon, 2 Jul 2007 17:00:59 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 02/07/2007 17:01:00, Serialize complete at 02/07/2007 17:01:00 X-Spam-Score: 0.1 (/) X-Scan-Signature: 213cf0777a99c4ccdd94bb20659dd28c Cc: ips@ietf.org, Eddy Quicksall , "Sandars, Ken" X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2078646978==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============2078646978== Content-Type: multipart/alternative; boundary="=_alternative 004CFCB5C225730C_=" This is a multipart message in MIME format. --=_alternative 004CFCB5C225730C_= Content-Type: text/plain; charset="US-ASCII" Parav, Nobody minds any sort of question. As for me getting annoyed it was just about an unwarranted innuendo by Ken. Julo Parav Pandit 02/07/07 09:20 To Julian Satran/Haifa/IBM@IBMIL, "Sandars, Ken" cc ips@ietf.org, Parav Pandit , Eddy Quicksall Subject RE: [Ips] iSCSI protocol - use of SendTargets Hi all, I apologize for asking such basic question on this mailing list. I would read the iSCSI RFC 3720 by myself. I thought of sharing and gaining knowledge through this mailing list faster, but now I understand it may not be the perfect for starters. Thanks a lot for your the kind support, suggestions and information. Regards, Parav Pandit Julian Satran wrote: Hard to comment on your statement. Sounds more like a group "denigration" of the authors - and I don't know about any of us doing what you suggest. I am a bit uneasy about this statement - to say the least. Julo "Sandars, Ken" 02/07/07 00:35 To Julian Satran/Haifa/IBM@IBMIL, "Eddy Quicksall" cc , "Parav Pandit" Subject RE: [Ips] iSCSI protocol - use of SendTargets Hi Julo, I don't know how many third party iSCSI 'Big Dummies' guides are out there, however, since RFC3720 succinctly describes the fundamentals of the iSCSI model I recommended that as the first choice. I'd have no objection if the author of RFC3720 wanted to advertise his publication here! ;-) Cheers Ken From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, 30 June 2007 19:04 To: Eddy Quicksall Cc: ips@ietf.org; Sandars, Ken; Parav Pandit Subject: Re: [Ips] iSCSI protocol - use of SendTargets Ken - what exactly does "Before any author shamelessly plugs their iSCSI publications, I suggest you have a quick re-read of RFC3720. " reffer to? - Julo "Eddy Quicksall" 29/06/07 15:24 To "Sandars, Ken" , "Parav Pandit" , cc Subject Re: [Ips] iSCSI protocol - use of SendTargets I agree with Ken on the reading below. You may have alredy figured this out but just to try to give a simple answer to your question ... suppose you have built a box that has several targets each with different ip addresses; the user at the initiator could just give one of the ip addresses as the "discovery address"; this could be the address of only one of the targets; the initiator can then log on as a discovery session using that address and use SendTargets to find the names and addresses of all targets. Eddy ----- Original Message ----- From: Sandars, Ken To: Parav Pandit ; ips@ietf.org Sent: Thursday, June 07, 2007 5:58 PM Subject: RE: [Ips] iSCSI protocol - use of SendTargets Hi Parav, Before any author shamelessly plugs their iSCSI publications, I suggest you have a quick re-read of RFC3720. In particular, section 3.4 pages 37-40 cover some really important concepts that I think will help your understanding. Then jump to the start of section 3, page 17 for more concepts and definitions. The specifics of the SendTargets command are in Appendix D. HTH Ken From: Parav Pandit [mailto:paravpandit@yahoo.com] Sent: Thursday, 7 June 2007 22:41 To: ips@ietf.org Subject: [Ips] iSCSI protocol - use of SendTargets Hi, I am new to iSCSI protocol and gearing up. Is this the right mailing list to ask questions related to iSCSI protocol? if yes, 1. iSCSI target is identified by the network portal (IP + port). So once the iSCSI target is identified by the network portal and Login to it is successful, why do we need to ask for SendTargets command? TargetName and TargetAddress returned are immaterial (because we already know the target address to which we have logged-in), unless there are multiple addresses for them and failover is required used. Or it is used for communicating different TCP port on which initiators can send TUR, Inquiry, Read, Write commands? What is the expected information from the target in response to SendTargets command? Regards, Parav Pandit It's here! Your new message! Get new email alerts with the free Yahoo! Toolbar. _______________________________________________ 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 Need a vacation? Get great deals to amazing places on Yahoo! Travel. --=_alternative 004CFCB5C225730C_= Content-Type: text/html; charset="US-ASCII"
Parav,

Nobody minds any sort of question. As for me getting annoyed it was just about an unwarranted innuendo by Ken.

Julo


"Eddy = Quicksall"=20 <Quicksall_iSCSI@Bellsouth.net>
29/06/07 = 15:24=20

To
 "Sandars, Ken"=20 <ken_sandars@adaptec.com>, "Parav Pandit"=20 <paravpandit@yahoo.com>, = <ips@ietf.org>
cc
Subject
 Re: [Ips] iSCSI = protocol - use=20 of SendTargets

Parav Pandit <paravpandit@yahoo.com>

02/07/07 09:20

To
Julian Satran/Haifa/IBM@IBMIL, "Sandars, Ken" <ken_sandars@adaptec.com>
cc
ips@ietf.org, Parav Pandit <paravpandit@yahoo.com>, Eddy Quicksall <Quicksall_iSCSI@Bellsouth.net>
Subject
RE: [Ips] iSCSI protocol - use of SendTargets





Hi all,

I apologize for asking such basic question on this mailing list. I would read the iSCSI RFC 3720 by myself.

I thought of sharing and gaining knowledge through this mailing list faster, but now I understand it may not be the perfect for starters.

Thanks a lot for your the kind support, suggestions and information.

Regards,
Parav Pandit




Julian Satran <Julian_Satran@il.ibm.com> wrote:

Hard to comment on your statement. Sounds more like a group "denigration" of the authors - and I don't know about any of us doing what you suggest.
I am a bit uneasy about this statement - to say the least.

Julo

"Sandars, Ken" <ken_sandars@adaptec.com>
02/07/07 00:35
To
Julian Satran/Haifa/IBM@IBMIL, "Eddy Quicksall" <Quicksall_iSCSI@Bellsouth.net>
cc
<ips@ietf.org>, "Parav Pandit" <paravpandit@yahoo.com>
Subject
RE: [Ips] iSCSI protocol - use of SendTargets







Hi Julo,
 
I don't know how many third party iSCSI 'Big Dummies' guides are out there, however, since RFC3720 succinctly describes the fundamentals of the iSCSI model I recommended that as the first choice.
 
I'd have no objection if the author of RFC3720 wanted to advertise his publication here! ;-)
 
Cheers
Ken
 
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, 30 June 2007 19:04
To: Eddy Quicksall
Cc: ips@ietf.org; Sandars, Ken; Parav Pandit
Subject: Re: [Ips] iSCSI protocol - use of SendTargets


Ken - what exactly does "Before any author shamelessly plugs their iSCSI publications, I suggest you have a quick re-read of RFC3720. " reffer to? - Julo
"Eddy Quicksall" <Quicksall_iSCSI@Bellsouth.net>
29/06/07 15:24
To
"Sandars, Ken" <ken_sandars@adaptec.com>, "Parav Pandit" <paravpandit@yahoo.com>, <ips@ietf.org>
cc
Subject
Re: [Ips] iSCSI protocol - use of SendTargets






I agree with Ken on the reading below. You may have alredy figured this out but just to try to give a simple answer to your question ... suppose you have built a box that has several targets each with different ip addresses; the user at the initiator could just give one of the ip addresses as the "discovery address"; this could be the address of only one of the targets; the initiator can then log on as a discovery session using that address and use SendTargets to find the names and addresses of all targets.

Eddy
----- Original Message -----
From: Sandars, Ken
To: Parav Pandit ; ips@ietf.org
Sent: Thursday, June 07, 2007 5:58 PM
Subject: RE: [Ips] iSCSI protocol - use of SendTargets

Hi Parav,

Before any author shamelessly plugs their iSCSI publications, I suggest you have a quick re-read of RFC3720.

In particular, section 3.4 pages 37-40 cover some really important concepts that I think will help your understanding. Then jump to the start of section 3, page 17 for more concepts and definitions.

The specifics of the SendTargets command are in Appendix D.

HTH
Ken

From: Parav Pandit [mailto:paravpandit@yahoo.com]
Sent: Thursday, 7 June 2007 22:41
To: ips@ietf.org
Subject: [Ips] iSCSI protocol - use of SendTargets

Hi,

I am new to iSCSI protocol and gearing up.
Is this the right mailing list to ask questions related to  iSCSI protocol?

if yes,

1.  iSCSI target is identified by the network portal (IP + port).
So once the iSCSI target is identified by the network portal and Login to it is successful, why do we need to ask for SendTargets command?
TargetName and TargetAddress returned are immaterial (because we already know the target address to which we have logged-in), unless there are multiple addresses for them and failover is required used.
Or it is used for communicating different TCP port on which initiators can send TUR, Inquiry, Read, Write commands?

What is the expected information from the target in response to SendTargets command?

Regards,
Parav Pandit
It's here! Your new message!
Get new email alerts with the free Yahoo! Toolbar.

_______________________________________________
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

 

Need a vacation? Get great deals to amazing places on Yahoo! Travel.

--=_alternative 004CFCB5C225730C_=-- --===============2078646978== 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 --===============2078646978==-- From ips-bounces@ietf.org Mon Jul 02 17:16:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5TFc-0007dc-Nz; Mon, 02 Jul 2007 17:16:04 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1I5TFb-0007dW-Fw for ips-confirm+ok@megatron.ietf.org; Mon, 02 Jul 2007 17:16:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5TFb-0007dO-69 for ips@ietf.org; Mon, 02 Jul 2007 17:16:03 -0400 Received: from mail-gw3.adaptec.com ([216.52.22.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5TEd-0001Bj-8p for ips@ietf.org; Mon, 02 Jul 2007 17:16:03 -0400 Received: from aime2k302.adaptec.com (aime2k302.adaptec.com [10.25.8.48]) by mail-gw3.adaptec.com (Spam Firewall) with ESMTP id DB49C17CD3D; Mon, 2 Jul 2007 14:15:00 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ips] iSCSI protocol - use of SendTargets Date: Mon, 2 Jul 2007 14:14:58 -0700 Message-ID: <368FBF3D8437A748BA8222526BF9309901FE5E6C@aime2k302.adaptec.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] iSCSI protocol - use of SendTargets Thread-Index: Ace8sW6dFhyG716OR7KC+K5fEWY/AwAOhd3w References: <230506.93285.qm@web30103.mail.mud.yahoo.com> From: "Sandars, Ken" To: "Julian Satran" , "Parav Pandit" X-Spam-Score: 0.3 (/) X-Scan-Signature: dae47ebd0d959deee2d6f67621ddb2e3 Cc: ips@ietf.org, Eddy Quicksall X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2101963935==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============2101963935== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7BCEE.0CE32408" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7BCEE.0CE32408 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 Unfortunately my innuendo was poorly worded, so I apologize to all readers on this list who took offence at my comments since the intent was not malicious or disrespectful. =20 Parav, did the specific sections I pointed out help with your understanding? If you have anything you are not sure of this is the forum to ask in. =20 Cheers Ken ________________________________ From: Julian Satran [mailto:Julian_Satran@il.ibm.com]=20 Sent: Tuesday, 3 July 2007 00:01 To: Parav Pandit Cc: ips@ietf.org; Sandars, Ken; Parav Pandit; Eddy Quicksall Subject: RE: [Ips] iSCSI protocol - use of SendTargets Parav,=20 Nobody minds any sort of question. As for me getting annoyed it was just about an unwarranted innuendo by Ken.=20 Julo=20 Parav Pandit =20 02/07/07 09:20=20 To Julian Satran/Haifa/IBM@IBMIL, "Sandars, Ken" =20 cc ips@ietf.org, Parav Pandit , Eddy Quicksall =20 Subject RE: [Ips] iSCSI protocol - use of SendTargets =09 Hi all, I apologize for asking such basic question on this mailing list. I would read the iSCSI RFC 3720 by myself.=20 I thought of sharing and gaining knowledge through this mailing list faster, but now I understand it may not be the perfect for starters. Thanks a lot for your the kind support, suggestions and information. Regards, Parav Pandit Julian Satran wrote:=20 Hard to comment on your statement. Sounds more like a group "denigration" of the authors - and I don't know about any of us doing what you suggest.=20 I am a bit uneasy about this statement - to say the least.=20 Julo=20 "Sandars, Ken" =20 02/07/07 00:35 =09 To Julian Satran/Haifa/IBM@IBMIL, "Eddy Quicksall" =20 cc , "Parav Pandit" =20 Subject RE: [Ips] iSCSI protocol - use of SendTargets =09 Hi Julo,=20 =20 I don't know how many third party iSCSI 'Big Dummies' guides are out there, however, since RFC3720 succinctly describes the fundamentals of the iSCSI model I recommended that as the first choice.=20 =20 I'd have no objection if the author of RFC3720 wanted to advertise his publication here! ;-)=20 =20 Cheers=20 Ken=20 =20 ________________________________ From: Julian Satran [mailto:Julian_Satran@il.ibm.com]=20 Sent: Saturday, 30 June 2007 19:04 To: Eddy Quicksall Cc: ips@ietf.org; Sandars, Ken; Parav Pandit Subject: Re: [Ips] iSCSI protocol - use of SendTargets Ken - what exactly does "Before any author shamelessly plugs their iSCSI publications, I suggest you have a quick re-read of RFC3720. " reffer to? - Julo=20 "Eddy Quicksall" =20 29/06/07 15:24 =09 To "Sandars, Ken" , "Parav Pandit" , =20 cc Subject Re: [Ips] iSCSI protocol - use of SendTargets =09 I agree with Ken on the reading below. You may have alredy figured this out but just to try to give a simple answer to your question ... suppose you have built a box that has several targets each with different ip addresses; the user at the initiator could just give one of the ip addresses as the "discovery address"; this could be the address of only one of the targets; the initiator can then log on as a discovery session using that address and use SendTargets to find the names and addresses of all targets.=20 Eddy=20 ----- Original Message -----=20 From: Sandars, Ken =20 To: Parav Pandit ; ips@ietf.org =20 Sent: Thursday, June 07, 2007 5:58 PM=20 Subject: RE: [Ips] iSCSI protocol - use of SendTargets=20 Hi Parav,=20 Before any author shamelessly plugs their iSCSI publications, I suggest you have a quick re-read of RFC3720.=20 In particular, section 3.4 pages 37-40 cover some really important concepts that I think will help your understanding. Then jump to the start of section 3, page 17 for more concepts and definitions.=20 The specifics of the SendTargets command are in Appendix D.=20 HTH=20 Ken=20 ________________________________ From: Parav Pandit [mailto:paravpandit@yahoo.com]=20 Sent: Thursday, 7 June 2007 22:41 To: ips@ietf.org Subject: [Ips] iSCSI protocol - use of SendTargets Hi, I am new to iSCSI protocol and gearing up. Is this the right mailing list to ask questions related to iSCSI protocol? if yes, 1. iSCSI target is identified by the network portal (IP + port). So once the iSCSI target is identified by the network portal and Login to it is successful, why do we need to ask for SendTargets command? TargetName and TargetAddress returned are immaterial (because we already know the target address to which we have logged-in), unless there are multiple addresses for them and failover is required used. Or it is used for communicating different TCP port on which initiators can send TUR, Inquiry, Read, Write commands? What is the expected information from the target in response to SendTargets command? Regards, Parav Pandit=20 ________________________________ It's here! Your new message! Get new email alerts with the free Yahoo! Toolbar. =20 ________________________________ _______________________________________________ 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=20 ________________________________ Need a vacation? Get great deals to amazing places on Yahoo! Travel.=20 ------_=_NextPart_001_01C7BCEE.0CE32408 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,
 
Unfortunately my innuendo was poorly = worded, so I=20 apologize to all readers on this list who took offence at my comments = since the=20 intent was not malicious or disrespectful.
 
Parav, did the specific sections I pointed out = help with=20 your understanding? If you have anything you are not sure of this is the = forum=20 to ask in.
 
Cheers
Ken

From: Julian Satran=20 [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, 3 July 2007=20 00:01
To: Parav Pandit
Cc: ips@ietf.org; Sandars, = Ken; Parav=20 Pandit; Eddy Quicksall
Subject: RE: [Ips] iSCSI protocol - use = of=20 SendTargets


Parav, =

Nobody minds any sort of question. As for me = getting=20 annoyed it was just about an unwarranted innuendo by Ken. =

Julo


Parav Pandit=20 <paravpandit@yahoo.com>

02/07/07 09:20

To
Julian = Satran/Haifa/IBM@IBMIL,=20 "Sandars, Ken" <ken_sandars@adaptec.com>=20
cc
ips@ietf.org, Parav = Pandit=20 <paravpandit@yahoo.com>, Eddy Quicksall=20 <Quicksall_iSCSI@Bellsouth.net>=20
Subject
RE: [Ips] iSCSI protocol = - use of=20 SendTargets

=




Hi=20 all,

I apologize for asking such basic question on this mailing = list. I=20 would read the iSCSI RFC 3720 by myself.

I thought of sharing = and=20 gaining knowledge through this mailing list faster, but now I understand = it may=20 not be the perfect for starters.

Thanks a lot for your the kind = support,=20 suggestions and information.

Regards,
Parav=20 Pandit




Julian Satran=20 <Julian_Satran@il.ibm.com> wrote:

Hard to comment on your statement. Sounds more like a group = "denigration" of the authors - and I don't know about any of us doing = what you=20 suggest.
I am a bit=20 uneasy about this statement - to say the least.=20

Julo=20

"Sandars, Ken" = <ken_sandars@adaptec.com>
02/07/07 00:35
To
Julian=20 Satran/Haifa/IBM@IBMIL, "Eddy Quicksall"=20 <Quicksall_iSCSI@Bellsouth.net> =
cc
<ips@ietf.org>, = "Parav=20 Pandit" <paravpandit@yahoo.com> =
Subject
RE: [Ips] iSCSI protocol = - use of=20 SendTargets







Hi=20 Julo,
 
I don't know how many third party iSCSI 'Big Dummies' = guides are out=20 there, however, since RFC3720 succinctly describes the fundamentals of = the iSCSI=20 model I recommended that as the first choice.=20
 
I'd have = no objection if=20 the author of RFC3720 wanted to advertise his publication here! = ;-)
 
Cheers
Ken
 
From: Julian Satran=20 [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, 30 June = 2007=20 19:04
To: Eddy Quicksall
Cc: ips@ietf.org; Sandars, = Ken;=20 Parav Pandit
Subject: Re: [Ips] iSCSI protocol - use of=20 SendTargets


Ken - what exactly does "Before any author shamelessly plugs their iSCSI publications, I = suggest=20 you have a quick re-read of RFC3720. "=20 reffer to? - Julo
"Eddy = Quicksall"=20 <Quicksall_iSCSI@Bellsouth.net>
29/06/07 15:24
To
"Sandars, = Ken"=20 <ken_sandars@adaptec.com>, "Parav Pandit"=20 <paravpandit@yahoo.com>, = <ips@ietf.org>
cc
Subject
Re: [Ips] iSCSI protocol = - use of=20 SendTargets









I agree with Ken on the = reading=20 below. You may have alredy figured this out but just to try to give a = simple=20 answer to your question ... suppose you have built a box that has = several=20 targets each with different ip addresses; the user at the initiator = could just=20 give one of the ip addresses as the "discovery address"; this could be = the=20 address of only one of the targets; the initiator can then log on as a = discovery=20 session using that address and use SendTargets to find the names and = addresses=20 of all targets.

Eddy
----- Original Message -----
From: Sandars,=20 Ken
To: Parav=20 Pandit ; ips@ietf.org =
Sent:=20 Thursday, June 07, 2007 5:58 PM
Subject: RE: [Ips] iSCSI = protocol -=20 use of SendTargets

Hi=20 Parav,

Before any author shamelessly plugs their iSCSI = publications, I=20 suggest you have a quick re-read of RFC3720.

In = particular, section=20 3.4 pages 37-40 cover some really important concepts that I think will = help your=20 understanding. Then jump to the start of section 3, page 17 for more = concepts=20 and definitions.

The specifics of the SendTargets command are in Appendix=20 D.

HTH
Ken

From: Parav Pandit=20 [mailto:paravpandit@yahoo.com]
Sent: Thursday, 7 June 2007=20 22:41
To: ips@ietf.org
Subject: [Ips] iSCSI protocol = - use=20 of SendTargets

Hi,

I am new to iSCSI = protocol=20 and gearing up.
Is this the right mailing list to ask questions = related to=20  iSCSI protocol?

if yes,

1.  iSCSI target is = identified=20 by the network portal (IP + port).
So once the iSCSI target is = identified by=20 the network portal and Login to it is successful, why do we need to ask = for=20 SendTargets command?
TargetName and TargetAddress returned are = immaterial=20 (because we already know the target address to which we have logged-in), = unless=20 there are multiple addresses for them and failover is required = used.
Or it is=20 used for communicating different TCP port on which initiators can send = TUR,=20 Inquiry, Read, Write commands?

What is the expected information = from the=20 target in response to SendTargets command?

Regards,
Parav = Pandit=20
It's here! Your new message!
Get new email alerts = with the free=20 Yahoo! Toolbar. =

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

=20

Need a vacation? Get great deals to amazing places = on Yahoo! Travel.

------_=_NextPart_001_01C7BCEE.0CE32408-- --===============2101963935== 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 --===============2101963935==-- From ips-bounces@ietf.org Mon Jul 16 14:06:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAUxZ-0006rB-3O; Mon, 16 Jul 2007 14:06:13 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1IAUxX-0006qz-6S for ips-confirm+ok@megatron.ietf.org; Mon, 16 Jul 2007 14:06:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAUxW-0006qr-Rz for ips@ietf.org; Mon, 16 Jul 2007 14:06:10 -0400 Received: from mail3.pillardata.com ([209.120.231.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAUxH-0007OF-I5 for ips@ietf.org; Mon, 16 Jul 2007 14:06:10 -0400 Received: from coex02.trans.corp ([172.18.24.19]) by mail3.pillardata.com with ESMTP; 16 Jul 2007 11:04:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 16 Jul 2007 12:04:44 -0600 Message-ID: <16236EEEF4D4264DA31C2E35E3607CFE03DA713F@coex02.trans.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: iSNS transaction ID uniqueness Thread-Index: AcfH08nQwIqhl83GS++bk2lBEW15RA== From: "Paul Hughes" To: "IP Storage Mailing List (E-mail)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Subject: [Ips] iSNS transaction ID uniqueness X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0743621703==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0743621703== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C7D3.C9C1F129" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C7D3.C9C1F129 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Section 5.1.5 of RFC 4171 (iSNS) states: The TRANSACTION ID MUST be set = to a unique value for each concurrently outstanding request message. For an iSCSI target registering with or querying an iSNS server, does = the Transaction ID have to be unique for every message sent by any = portal of the target (any message from the network entity) or does the = Transaction ID only need to be unique for messages sent by a specific = portal? I'm mostly just curious what the intent is. I can easily create = entity-unique transaction IDs for cases where more than one target = portal could be sending concurrent request messages to the server. Thanks, Paul ------_=_NextPart_001_01C7C7D3.C9C1F129 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable iSNS transaction ID uniqueness

Section 5.1.5 of RFC 4171 (iSNS) = states:  The TRANSACTION ID MUST be set to a unique value for each = concurrently outstanding request message.

For an iSCSI target registering with or = querying an iSNS server, does the Transaction ID have to be unique for = every message sent by any portal of the target (any message from the = network entity) or does the Transaction ID only need to be unique for = messages sent by a specific portal?

I'm mostly just curious what the intent = is.  I can easily create entity-unique transaction IDs for cases = where more than one target portal could be sending concurrent request = messages to the server.

Thanks,
Paul

------_=_NextPart_001_01C7C7D3.C9C1F129-- --===============0743621703== 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 --===============0743621703==-- From ips-bounces@ietf.org Thu Jul 19 08:52:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBVUh-0002bi-H6; Thu, 19 Jul 2007 08:52:35 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1IBVUg-0002bc-30 for ips-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 08:52:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBVUf-0002bU-Dl for ips@ietf.org; Thu, 19 Jul 2007 08:52:33 -0400 Received: from sineb-mail-1.sun.com ([192.18.19.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBVUa-0007bu-37 for ips@ietf.org; Thu, 19 Jul 2007 08:52:33 -0400 Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6JCqLRr028714 for ; Thu, 19 Jul 2007 12:52:25 GMT Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JLF00B01FKAUP00@mail-apac.sun.com> (original mail from Victor.Li@Sun.COM) for ips@ietf.org; Thu, 19 Jul 2007 20:52:21 +0800 (SGT) Received: from [129.158.144.124] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JLF006VMFR8R7DA@mail-apac.sun.com>; Thu, 19 Jul 2007 20:52:21 +0800 (SGT) Date: Thu, 19 Jul 2007 20:51:51 +0800 From: Victor Li Subject: Re: [Ips] iSNS transaction ID uniqueness In-reply-to: <16236EEEF4D4264DA31C2E35E3607CFE03DA713F@coex02.trans.corp> To: Paul Hughes Message-id: <469F5E67.1030406@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <16236EEEF4D4264DA31C2E35E3607CFE03DA713F@coex02.trans.corp> User-Agent: Thunderbird 2.0.0.0 (X11/20070423) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: "IP Storage Mailing List \(E-mail\)" X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org The TRANSACTION ID will be used for validation of the received PDUs. Since one iSNSP message can be comprised by multiple PDUs, the PDUs that have the same TRANSACTION ID, sequential SEQUENCE IDs and correct flag bits will be a valid iSNSP message. Hope this helps! Victor Paul Hughes wrote: > > Section 5.1.5 of RFC 4171 (iSNS) states: The TRANSACTION ID MUST be > set to a unique value for each concurrently outstanding request message. > > For an iSCSI target registering with or querying an iSNS server, does > the Transaction ID have to be unique for every message sent by any > portal of the target (any message from the network entity) or does the > Transaction ID only need to be unique for messages sent by a specific > portal? > > I'm mostly just curious what the intent is. I can easily create > entity-unique transaction IDs for cases where more than one target > portal could be sending concurrent request messages to the server. > > Thanks, > Paul > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Thu Jul 19 08:56:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBVYf-0003PX-N1; Thu, 19 Jul 2007 08:56:41 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1IBVYe-0003PI-CB for ips-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 08:56:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBVYe-0003PA-2e for ips@ietf.org; Thu, 19 Jul 2007 08:56:40 -0400 Received: from sineb-mail-2.sun.com ([192.18.19.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBVYc-0005kB-8A for ips@ietf.org; Thu, 19 Jul 2007 08:56:40 -0400 Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6JCuYUw029463 for ; Thu, 19 Jul 2007 12:56:34 GMT Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JLF00101FQCJD00@mail-apac.sun.com> (original mail from Victor.Li@Sun.COM) for ips@ietf.org; Thu, 19 Jul 2007 20:56:34 +0800 (SGT) Received: from [129.158.144.124] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JLF0020IFY994P8@mail-apac.sun.com>; Thu, 19 Jul 2007 20:56:34 +0800 (SGT) Date: Thu, 19 Jul 2007 20:56:04 +0800 From: Victor Li Subject: Re: [Ips] iSNS transaction ID uniqueness In-reply-to: <16236EEEF4D4264DA31C2E35E3607CFE03DA713F@coex02.trans.corp> To: Paul Hughes Message-id: <469F5F64.4010105@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <16236EEEF4D4264DA31C2E35E3607CFE03DA713F@coex02.trans.corp> User-Agent: Thunderbird 2.0.0.0 (X11/20070423) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: "IP Storage Mailing List \(E-mail\)" X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org follow up with previous message: For your case, I think either way will be correct, as long as the TRANSACTION ID is guaranteed to be unique for each concurrently outstanding request message by your iSNS client. Paul Hughes wrote: > > Section 5.1.5 of RFC 4171 (iSNS) states: The TRANSACTION ID MUST be > set to a unique value for each concurrently outstanding request message. > > For an iSCSI target registering with or querying an iSNS server, does > the Transaction ID have to be unique for every message sent by any > portal of the target (any message from the network entity) or does the > Transaction ID only need to be unique for messages sent by a specific > portal? > > I'm mostly just curious what the intent is. I can easily create > entity-unique transaction IDs for cases where more than one target > portal could be sending concurrent request messages to the server. > > Thanks, > Paul > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Thu Jul 19 14:06:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaOi-0006CP-F7; Thu, 19 Jul 2007 14:06:44 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1IBaOh-0006CK-Fc for ips-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 14:06:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaOh-0006CC-5x for ips@ietf.org; Thu, 19 Jul 2007 14:06:43 -0400 Received: from web60713.mail.yahoo.com ([209.73.178.216]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IBaOg-0005xk-H5 for ips@ietf.org; Thu, 19 Jul 2007 14:06:43 -0400 Received: (qmail 99513 invoked by uid 60001); 19 Jul 2007 18:06:41 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=cScBsB4d5fOv2/xlH1FF3s4UviW6PyMMOdAzWz7tUJTZRxU6Bb5RE6mqLd8tviz7xgdiLdtbHi1BiXibZCz4l40yGDRte6v78e9JVz28QOV21up32s6K8Oqy9rZ5mzZFSff/6eFb+bLFg8aG3SK3bHN02+pPRF78yjyn1ksW2Jw=; X-YMail-OSG: 0eb0wJQVM1lz9bjssmLuDuQXsNF7Xm_RHjArgoXl0gdQE0LCbfZ9Fd_KbZ.OgvOAqg-- Received: from [66.195.191.22] by web60713.mail.yahoo.com via HTTP; Thu, 19 Jul 2007 11:06:41 PDT X-Mailer: YahooMailRC/651.41 YahooMailWebService/0.7.41.16 Date: Thu, 19 Jul 2007 11:06:41 -0700 (PDT) From: Joe Souza Subject: Re: [Ips] iSNS transaction ID uniqueness To: Victor Li , Paul Hughes MIME-Version: 1.0 Message-ID: <548909.98708.qm@web60713.mail.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: "IP Storage Mailing List \(E-mail\)" X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0262703662==" Errors-To: ips-bounces@ietf.org --===============0262703662== Content-Type: multipart/alternative; boundary="0-411865586-1184868401=:98708" --0-411865586-1184868401=:98708 Content-Type: text/plain; charset=ascii I believe the intent is such that the Transaction ID should be unique per registered client. A registered client, from the iSNS server point of view, is a Node, not a Portal (i.e. see Source Attribute description), so the Transaction ID should be unique across all Portals associated with a given Node. Thanks, -Joe ----- Original Message ---- From: Victor Li To: Paul Hughes Cc: IP Storage Mailing List (E-mail) Sent: Thursday, July 19, 2007 5:56:04 AM Subject: Re: [Ips] iSNS transaction ID uniqueness follow up with previous message: For your case, I think either way will be correct, as long as the TRANSACTION ID is guaranteed to be unique for each concurrently outstanding request message by your iSNS client. Paul Hughes wrote: > > Section 5.1.5 of RFC 4171 (iSNS) states: The TRANSACTION ID MUST be > set to a unique value for each concurrently outstanding request message. > > For an iSCSI target registering with or querying an iSNS server, does > the Transaction ID have to be unique for every message sent by any > portal of the target (any message from the network entity) or does the > Transaction ID only need to be unique for messages sent by a specific > portal? > > I'm mostly just curious what the intent is. I can easily create > entity-unique transaction IDs for cases where more than one target > portal could be sending concurrent request messages to the server. > > Thanks, > Paul > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 --0-411865586-1184868401=:98708 Content-Type: text/html; charset=ascii
I believe the intent is such that the Transaction ID should be unique per registered client.  A registered client, from the iSNS server point of view, is a Node, not a Portal (i.e. see Source Attribute description), so the Transaction ID should be unique across all Portals associated with a given Node.

Thanks,
-Joe

----- Original Message ----
From: Victor Li <Victor.Li@Sun.COM>
To: Paul Hughes <phughes@pillardata.com>
Cc: IP Storage Mailing List (E-mail) <ips@ietf.org>
Sent: Thursday, July 19, 2007 5:56:04 AM
Subject: Re: [Ips] iSNS transaction ID uniqueness

follow up with previous message:

For your case, I think either way will be correct, as long as the
TRANSACTION ID is guaranteed to be unique for each concurrently
outstanding request message by your iSNS client.

Paul Hughes wrote:
>
> Section 5.1.5 of RFC 4171 (iSNS) states:  The TRANSACTION ID MUST be
> set to a unique value for each concurrently outstanding request message.
>
> For an iSCSI target registering with or querying an iSNS server, does
> the Transaction ID have to be unique for every message sent by any
> portal of the target (any message from the network entity) or does the
> Transaction ID only need to be unique for messages sent by a specific
> portal?
>
> I'm mostly just curious what the intent is.  I can easily create
> entity-unique transaction IDs for cases where more than one target
> portal could be sending concurrent request messages to the server.
>
> Thanks,
> Paul
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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

--0-411865586-1184868401=:98708-- --===============0262703662== 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 --===============0262703662==-- From ips-bounces@ietf.org Mon Jul 23 04:51:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICtdZ-0001gp-2u; Mon, 23 Jul 2007 04:51:29 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1ICtdX-0001gj-86 for ips-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 04:51:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICtdW-0001gb-R6 for ips@ietf.org; Mon, 23 Jul 2007 04:51:26 -0400 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICtdV-0007wD-Vw for ips@ietf.org; Mon, 23 Jul 2007 04:51:26 -0400 Received: by ug-out-1314.google.com with SMTP id u2so2667426uge for ; Mon, 23 Jul 2007 01:51:25 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=kcN5obCdIaCeVlcNrsDh6mcB8bCcU1QRqw7WK1XD0EgY/cyMfWBJNmwRXAPKOFM/XL8JfK94BECxci1p5iOw2F/WUKbeT93uNu8sN8iKdJ0HD2T3yKmrXgAMY2bXOrLk0oJ8sBFxYnVebgkL+Gfz6FNIEEu+b7doSTgPnfW+5AQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=t0mzd8b+lVPNoDnVbyMaQaord8UT0raVdye7tWAx/Ot5rxonnPigjzliFPOoYJZTgexI05epDYq7gODV1EFAvB60oCC3GtqZwCnJAHFTWXICN1NBjTMr+pGtYbYKZ5mMC+kXMNIs0RlS4TRhqZrDNDplOtq6VhwlbGNDHc24DM4= Received: by 10.86.26.11 with SMTP id 11mr2285945fgz.1185180685267; Mon, 23 Jul 2007 01:51:25 -0700 (PDT) Received: by 10.86.49.14 with HTTP; Mon, 23 Jul 2007 01:51:25 -0700 (PDT) Message-ID: Date: Mon, 23 Jul 2007 01:51:25 -0700 From: "Vishal Study" To: ips MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Ips] FCIP reference code X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Hello: Can someone please point me to a publicly available implemention (source code) of FCIP (as IET is for iSCSI)? Please pardon me as this is slightly off-topic for this list... Thanks in advance, Vishal. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Jul 23 14:50:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID2zc-00064a-WB; Mon, 23 Jul 2007 14:50:53 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1ID2zW-0005gd-Dp for ips-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 14:50:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID2zV-0005cy-Vg; Mon, 23 Jul 2007 14:50:46 -0400 Received: from bosco.isi.edu ([128.9.168.207]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID2zV-0006E3-H1; Mon, 23 Jul 2007 14:50:45 -0400 Received: by bosco.isi.edu (Postfix, from userid 70) id 9DACDDA986; Mon, 23 Jul 2007 11:48:51 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20070723184851.9DACDDA986@bosco.isi.edu> Date: Mon, 23 Jul 2007 11:48:51 -0700 (PDT) X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: ips@ietf.org, rfc-editor@rfc-editor.org Subject: [Ips] RFC 4939 on Definitions of Managed Objects for iSNS (Internet Storage Name Service) X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4939 Title: Definitions of Managed Objects for iSNS (Internet Storage Name Service) Author: K. Gibbons, G. Ramkumar, S. Kipp Status: Standards Track Date: July 2007 Mailbox: kgibbons@yahoo.com, gramkumar@stanfordalumni.org, skipp@brocade.com Pages: 80 Characters: 165381 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ips-isns-mib-11.txt URL: http://www.rfc-editor.org/rfc/rfc4939.txt The iSNS (Internet Storage Name Service) protocol provides storage name service functionality on an IP network that is being used for iSCSI (Internet Small Computer System Interface) or iFCP (Internet Fibre Channel Protocol) storage. This document provides a mechanism to monitor multiple iSNS Servers, including information about registered objects in an iSNS Server. [STANDARDS TRACK] This document is a product of the IP Storage Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Jul 26 07:26:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE1Tk-00081o-To; Thu, 26 Jul 2007 07:26:00 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1IE1Tj-00081g-Ee for ips-confirm+ok@megatron.ietf.org; Thu, 26 Jul 2007 07:25:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE1Tj-00081R-0n for ips@ietf.org; Thu, 26 Jul 2007 07:25:59 -0400 Received: from fwil.voltaire.com ([193.47.165.2] helo=exil.voltaire.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IE1Tg-0001C5-EM for ips@ietf.org; Thu, 26 Jul 2007 07:25:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 26 Jul 2007 14:25:50 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: iSCSI boot - root path DHCP option Thread-Index: AcfPd7h8p2QiRcAeTW+A4vzoaFWfvw== From: "Yaron Haviv" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 Cc: Subject: [Ips] iSCSI boot - root path DHCP option X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0738668660==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0738668660== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7CF77.B9996455" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7CF77.B9996455 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Guys,=20 =20 I'm trying to figure out something relating to the iSCSI root-path DHCP option=20 =20 The iSCSI boot spec (RFC4173) seem to indicate that the iSCSI root path option in the DHCP server should look like: =20 "iscsi:"":"":"":"":" =20 While I saw an implementation that uses: (http://iscsi-init.sourceforge.net/README.html) =20 option root-path "[if_name1:][,[if_name2:]]:/[/[/]]"; =20 the RFC doesn't seem to address key issues which are enabled through the 2nd alternative such as specifying an alternate IP address of a target (pretty important for HA) and specifying the initiator Iqn (after all the LUN masking is done on the target based on the initiator iqn) =20 Any idea if the RFC taken those into considerations, or has changed recently ? =20 Thanks, Yaron ------_=_NextPart_001_01C7CF77.B9996455 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Guys,

 

I’m trying to figure out something relating to = the iSCSI root-path DHCP option

 

The iSCSI boot spec (RFC4173) seem to indicate that = the iSCSI root path option in the DHCP server should look = like:

  

  = "iscsi:"<servername>":"<protocol>":&= quot;<port>":"<LUN>":"<targetname><= o:p>

 

While I saw an implementation that = uses:

(http://iscsi-init.= sourceforge.net/README.html)

 

option root-path =
"[if_name1:]<target_ip1>[,[if_name2:]<target_ip2>]:/<=
target_name>[/<initiator_name>[/<lun_number>]]";=

 

the RFC doesn’t seem to address key issues = which are enabled through the 2nd = alternative

such as specifying an alternate IP address of a = target (pretty important for HA)

and specifying the initiator Iqn (after all the LUN = masking is done on the target based on the initiator = iqn)

 

Any idea if the RFC taken those into considerations, = or has changed recently ?

 

Thanks, Yaron

------_=_NextPart_001_01C7CF77.B9996455-- --===============0738668660== 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 --===============0738668660==-- From ips-bounces@ietf.org Sun Jul 29 21:56:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFKV6-0004g6-ET; Sun, 29 Jul 2007 21:56:48 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1IFKV4-0004fR-KA for ips-confirm+ok@megatron.ietf.org; Sun, 29 Jul 2007 21:56:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFKV4-0004f0-9H for ips@ietf.org; Sun, 29 Jul 2007 21:56:46 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFKV3-0003k3-GC for ips@ietf.org; Sun, 29 Jul 2007 21:56:46 -0400 Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.11]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l6U1uiip023443 for ; Sun, 29 Jul 2007 21:56:44 -0400 (EDT) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l6U1tx1O006642 for ; Sun, 29 Jul 2007 21:56:42 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.12]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 29 Jul 2007 21:56:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sun, 29 Jul 2007 21:56:41 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 4963 on IPv4 Reassembly Errors at High Data Rates Thread-Index: AcfQlkKAOYsucDDXTfuMfwhD+mCT4ABtMp+A To: X-OriginalArrivalTime: 30 Jul 2007 01:56:41.0781 (UTC) FILETIME=[DFD27E50:01C7D24C] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.6.21134 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: -3.4 (---) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Subject: [Ips] FW: RFC 4963 on IPv4 Reassembly Errors at High Data Rates X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org FYI - IPv4 fragmentation can be harmful at high speed. The best bet is to not to allow fragmentation, but the RFC says: "stronger error checking at any level above IP" is a mitigation measure. iSCSI digests and the end-to-end use of the FC frame CRC by FCIP and iFCP are examples of this sort of "stronger error checking". --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: rfc-editor@rfc-editor.org [mailto:rfc-editor@rfc-editor.org]=20 Sent: Friday, July 27, 2007 5:34 PM To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org Cc: rfc-editor@rfc-editor.org Subject: RFC 4963 on IPv4 Reassembly Errors at High Data Rates A new Request for Comments is now available in online RFC libraries. =20 RFC 4963 Title: IPv4 Reassembly Errors at High=20 Data Rates=20 Author: J. Heffner, M. Mathis, B. Chandler Status: Informational Date: July 2007 Mailbox: jheffner@psc.edu,=20 mathis@psc.edu,=20 bchandle@gmail.com Pages: 10 Characters: 22399 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-heffner-frag-harmful-05.txt URL: http://www.rfc-editor.org/rfc/rfc4963.txt IPv4 fragmentation is not sufficiently robust for use under some conditions in today's Internet. At high data rates, the 16-bit IP identification field is not large enough to prevent frequent incorrectly assembled IP fragments, and the TCP and UDP checksums are insufficient to prevent the resulting corrupted datagrams from being delivered to higher protocol layers. This note describes some easily reproduced experiments demonstrating the problem, and discusses some of the operational implications of these observations. This memo provides information for the Internet community. INFORMATIONAL: This memo provides information for the Internet community.=20 It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body=20 help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Sun Jul 29 22:14:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFKm3-0004MY-TE; Sun, 29 Jul 2007 22:14:19 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1IFKm2-0004MT-4M for ips-confirm+ok@megatron.ietf.org; Sun, 29 Jul 2007 22:14:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFKm1-0004ML-Qw for ips@ietf.org; Sun, 29 Jul 2007 22:14:17 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFKm0-00045b-G9 for ips@ietf.org; Sun, 29 Jul 2007 22:14:17 -0400 Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l6U2EEn6024718; Sun, 29 Jul 2007 22:14:15 -0400 (EDT) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l6U2DYHs006376; Sun, 29 Jul 2007 22:14:10 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.12]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 29 Jul 2007 22:14:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 29 Jul 2007 22:14:05 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: iSCSI boot - root path DHCP option Thread-Index: AcfPd7h8p2QiRcAeTW+A4vzoaFWfvwC1vhmg References: To: , X-OriginalArrivalTime: 30 Jul 2007 02:14:06.0013 (UTC) FILETIME=[4E3BA6D0:01C7D24F] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.6.21134 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, HTML_70_90 0.1, NO_REAL_NAME 0, __C230066_P5 0, __CP_URI_IN_BODY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __HAS_MSGID 0, __HTML_FONT_BLUE 0, __IMS_MSGID 0, __MIME_HTML 0, __MIME_VERSION 0, __SANE_MSGID 0, __TAG_EXISTS_HTML 0' X-Spam-Score: -4.0 (----) X-Scan-Signature: 9f79b8e383fd3af2b1b5b1d0910f6094 Cc: Subject: [Ips] RE: iSCSI boot - root path DHCP option X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1571789957==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1571789957== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7D24F.4DAA7503" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7D24F.4DAA7503 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Yaron, =20 RFC 4173 essentially specifies the format of the root path option when the path string begins with "iscsi:". The implementation you refer to has chosen to do something else - the result is likely to be implementation-specific and have interoperability issues. =20 If there's interest in updating RFC 4173 to address additional issues and/or standardize this format, please submit an Internet-Draft. It is not necessary to replace RFC 4173 in its entirety - a description of what is new and/or changed will suffice. =20 Thanks, --David (ips WG chair) ----------------------------------------------------=20 David L. Black, Senior Technologist=20 EMC Corporation, 176 South St., Hopkinton, MA 01748=20 +1 (508) 293-7953 FAX: +1 (508) 293-7786=20 black_david@emc.com Mobile: +1 (978) 394-7754=20 ---------------------------------------------------- ________________________________ From: Yaron Haviv [mailto:yaronh@voltaire.com]=20 Sent: Thursday, July 26, 2007 7:26 AM To: Black, David; ips@ietf.org Subject: iSCSI boot - root path DHCP option =09 =09 Guys,=20 =20 I'm trying to figure out something relating to the iSCSI root-path DHCP option=20 =20 The iSCSI boot spec (RFC4173) seem to indicate that the iSCSI root path option in the DHCP server should look like: =20 =09 "iscsi:"":"":"":"":" =20 While I saw an implementation that uses: (http://iscsi-init.sourceforge.net/README.html) =20 option root-path "[if_name1:][,[if_name2:]]:/[/[/]]"; =20 the RFC doesn't seem to address key issues which are enabled through the 2nd alternative such as specifying an alternate IP address of a target (pretty important for HA) and specifying the initiator Iqn (after all the LUN masking is done on the target based on the initiator iqn) =20 Any idea if the RFC taken those into considerations, or has changed recently ? =20 Thanks, Yaron ------_=_NextPart_001_01C7D24F.4DAA7503 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Yaron,
 
RFC 4173 essentially specifies the format of the root path = option=20 when
the path string begins with "iscsi:".  The implementation = you refer=20 to
has chosen to do something else - the result is likely = to=20 be
implementation-specific and have=20 interoperability issues.
 
If there's interest in updating RFC 4173 to address additional=20 issues
and/or standardize this format, please submit an = Internet-Draft. =20 It
is not necessary to replace RFC 4173 in its entirety - a=20 description
of what is new and/or changed will suffice.
 
Thanks,
--David (ips WG chair)
----------------------------------------------------=20
David L. = Black, Senior=20 Technologist
EMC Corporation, 176 South St., Hopkinton, MA  = 01748=20
+1 (508)=20 293-7953           = ; =20 FAX: +1 (508) 293-7786
black_david@emc.com        = Mobile: +1=20 (978) 394-7754
----------------------------------------------------
From: Yaron Haviv = [mailto:yaronh@voltaire.com]=20
Sent: Thursday, July 26, 2007 7:26 AM
To: Black, = David;=20 ips@ietf.org
Subject: iSCSI boot - root path DHCP=20 option

Guys,=20

 

I’m trying to = figure out something=20 relating to the iSCSI root-path DHCP option =

 

The iSCSI boot spec = (RFC4173) seem=20 to indicate that the iSCSI root path option in the DHCP server should = look=20 like:

  =20

 =20 = "iscsi:"<servername>":"<protocol>":"<port>":"<LUN>= ;":"<targetname>

 

While I saw an = implementation that=20 uses:

(http://iscsi-init.= sourceforge.net/README.html)

 

option root-path =
"[if_name1:]<target_ip1>[,[if_name2:]<target_ip2>]:/<targe=
t_name>[/<initiator_name>[/<lun_number>]]";

 

the RFC doesn’t = seem to address=20 key issues which are enabled through the 2nd=20 alternative

such as specifying an = alternate IP=20 address of a target (pretty important for = HA)

and specifying the = initiator Iqn=20 (after all the LUN masking is done on the target based on the = initiator=20 iqn)

 

Any idea if the RFC = taken those=20 into considerations, or has changed recently = ?

 

Thanks,=20 Yaron

------_=_NextPart_001_01C7D24F.4DAA7503-- --===============1571789957== 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 --===============1571789957==--