From ips-bounces@ietf.org Mon May 01 14:55:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FadY0-0002hZ-TZ; Mon, 01 May 2006 14:55:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FadXz-0002hR-AT; Mon, 01 May 2006 14:55:03 -0400 Received: from mms3.broadcom.com ([216.31.210.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FadXy-0007Hr-Sk; Mon, 01 May 2006 14:55:03 -0400 Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Mon, 01 May 2006 11:54:46 -0700 X-Server-Uuid: B238DE4C-2139-4D32-96A8-DD564EF2313E Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 1487E2AF; Mon, 1 May 2006 11:54:46 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id CFB8F2AE; Mon, 1 May 2006 11:54:45 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5-GA) with ESMTP id DKQ52500; Mon, 1 May 2006 11:54:37 -0700 (PDT) Received: from NT-SJCA-0750.brcm.ad.broadcom.com (nt-sjca-0750 [10.16.192.220]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id DEA3420501; Mon, 1 May 2006 11:54:36 -0700 (PDT) Received: from NT-SJCA-0752.brcm.ad.broadcom.com ([10.16.192.222]) by NT-SJCA-0750.brcm.ad.broadcom.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 May 2006 11:54:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ips] DDP message interleaving Date: Mon, 1 May 2006 11:54:31 -0700 Message-ID: <710F16C36810444CA2F5821E5EAB7F230366F8@NT-SJCA-0752.brcm.ad.broadcom.com> Thread-Topic: [Ips] DDP message interleaving Thread-Index: AcZkjqcMBQlzsOCFQ9ajDyoo28nYaAIwYPHw From: "Pat Thaler" To: "Caitlin Bestler" , "Ben Sum" , ips@ietf.org, rddp@ietf.org X-OriginalArrivalTime: 01 May 2006 18:54:36.0810 (UTC) FILETIME=[B16C16A0:01C66D50] X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006050106; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230312E34343536353742322E303035462D452D5046786C33494E497A33445631553653544639524F673D3D; ENG=IBF; TS=20060501185447; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006050106_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 684886FC3NG11799514-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: 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 [This discussion seems more appropriate to the rddp reflector so I've copied that and suggest we move over there if more is needed] Caitlin, In the general case, the RDMAP protocol and the ULPs built on it are designed to rely on in order delivery of messages. A lower layer protocol that sends out of order but reorders before the packets leave the llp at the receiver (e.g. TCP retransmission of dropped packets) is okay. A lower layer level that allowed interleaving but didn't have a mechanism to undo it at the receiver, would have to be protocol aware to an extent that would be a layering violation.=20 The particular example show doesn't cause a problem at the receiver because the last segment of each message occurs in the right order so the message completions in DDP and RDMAP will occur in the correct order. However, one could have something else like: Message 1 - tagged (e.g. the last RDMA data transfer of an SCSI Read over iSCSI/iSER) FPDU frame TO =3D 0, L =3D 0, T =3D 1 FPDU frame TO =3D = 1000, L =3D 0, T =3D 1 Message 2 - untagged (e.g. the status message indicating that the SCSI Read has completed) FPDU frame MSN =3D 0, M0 =3D 0, L =3D 1 If those frames were interleaved and sent: FPDU frame TO =3D 0, L =3D 0, T =3D 1 FPDU frame MSN =3D 0, M0 =3D 0, L =3D 1 FPDU frame TO =3D 1000, L =3D 0, T =3D 1 the untagged message indicating that the SCSI Read has completed would be sent to RDMAP before the transfer of read data had finished. Data corruption could occur. To avoid such problems, the last segment of each message must be sent in order.=20 Even if last segments are kept in order, there can be undesireable consequences at the receiver of interleaving. It shouldn't be done. Unfortunately, we didn't put a very clear statement of this in rddp's list of reliable delivery requirements. The closest we came was: 4. The LLP MUST preserve DDP Segment and Message boundaries at the=20 Data Sink.=20 5. The LLP MAY provide the incoming segments out of order for=20 Placement, but if it does, it MUST also provide information that=20 specifies what the sender specified order was.=20 With 5. we were thinking more of out of order arrival of segments due to reordering in the path or packet drops - not at the transmitter. Regards, Pat=20 -----Original Message----- From: Caitlin Bestler [mailto:cait@asomi.com]=20 Sent: Thursday, April 20, 2006 8:25 AM To: Ben Sum; ips@ietf.org Subject: Re: [Ips] DDP message interleaving > -----Original Message----- > From: Ben Sum [mailto:bens@ivivity.com] > Sent: Wednesday, April 19, 2006 06:09 PM > To: ips@ietf.org > Subject: [Ips] DDP message interleaving >=20 > Is sender ever multiplexing messages? Considering following message: >=20 > Message1: =20 >=20 > FPDU frame MSN =3D 0, MO =3D 0, L =3D 0, T=3D 0 >=20 > FPDU frame MSN =3D 0, MO =3D 1000, L =3D 1, T=3D 0=20 > Message2: =20 >=20 > FPDU frame T =3D 1, TO =3D 0, L =3D 0 > FPDU frame T =3D 1, TO =3D 1000, L =3D 1 > =20 > Can the sender transmit as following:=20 > 1) FPDU frame MSN =3D 0, MO =3D 0, L =3D 0, T =3D 0=20 > 2) FPDU frame T =3D 1, TO =3D 0, L =3D 0=20 > 3) FPDU frame MSN =3D 0, MO =3D 1000, L =3D 1, T =3D 0=20 > 4) FPDU frame T =3D 1, TO =3D 1000, L =3D 1 >=20 > =20 >=20 > Regards, >=20 > Ben >=20 There are two issues here: what you should accept, and what you should send. On the receive side, if you are processing the incoming packets optimally you will not even notice this type of anomolous ordering. A receiver definitely SHOULD NOT add extra steps to attempt to detect something of this nature. On the other hand this is definitely something that a sender SHOULD NOT send, possibly MUST NOT send. The DDP spec clarifies that the DDP layer segments messages and submits them to the LLP. It is clear that the DDP layer MUST submit all of the segments for a message in sequence and non-interleaved. What is not clear is if the LLP layer MUST assign these segments successive LLP sequences, or if it can interleave in ways that do change the sequence of L flags or the fact that the L flag is the last segment of the message. Nobody has identified a reason why a MPA layer would do such a thing, and assigning the expected TCP sequencing is at the minimum an implied SHOULD. But this is not explicitly a constraint. The SCTP Adaptation, which is under the exact same constraints as the MPA/TCP adaptation explicitly recognizes that SCTP stacks are allowed to re-order Data Chunks in order to optimize transmission. IF DDP does not impose a MUST behavior on SCTP, then it does not impose it on MPA/TCP. But SCTP has a valid "SHOULD trumping"=20 reason for reordering packets, MPA/TCP does not. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue May 02 19:34:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb4Ni-0000v4-HW; Tue, 02 May 2006 19:34:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb4Nh-0000uz-Jq for ips@ietf.org; Tue, 02 May 2006 19:34:13 -0400 Received: from mexforward.lss.emc.com ([168.159.213.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb4Ng-0006IH-Ce for ips@ietf.org; Tue, 02 May 2006 19:34:13 -0400 Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13]) by mexforward.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k42NYBOD017825 for ; Tue, 2 May 2006 19:34:11 -0400 (EDT) Received: from MAHO3MSX2.corp.emc.com (maho3msx2.corp.emc.com [128.221.11.32]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k42NY9Z7028183 for ; Tue, 2 May 2006 19:34:11 -0400 (EDT) Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 May 2006 19:34:09 -0400 Message-ID: From: Black_David@emc.com To: ips@ietf.org Date: Tue, 2 May 2006 19:34:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.3.0.1, Antispam-Data: 2006.5.2.161111 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Ips] Draft status update 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 I just sent a note to the RDDP list indicating that the RDDP protocol drafts should enter IETF Last Call in May. iSER and DA have to wait for these drafts - I hope to get them to IETF Last Call in June (assuming the authors can revise them rapidly once I have the comments that need attention). I'm going to guess that IESG review for approval probably won't be until after the Montreal meetings, but we might get lucky and get this done before. David W - you're clear to submit the draft-ietf-ips-...-00 version of your implementation version key draft, based on list discussion - please produce that and submit it with that form of name so it'll appear as an official WG draft. Thanks, --David (ips WG chair) ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed May 03 09:23:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbHJo-0005kT-OY; Wed, 03 May 2006 09:23:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaeDo-0003IJ-RS; Mon, 01 May 2006 15:38:16 -0400 Received: from mms2.broadcom.com ([216.31.210.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaeDn-0000uQ-Ff; Mon, 01 May 2006 15:38:16 -0400 Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Mon, 01 May 2006 12:38:02 -0700 X-Server-Uuid: D9EB6F12-1469-4C1C-87A2-5E4C0D6F9D06 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id B632F2AF; Mon, 1 May 2006 12:38:02 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 8A6212AE; Mon, 1 May 2006 12:38:02 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5-GA) with ESMTP id DKQ70451; Mon, 1 May 2006 12:38:02 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 26D1F20501; Mon, 1 May 2006 12:38:02 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [rddp] RE: [Ips] DDP message interleaving Date: Mon, 1 May 2006 12:38:01 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F143B28C@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [rddp] RE: [Ips] DDP message interleaving Thread-Index: AcZkjqcMBQlzsOCFQ9ajDyoo28nYaAIwYPHwAAFtAvA= From: "Caitlin Bestler" To: "Pat Thaler" , "Ben Sum" , ips@ietf.org, rddp@ietf.org X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006050106; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230392E34343536363144392E303033322D412D; ENG=IBF; TS=20060501193806; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006050106_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 6848BC104I84815557-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 X-Mailman-Approved-At: Wed, 03 May 2006 09:23:03 -0400 Cc: 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 Pat Thaler wrote: > [This discussion seems more appropriate to the rddp reflector > so I've copied that and suggest we move over there if more is needed] >=20 > Caitlin, >=20 > In the general case, the RDMAP protocol and the ULPs built on > it are designed to rely on in order delivery of messages. A > lower layer protocol that sends out of order but reorders > before the packets leave the llp at the receiver (e.g. TCP > retransmission of dropped packets) is okay. A lower layer > level that allowed interleaving but didn't have a mechanism > to undo it at the receiver, would have to be protocol aware > to an extent that would be a layering violation. >=20 > The particular example show doesn't cause a problem at the > receiver because the last segment of each message occurs in > the right order so the message completions in DDP and RDMAP > will occur in the correct order. However, one could have > something else like: >=20 > Message 1 - tagged (e.g. the last RDMA data transfer of an > SCSI Read over iSCSI/iSER) FPDU frame TO =3D 0, L =3D 0, T =3D 1 > FPDU frame TO =3D 1000, L =3D 0, T =3D 1 >=20 > Message 2 - untagged (e.g. the status message indicating that > the SCSI Read has completed) FPDU frame MSN =3D 0, M0 =3D 0, L =3D 1 >=20 > If those frames were interleaved and sent: >=20 > FPDU frame TO =3D 0, L =3D 0, T =3D 1 > FPDU frame MSN =3D 0, M0 =3D 0, L =3D 1 > FPDU frame TO =3D 1000, L =3D 0, T =3D 1 >=20 > the untagged message indicating that the SCSI Read has > completed would be sent to RDMAP before the transfer of read > data had finished. Data corruption could occur. To avoid such > problems, the last segment of each message must be sent in order. >=20 > Even if last segments are kept in order, there can be > undesireable consequences at the receiver of interleaving. It > shouldn't be done.=20 >=20 Agreed, it SHOULD NOT be done. But the justification for having predictable segment ordering, beyound the ordering requirements associated with the L-segments, is optimization not interoperability. That is why there is no MUST language associated with this. Note that the ascending order of for Message Offset in a message is similarly a SHOULD, not a MUST. My advice to implementers is 1) transmit in order, 2) optimize your caching and related resource usage assuming that you will receive in order, but 3) be ready to accept in any order and 4) do not waste receiver code/firmware trying to detect non-standard segmentation strategies. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed May 03 09:24:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbHKp-0006Bg-5z; Wed, 03 May 2006 09:24:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbHKo-0006Bb-IP for ips@ietf.org; Wed, 03 May 2006 09:24:06 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbHKn-00082h-Av for ips@ietf.org; Wed, 03 May 2006 09:24:06 -0400 Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2.netapp.com with ESMTP; 03 May 2006 06:24:04 -0700 X-IronPort-AV: i="4.05,84,1146466800"; d="scan'208"; a="378176824:sNHT16565480" Received: from [10.61.18.55] (starbug [10.61.18.55] (may be forged)) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id k43DO3RY021735; Wed, 3 May 2006 06:24:04 -0700 (PDT) Message-ID: <4458ACA7.4080107@netapp.com> Date: Wed, 03 May 2006 09:14:15 -0400 From: David Wysochanski User-Agent: Thunderbird 1.5 (X11/20060210) MIME-Version: 1.0 To: Black_David@emc.com Subject: Re: [Ips] Draft status update References: In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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: , Errors-To: ips-bounces@ietf.org Black_David@emc.com wrote: > > I just sent a note to the RDDP list indicating that the > RDDP protocol drafts should enter IETF Last Call in May. > iSER and DA have to wait for these drafts - I hope to > get them to IETF Last Call in June (assuming the authors > can revise them rapidly once I have the comments that > need attention). I'm going to guess that IESG review > for approval probably won't be until after the Montreal > meetings, but we might get lucky and get this done > before. > > David W - you're clear to submit the draft-ietf-ips-...-00 > version of your implementation version key draft, based > on list discussion - please produce that and submit it > with that form of name so it'll appear as an official > WG draft. > Yes, sorry it has been delayed. I will get this out hopefully this week though. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu May 04 18:05:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FblxE-0001On-Ae; Thu, 04 May 2006 18:05:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FblxD-0001OM-P1; Thu, 04 May 2006 18:05:47 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FblxD-00010t-4o; Thu, 04 May 2006 18:05:47 -0400 Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2.netapp.com with ESMTP; 04 May 2006 15:05:46 -0700 X-IronPort-AV: i="4.05,89,1146466800"; d="txt'?scan'208"; a="378497052:sNHT29183100" Received: from [10.61.18.55] (starbug [10.61.18.55] (may be forged)) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id k44M5jSx020438; Thu, 4 May 2006 15:05:45 -0700 (PDT) Message-ID: <445A785F.5080206@netapp.com> Date: Thu, 04 May 2006 17:55:43 -0400 From: David Wysochanski User-Agent: Thunderbird 1.5 (X11/20060210) MIME-Version: 1.0 To: internet-drafts@ietf.org Content-Type: multipart/mixed; boundary="------------000705090005010603070809" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4166dd0e0c668adc975c3d3e0f1bce3b Cc: ips@ietf.org, Black_David@emc.com Subject: [Ips] Declarative Public Extension Key for iSCSI Node Architecture 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 This is a multi-part message in MIME format. --------------000705090005010603070809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Per discussions on the IETF IPS workgroup reflector, I submit the attached Internet Draft as a WG draft. --------------000705090005010603070809 Content-Type: text/plain; name="draft-ietf-ips-iscsi-nodearch-key-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-ietf-ips-iscsi-nodearch-key-00.txt" INTERNET-DRAFT Dave Wysochanski Expires: November 4, 2006 Network Appliance, Inc May 4, 2006 Declarative Public Extension Key for iSCSI Node Architecture draft-ietf-ips-iscsi-nodearch-key-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 4, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The iSCSI protocol, described in [RFC3720], allows for extension items to the protocol in the form of Private or Public Extension Keys. This Internet-Draft describes a Public Extension Key for the purpose of enhancing iSCSI supportability. The key accomplishes this objective by allowing iSCSI nodes to communicate architecture details during the iSCSI login sequence. The receiving node can then use this information for enhanced logging and support. Wysochanski Expires November 4, 2006 [Page 1] Internet-Draft iSCSI Node Architecture May 2006 1. Introduction 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.2 Overview This Internet-Draft describes a declarative Public Extension Key as defined by section 12.22 of [RFC3720] that may be used to communicate additional iSCSI node information to the opposite node in a session. The information carried in the described key has been found to be valuable in real iSCSI customer environments as initiator and target vendors collaborate to resolve technical issues and better understand the evolving iSCSI market. The key has been modeled after the "Server" and "User-Agent" header fields as specified in sections 14.38 and 14.43 of [RFC2616], with the text-value(s) of the key roughly equivalent to Product Tokens in section 3.8 of [RFC2616]. Note however that the text-value(s) in the keys list-of-values MUST conform to the Text Format as specified in section 5.1 of [RFC3720]. The following described Public Extension Key is sent during the login phase of an iSCSI normal session. It is important to note that the intended use of this key is to provide enhanced logging and support capabilities, and to enable collection of iSCSI implementation usage information. Functional behavior of the iSCSI node MUST NOT depend on the presence, absence, or content of the key. The key MUST NOT be used by iSCSI nodes for things such as interoperability, performance, or exclusion or deception of other nodes. To enforce intended use, iSCSI nodes MUST NOT allow user modification of the key value(s), and SHOULD set the value automatically based on standard internal interfaces. Wysochanski Expires November 4, 2006 [Page 2] Internet-Draft iSCSI Node Architecture May 2006 2. Definition The definition of extension the key is as follows, with example list-of-values conforming to section 5.1 of [RFC3720]. X#NodeArchitecture Use: LO, Declarative Senders: Initiator and Target Scope: SW X#NodeArchitecture= Examples: X#NodeArchitecture="Microsoft Software Initiator/1.05a, Microsoft Windows/2003Build1489, Microsoft Cluster Services/2.0, CPU Architecture/x86_64" X#NodeArchitecture="Qlogic iSCSI 4010 Hardware Initiator/rev1, Qlogic Firmware/2.0.0.5, Qlogic Driver/2.0.0.1" X#NodeArchitecture="Linux iSCSI Software Initiator/4:0.1.11-3, Red Hat Enterprise Linux/4u3, Linux Kernel/2.6.9-34.26.ELsmp, CPU Architecture/i686, CPU Speed/3.06GHz, Memory Size/4059364kB" X#NodeArchitecture="NetApp Software Target/7.1, Data ONTAP/7.1, NetApp FAS/270c" The initiator or target declares the details of its iSCSI node architecture to the remote endpoint. These details may include, but are not limited to, iSCSI vendor software, firmware, or hardware versions, the OS version, or hardware architecture. X#NodeArchitecture MUST NOT be redeclared. Wysochanski Expires November 4, 2006 [Page 3] Internet-Draft iSCSI Node Architecture May 2006 3. Security Considerations This extension key transmits specific implementation details about the node that sends it; such details may be considered sensitive in some environments. For example, if a certain software or firmware version is known to contain security weaknesses, announcing the presence of that version via this key may not be desirable. The countermeasures for this security concern are: - sending less detailed information in the key values, or - not sending the extension key, or - using IPsec to provide confidentiality for the iSCSI connection on which the key is sent (see [RFC3720] and [RFC3723]). To support the first and second countermeasures, all implementations of this extension key SHOULD provide an administrative mechanism to configure different levels of detail in the extension key values and MUST provide an administrative mechanism to disable sending the key. The choice of which countermeasure is most appropriate depends on the environment. However, the second countermeasure may be acceptable in many environments, since it provides a compromise between sending too much information and the other more complete countermeasures of not sending the key at all or using IPsec. Wysochanski Expires November 4, 2006 [Page 4] Internet-Draft iSCSI Node Architecture May 2006 4. IANA Considerations This document defines the iSCSI Extension Key NodeArchitecture to be registered in the IANA iSCSI extended key registry. Wysochanski Expires November 4, 2006 [Page 5] Internet-Draft iSCSI Node Architecture May 2006 5. References 5.1 Normative References [RFC2119] Bradner, S. "Key Words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, April 2004. 5.2 Informative References [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC3723] Adoba, B., Tseng, J., Walker, J., Rangan, V., and Travostino, F., "Securing Block Storage Protocols over IP", RFC 3723, April 2004. Wysochanski Expires November 4, 2006 [Page 6] Internet-Draft iSCSI Node Architecture May 2006 6. Author's Address Dave Wysochanski Network Appliance, Inc. 7301 Kit Creek Road P. O. Box 13917 Research Triangle, NC 27709 Phone: +1-919-476-5628 E-mail: davidw@netapp.com Wysochanski Expires November 4, 2006 [Page 7] Internet-Draft iSCSI Node Architecture May 2006 7. Acknowledgements The IP Storage (ips) Working Group in the Transport Area of IETF has been responsible for defining the iSCSI protocol (apart from a host of other relevant IP Storage protocols). The editor acknowledges the contributions of the entire working group. The following individuals directly contributed to identifying issues and/or suggesting resolutions to the issues found in this document: David Black, Mallikarjun Chadalapaka, Paul Koning, Julian Satran, John Hufferd, Claire Kraft, Ranga Sankar, Joseph Pittman, Greg Berg, and John Forte. This document benefited from all these contributions. Wysochanski Expires November 4, 2006 [Page 8] Internet-Draft iSCSI Node Architecture May 2006 8. Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Wysochanski Expires November 4, 2006 [Page 9] Internet-Draft iSCSI Node Architecture May 2006 9. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Wysochanski Expires November 4, 2006 [Page 10] --------------000705090005010603070809 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 --------------000705090005010603070809-- From ips-bounces@ietf.org Thu May 04 18:18:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbm9B-0003JO-Ox; Thu, 04 May 2006 18:18:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbm9A-0003JJ-NT for ips@ietf.org; Thu, 04 May 2006 18:18:08 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbm9A-0001OI-FZ for ips@ietf.org; Thu, 04 May 2006 18:18:08 -0400 Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2.netapp.com with ESMTP; 04 May 2006 15:18:08 -0700 X-IronPort-AV: i="4.05,89,1146466800"; d="scan'208"; a="378498917:sNHT15772200" Received: from [10.61.18.55] (starbug [10.61.18.55] (may be forged)) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id k44MI7EX024103 for ; Thu, 4 May 2006 15:18:07 -0700 (PDT) Message-ID: <445A7B45.4060403@netapp.com> Date: Thu, 04 May 2006 18:08:05 -0400 From: David Wysochanski User-Agent: Thunderbird 1.5 (X11/20060210) MIME-Version: 1.0 To: ips@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Ips] Status/Todo draft-ietf-ips-iscsi-nodearch-key-00.txt 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 draft I just submitted should have incorporated all of the comments to date. In addition, I made the following changes: 1. Cleaned up references - I think normative / informative should be correct now 2. Ran through http://tools.ietf.org/tools/idnits/ 3. Updated examples section The additional TODO items I have are: 1. Update intended use section. This probably needs some thought to be sure not to preclude valid uses and be clear on compliance. For now I just removed the ambiguous statement. 2. Working with one other reviewer on other possible additions to the security section, including discussion of logging types (memory vs disk), implications of logging on a target versus an initiator (nodes connected to many other nodes vs singly connected nodes), etc If there are other items I missed, or you see a new item, please let me know. Thanks. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri May 05 15:50:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc6Ji-0006ZR-MM; Fri, 05 May 2006 15:50:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc6JQ-0006UI-LO; Fri, 05 May 2006 15:50:04 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc6JQ-0002fF-Hu; Fri, 05 May 2006 15:50:04 -0400 Received: from pine.neustar.com ([209.173.57.70]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fc6JO-0006Oo-2z; Fri, 05 May 2006 15:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k45Jo1vP000919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 May 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fc6JN-0008PE-Lx; Fri, 05 May 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 05 May 2006 15:50:01 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: ips@ietf.org Subject: [Ips] I-D ACTION:draft-ietf-ips-iscsi-nodearch-key-00.txt 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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : Declarative Public Extension Key for iSCSI Node Architecture Author(s) : D. Wysochanski Filename : draft-ietf-ips-iscsi-nodearch-key-00.txt Pages : 10 Date : 2006-5-5 The iSCSI protocol, described in [RFC3720], allows for extension items to the protocol in the form of Private or Public Extension Keys. This Internet-Draft describes a Public Extension Key for the purpose of enhancing iSCSI supportability. The key accomplishes this objective by allowing iSCSI nodes to communicate architecture details during the iSCSI login sequence. The receiving node can then use this information for enhanced logging and support. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-nodearch-key-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-iscsi-nodearch-key-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-iscsi-nodearch-key-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-5-5143908.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-nodearch-key-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-nodearch-key-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-5143908.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --NextPart-- From ips-bounces@ietf.org Wed May 10 08:30:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdnpR-00041x-0P; Wed, 10 May 2006 08:30:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdnpP-00041s-At for ips@ietf.org; Wed, 10 May 2006 08:30:07 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdnpO-0002xq-3A for ips@ietf.org; Wed, 10 May 2006 08:30:07 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k4ACTnxO012415; Wed, 10 May 2006 07:29:50 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 10 May 2006 14:29:48 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550A004918@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "David Black (E-mail)" Date: Wed, 10 May 2006 14:29:46 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ips@ietf.org Subject: [Ips] RFC4171 error? [ was MIB Doctor review for: draft-ietf-ips-isns-m ib-09.txt] 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 Dan asked for a volunteer for MIB doctor review, and I offered to do so. It is a pretty big MIB module, and so I need some mroe time than I had originally allocated. If the WG wants me to, I can send what I have now, or I can wait till I have completed my review (not sure I will be able to finish this week). In order to do proper review I am also reading RFC4171. I fin there (in my view) a discrepancy between the figure in sect 5 and the flag bit positions in sect 5.1.4 >From the figure it seems tto me that the flags field is only 16 bits. Yet section 5.1.4 talks about bit positions 16-31 ?? Is this on purpose? Am I missing something? Bert _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed May 10 12:00:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdr6y-00046K-0i; Wed, 10 May 2006 12:00:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdr6v-00043k-UD for ips@ietf.org; Wed, 10 May 2006 12:00:25 -0400 Received: from gate02out.mcdata.com ([208.47.132.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fdr6u-0003a2-LA for ips@ietf.org; Wed, 10 May 2006 12:00:25 -0400 Received: from MC4GATE02.mcdata.com ([172.16.11.207]) by GATE02out.mcdata.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 May 2006 10:00:23 -0600 Received: from MC4EXCH01.mcdata.com ([172.16.11.123]) by MC4GATE02.mcdata.com with InterScan Message Security Suite; Wed, 10 May 2006 10:00:19 -0600 Received: from SCEXCH01.mcdata.com ([172.19.161.171]) by MC4EXCH01.mcdata.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 May 2006 10:00:12 -0600 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 Subject: RE: [Ips] RFC4171 error? [ was MIB Doctor review for:draft-ietf-ips-isns-m ib-09.txt] Date: Wed, 10 May 2006 09:00:11 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] RFC4171 error? [ was MIB Doctor review for:draft-ietf-ips-isns-m ib-09.txt] Thread-Index: AcZ0Lp3/0gLvI3SiSe2CuLEEXgu4UgAGZ8eA From: "Kevin Gibbons" To: "Wijnen, Bert \(Bert\)" , "David Black \(E-mail\)" X-OriginalArrivalTime: 10 May 2006 16:00:12.0112 (UTC) FILETIME=[D1B1A500:01C6744A] X-imss-version: 2.038 X-imss-result: Passed X-imss-approveListMatch: *@mcdata.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ips@ietf.org, gramkumar@gmail.com, Scott Kipp 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 Bert, As a co-author of the iSNS MIB draft, I would prefer you send the feedback that you have now. That would allow us to get started on the response progress. Regarding RFC 4171, bits 16 to 31 would comprise 16 bits. Or am I missing something in the feedback? 1 2 3 6789012345678901 Regards, Kevin (gate01) -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 Sent: Wednesday, May 10, 2006 5:30 AM To: David Black (E-mail) Cc: ips@ietf.org Subject: [Ips] RFC4171 error? [ was MIB Doctor review for:draft-ietf-ips-isns-m ib-09.txt] Dan asked for a volunteer for MIB doctor review, and I offered to do so. It is a pretty big MIB module, and so I need some mroe time than I had originally allocated. If the WG wants me to, I can send what I have now, or I can wait till I have completed my review (not sure I will be able to finish this week). In order to do proper review I am also reading RFC4171. I fin there (in my view) a discrepancy between the figure in sect 5 and the flag bit positions in sect 5.1.4 >From the figure it seems tto me that the flags field is only 16 bits. Yet section 5.1.4 talks about bit positions 16-31 ?? Is this on purpose? Am I missing something? Bert _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed May 10 17:13:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdvza-0005tk-8H; Wed, 10 May 2006 17:13:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdvzZ-0005tI-2x for ips@ietf.org; Wed, 10 May 2006 17:13:09 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdvzY-0001Yx-T6 for ips@ietf.org; Wed, 10 May 2006 17:13:09 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k4ALD3TR003389; Wed, 10 May 2006 16:13:06 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 10 May 2006 23:13:03 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550A004AF8@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Kevin Gibbons , "David Black (E-mail)" Subject: RE: [Ips] RFC4171 error? [ was MIB Doctor review for:draft-ietf- ips-isns-m ib-09.txt] Date: Wed, 10 May 2006 23:12:58 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ips@ietf.org, gramkumar@gmail.com, Scott Kipp 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 Inline > -----Original Message----- > From: Kevin Gibbons [mailto:kevin.gibbons@mcdata.com] > Sent: Wednesday, May 10, 2006 18:00 > To: Wijnen, Bert (Bert); David Black (E-mail) > Cc: ips@ietf.org; Scott Kipp; gramkumar@gmail.com > Subject: RE: [Ips] RFC4171 error? [ was MIB Doctor review > for:draft-ietf-ips-isns-m ib-09.txt] > > > Bert, > > As a co-author of the iSNS MIB draft, I would prefer you send the > feedback that you have now. That would allow us to get started on the > response progress. > OK, will package and send asap. > Regarding RFC 4171, bits 16 to 31 would comprise 16 bits. Or am I > missing something in the feedback? > > 1 2 3 > 6789012345678901 > Well, the mismatch is that a field of 16 bits (in my view) has bits 0-15 and not 16-31. Bert > Regards, Kevin > > (gate01) _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed May 10 17:17:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdw3b-0006PC-2e; Wed, 10 May 2006 17:17:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdw3Z-0006Or-Jh for ips@ietf.org; Wed, 10 May 2006 17:17:17 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fdw3Z-0001gB-GB for ips@ietf.org; Wed, 10 May 2006 17:17:17 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fdw3W-00013l-Ru for ips@ietf.org; Wed, 10 May 2006 17:17:17 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k4ALGsit007505; Wed, 10 May 2006 16:16:54 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 10 May 2006 23:16:53 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550A004AF9@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Kevin Gibbons , "David Black (E-mail)" , Scott Kipp , gramkumar@gmail.com Date: Wed, 10 May 2006 23:16:51 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: -2.6 (--) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 Cc: ips@ietf.org Subject: [Ips] MIB Doctor review (part-1) for: draft-ietf-ips-isns-mib-09.txt 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 Dan asked for a volunteer for MIB doctor review, and I offered to do so. Here is my review part-1: - Syntax checking SMICng tells me: W: f(isns.mi2), (2626,19) Row "isnsRegFcNodePortEntry" does not have a consistent indexing scheme - cannot specify an index item from additional "base row" isnsRegFcNodeEntry, since can have only one "base row" which is isnsRegFcPortEntry W: f(isns.mi2), (294,7) Textual convention "IsnsNodeIndexIdOrZero" defined but not used Both are probably OK as long as you are sure that this is what you intend for the first warning. For the second warning one could wonder wht the TC was defined if it is not (yet?) used. Maybe another MIB module is using it? - smilint has no complaints. - I am somehwat confused by: IsnsEntityProtocolId ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The type of protocol that is supported by this entity. Type Value Entity Type ---------- ----------- 1 No Protocol 2 iSCSI 3 iFCP All Others As in the iSNS Specification " REFERENCE "RFC 4171, Section 6" SYNTAX INTEGER { noProtocol(1), iSCSI(2), iFCP(3) } Since this is an ENUMERATION, I have difficulty understanding what "All Others" means in the DESCRIPTION clause. Now if I go to the RFC4171, then I see that IANA assigns new values (and so I think that that is meant here). So I then wonder if it would not be better to move this to an IANA maintained MIB module that is kept in sync with the registry that IANA already must maintain, i.e. the registry at http://www.iana.org/assignments/isns-parameters ? - I also get confused by: IsnsPortalGroupTagIdOrZero ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The Portal Group Tag (PGT) TC for iSCSI Portal Group objects registered in the iSNS. The value of zero indicates a NULL value, or no association, between the associated Portal and iSCSI Node." REFERENCE "RFC 4171, Section 6" SYNTAX Unsigned32 ( 0 .. 65535 ) Sect 6.5.4 of 4171 claims that zero is a valid PGT value/ID, and that a NULL PFT would be expressed by using a zero length in a TLV. So is the use of zero here in conflict with that sect 6.5.4? If not, pls explain why not (and do so in the DESCRIPTION clause. - When I see IsnsPortalSecurityBitmapId ::= TEXTUAL-CONVENTION Then I first wonde if this is an "Id" (Identifier?) of if the name would better be IsnsPortalSecurityBitmap ::= TEXTUAL-CONVENTION But I am more worried about the fact that the bit numbers are different from what is described in sect 6.3.9 of RFC4171. If the WG wants to do it this way conscuiously, then fine, but imagine what happens if other bits get used in the fture (say 23 and 24) and we map those to bits 7 and 8 in the TC, and then yet later bits 21 and 22 get used and we map them to bit 9 and 10. Won;t that start to be confusing? Would it not be handier to define it as SYNTAX BITS { reserved0(0), reserved1)1), ... reserved24(24), tunnelModePreferred(25), transportModePreferred(26), pfsEnabled(27), agressiveModeEnabled(28), mainModeEnabled(29), ikeIpsecEnabled(30), bitmapVALID(31) } So that it maps directly onto the bits in 4171 sect 6.3.9 ?? - for IsnsNodeIndexIdOrZero I guess that the value zero often means none, i.e. no NodeIndexID exists. But I could see it means something else depending on the object that uses this syntax. I would suggest to change the DESCRIPTION clause to something aka: "This textual convention is an extension of the IsnsNodeIndexId textual convention. The latter defines a greater than zero value used to identify an IsnsNode. This extension permits the additional value of zero. The value zero is object-specific and MUST therefore be defined as part of the description of any object which uses this syntax. Examples of the usage of zero might include situations where the IsnsNode was unknown, or when none or all IsnsNodes need to be referenced." - IsnsNodeTypeId is it an Id (Identifier?)? or is it actually a map (or list) of nodeTypes? Good names make sense in my view. Again, I wonder if mapping it to actualy the same bit positions as in RFC4171 would not be better. - IsnsCosBitmapId is it an Id (Indetifier?)? Same question on mapping bits - Same for IsnsScnBitmapId - Same for: IsnsSrvrDscvryMthdId Seems like a map of (supported?) methods as opposed to an ID. - When I see: isnsSrvrInstPhyIndex OBJECT-TYPE SYNTAX Unsigned32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "An index indicating the location of this iSNS Server within a larger entity, if one exists. If the iSNS Server instance is not part of a larger entity, then the value is 0." REFERENCE "RFC 4171" ::= { isnsSrvrInstEntry 5 } Then I am not sure how this "index" tells me anything about the location within a larger entity. Possibly it dioes because it is an index into some other table, but can you pls specify which table that would be. If it is not an index into some other table, then pls explain how it helps in determining "location"? - Why does isnsSrvrInstRole OBJECT-TYPE SYNTAX INTEGER { notSet(0), server(1), serverNotPrimary(2) } not start ENUMerating at 1 instead of zero. We recommend starting at 1 unless there is a good reason to start at zero (which we then like to see mentioned in the DESCRIPTION clause) I can't find why starting at zero is required. Is there any specific section in RFC4171 about this? I see a section on bacup (2.8), that speaks about an "active server" which I do not see mentioned here. Is "serving as a primary" teh same as "active server" ?? That section also speaks about "backup server" which I do not see here? The section indeed also speaks about a "primary server" In any event, I am not sure if and how this object is related to section 2.8. Maybe it is not and maybe it is related to something else? - isnsSrvrInstDiscMcGrp Whever you define an object with SYNTAX of InetAddress, then (according to the DESCRIPTION clasue of InetAddress in RFC4001), you MUST state WHICH object of SYNTAX InetAddressType specifies the format of this object. It seems obvious that this is isnsSrvrInstDiscMcGrpType, yet it is good to mention that. Further, it states: for this server instance. If not configured, then the value is an empty string." But, if it is not configured, then the isnsSrvrInstDiscMcGrpType has a value of unknown (or so I assume), and the value of this object then better be the "zero length string" as opposed to "empty". What does "empty" mean? I would personally rename isnsSrvrInstDiscMcGrp to isnsSrvrInstDiscMcGrpAddress - W.r.t. isnsSrvrInstDiscMcGrpType and isnsSrvrInstDiscMcGrp, I think one could say some more about the allowed InetAddressTypes (if not in the DESCRIPTION clauses of these objects themselves, then at least in a OBJECT clause in the MODULE-COMPLIANCE statements. If I understand things correctly, it has to be an IP multicast address, so possibly only the types "unknown", "ipv4" and "ipv6" are allowed? If "dns| is allowed, then you need to add text as to when a DNS name would be resolved (as per RFC4001). - isnsSrvrInstEsiNonRespThrshld, isnsSrvrInstEnblCntrlNdeMgtScn and isnsSrvrInstCntrlNodeAuth, isnsSrvrInstDfltDdDdsStatus and isnsSrvrInstUpdateDdDdsSpprtd and a few more that follow These objects have a REFERENCE "RFC 4171, Section 3.4" but maybe you mean sect 2.4 ?? - I can't say that I find the DESCRIPTION clause for isnsSrvrInstCntrlNodeAuth very well written. I still need to review the other tables it is pointing to, so I can't say much more yet. nits/typos/consistency/questions: - I wonder why IsnsDdsStatusId ::= TEXTUAL-CONVENTION is not just named IsnsDdsStatus ::= TEXTUAL-CONVENTION I.e. I do nto see why it is an Id (Identifier?)?? Further, IsnsDdsStatusId ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The bitmap indicating the status of a Discovery Domain Set (DDS) registered in the iSNS. Bit Status --------- --------- 0 enabled If bit(0) is set to true then the DDS is Enabled. Otherwise the DDS is disabled." REFERENCE "RFC 4171, Section 6" SYNTAX BITS { enabled(0) } "If bit(0) is set to true" ??? I understand what is meant. But I think it would be cleared to just say "If bit(0) is set to 1" or "If bit(0) is set" Or/and be consistent with how you describe the setting of a bit with other BITS TCs like DdFeatureBitmapId - For consistency, I would rename DdFeatureBitmapId ::= TEXTUAL-CONVENTION to IsnsDdFeatureBitmapId ::= TEXTUAL-CONVENTION or even better: IsnsDdFeatureBitmap ::= TEXTUAL-CONVENTION again, I do not see how this is an Id (Identifier?)?? - isnsSrvrInstEsiNonRespThrshld ... is this an Id (Indetifier?) or is it a threshold. From the descritpion clause it seems it is the latter. So I would rename to isnsSrvrInstEsiNonRespThrsh Mmm... now I see, the l is probably an el and not a one. Why abbreviate "hold" to "hld" ?? In fact why abbreviate "Threshold" to "Thrshld". We (readers) are not all Americans or native English speakers. In fact this whole doc uses (for my taste) far to much (strange) abbreviations for object descriptors and labels. But who is me. - isnsSrvrInstUpdateDdDdsSpprtd and isnsSrvrInstUpdateDdDdsSpprtd use a TC for theri SYNTAX. The idea of a TC is that you only define the semantics in teh DESCRIPTION clause of the TC so you do not have to repeat it everytime that the TC is used as a SYNTAX. admin/bureaucracy: - You may want to check the occurences of "MIB", which in many cases woul be better stated as "MIB module". - references/citations: !! Contains embedded space: P001 L134: network [RFC 4171]. It has the capability to group devices into !! Contains embedded space: P001 L264: Specification [RFC 4171], a DDS can be enabled or disabled, !! Contains embedded space: P001 L307: As described in iSCSI [RFC 3347], Portal Groups provide a The first two are indeed just what it says, namely a blank in between RFC and the actual number. In the references section, you list it as [RFC4171] without a space. The 3rd does have an embadded space too, but also, that RFC does not show up in the references section. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu May 11 07:07:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe8yX-0003eT-Pa; Thu, 11 May 2006 07:04:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe8yW-0003eO-Cj for ips@ietf.org; Thu, 11 May 2006 07:04:56 -0400 Received: from rwcrmhc13.comcast.net ([204.127.192.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fe8yV-0002vC-VH for ips@ietf.org; Thu, 11 May 2006 07:04:56 -0400 Received: from ivvtdkv0981 (unknown[220.196.29.2]) by comcast.net (rwcrmhc13) with SMTP id <20060511110454m1300egrk7e>; Thu, 11 May 2006 11:04:54 +0000 Message-ID: <000001c6754f$5872e9f0$0900050a@ivivity.com> From: "Eddy Quicksall" To: "William Studenmund" References: <000001c66a58$92bc5440$2301a8c0@ivivity.com> <83C76124-0CAA-49D7-B635-52C072572B28@wasabisystems.com> Subject: Re: [Ips] Targets that don't want to support discovery Date: Thu, 11 May 2006 09:56:17 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c 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="===============0749583395==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0749583395== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01C674E1.2583DC20" This is a multi-part message in MIME format. ------=_NextPart_000_0011_01C674E1.2583DC20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I can't find anything in the spec that says a discovery session can't be = redirected. I know that it is logical that redirection would require a = TargetName but I don't see that in the spec either. (but I may be missing those parts so please point out the reference). Eddy ----- Original Message -----=20 From: William Studenmund=20 To: Eddy Quicksall=20 Cc: ips@ietf.org=20 Sent: Thursday, April 27, 2006 7:09 PM Subject: Re: [Ips] Targets that don't want to support discovery On Apr 27, 2006, at 11:50 AM, Eddy Quicksall wrote: Appendix D says: A system that contains targets MUST support discovery sessions on each of its iSCSI IP address-port pairs, and MUST support the SendTargets command on the discovery session Suppose I have targets A, B and C. I want target A to be the only = target that can support discovery. Login to targets B and C will be = redirected by A. This is fine except for the fact that once the redirection occurs = the initiator has the address of B and C and could open a discovery = session to B or C. I'm thinking that I could have B and C redirect to A for any = discovery session hence A would become the only target to support = discovery (but that would "break the law"). I'm wondering how the community thinks this should be handled. I have a feeling that that'd be breaking the rules. Why do you want to do this? Another option is that while ports B and C should support discovery = sessions, they don't have to do it very efficiently. It's fine if they = use some sort of proxy to internally route the commands to A for = processing. So only A is very smart, but discovery works everywhere. Take care, Bill -------------------------------------------------------------------------= ----- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------=_NextPart_000_0011_01C674E1.2583DC20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I can't find anything in the spec that says a = discovery=20 session can't be redirected. I know that it is logical that redirection = would=20 require a TargetName but I don't see that in the spec = either.
 
(but I may be missing those parts so please point = out the=20 reference).
 
Eddy
----- Original Message -----
From:=20 William Studenmund =
To: Eddy = Quicksall=20
Sent: Thursday, April 27, 2006 = 7:09=20 PM
Subject: Re: [Ips] Targets that = don't=20 want to support discovery

On Apr 27, 2006, at 11:50 AM, Eddy Quicksall wrote:
Appendix D says:
   A system that contains targets MUST = support=20 discovery sessions on
   each of its iSCSI IP = address-port=20 pairs, and MUST support the
   SendTargets command on = the=20 discovery session
 
Suppose I have targets A, B and C. I want target = A to be=20 the only target that can support discovery. Login to targets B and C = will be=20 redirected by A.
 
This is fine except for the fact that once the = redirection=20 occurs the initiator has the address of B and C and could open a = discovery=20 session to B or C.
 
I'm thinking that I could have B and C redirect = to A for=20 any discovery session hence A would become the only target to = support=20 discovery (but that would "break the law").
 
I'm wondering how the community thinks this = should be=20 handled.

I have a feeling that that'd be breaking the rules.

Why do you want to do this?

Another option is that while ports B and C should support = discovery=20 sessions, they don't have to do it very efficiently. It's fine if they = use=20 some sort of proxy to internally route the commands to A for = processing. So=20 only A is very smart, but discovery works everywhere.

Take care,

Bill

_______________________________________________
Ips mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
------=_NextPart_000_0011_01C674E1.2583DC20-- --===============0749583395== 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 --===============0749583395==-- From ips-bounces@ietf.org Thu May 11 13:54:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeFKB-0000i0-MC; Thu, 11 May 2006 13:51:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeFK9-0000hu-UP for ips@ietf.org; Thu, 11 May 2006 13:51:41 -0400 Received: from mail74.messagelabs.com ([216.82.244.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FeFK7-0004r9-CT for ips@ietf.org; Thu, 11 May 2006 13:51:41 -0400 X-VirusChecked: Checked X-Env-Sender: jhufferd@Brocade.COM X-Msg-Ref: server-12.tower-74.messagelabs.com!1147369403!31032!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [66.243.153.112] Received: (qmail 10400 invoked from network); 11 May 2006 17:43:24 -0000 Received: from f112.brocade.com (HELO scooby.brocade.com) (66.243.153.112) by server-12.tower-74.messagelabs.com with SMTP; 11 May 2006 17:43:24 -0000 Received: from hq-ex-6.corp.brocade.com (hq-ex-6 [192.168.38.36]) by scooby.brocade.com (Postfix) with ESMTP id 8649225801A; Thu, 11 May 2006 10:43:10 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ips] Targets that don't want to support discovery Date: Thu, 11 May 2006 10:43:23 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] Targets that don't want to support discovery thread-index: AcZ064YBdGQcEwHCRpaIeBxNwPDhlQANDXIw From: "John Hufferd" To: "Eddy Quicksall" , "William Studenmund" X-Spam-Score: 0.0 (/) X-Scan-Signature: ec9c506f029e38d2a6e7b00bc7714181 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="===============1713367150==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1713367150== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C67522.668D4EA3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C67522.668D4EA3 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable The whole issue here was that when we created the discovery stuff we wanted the host system to be able to start their discovery with any portal that they knew about. I am not sure that we would want to prevent what you are suggesting, and I do not think there is any prohibition against it. Especially since the initiator can still start at any known portal. =20 In fact since one of the reasons we created redirection was to permit maintenance to be applied to the targets; this capability may actually be appropriate. The intention was that with some implementations you can have just enough capabilities at the portal to permit the redirection but nothing else while maintenance for the target controller board is being applied. =20 So I would think, therefore, that redirection in the discovery process would be permitted. =20 The issue for any product that uses this approach is: will the iSCSI initiators actually permit this, or will they be surprised by the action and fail in some manner. You may then be technically correct that the initiator has a bug, but this may impact your product schedules as you attempt to get the initiators fixed. You might want to test it first before you bet any development dollars on this. =20 =20 . . . John L Hufferd Sr. Executive Director of Technology Brocade Communications Systems, Inc jhufferd@brocade.com Office Phone: (408) 333-5244; eFAX: (408) 904-4688 Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606 =20 _____ =20 From: Eddy Quicksall [mailto:eddy_quicksall_iVivity_iSCSI@Comcast.net]=20 Sent: Thursday, May 11, 2006 6:56 AM To: William Studenmund Cc: ips@ietf.org Subject: Re: [Ips] Targets that don't want to support discovery =20 I can't find anything in the spec that says a discovery session can't be redirected. I know that it is logical that redirection would require a TargetName but I don't see that in the spec either. =20 (but I may be missing those parts so please point out the reference). =20 Eddy ----- Original Message -----=20 From: William Studenmund =20 To: Eddy Quicksall =20 Cc: ips@ietf.org=20 Sent: Thursday, April 27, 2006 7:09 PM Subject: Re: [Ips] Targets that don't want to support discovery =20 On Apr 27, 2006, at 11:50 AM, Eddy Quicksall wrote: =09 =09 =09 Appendix D says: A system that contains targets MUST support discovery sessions on each of its iSCSI IP address-port pairs, and MUST support the SendTargets command on the discovery session =20 Suppose I have targets A, B and C. I want target A to be the only target that can support discovery. Login to targets B and C will be redirected by A. =20 This is fine except for the fact that once the redirection occurs the initiator has the address of B and C and could open a discovery session to B or C. =20 I'm thinking that I could have B and C redirect to A for any discovery session hence A would become the only target to support discovery (but that would "break the law"). =20 I'm wondering how the community thinks this should be handled. =20 I have a feeling that that'd be breaking the rules. =20 Why do you want to do this? =20 Another option is that while ports B and C should support discovery sessions, they don't have to do it very efficiently. It's fine if they use some sort of proxy to internally route the commands to A for processing. So only A is very smart, but discovery works everywhere. =20 Take care, =20 Bill =09 _____ =20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------_=_NextPart_001_01C67522.668D4EA3 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

The whole issue here was that when = we created the discovery stuff we wanted the host system to be able to = start their discovery with any portal that they knew about.  I am not sure that = we would want to prevent what you are suggesting, and I do not think there = is any prohibition against it. Especially since the initiator can still start at any known = portal.

 

In fact since one of the reasons we created redirection was to permit maintenance to be applied to the = targets; this capability may actually be appropriate. The intention was that with = some implementations you can have just enough capabilities at the portal to permit the = redirection but nothing else while maintenance for the target controller board is = being applied.

 

So I would think, therefore, that redirection in the discovery process would be = permitted.

 

The issue for any product that uses = this approach is: will the iSCSI initiators actually permit this, or will = they be surprised by the action and fail in some manner.  You may then be technically correct that the initiator has a bug, but this may impact = your product schedules as you attempt to get the initiators fixed.  You = might want to test it first before you bet any development dollars on = this. 

 

.

.

.

John L Hufferd

Sr. Executive Director of = Technology

Brocade Communications Systems, = Inc

jhufferd@brocade.com

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

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

 

From: Eddy = Quicksall [mailto:eddy_quicksall_iVivity_iSCSI@Comcast.net]
Sent: Thursday, May 11, = 2006 6:56 AM
To: William = Studenmund
Cc: ips@ietf.org
Subject: Re: [Ips] = Targets that don't want to support discovery

 

I can't find anything in the spec that says a discovery session = can't be redirected. I know that it is logical that redirection would require = a TargetName but I don't see that in the spec = either.

 

(but I may be missing those parts so please point out the = reference).

 

Eddy

----- Original Message ----- =

Cc: ips@ietf.org =

Sent: = Thursday, April 27, 2006 7:09 PM

Subject: Re: = [Ips] Targets that don't want to support discovery

 

On Apr 27, 2006, at 11:50 AM, Eddy Quicksall = wrote:



Appendix D says:

   A system that contains targets MUST support = discovery sessions on
   each of its iSCSI IP address-port pairs, and MUST support = the
   SendTargets command on the discovery = session

 

Suppose I have targets A, B and C. I want target A to be the = only target that can support discovery. Login to targets B and C will be redirected by A.

 

This is fine except for the fact that once the redirection = occurs the initiator has the address of B and C and could open a discovery session = to B or C.

 

I'm thinking that I could have B and C redirect to A for any = discovery session hence A would become the only target to support discovery (but = that would "break the law").

 

I'm wondering how the community thinks this should be = handled.

 

I have a feeling that that'd be breaking the = rules.

 

Why do you want to do this?

 

Another option is that while ports B and C should support = discovery sessions, they don't have to do it very efficiently. It's fine if they = use some sort of proxy to internally route the commands to A for processing. So = only A is very smart, but discovery works = everywhere.

 

Take care,

 

Bill

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

------_=_NextPart_001_01C67522.668D4EA3-- --===============1713367150== 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 --===============1713367150==-- From ips-bounces@ietf.org Sat May 20 07:39:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhPnB-0002Qq-FC; Sat, 20 May 2006 07:38:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhPn9-0002Qg-UD for ips@ietf.org; Sat, 20 May 2006 07:38:43 -0400 Received: from sccrmhc12.comcast.net ([63.240.77.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhPn7-0002g5-O5 for ips@ietf.org; Sat, 20 May 2006 07:38:43 -0400 Received: from ivvtdkv0981 (c-66-177-56-218.hsd1.fl.comcast.net[66.177.56.218]) by comcast.net (sccrmhc12) with SMTP id <20060520113840012005a8iqe>; Sat, 20 May 2006 11:38:41 +0000 Message-ID: <001201c67c01$f1415500$04031eac@ivivity.com> From: "Eddy Quicksall" To: Date: Sat, 20 May 2006 07:38:39 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [Ips] DDP question 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="===============0902034957==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0902034957== Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C67BE0.698655A0" This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C67BE0.698655A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I want to ask a DDP question. Does anyone know how to access the DDP = forum? Eddy ------=_NextPart_000_000F_01C67BE0.698655A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I want to ask a DDP question. Does anyone know how = to access=20 the DDP forum?
 
Eddy
------=_NextPart_000_000F_01C67BE0.698655A0-- --===============0902034957== 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 --===============0902034957==-- From ips-bounces@ietf.org Sun May 21 12:05:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhqQk-0006Gk-3L; Sun, 21 May 2006 12:05:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhqQi-0006Gf-S9 for ips@ietf.org; Sun, 21 May 2006 12:05:20 -0400 Received: from mexforward.lss.emc.com ([168.159.213.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhqQh-00043Q-KF for ips@ietf.org; Sun, 21 May 2006 12:05:20 -0400 Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13]) by mexforward.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4LG5HcN000225; Sun, 21 May 2006 12:05:17 -0400 (EDT) Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4LG5GQk003263; Sun, 21 May 2006 12:05:16 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Sun, 21 May 2006 12:05:16 -0400 Message-ID: From: Black_David@emc.com To: eddy_quicksall_iVivity_iSCSI@Comcast.net, ips@ietf.org Subject: RE: [Ips] DDP question Date: Sun, 21 May 2006 12:05:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.3.0.1, Antispam-Data: 2006.5.21.83104 X-PerlMx-Spam: Gauge=, SPAM=3%, Reason='EMC_FROM_0+ -2, HTML_70_90 0.1, NO_REAL_NAME 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_HTML 0, __MIME_VERSION 0, __SANE_MSGID 0, __TAG_EXISTS_HTML 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: 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="===============1204426067==" Errors-To: ips-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1204426067== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C67CF0.56BDAE89" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C67CF0.56BDAE89 Content-Type: text/plain rddp@ietf.org --David _____ From: Eddy Quicksall [mailto:eddy_quicksall_iVivity_iSCSI@Comcast.net] Sent: Saturday, May 20, 2006 7:39 AM To: ips@ietf.org Subject: [Ips] DDP question I want to ask a DDP question. Does anyone know how to access the DDP forum? Eddy ------_=_NextPart_001_01C67CF0.56BDAE89 Content-Type: text/html
rddp@ietf.org  --David

From: Eddy Quicksall [mailto:eddy_quicksall_iVivity_iSCSI@Comcast.net]
Sent: Saturday, May 20, 2006 7:39 AM
To: ips@ietf.org
Subject: [Ips] DDP question

I want to ask a DDP question. Does anyone know how to access the DDP forum?
 
Eddy
------_=_NextPart_001_01C67CF0.56BDAE89-- --===============1204426067== 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 --===============1204426067==-- From ips-bounces@ietf.org Tue May 23 14:22:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FibVx-0007GD-Fc; Tue, 23 May 2006 14:21:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FibVv-0007G7-LH for ips@ietf.org; Tue, 23 May 2006 14:21:51 -0400 Received: from sccrmhc13.comcast.net ([204.127.200.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FibVu-0003hD-FA for ips@ietf.org; Tue, 23 May 2006 14:21:51 -0400 Received: from ivvtdkv0981 (c-66-177-56-218.hsd1.fl.comcast.net[66.177.56.218]) by comcast.net (sccrmhc13) with SMTP id <2006052318214901300bku5fe>; Tue, 23 May 2006 18:21:50 +0000 Message-ID: <000b01c67e95$c24c3940$04031eac@ivivity.com> From: "Eddy Quicksall" To: Date: Tue, 23 May 2006 14:21:48 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [Ips] [iSER] Connection_Handle question 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="===============0680616652==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0680616652== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C67E74.3A87C400" This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C67E74.3A87C400 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Generally when an upper layer is going to use a lower layer, the lower = layer gives a handle (many times via an open call). In the primitives the Connection_Handle is passed as an input qualifier. = But I don't see any primitive that returns the Connection_Handle. Am I = missing that? Eddy ------=_NextPart_000_0008_01C67E74.3A87C400 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Generally when an upper layer is going to use a = lower=20 layer, the lower layer gives a handle (many times via an open=20 call).
 
In the primitives the Connection_Handle is passed as = an input qualifier. But I don't see any primitive that returns = the=20 Connection_Handle. Am I missing that?
 
Eddy
------=_NextPart_000_0008_01C67E74.3A87C400-- --===============0680616652== 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 --===============0680616652==-- From ips-bounces@ietf.org Tue May 23 16:51:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fidpw-0001Af-K1; Tue, 23 May 2006 16:50:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fidpv-0001Aa-Q1 for ips@ietf.org; Tue, 23 May 2006 16:50:39 -0400 Received: from rwcrmhc13.comcast.net ([216.148.227.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fidpu-0003BE-Hn for ips@ietf.org; Tue, 23 May 2006 16:50:39 -0400 Received: from ivvtdkv0981 (c-66-177-56-218.hsd1.fl.comcast.net[66.177.56.218]) by comcast.net (rwcrmhc13) with SMTP id <20060523205037m1300gieq3e>; Tue, 23 May 2006 20:50:37 +0000 Message-ID: <000c01c67eaa$8e9c8400$04031eac@ivivity.com> From: "Eddy Quicksall" To: Date: Tue, 23 May 2006 16:50:41 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [Ips] TargetAddress used in discovery without a SendTargets 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="===============0469886939==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0469886939== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C67E89.06E86270" This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C67E89.06E86270 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable For a discovery session the initiator is allowed to login without a = TargetName. Normally the initiator uses SendTargets to solicit the = TargetAddress(s). But if the SendTargets is not used and there was no TargetName given by = the initiator, is it intended that the target could send the = TargetAddress/TargetAlias/TargetPortalGroupTag information? Eddy ------=_NextPart_000_0009_01C67E89.06E86270 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
For a discovery session the initiator is = allowed to=20 login without a TargetName. Normally the initiator uses SendTargets to = solicit=20 the TargetAddress(s).
 
But if the SendTargets is not used and there was no = TargetName=20 given by the initiator, is it intended that the target could send = the=20 TargetAddress/TargetAlias/TargetPortalGroupTag information?
 
Eddy
------=_NextPart_000_0009_01C67E89.06E86270-- --===============0469886939== 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 --===============0469886939==-- From ips-bounces@ietf.org Wed May 24 14:34:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiyBK-0007M3-9j; Wed, 24 May 2006 14:34:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiyBJ-0007Lv-GN for ips@ietf.org; Wed, 24 May 2006 14:34:05 -0400 Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiyBI-0006qN-5r for ips@ietf.org; Wed, 24 May 2006 14:34:05 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 573FE87165; Wed, 24 May 2006 14:33:56 -0400 (EDT) In-Reply-To: <000c01c67eaa$8e9c8400$04031eac@ivivity.com> References: <000c01c67eaa$8e9c8400$04031eac@ivivity.com> Mime-Version: 1.0 (Apple Message framework v750) X-Priority: 3 Message-Id: From: William Studenmund Subject: Re: [Ips] TargetAddress used in discovery without a SendTargets Date: Wed, 24 May 2006 11:33:49 -0700 To: Eddy Quicksall X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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="===============1652038414==" Errors-To: ips-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1652038414== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-2-537221722" Content-Transfer-Encoding: 7bit This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-2-537221722 Content-Type: multipart/alternative; boundary=Apple-Mail-1-537221645 --Apple-Mail-1-537221645 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On May 23, 2006, at 1:50 PM, Eddy Quicksall wrote: > For a discovery session the initiator is allowed to login without a > TargetName. Normally the initiator uses SendTargets to solicit the > TargetAddress(s). > > But if the SendTargets is not used and there was no TargetName > given by the initiator, is it intended that the target could send > the TargetAddress/TargetAlias/TargetPortalGroupTag information? A discovery session is, as I understand it, intended for SendTargets discovery. If the initiator doesn't want to perform SendTargets discovery even after starting a discovery session, why do we feel the need for the target to do anything? Take care, Bill --Apple-Mail-1-537221645 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On May 23, 2006, at = 1:50 PM, Eddy Quicksall wrote:

=
For a discovery session=A0the initiator=A0is = allowed to login without a TargetName. Normally the initiator uses = SendTargets to solicit the TargetAddress(s).
=A0
But if the SendTargets = is not used and there was no TargetName given by the initiator, is it = intended that the target=A0could send the = TargetAddress/TargetAlias/TargetPortalGroupTag = information?

A discovery session = is, as I understand it, intended for SendTargets discovery. If the = initiator doesn't want to perform SendTargets discovery even after = starting a discovery session, why do we feel the need for the target to = do anything?

Take care,

Bill
= --Apple-Mail-1-537221645-- --Apple-Mail-2-537221722 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEdKcTDJT2Egh26K0RAo1HAKCfr8nfO5j+gmqgYeNbJAFYFYekYQCfdPJN 6zO5HI5zAZl9I2Ii1WPw2ro= =s9BZ -----END PGP SIGNATURE----- --Apple-Mail-2-537221722-- --===============1652038414== 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 --===============1652038414==-- From ips-bounces@ietf.org Thu May 25 13:45:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjJtl-0003yi-Pg; Thu, 25 May 2006 13:45:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjJtk-0003ya-B5 for ips@ietf.org; Thu, 25 May 2006 13:45:24 -0400 Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjJtj-0006Jl-2H for ips@ietf.org; Thu, 25 May 2006 13:45:24 -0400 Received: from ivvtdkv0981 (c-66-177-56-218.hsd1.fl.comcast.net[66.177.56.218]) by comcast.net (sccrmhc14) with SMTP id <2006052517450701400ksj98e>; Thu, 25 May 2006 17:45:12 +0000 Message-ID: <001601c68022$f9b749e0$04031eac@ivivity.com> From: "Eddy Quicksall" To: "William Studenmund" References: <000c01c67eaa$8e9c8400$04031eac@ivivity.com> Subject: Re: [Ips] TargetAddress used in discovery without a SendTargets Date: Thu, 25 May 2006 13:45:08 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab 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="===============0197135081==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0197135081== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01C68001.6FA62580" This is a multi-part message in MIME format. ------=_NextPart_000_0011_01C68001.6FA62580 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I don't. What I asked is if it is "intended that the target could send = it". Eddy ----- Original Message -----=20 From: William Studenmund=20 To: Eddy Quicksall=20 Cc: ips@ietf.org=20 Sent: Wednesday, May 24, 2006 2:33 PM Subject: Re: [Ips] TargetAddress used in discovery without a = SendTargets On May 23, 2006, at 1:50 PM, Eddy Quicksall wrote: For a discovery session the initiator is allowed to login without a = TargetName. Normally the initiator uses SendTargets to solicit the = TargetAddress(s). But if the SendTargets is not used and there was no TargetName given = by the initiator, is it intended that the target could send the = TargetAddress/TargetAlias/TargetPortalGroupTag information? A discovery session is, as I understand it, intended for SendTargets = discovery. If the initiator doesn't want to perform SendTargets = discovery even after starting a discovery session, why do we feel the = need for the target to do anything? Take care, Bill -------------------------------------------------------------------------= ----- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------=_NextPart_000_0011_01C68001.6FA62580 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I don't. What I asked is if it is "intended that the = target=20 could send it".
 
Eddy
----- Original Message -----
From:=20 William Studenmund =
To: Eddy = Quicksall=20
Sent: Wednesday, May 24, 2006 = 2:33=20 PM
Subject: Re: [Ips] = TargetAddress used in=20 discovery without a SendTargets

On May 23, 2006, at 1:50 PM, Eddy Quicksall wrote:
For a discovery session the = initiator is allowed=20 to login without a TargetName. Normally the initiator uses = SendTargets to=20 solicit the TargetAddress(s).
 
But if the SendTargets is not used and there was = no=20 TargetName given by the initiator, is it intended that the = target could=20 send the TargetAddress/TargetAlias/TargetPortalGroupTag=20 information?

A discovery session is, as I understand it, intended for = SendTargets=20 discovery. If the initiator doesn't want to perform SendTargets = discovery even=20 after starting a discovery session, why do we feel the need for the = target to=20 do anything?

Take care,

Bill

_______________________________________________
Ips mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
------=_NextPart_000_0011_01C68001.6FA62580-- --===============0197135081== 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 --===============0197135081==-- From ips-bounces@ietf.org Thu May 25 13:51:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjJzg-0008KT-2c; Thu, 25 May 2006 13:51:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjJze-0008KO-SE for ips@ietf.org; Thu, 25 May 2006 13:51:30 -0400 Received: from sccrmhc14.comcast.net ([204.127.200.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjJzd-000711-Jb for ips@ietf.org; Thu, 25 May 2006 13:51:30 -0400 Received: from ivvtdkv0981 (c-66-177-56-218.hsd1.fl.comcast.net[66.177.56.218]) by comcast.net (sccrmhc14) with SMTP id <2006052517512901400km35de>; Thu, 25 May 2006 17:51:29 +0000 Message-ID: <002401c68023$d9f60eb0$04031eac@ivivity.com> From: "Eddy Quicksall" To: References: <000b01c67e95$c24c3940$04031eac@ivivity.com> Subject: Re: [Ips] [iSER] Connection_Handle question Date: Thu, 25 May 2006 13:51:28 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.1 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f 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="===============0181175637==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0181175637== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01C68002.526D69F0" This is a multi-part message in MIME format. ------=_NextPart_000_0021_01C68002.526D69F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think I found the answer in the definition of "Connection Handle". Am = I correct that the iSCSI and iSER layers both must understand the handle = since both must access the TCP/IP stack. For example if it is sockets, = the handle may be the "socket"; or if it is a proprietary scheme the = handle may be a pointer to a structure that is understood by both the = iSER and iSCSI layers. Eddy ----- Original Message -----=20 From: Eddy Quicksall=20 To: ips@ietf.org=20 Sent: Tuesday, May 23, 2006 2:21 PM Subject: [Ips] [iSER] Connection_Handle question Generally when an upper layer is going to use a lower layer, the lower = layer gives a handle (many times via an open call). In the primitives the Connection_Handle is passed as an input = qualifier. But I don't see any primitive that returns the = Connection_Handle. Am I missing that? Eddy -------------------------------------------------------------------------= ----- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------=_NextPart_000_0021_01C68002.526D69F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I think I found the answer in the definition of = "Connection=20 Handle". Am I correct that the iSCSI and iSER layers both must = understand the=20 handle since both must access the TCP/IP stack. For example if it=20 is sockets, the handle may be the "socket"; or if it is a = proprietary=20 scheme the handle may be a pointer to a structure that = is understood by=20 both the iSER and iSCSI layers.
 
Eddy
----- Original Message -----
From:=20 Eddy = Quicksall=20
Sent: Tuesday, May 23, 2006 = 2:21 PM
Subject: [Ips] [iSER] = Connection_Handle=20 question

Generally when an upper layer is going to use = a lower=20 layer, the lower layer gives a handle (many times via an open=20 call).
 
In the primitives the Connection_Handle is passed = as=20 an input qualifier. But I don't see any primitive that = returns the=20 Connection_Handle. Am I missing that?
 
Eddy

_______________________________________________
Ips mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
------=_NextPart_000_0021_01C68002.526D69F0-- --===============0181175637== 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 --===============0181175637==-- From ips-bounces@ietf.org Thu May 25 17:45:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjNdX-0007Jr-Oc; Thu, 25 May 2006 17:44:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjNdW-0007Il-SM for ips@ietf.org; Thu, 25 May 2006 17:44:54 -0400 Received: from sccrmhc12.comcast.net ([204.127.200.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjNc3-0003Z1-Ux for ips@ietf.org; Thu, 25 May 2006 17:43:26 -0400 Received: from ivvtdkv0981 (c-66-177-56-218.hsd1.fl.comcast.net[66.177.56.218]) by comcast.net (sccrmhc12) with SMTP id <2006052521432201200eg17je>; Thu, 25 May 2006 21:43:23 +0000 Message-ID: <003901c68044$410fbe00$04031eac@ivivity.com> From: "Eddy Quicksall" To: "William Studenmund" References: <000c01c67eaa$8e9c8400$04031eac@ivivity.com> <001601c68022$f9b749e0$04031eac@ivivity.com> Subject: Re: [Ips] TargetAddress used in discovery without a SendTargets Date: Thu, 25 May 2006 17:43:17 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.1 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 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="===============0137648542==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0137648542== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0036_01C68022.B4EE7E50" This is a multi-part message in MIME format. ------=_NextPart_000_0036_01C68022.B4EE7E50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I realize the confusion ... I was not really clear. Here is the case: = the initiator logs in with SessionType=3DDiscovery and does not specify = a TargetName but before the login is complete the "target" (which has = not been named) sends the TargetName. The spec does not prohibit this. = My question is: was this intended? Eddy ----- Original Message -----=20 From: Eddy Quicksall=20 To: William Studenmund=20 Cc: ips@ietf.org=20 Sent: Thursday, May 25, 2006 1:45 PM Subject: Re: [Ips] TargetAddress used in discovery without a = SendTargets I don't. What I asked is if it is "intended that the target could send = it". Eddy ----- Original Message -----=20 From: William Studenmund=20 To: Eddy Quicksall=20 Cc: ips@ietf.org=20 Sent: Wednesday, May 24, 2006 2:33 PM Subject: Re: [Ips] TargetAddress used in discovery without a = SendTargets On May 23, 2006, at 1:50 PM, Eddy Quicksall wrote: For a discovery session the initiator is allowed to login without = a TargetName. Normally the initiator uses SendTargets to solicit the = TargetAddress(s). But if the SendTargets is not used and there was no TargetName = given by the initiator, is it intended that the target could send the = TargetAddress/TargetAlias/TargetPortalGroupTag information? A discovery session is, as I understand it, intended for SendTargets = discovery. If the initiator doesn't want to perform SendTargets = discovery even after starting a discovery session, why do we feel the = need for the target to do anything? Take care, Bill -------------------------------------------------------------------------= --- _______________________________________________ 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_000_0036_01C68022.B4EE7E50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I realize the confusion ... I was not really clear. = Here is=20 the case: the initiator logs in with SessionType=3DDiscovery and does = not specify=20 a TargetName but before the login is complete the "target" (which = has not=20 been named) sends the TargetName. The spec does not prohibit=20 this. My question is: was this intended?
 
Eddy
----- Original Message -----
From:=20 Eddy = Quicksall=20
Sent: Thursday, May 25, 2006 = 1:45=20 PM
Subject: Re: [Ips] = TargetAddress used in=20 discovery without a SendTargets

I don't. What I asked is if it is "intended that = the target=20 could send it".
 
Eddy
----- Original Message -----
From:=20 William Studenmund =
To: Eddy = Quicksall=20
Sent: Wednesday, May 24, 2006 = 2:33=20 PM
Subject: Re: [Ips] = TargetAddress used=20 in discovery without a SendTargets

On May 23, 2006, at 1:50 PM, Eddy Quicksall wrote:
For a discovery session the = initiator is=20 allowed to login without a TargetName. Normally the initiator uses = SendTargets to solicit the TargetAddress(s).
 
But if the SendTargets is not used and there = was no=20 TargetName given by the initiator, is it intended that the=20 target could send the = TargetAddress/TargetAlias/TargetPortalGroupTag=20 information?

A discovery session is, as I understand it, intended for = SendTargets=20 discovery. If the initiator doesn't want to perform SendTargets = discovery=20 even after starting a discovery session, why do we feel the need for = the=20 target to do anything?

Take care,

Bill

_______________________________________________
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_000_0036_01C68022.B4EE7E50-- --===============0137648542== 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 --===============0137648542==-- From ips-bounces@ietf.org Thu May 25 18:00:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjNsp-0002T2-Dr; Thu, 25 May 2006 18:00:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjNsn-0002Sx-H0 for ips@ietf.org; Thu, 25 May 2006 18:00:41 -0400 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjNsl-0005qA-Qt for ips@ietf.org; Thu, 25 May 2006 18:00:41 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.13.6/8.13.6) with ESMTP id k4PM0d4x094808 for ; Thu, 25 May 2006 22:00:39 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k4PM2JQw137546 for ; Fri, 26 May 2006 00:02:19 +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 k4PM0cjh007393 for ; Fri, 26 May 2006 00:00:38 +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 k4PM0cD9007370; Fri, 26 May 2006 00:00:38 +0200 In-Reply-To: <003901c68044$410fbe00$04031eac@ivivity.com> To: "Eddy Quicksall" Subject: Re: [Ips] TargetAddress used in discovery without a SendTargets MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 August 18, 2005 From: Julian Satran Message-ID: Date: Thu, 25 May 2006 18:02:17 -0400 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.1HF123 | April 14, 2006) at 26/05/2006 01:02:18, Serialize complete at 26/05/2006 01:02:18 X-Spam-Score: 0.1 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Cc: ips@ietf.org, William Studenmund 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="===============2123516811==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============2123516811== Content-Type: multipart/alternative; boundary="=_alternative 0078E66F85257179_=" This is a multipart message in MIME format. --=_alternative 0078E66F85257179_= Content-Type: text/plain; charset="US-ASCII" It does do any harm. TargetName is mandated if you name things to validate that you got where you intended but why forbit it if it does no harm. Julo "Eddy Quicksall" 25/05/06 17:43 To "William Studenmund" cc ips@ietf.org Subject Re: [Ips] TargetAddress used in discovery without a SendTargets I realize the confusion ... I was not really clear. Here is the case: the initiator logs in with SessionType=Discovery and does not specify a TargetName but before the login is complete the "target" (which has not been named) sends the TargetName. The spec does not prohibit this. My question is: was this intended? Eddy ----- Original Message ----- From: Eddy Quicksall To: William Studenmund Cc: ips@ietf.org Sent: Thursday, May 25, 2006 1:45 PM Subject: Re: [Ips] TargetAddress used in discovery without a SendTargets I don't. What I asked is if it is "intended that the target could send it". Eddy ----- Original Message ----- From: William Studenmund To: Eddy Quicksall Cc: ips@ietf.org Sent: Wednesday, May 24, 2006 2:33 PM Subject: Re: [Ips] TargetAddress used in discovery without a SendTargets On May 23, 2006, at 1:50 PM, Eddy Quicksall wrote: For a discovery session the initiator is allowed to login without a TargetName. Normally the initiator uses SendTargets to solicit the TargetAddress(s). But if the SendTargets is not used and there was no TargetName given by the initiator, is it intended that the target could send the TargetAddress/TargetAlias/TargetPortalGroupTag information? A discovery session is, as I understand it, intended for SendTargets discovery. If the initiator doesn't want to perform SendTargets discovery even after starting a discovery session, why do we feel the need for the target to do anything? Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 0078E66F85257179_= Content-Type: text/html; charset="US-ASCII"
It does do any harm. TargetName is mandated if you name things to validate that you got where you intended but why forbit it if it does no harm.

Julo


"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@Comcast.net>

25/05/06 17:43

To
"William Studenmund" <wrstuden@wasabisystems.com>
cc
ips@ietf.org
Subject
Re: [Ips] TargetAddress used in discovery without a SendTargets





I realize the confusion ... I was not really clear. Here is the case: the initiator logs in with SessionType=Discovery and does not specify a TargetName but before the login is complete the "target" (which has not been named) sends the TargetName. The spec does not prohibit this. My question is: was this intended?
 
Eddy
----- Original Message -----
From: Eddy Quicksall
To: William Studenmund
Cc: ips@ietf.org
Sent: Thursday, May 25, 2006 1:45 PM
Subject: Re: [Ips] TargetAddress used in discovery without a SendTargets

I don't. What I asked is if it is "intended that the target could send it".
 
Eddy
----- Original Message -----
From: William Studenmund
To: Eddy Quicksall
Cc: ips@ietf.org
Sent: Wednesday, May 24, 2006 2:33 PM
Subject: Re: [Ips] TargetAddress used in discovery without a SendTargets

On May 23, 2006, at 1:50 PM, Eddy Quicksall wrote:

For a discovery session the initiator is allowed to login without a TargetName. Normally the initiator uses SendTargets to solicit the TargetAddress(s).
 
But if the SendTargets is not used and there was no TargetName given by the initiator, is it intended that the target could send the TargetAddress/TargetAlias/TargetPortalGroupTag information?

A discovery session is, as I understand it, intended for SendTargets discovery. If the initiator doesn't want to perform SendTargets discovery even after starting a discovery session, why do we feel the need for the target to do anything?

Take care,

Bill

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

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

--=_alternative 0078E66F85257179_=-- --===============2123516811== 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 --===============2123516811==-- From ips-bounces@ietf.org Thu May 25 18:11:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjO3G-0006OB-Vd; Thu, 25 May 2006 18:11:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjO3E-0006O6-V2 for ips@ietf.org; Thu, 25 May 2006 18:11:28 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjO38-0006wO-IH for ips@ietf.org; Thu, 25 May 2006 18:11:28 -0400 Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k4PMBLmO007733 for ; Thu, 25 May 2006 16:11:21 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IZU00101DG89H00@mail-amer.sun.com> (original mail from David.Weibel@Sun.COM) for ips@ietf.org; Thu, 25 May 2006 16:11:21 -0600 (MDT) Received: from [129.147.9.33] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IZU00CZHDMWBNU2@mail-amer.sun.com> for ips@ietf.org; Thu, 25 May 2006 16:11:21 -0600 (MDT) Date: Thu, 25 May 2006 16:11:20 -0600 From: David Weibel To: ips@ietf.org Message-id: <44762B88.7060306@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050322) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Ips] TargetAlias in SendTarget response 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 I was wondering what people would think about adding the allowed and suggested use of TargetAlias during a SendTargets response. This would be an optional component of the response. The goal would be to send the alias earlier in the discovery process so the initiator software could also present it earlier to the user. This would require the ammendment of Appendix D. "No text keys other than TargetName and TargetAddress are permitted within a SendTargets response." Along with some additional text. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu May 25 22:47:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjSM3-0007A2-V9; Thu, 25 May 2006 22:47:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjSM2-00074p-Qs for ips@ietf.org; Thu, 25 May 2006 22:47:10 -0400 Received: from mail-gw3.adaptec.com ([216.52.22.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjSM1-0005Mu-FF for ips@ietf.org; Thu, 25 May 2006 22:47:10 -0400 Received: from aime2k04.adaptec.com (aime2k04.adaptec.com [10.25.8.45]) by mail-gw3.adaptec.com (Spam Firewall) with ESMTP id 890E4A8FCD; Thu, 25 May 2006 19:47:04 -0700 (PDT) Received: from aime2k302.adaptec.com ([10.25.8.48]) by aime2k04.adaptec.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 25 May 2006 19:47:04 -0700 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 Subject: RE: [Ips] TargetAlias in SendTarget response Date: Thu, 25 May 2006 19:46:59 -0700 Message-ID: <368FBF3D8437A748BA8222526BF9309962CDE4@aime2k302.adaptec.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] TargetAlias in SendTarget response Thread-Index: AcaASGv8AknEToOwSVG5YVigUlYKxwAIlC+w From: "Sandars, Ken" To: "David Weibel" , X-OriginalArrivalTime: 26 May 2006 02:47:04.0557 (UTC) FILETIME=[ABE901D0:01C6806E] X-Virus-Scanned: by Barracuda Spam Firewall at adaptec.com X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: 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 Hi David, It's certainly a nice idea, and I cannot remember why the TargetAlias was excluded from the SendTargets response. Since it would be optional the target can decide if there are any security issues or FUD with sending it or not. The benefit is it avoids the rather clumsy sequence of doing a (discovery) login and logout to each target found in the original unnamed discovery session just to provoke the target into sending the TargetAlias as part of the login phase. However, it cannot just be added now without potentially breaking some initiators which are not expecting it, or are actively ensuring it is not sent. Perhaps a new IO,LO,Declarative key could be introduced for use by the initiator to indicate its willingness to accept TargetAlias as part of the SendTarget's response? Cheers Ken > -----Original Message----- > From: David Weibel [mailto:David.Weibel@Sun.COM]=20 > Sent: 26 May 2006 08:11 > To: ips@ietf.org > Subject: [Ips] TargetAlias in SendTarget response >=20 >=20 > I was wondering what people would think about adding the > allowed and suggested use of TargetAlias during a SendTargets > response. This would be an optional component of the response. > The goal would be to send the alias earlier in the discovery > process so the initiator software could also present it earlier > to the user. >=20 > This would require the ammendment of Appendix D. "No text > keys other than TargetName and TargetAddress are permitted > within a SendTargets response." Along with some additional > text. >=20 > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips >=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri May 26 13:05:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjfkt-0007Gj-5N; Fri, 26 May 2006 13:05:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjfks-0007Ge-8w for ips@ietf.org; Fri, 26 May 2006 13:05:42 -0400 Received: from web51902.mail.yahoo.com ([206.190.48.65]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fjfkr-00013e-1E for ips@ietf.org; Fri, 26 May 2006 13:05:42 -0400 Received: (qmail 39871 invoked by uid 60001); 26 May 2006 17:05:38 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ONUow2EDcvNTkeyv8055PUdiNwsCZKi3DV5L/IWgyOHSBK0IzGp3sym9V9+KSj9k9ePrzPAAP+HqGU2UcyE0aALtl/eIwg6m2al5UggKNG1frRemRS80WmGOVqg5fMjhMZpBECN4ffXI7JClU+Lr+d+u+ngwZpiVnKHKNbQXdTU= ; Message-ID: <20060526170538.39869.qmail@web51902.mail.yahoo.com> Received: from [161.114.64.75] by web51902.mail.yahoo.com via HTTP; Fri, 26 May 2006 10:05:38 PDT Date: Fri, 26 May 2006 10:05:38 -0700 (PDT) From: "Mallikarjun C." Subject: Re: [Ips] [iSER] Connection_Handle question To: ips@ietf.org In-Reply-To: <002401c68023$d9f60eb0$04031eac@ivivity.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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 Yes, you are correct. Mallikarjun --- Eddy Quicksall wrote: > I think I found the answer in the definition of > "Connection Handle". Am I correct that the iSCSI and > iSER layers both must understand the handle since > both must access the TCP/IP stack. For example if it > is sockets, the handle may be the "socket"; or if it > is a proprietary scheme the handle may be a pointer > to a structure that is understood by both the iSER > and iSCSI layers. > > Eddy > ----- Original Message ----- > From: Eddy Quicksall > To: ips@ietf.org > Sent: Tuesday, May 23, 2006 2:21 PM > Subject: [Ips] [iSER] Connection_Handle question > > > Generally when an upper layer is going to use a > lower layer, the lower layer gives a handle (many > times via an open call). > > In the primitives the Connection_Handle is passed > as an input qualifier. But I don't see any primitive > that returns the Connection_Handle. Am I missing > that? > > Eddy > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > 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 > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue May 30 19:14:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlDPs-0000pf-EI; Tue, 30 May 2006 19:14:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlDPo-0000mi-HZ; Tue, 30 May 2006 19:14:20 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlDPm-0001Mq-Ri; Tue, 30 May 2006 19:14:20 -0400 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k4UNEIng018960; Tue, 30 May 2006 16:14:18 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k4UNEImp018959; Tue, 30 May 2006 16:14:18 -0700 Date: Tue, 30 May 2006 16:14:18 -0700 Message-Id: <200605302314.k4UNEImp018959@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: ips@ietf.org, rfc-editor@rfc-editor.org Subject: [Ips] RFC 4544 on Definitions of Managed Objects for Internet Small Computer System Interface (iSCSI) 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 4544 Title: Definitions of Managed Objects for Internet Small Computer System Interface (iSCSI) Author: M. Bakke, M. Krueger, T. McSweeney, J. Muchow Status: Standards Track Date: May 2006 Mailbox: mbakke@cisco.com, marjorie_krueger@hp.com, tommcs@us.ibm.com, james.muchow@qlogic.com Pages: 83 Characters: 156541 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ips-iscsi-mib-11.txt URL: http://www.rfc-editor.org/rfc/rfc4544.txt This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing a client using the Internet Small Computer System Interface (iSCSI) protocol (SCSI over TCP). [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. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue May 30 19:14:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlDPl-0000m8-Ld; Tue, 30 May 2006 19:14:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlDPj-0000l3-4B; Tue, 30 May 2006 19:14:15 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlDPh-0001MU-Op; Tue, 30 May 2006 19:14:15 -0400 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k4UNED8p018955; Tue, 30 May 2006 16:14:13 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k4UNEDA3018954; Tue, 30 May 2006 16:14:13 -0700 Date: Tue, 30 May 2006 16:14:13 -0700 Message-Id: <200605302314.k4UNEDA3018954@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: ips@ietf.org, rfc-editor@rfc-editor.org Subject: [Ips] RFC 4545 on Definitions of Managed Objects for IP Storage User Identity Authorization 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 4545 Title: Definitions of Managed Objects for IP Storage User Identity Authorization Author: M. Bakke, J. Muchow Status: Standards Track Date: May 2006 Mailbox: mbakke@cisco.com, james.muchow@qlogic.com Pages: 43 Characters: 87345 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ips-auth-mib-08.txt URL: http://www.rfc-editor.org/rfc/rfc4545.txt This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing user identities and the names, addresses, and credentials required manage access control, for use with various protocols. This document was motivated by the need for the configuration of authorized user identities for the iSCSI protocol, but has been extended to be useful for other protocols that have similar requirements. It is important to note that this MIB module provides only the set of identities to be used within access lists; it is the responsibility of other MIB modules making use of this one to tie them to their own access lists or other authorization control methods. [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. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed May 31 08:13:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlPZG-0001sj-9b; Wed, 31 May 2006 08:12:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlPZE-0001se-Ri for ips@ietf.org; Wed, 31 May 2006 08:12:52 -0400 Received: from sccrmhc12.comcast.net ([63.240.77.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlPZD-0006si-K8 for ips@ietf.org; Wed, 31 May 2006 08:12:52 -0400 Received: from ivvtdkv0981 (adsl-074-228-222-058.sip.asm.bellsouth.net[74.228.222.58]) by comcast.net (sccrmhc12) with SMTP id <20060531121248012003dhs5e>; Wed, 31 May 2006 12:12:49 +0000 Message-ID: <000001c684ab$89367780$7e00470a@ivivity.com> From: "Eddy Quicksall" To: "Sandars, Ken" , "David Weibel" , References: <368FBF3D8437A748BA8222526BF9309962CDE4@aime2k302.adaptec.com> Subject: Re: [Ips] TargetAlias in SendTarget response Date: Tue, 30 May 2006 19:31:16 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: 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 TargetAlias would be allowed in a discovery session if it is not in response to the SendTargets key. Would that be OK? Then there would be no need to change the spec. Eddy ----- Original Message ----- From: "Sandars, Ken" To: "David Weibel" ; Sent: Thursday, May 25, 2006 10:46 PM Subject: RE: [Ips] TargetAlias in SendTarget response Hi David, It's certainly a nice idea, and I cannot remember why the TargetAlias was excluded from the SendTargets response. Since it would be optional the target can decide if there are any security issues or FUD with sending it or not. The benefit is it avoids the rather clumsy sequence of doing a (discovery) login and logout to each target found in the original unnamed discovery session just to provoke the target into sending the TargetAlias as part of the login phase. However, it cannot just be added now without potentially breaking some initiators which are not expecting it, or are actively ensuring it is not sent. Perhaps a new IO,LO,Declarative key could be introduced for use by the initiator to indicate its willingness to accept TargetAlias as part of the SendTarget's response? Cheers Ken > -----Original Message----- > From: David Weibel [mailto:David.Weibel@Sun.COM] > Sent: 26 May 2006 08:11 > To: ips@ietf.org > Subject: [Ips] TargetAlias in SendTarget response > > > I was wondering what people would think about adding the > allowed and suggested use of TargetAlias during a SendTargets > response. This would be an optional component of the response. > The goal would be to send the alias earlier in the discovery > process so the initiator software could also present it earlier > to the user. > > This would require the ammendment of Appendix D. "No text > keys other than TargetName and TargetAddress are permitted > within a SendTargets response." Along with some additional > text. > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed May 31 08:40:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlPzv-0004aV-Bu; Wed, 31 May 2006 08:40:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlPzt-0004aL-Qs for ips@ietf.org; Wed, 31 May 2006 08:40:25 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlPzo-0008SG-6j for ips@ietf.org; Wed, 31 May 2006 08:40:25 -0400 Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k4VCeJH1025121 for ; Wed, 31 May 2006 06:40:19 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J0400201QDP9N00@mail-amer.sun.com> (original mail from Rick.McNeal@Sun.COM) for ips@ietf.org; Wed, 31 May 2006 06:40:19 -0600 (MDT) Received: from [10.0.1.2] ([206.168.11.149]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J0400MVNR76IGK0@mail-amer.sun.com>; Wed, 31 May 2006 06:40:19 -0600 (MDT) Date: Wed, 31 May 2006 06:40:17 -0600 From: Rick McNeal Subject: Re: [Ips] TargetAlias in SendTarget response In-reply-to: <000001c684ab$89367780$7e00470a@ivivity.com> To: Eddy Quicksall Message-id: <65B99E2B-02E6-4559-B8C8-EE6D2EFA7527@Sun.COM> MIME-version: 1.0 X-Mailer: Apple Mail (2.750) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT X-Priority: 3 References: <368FBF3D8437A748BA8222526BF9309962CDE4@aime2k302.adaptec.com> <000001c684ab$89367780$7e00470a@ivivity.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: ips@ietf.org, David Weibel , "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: , Errors-To: ips-bounces@ietf.org Since the TargetName is not required during the discovery session how would a target know which TargetAlias to return? Not to mention that during a discovery session there could be many targets which are discovered. It seems like using having an extra key sent by the initiator during the discovery session would be the simplest method. On May 30, 2006, at 5:31 PM, Eddy Quicksall wrote: > TargetAlias would be allowed in a discovery session if it is not in > response to the SendTargets key. > > Would that be OK? Then there would be no need to change the spec. > > Eddy > > ----- Original Message ----- From: "Sandars, Ken" > > To: "David Weibel" ; > Sent: Thursday, May 25, 2006 10:46 PM > Subject: RE: [Ips] TargetAlias in SendTarget response > > > Hi David, > > It's certainly a nice idea, and I cannot remember why the TargetAlias > was excluded from the SendTargets response. Since it would be optional > the target can decide if there are any security issues or FUD with > sending it or not. > > The benefit is it avoids the rather clumsy sequence of doing a > (discovery) login and logout to each target found in the original > unnamed discovery session just to provoke the target into sending the > TargetAlias as part of the login phase. > > However, it cannot just be added now without potentially breaking some > initiators which are not expecting it, or are actively ensuring it is > not sent. > > Perhaps a new IO,LO,Declarative key could be introduced for use by the > initiator to indicate its willingness to accept TargetAlias as part of > the SendTarget's response? > > Cheers > Ken > >> -----Original Message----- >> From: David Weibel [mailto:David.Weibel@Sun.COM] >> Sent: 26 May 2006 08:11 >> To: ips@ietf.org >> Subject: [Ips] TargetAlias in SendTarget response >> >> >> I was wondering what people would think about adding the >> allowed and suggested use of TargetAlias during a SendTargets >> response. This would be an optional component of the response. >> The goal would be to send the alias earlier in the discovery >> process so the initiator software could also present it earlier >> to the user. >> >> This would require the ammendment of Appendix D. "No text >> keys other than TargetName and TargetAddress are permitted >> within a SendTargets response." Along with some additional >> text. >> >> _______________________________________________ >> Ips mailing list >> Ips@ietf.org >> https://www1.ietf.org/mailman/listinfo/ips >> > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips ---- Rick McNeal A good friend will come and bail you out of jail...but, a true friend will be sitting next to you saying, "Damn...that was fun! " _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed May 31 09:08:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlQR2-0008Ea-2j; Wed, 31 May 2006 09:08:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlQR1-0008EU-AJ for ips@ietf.org; Wed, 31 May 2006 09:08:27 -0400 Received: from rwcrmhc12.comcast.net ([204.127.192.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlQQz-0002mX-Vt for ips@ietf.org; Wed, 31 May 2006 09:08:27 -0400 Received: from ivvtdkv0981 (unknown[64.238.111.98]) by comcast.net (rwcrmhc12) with SMTP id <20060531130824m1200l6sane>; Wed, 31 May 2006 13:08:24 +0000 Message-ID: <000301c684b3$4cd2be90$3401a8c0@ivivity.com> From: "Eddy Quicksall" To: "Rick McNeal" References: <368FBF3D8437A748BA8222526BF9309962CDE4@aime2k302.adaptec.com><000001c684ab$89367780$7e00470a@ivivity.com> <65B99E2B-02E6-4559-B8C8-EE6D2EFA7527@Sun.COM> Subject: Re: [Ips] TargetAlias in SendTarget response Date: Wed, 31 May 2006 09:08:23 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: ips@ietf.org, David Weibel , "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: , Errors-To: ips-bounces@ietf.org Weren't you looking for a way to display the target alias of the target that was used for discovery? If so then TargetName would not need to be sent. Or are you saying that for every target reported there would be a TargetAlias? Eddy ----- Original Message ----- From: "Rick McNeal" To: "Eddy Quicksall" Cc: ; "David Weibel" ; "Sandars,Ken" Sent: Wednesday, May 31, 2006 8:40 AM Subject: Re: [Ips] TargetAlias in SendTarget response > Since the TargetName is not required during the discovery session how > would a target know which TargetAlias to return? Not to mention that > during a discovery session there could be many targets which are > discovered. > > It seems like using having an extra key sent by the initiator during the > discovery session would be the simplest method. > > On May 30, 2006, at 5:31 PM, Eddy Quicksall wrote: > >> TargetAlias would be allowed in a discovery session if it is not in >> response to the SendTargets key. >> >> Would that be OK? Then there would be no need to change the spec. >> >> Eddy >> >> ----- Original Message ----- From: "Sandars, Ken" >> >> To: "David Weibel" ; >> Sent: Thursday, May 25, 2006 10:46 PM >> Subject: RE: [Ips] TargetAlias in SendTarget response >> >> >> Hi David, >> >> It's certainly a nice idea, and I cannot remember why the TargetAlias >> was excluded from the SendTargets response. Since it would be optional >> the target can decide if there are any security issues or FUD with >> sending it or not. >> >> The benefit is it avoids the rather clumsy sequence of doing a >> (discovery) login and logout to each target found in the original >> unnamed discovery session just to provoke the target into sending the >> TargetAlias as part of the login phase. >> >> However, it cannot just be added now without potentially breaking some >> initiators which are not expecting it, or are actively ensuring it is >> not sent. >> >> Perhaps a new IO,LO,Declarative key could be introduced for use by the >> initiator to indicate its willingness to accept TargetAlias as part of >> the SendTarget's response? >> >> Cheers >> Ken >> >>> -----Original Message----- >>> From: David Weibel [mailto:David.Weibel@Sun.COM] >>> Sent: 26 May 2006 08:11 >>> To: ips@ietf.org >>> Subject: [Ips] TargetAlias in SendTarget response >>> >>> >>> I was wondering what people would think about adding the >>> allowed and suggested use of TargetAlias during a SendTargets >>> response. This would be an optional component of the response. >>> The goal would be to send the alias earlier in the discovery >>> process so the initiator software could also present it earlier >>> to the user. >>> >>> This would require the ammendment of Appendix D. "No text >>> keys other than TargetName and TargetAddress are permitted >>> within a SendTargets response." Along with some additional >>> text. >>> >>> _______________________________________________ >>> Ips mailing list >>> Ips@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ips >>> >> >> _______________________________________________ >> Ips mailing list >> Ips@ietf.org >> https://www1.ietf.org/mailman/listinfo/ips >> >> >> _______________________________________________ >> Ips mailing list >> Ips@ietf.org >> https://www1.ietf.org/mailman/listinfo/ips > > ---- > Rick McNeal > > A good friend will come and bail you out of jail...but, a true friend > will be sitting next to you saying, "Damn...that was fun! " > > > > > _______________________________________________ > 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 Wed May 31 09:21:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlQcs-00050L-17; Wed, 31 May 2006 09:20:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlQcq-00050G-Sq for ips@ietf.org; Wed, 31 May 2006 09:20:40 -0400 Received: from rwcrmhc12.comcast.net ([204.127.192.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlQcp-0003Wy-EH for ips@ietf.org; Wed, 31 May 2006 09:20:40 -0400 Received: from ivvtdkv0981 (unknown[64.238.111.98]) by comcast.net (rwcrmhc12) with SMTP id <20060531132037m1200l714qe>; Wed, 31 May 2006 13:20:38 +0000 Message-ID: <001301c684b5$021f4ab0$3401a8c0@ivivity.com> From: "Eddy Quicksall" To: "Rick McNeal" References: <368FBF3D8437A748BA8222526BF9309962CDE4@aime2k302.adaptec.com> <000001c684ab$89367780$7e00470a@ivivity.com> <65B99E2B-02E6-4559-B8C8-EE6D2EFA7527@Sun.COM> <000301c684b3$4cd2be90$3401a8c0@ivivity.com> Subject: Re: [Ips] TargetAlias in SendTarget response Date: Wed, 31 May 2006 09:20:37 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: ips@ietf.org, David Weibel , "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: , Errors-To: ips-bounces@ietf.org I see. Yes I agree that sounds like a good idea. Eddy ----- Original Message ----- From: "Rick McNeal" To: "Eddy Quicksall" Cc: ; "David Weibel" ; "Sandars,Ken" Sent: Wednesday, May 31, 2006 9:18 AM Subject: Re: [Ips] TargetAlias in SendTarget response > During a discovery session the TargetName is not sent because it's not > known. The thought was that in the text response for the SendTargets=All > the target could return: > > TargetName=iqn.xxxx > TargetAlias=fubar > TargetAddress=yyyy (1 or more) > > To do this without changing the specification means adding a new key > which is sent by the initiator. > > On May 31, 2006, at 7:08 AM, Eddy Quicksall wrote: > >> Weren't you looking for a way to display the target alias of the target >> that was used for discovery? If so then TargetName would not need to be >> sent. >> >> Or are you saying that for every target reported there would be a >> TargetAlias? >> >> Eddy >> >> ----- Original Message ----- From: "Rick McNeal" >> To: "Eddy Quicksall" >> Cc: ; "David Weibel" ; "Sandars,Ken" >> >> Sent: Wednesday, May 31, 2006 8:40 AM >> Subject: Re: [Ips] TargetAlias in SendTarget response >> >> >>> Since the TargetName is not required during the discovery session how >>> would a target know which TargetAlias to return? Not to mention that >>> during a discovery session there could be many targets which are >>> discovered. >>> >>> It seems like using having an extra key sent by the initiator during >>> the discovery session would be the simplest method. >>> >>> On May 30, 2006, at 5:31 PM, Eddy Quicksall wrote: >>> >>>> TargetAlias would be allowed in a discovery session if it is not in >>>> response to the SendTargets key. >>>> >>>> Would that be OK? Then there would be no need to change the spec. >>>> >>>> Eddy >>>> >>>> ----- Original Message ----- From: "Sandars, Ken" >>>> >>>> To: "David Weibel" ; >>>> Sent: Thursday, May 25, 2006 10:46 PM >>>> Subject: RE: [Ips] TargetAlias in SendTarget response >>>> >>>> >>>> Hi David, >>>> >>>> It's certainly a nice idea, and I cannot remember why the TargetAlias >>>> was excluded from the SendTargets response. Since it would be optional >>>> the target can decide if there are any security issues or FUD with >>>> sending it or not. >>>> >>>> The benefit is it avoids the rather clumsy sequence of doing a >>>> (discovery) login and logout to each target found in the original >>>> unnamed discovery session just to provoke the target into sending the >>>> TargetAlias as part of the login phase. >>>> >>>> However, it cannot just be added now without potentially breaking some >>>> initiators which are not expecting it, or are actively ensuring it is >>>> not sent. >>>> >>>> Perhaps a new IO,LO,Declarative key could be introduced for use by the >>>> initiator to indicate its willingness to accept TargetAlias as part of >>>> the SendTarget's response? >>>> >>>> Cheers >>>> Ken >>>> >>>>> -----Original Message----- >>>>> From: David Weibel [mailto:David.Weibel@Sun.COM] >>>>> Sent: 26 May 2006 08:11 >>>>> To: ips@ietf.org >>>>> Subject: [Ips] TargetAlias in SendTarget response >>>>> >>>>> >>>>> I was wondering what people would think about adding the >>>>> allowed and suggested use of TargetAlias during a SendTargets >>>>> response. This would be an optional component of the response. >>>>> The goal would be to send the alias earlier in the discovery >>>>> process so the initiator software could also present it earlier >>>>> to the user. >>>>> >>>>> This would require the ammendment of Appendix D. "No text >>>>> keys other than TargetName and TargetAddress are permitted >>>>> within a SendTargets response." Along with some additional >>>>> text. >>>>> >>>>> _______________________________________________ >>>>> Ips mailing list >>>>> Ips@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/ips >>>>> >>>> >>>> _______________________________________________ >>>> Ips mailing list >>>> Ips@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/ips >>>> >>>> >>>> _______________________________________________ >>>> Ips mailing list >>>> Ips@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/ips >>> >>> ---- >>> Rick McNeal >>> >>> A good friend will come and bail you out of jail...but, a true friend >>> will be sitting next to you saying, "Damn...that was fun! " >>> >>> >>> >>> >>> _______________________________________________ >>> Ips mailing list >>> Ips@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ips >> > > ---- > Rick McNeal > > A good friend will come and bail you out of jail...but, a true friend > will be sitting next to you saying, "Damn...that was fun! " > > > > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed May 31 11:00:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlSAn-0004SU-61; Wed, 31 May 2006 10:59:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlSAm-0004RQ-13 for ips@ietf.org; Wed, 31 May 2006 10:59:48 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlQoa-00044p-LC for ips@ietf.org; Wed, 31 May 2006 09:32:48 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FlQam-0007Fx-UV for ips@ietf.org; Wed, 31 May 2006 09:18:36 -0400 Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k4VDIWTR005832 for ; Wed, 31 May 2006 07:18:32 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J0400F01SO2CG00@mail-amer.sun.com> (original mail from Rick.McNeal@Sun.COM) for ips@ietf.org; Wed, 31 May 2006 07:18:32 -0600 (MDT) Received: from [10.0.1.2] ([206.168.11.149]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J0400I45SYUUUP1@mail-amer.sun.com>; Wed, 31 May 2006 07:18:32 -0600 (MDT) Date: Wed, 31 May 2006 07:18:29 -0600 From: Rick McNeal Subject: Re: [Ips] TargetAlias in SendTarget response In-reply-to: <000301c684b3$4cd2be90$3401a8c0@ivivity.com> To: Eddy Quicksall Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.750) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT X-Priority: 3 References: <368FBF3D8437A748BA8222526BF9309962CDE4@aime2k302.adaptec.com> <000001c684ab$89367780$7e00470a@ivivity.com> <65B99E2B-02E6-4559-B8C8-EE6D2EFA7527@Sun.COM> <000301c684b3$4cd2be90$3401a8c0@ivivity.com> X-Spam-Score: -2.6 (--) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: ips@ietf.org, David Weibel , "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: , Errors-To: ips-bounces@ietf.org During a discovery session the TargetName is not sent because it's not known. The thought was that in the text response for the SendTargets=All the target could return: TargetName=iqn.xxxx TargetAlias=fubar TargetAddress=yyyy (1 or more) To do this without changing the specification means adding a new key which is sent by the initiator. On May 31, 2006, at 7:08 AM, Eddy Quicksall wrote: > Weren't you looking for a way to display the target alias of the > target that was used for discovery? If so then TargetName would not > need to be sent. > > Or are you saying that for every target reported there would be a > TargetAlias? > > Eddy > > ----- Original Message ----- From: "Rick McNeal" > To: "Eddy Quicksall" > Cc: ; "David Weibel" ; > "Sandars,Ken" > Sent: Wednesday, May 31, 2006 8:40 AM > Subject: Re: [Ips] TargetAlias in SendTarget response > > >> Since the TargetName is not required during the discovery session >> how would a target know which TargetAlias to return? Not to >> mention that during a discovery session there could be many >> targets which are discovered. >> >> It seems like using having an extra key sent by the initiator >> during the discovery session would be the simplest method. >> >> On May 30, 2006, at 5:31 PM, Eddy Quicksall wrote: >> >>> TargetAlias would be allowed in a discovery session if it is not >>> in response to the SendTargets key. >>> >>> Would that be OK? Then there would be no need to change the spec. >>> >>> Eddy >>> >>> ----- Original Message ----- From: "Sandars, Ken" >>> >>> To: "David Weibel" ; >>> Sent: Thursday, May 25, 2006 10:46 PM >>> Subject: RE: [Ips] TargetAlias in SendTarget response >>> >>> >>> Hi David, >>> >>> It's certainly a nice idea, and I cannot remember why the >>> TargetAlias >>> was excluded from the SendTargets response. Since it would be >>> optional >>> the target can decide if there are any security issues or FUD with >>> sending it or not. >>> >>> The benefit is it avoids the rather clumsy sequence of doing a >>> (discovery) login and logout to each target found in the original >>> unnamed discovery session just to provoke the target into sending >>> the >>> TargetAlias as part of the login phase. >>> >>> However, it cannot just be added now without potentially breaking >>> some >>> initiators which are not expecting it, or are actively ensuring >>> it is >>> not sent. >>> >>> Perhaps a new IO,LO,Declarative key could be introduced for use >>> by the >>> initiator to indicate its willingness to accept TargetAlias as >>> part of >>> the SendTarget's response? >>> >>> Cheers >>> Ken >>> >>>> -----Original Message----- >>>> From: David Weibel [mailto:David.Weibel@Sun.COM] >>>> Sent: 26 May 2006 08:11 >>>> To: ips@ietf.org >>>> Subject: [Ips] TargetAlias in SendTarget response >>>> >>>> >>>> I was wondering what people would think about adding the >>>> allowed and suggested use of TargetAlias during a SendTargets >>>> response. This would be an optional component of the response. >>>> The goal would be to send the alias earlier in the discovery >>>> process so the initiator software could also present it earlier >>>> to the user. >>>> >>>> This would require the ammendment of Appendix D. "No text >>>> keys other than TargetName and TargetAddress are permitted >>>> within a SendTargets response." Along with some additional >>>> text. >>>> >>>> _______________________________________________ >>>> Ips mailing list >>>> Ips@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/ips >>>> >>> >>> _______________________________________________ >>> Ips mailing list >>> Ips@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ips >>> >>> >>> _______________________________________________ >>> Ips mailing list >>> Ips@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ips >> >> ---- >> Rick McNeal >> >> A good friend will come and bail you out of jail...but, a true >> friend will be sitting next to you saying, "Damn...that was fun! " >> >> >> >> >> _______________________________________________ >> Ips mailing list >> Ips@ietf.org >> https://www1.ietf.org/mailman/listinfo/ips > ---- Rick McNeal A good friend will come and bail you out of jail...but, a true friend will be sitting next to you saying, "Damn...that was fun! " _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed May 31 11:52:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlT00-0005Xk-IX; Wed, 31 May 2006 11:52:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlSzz-0005Xe-42 for ips@ietf.org; Wed, 31 May 2006 11:52:43 -0400 Received: from ausc60ps301.us.dell.com ([143.166.148.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlSzw-0002kD-Ce for ips@ietf.org; Wed, 31 May 2006 11:52:43 -0400 DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; b=d/8pvAI2mTI69MR50KHirNTtWs2SjxgAUmxf66tIJ/5CCqokbhf/FJwK4WqZnJ6hl2HYOBsn6daBdpGdiIywqjCgZWyTtJtIgYbyxQEIj8vsmkASm/+peYd4ryn1tz85; Received: from ausx3bpc105.aus.amer.dell.com ([10.30.101.55]) by ausc60ps301.us.dell.com with ESMTP; 31 May 2006 10:52:37 -0500 X-IronPort-AV: i="4.05,193,1146459600"; d="scan'208"; a="23521024:sNHT36057978" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] TargetAlias in SendTarget response Date: Wed, 31 May 2006 10:52:37 -0500 Message-ID: <389040536173ED4AADA5EFEA9633358601677DEA@ausx3mpc106.aus.amer.dell.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] TargetAlias in SendTarget response Thread-Index: AcaEw5O2KVw/HBaFT4mwgi/imp7A4AABc5Gg From: To: X-OriginalArrivalTime: 31 May 2006 15:52:37.0623 (UTC) FILETIME=[3D78E070:01C684CA] X-Spam-Score: 0.2 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 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 If the purpose is to find the alias of a target in a discovery session, wouldn't it be better to define a new text key SendTargetAlias=3D"Target Name". This would not break existing implementations (either initiator or target). Legacy targets (those that do not support this key) would just reject the request. Legacy initiators would never issue it. Jacob Cherian -----Original Message----- From: Rick McNeal [mailto:Rick.McNeal@Sun.COM]=20 Sent: Wednesday, May 31, 2006 8:18 AM To: Eddy Quicksall Cc: ips@ietf.org; David Weibel; Sandars,Ken Subject: Re: [Ips] TargetAlias in SendTarget response During a discovery session the TargetName is not sent because it's =20 not known. The thought was that in the text response for the =20 SendTargets=3DAll the target could return: TargetName=3Diqn.xxxx TargetAlias=3Dfubar TargetAddress=3Dyyyy (1 or more) To do this without changing the specification means adding a new key =20 which is sent by the initiator. On May 31, 2006, at 7:08 AM, Eddy Quicksall wrote: > Weren't you looking for a way to display the target alias of the =20 > target that was used for discovery? If so then TargetName would not =20 > need to be sent. > > Or are you saying that for every target reported there would be a =20 > TargetAlias? > > Eddy > > ----- Original Message ----- From: "Rick McNeal" > To: "Eddy Quicksall" > Cc: ; "David Weibel" ; =20 > "Sandars,Ken" > Sent: Wednesday, May 31, 2006 8:40 AM > Subject: Re: [Ips] TargetAlias in SendTarget response > > >> Since the TargetName is not required during the discovery session =20 >> how would a target know which TargetAlias to return? Not to =20 >> mention that during a discovery session there could be many =20 >> targets which are discovered. >> >> It seems like using having an extra key sent by the initiator =20 >> during the discovery session would be the simplest method. >> >> On May 30, 2006, at 5:31 PM, Eddy Quicksall wrote: >> >>> TargetAlias would be allowed in a discovery session if it is not =20 >>> in response to the SendTargets key. >>> >>> Would that be OK? Then there would be no need to change the spec. >>> >>> Eddy >>> >>> ----- Original Message ----- From: "Sandars, Ken" =20 >>> >>> To: "David Weibel" ; >>> Sent: Thursday, May 25, 2006 10:46 PM >>> Subject: RE: [Ips] TargetAlias in SendTarget response >>> >>> >>> Hi David, >>> >>> It's certainly a nice idea, and I cannot remember why the =20 >>> TargetAlias >>> was excluded from the SendTargets response. Since it would be =20 >>> optional >>> the target can decide if there are any security issues or FUD with >>> sending it or not. >>> >>> The benefit is it avoids the rather clumsy sequence of doing a >>> (discovery) login and logout to each target found in the original >>> unnamed discovery session just to provoke the target into sending =20 >>> the >>> TargetAlias as part of the login phase. >>> >>> However, it cannot just be added now without potentially breaking =20 >>> some >>> initiators which are not expecting it, or are actively ensuring =20 >>> it is >>> not sent. >>> >>> Perhaps a new IO,LO,Declarative key could be introduced for use =20 >>> by the >>> initiator to indicate its willingness to accept TargetAlias as =20 >>> part of >>> the SendTarget's response? >>> >>> Cheers >>> Ken >>> >>>> -----Original Message----- >>>> From: David Weibel [mailto:David.Weibel@Sun.COM] >>>> Sent: 26 May 2006 08:11 >>>> To: ips@ietf.org >>>> Subject: [Ips] TargetAlias in SendTarget response >>>> >>>> >>>> I was wondering what people would think about adding the >>>> allowed and suggested use of TargetAlias during a SendTargets >>>> response. This would be an optional component of the response. >>>> The goal would be to send the alias earlier in the discovery >>>> process so the initiator software could also present it earlier >>>> to the user. >>>> >>>> This would require the ammendment of Appendix D. "No text >>>> keys other than TargetName and TargetAddress are permitted >>>> within a SendTargets response." Along with some additional >>>> text. >>>> >>>> _______________________________________________ >>>> Ips mailing list >>>> Ips@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/ips >>>> >>> >>> _______________________________________________ >>> Ips mailing list >>> Ips@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ips >>> >>> >>> _______________________________________________ >>> Ips mailing list >>> Ips@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ips >> >> ---- >> Rick McNeal >> >> A good friend will come and bail you out of jail...but, a true =20 >> friend will be sitting next to you saying, "Damn...that was fun! " >> >> >> >> >> _______________________________________________ >> Ips mailing list >> Ips@ietf.org >> https://www1.ietf.org/mailman/listinfo/ips > ---- Rick McNeal A good friend will come and bail you out of jail...but, a true friend =20 will be sitting next to you saying, "Damn...that was fun! " _______________________________________________ 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 Wed May 31 12:40:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlTjm-0008Lk-Hk; Wed, 31 May 2006 12:40:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlTjl-0008Lf-OD for ips@ietf.org; Wed, 31 May 2006 12:40:01 -0400 Received: from taurus.voltaire.com ([193.47.165.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlTjk-0007Qa-Bt for ips@ietf.org; Wed, 31 May 2006 12:40:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] [iSER] Connection_Handle question Date: Wed, 31 May 2006 19:39:44 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] [iSER] Connection_Handle question Thread-Index: AcaA5zUKCmdxEBw2SLyJdYJY06tNmAD6PfkQ From: "Dan Bar Dov" To: "Mallikarjun C." , X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: 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 I think you are discussing "implementation" rather than "protocol". While the datamover architecture concept is nice, I don't believe is should be a "standard". The wire protocol is a standard, and that covers both iSCSI and iSER. How and where an iSCSI=20 implementation supports iSER has nothing to do with it. We first implemented DA, including necessary extensions to it. We then had to ditch it altogether, due to a different iSCSI = implementation.=20 Dan > -----Original Message----- > From: Mallikarjun C. [mailto:cb_mallikarjun@yahoo.com]=20 > Sent: Friday, May 26, 2006 8:06 PM > To: ips@ietf.org > Subject: Re: [Ips] [iSER] Connection_Handle question >=20 > Yes, you are correct. >=20 > Mallikarjun >=20 >=20 > --- Eddy Quicksall > wrote: >=20 > > I think I found the answer in the definition of > > "Connection Handle". Am I correct that the iSCSI and > > iSER layers both must understand the handle since > > both must access the TCP/IP stack. For example if it > > is sockets, the handle may be the "socket"; or if it > > is a proprietary scheme the handle may be a pointer > > to a structure that is understood by both the iSER > > and iSCSI layers. > >=20 > > Eddy > > ----- Original Message -----=20 > > From: Eddy Quicksall=20 > > To: ips@ietf.org=20 > > Sent: Tuesday, May 23, 2006 2:21 PM > > Subject: [Ips] [iSER] Connection_Handle question > >=20 > >=20 > > Generally when an upper layer is going to use a > > lower layer, the lower layer gives a handle (many > > times via an open call). > >=20 > > In the primitives the Connection_Handle is passed > > as an input qualifier. But I don't see any primitive > > that returns the Connection_Handle. Am I missing > > that? > >=20 > > Eddy > >=20 > >=20 > > > -------------------------------------------------------------- > ---------------- > >=20 > >=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 >=20 >=20 > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around=20 > http://mail.yahoo.com=20 >=20 > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips >=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed May 31 12:48:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlTrd-0005wQ-Di; Wed, 31 May 2006 12:48:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlTrb-0005wA-Uf for ips@ietf.org; Wed, 31 May 2006 12:48:07 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlTrZ-0007wk-Ds for ips@ietf.org; Wed, 31 May 2006 12:48:07 -0400 Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k4VGm4TR000626 for ; Wed, 31 May 2006 10:48:04 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J0500L012B2A400@mail-amer.sun.com> (original mail from Rick.McNeal@Sun.COM) for ips@ietf.org; Wed, 31 May 2006 10:48:04 -0600 (MDT) Received: from [172.20.25.120] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J050042X2O1KQX1@mail-amer.sun.com>; Wed, 31 May 2006 10:48:01 -0600 (MDT) Date: Wed, 31 May 2006 10:47:59 -0600 From: Rick McNeal Subject: Re: [Ips] TargetAlias in SendTarget response In-reply-to: <389040536173ED4AADA5EFEA9633358601677DEA@ausx3mpc106.aus.amer.dell.com> To: Jacob_Cherian@Dell.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.749.3) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: <389040536173ED4AADA5EFEA9633358601677DEA@ausx3mpc106.aus.amer.dell.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 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: , Errors-To: ips-bounces@ietf.org I must not have made myself clear. The expectation would be that the target would only send the TargetAlias if a key was sent first by the Intiator. For example Sun's initiator could send: X-com.sun.sendaliases=true during the login phase when the SessionType=Discovery. The Solaris target would then add the TargetAlias information to a SendTargets=All response only if that value were true. This wouldn't cause any other initiators or targets to break since they (initiators) either will not send the key or understand the key (targets). If other folks feel that such a feature is worth prompting then I'll write up a proposal to create a new X#sendaliasinfo=true type key. On May 31, 2006, at 9:52 AM, Jacob_Cherian@Dell.com wrote: > If the purpose is to find the alias of a target in a discovery > session, > wouldn't it be better to define a new text key SendTargetAlias="Target > Name". This would not break existing implementations (either initiator > or target). > > Legacy targets (those that do not support this key) would just reject > the request. Legacy initiators would never issue it. > > Jacob Cherian > > > > -----Original Message----- > From: Rick McNeal [mailto:Rick.McNeal@Sun.COM] > Sent: Wednesday, May 31, 2006 8:18 AM > To: Eddy Quicksall > Cc: ips@ietf.org; David Weibel; Sandars,Ken > Subject: Re: [Ips] TargetAlias in SendTarget response > > During a discovery session the TargetName is not sent because it's > not known. The thought was that in the text response for the > SendTargets=All the target could return: > > TargetName=iqn.xxxx > TargetAlias=fubar > TargetAddress=yyyy (1 or more) > > To do this without changing the specification means adding a new key > which is sent by the initiator. > > On May 31, 2006, at 7:08 AM, Eddy Quicksall wrote: > >> Weren't you looking for a way to display the target alias of the >> target that was used for discovery? If so then TargetName would not >> need to be sent. >> >> Or are you saying that for every target reported there would be a >> TargetAlias? >> >> Eddy >> >> ----- Original Message ----- From: "Rick McNeal" >> >> To: "Eddy Quicksall" >> Cc: ; "David Weibel" ; >> "Sandars,Ken" >> Sent: Wednesday, May 31, 2006 8:40 AM >> Subject: Re: [Ips] TargetAlias in SendTarget response >> >> >>> Since the TargetName is not required during the discovery session >>> how would a target know which TargetAlias to return? Not to >>> mention that during a discovery session there could be many >>> targets which are discovered. >>> >>> It seems like using having an extra key sent by the initiator >>> during the discovery session would be the simplest method. >>> >>> On May 30, 2006, at 5:31 PM, Eddy Quicksall wrote: >>> >>>> TargetAlias would be allowed in a discovery session if it is not >>>> in response to the SendTargets key. >>>> >>>> Would that be OK? Then there would be no need to change the spec. >>>> >>>> Eddy >>>> >>>> ----- Original Message ----- From: "Sandars, Ken" >>>> >>>> To: "David Weibel" ; >>>> Sent: Thursday, May 25, 2006 10:46 PM >>>> Subject: RE: [Ips] TargetAlias in SendTarget response >>>> >>>> >>>> Hi David, >>>> >>>> It's certainly a nice idea, and I cannot remember why the >>>> TargetAlias >>>> was excluded from the SendTargets response. Since it would be >>>> optional >>>> the target can decide if there are any security issues or FUD with >>>> sending it or not. >>>> >>>> The benefit is it avoids the rather clumsy sequence of doing a >>>> (discovery) login and logout to each target found in the original >>>> unnamed discovery session just to provoke the target into sending >>>> the >>>> TargetAlias as part of the login phase. >>>> >>>> However, it cannot just be added now without potentially breaking >>>> some >>>> initiators which are not expecting it, or are actively ensuring >>>> it is >>>> not sent. >>>> >>>> Perhaps a new IO,LO,Declarative key could be introduced for use >>>> by the >>>> initiator to indicate its willingness to accept TargetAlias as >>>> part of >>>> the SendTarget's response? >>>> >>>> Cheers >>>> Ken >>>> >>>>> -----Original Message----- >>>>> From: David Weibel [mailto:David.Weibel@Sun.COM] >>>>> Sent: 26 May 2006 08:11 >>>>> To: ips@ietf.org >>>>> Subject: [Ips] TargetAlias in SendTarget response >>>>> >>>>> >>>>> I was wondering what people would think about adding the >>>>> allowed and suggested use of TargetAlias during a SendTargets >>>>> response. This would be an optional component of the response. >>>>> The goal would be to send the alias earlier in the discovery >>>>> process so the initiator software could also present it earlier >>>>> to the user. >>>>> >>>>> This would require the ammendment of Appendix D. "No text >>>>> keys other than TargetName and TargetAddress are permitted >>>>> within a SendTargets response." Along with some additional >>>>> text. >>>>> >>>>> _______________________________________________ >>>>> Ips mailing list >>>>> Ips@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/ips >>>>> >>>> >>>> _______________________________________________ >>>> Ips mailing list >>>> Ips@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/ips >>>> >>>> >>>> _______________________________________________ >>>> Ips mailing list >>>> Ips@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/ips >>> >>> ---- >>> Rick McNeal >>> >>> A good friend will come and bail you out of jail...but, a true >>> friend will be sitting next to you saying, "Damn...that was fun! " >>> >>> >>> >>> >>> _______________________________________________ >>> Ips mailing list >>> Ips@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ips >> > > ---- > Rick McNeal > > A good friend will come and bail you out of jail...but, a true friend > will be sitting next to you saying, "Damn...that was fun! " > > > > > _______________________________________________ > 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 ---- Rick McNeal A good friend will come and bail you out of jail ... but, a true friend will be sitting next to you saying, "Damn ... that was fun!" _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed May 31 13:11:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlUEJ-0000KZ-8a; Wed, 31 May 2006 13:11:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlUEH-0000KT-Tg for ips@ietf.org; Wed, 31 May 2006 13:11:33 -0400 Received: from mexforward.lss.emc.com ([168.159.213.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlUEF-0001H1-GH for ips@ietf.org; Wed, 31 May 2006 13:11:33 -0400 Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.11]) by mexforward.lss.emc.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k4VHBTA4017209; Wed, 31 May 2006 13:11:29 -0400 (EDT) Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4VHAucP027723; Wed, 31 May 2006 13:11:25 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 31 May 2006 13:10:52 -0400 Message-ID: <05AADEB492F5824996D28D504686739902AC538D@CORPUSMX40A.corp.emc.com> From: Sears_Bill@emc.com To: Rick.McNeal@Sun.COM Subject: RE: [Ips] TargetAlias in SendTarget response Date: Wed, 31 May 2006 13:08:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.3.0.1, Antispam-Data: 2006.5.31.95404 X-PerlMx-Spam: Gauge=, SPAM=2%, Reason='EMC_FROM_0+ -2, NO_REAL_NAME 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 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: , Errors-To: ips-bounces@ietf.org Only problem I see is that spec isnt very lenient on what keys may be sent during Discovery: Appendix D: A SendTargets command consists of a single Text request PDU. This PDU contains exactly one text key and value. The text key MUST be SendTargets. The expected response depends upon the value, as well as whether the session is a discovery or operational session. The language 'exactly one text key abd value' here is troublesome. A simple target that gets anything but a Sendtargets= key during login may simply fail login rather than respond to that key with NotUnderstood. Bill -----Original Message----- From: Rick McNeal [mailto:Rick.McNeal@Sun.COM] Sent: Wednesday, May 31, 2006 12:48 PM To: Jacob_Cherian@Dell.com Cc: ips@ietf.org Subject: Re: [Ips] TargetAlias in SendTarget response I must not have made myself clear. The expectation would be that the target would only send the TargetAlias if a key was sent first by the Intiator. For example Sun's initiator could send: X-com.sun.sendaliases=true during the login phase when the SessionType=Discovery. The Solaris target would then add the TargetAlias information to a SendTargets=All response only if that value were true. This wouldn't cause any other initiators or targets to break since they (initiators) either will not send the key or understand the key (targets). If other folks feel that such a feature is worth prompting then I'll write up a proposal to create a new X#sendaliasinfo=true type key. On May 31, 2006, at 9:52 AM, Jacob_Cherian@Dell.com wrote: > If the purpose is to find the alias of a target in a discovery > session, > wouldn't it be better to define a new text key SendTargetAlias="Target > Name". This would not break existing implementations (either initiator > or target). > > Legacy targets (those that do not support this key) would just reject > the request. Legacy initiators would never issue it. > > Jacob Cherian > > > > -----Original Message----- > From: Rick McNeal [mailto:Rick.McNeal@Sun.COM] > Sent: Wednesday, May 31, 2006 8:18 AM > To: Eddy Quicksall > Cc: ips@ietf.org; David Weibel; Sandars,Ken > Subject: Re: [Ips] TargetAlias in SendTarget response > > During a discovery session the TargetName is not sent because it's > not known. The thought was that in the text response for the > SendTargets=All the target could return: > > TargetName=iqn.xxxx > TargetAlias=fubar > TargetAddress=yyyy (1 or more) > > To do this without changing the specification means adding a new key > which is sent by the initiator. > > On May 31, 2006, at 7:08 AM, Eddy Quicksall wrote: > >> Weren't you looking for a way to display the target alias of the >> target that was used for discovery? If so then TargetName would not >> need to be sent. >> >> Or are you saying that for every target reported there would be a >> TargetAlias? >> >> Eddy >> >> ----- Original Message ----- From: "Rick McNeal" >> >> To: "Eddy Quicksall" >> Cc: ; "David Weibel" ; >> "Sandars,Ken" >> Sent: Wednesday, May 31, 2006 8:40 AM >> Subject: Re: [Ips] TargetAlias in SendTarget response >> >> >>> Since the TargetName is not required during the discovery session >>> how would a target know which TargetAlias to return? Not to >>> mention that during a discovery session there could be many >>> targets which are discovered. >>> >>> It seems like using having an extra key sent by the initiator >>> during the discovery session would be the simplest method. >>> >>> On May 30, 2006, at 5:31 PM, Eddy Quicksall wrote: >>> >>>> TargetAlias would be allowed in a discovery session if it is not >>>> in response to the SendTargets key. >>>> >>>> Would that be OK? Then there would be no need to change the spec. >>>> >>>> Eddy >>>> >>>> ----- Original Message ----- From: "Sandars, Ken" >>>> >>>> To: "David Weibel" ; >>>> Sent: Thursday, May 25, 2006 10:46 PM >>>> Subject: RE: [Ips] TargetAlias in SendTarget response >>>> >>>> >>>> Hi David, >>>> >>>> It's certainly a nice idea, and I cannot remember why the >>>> TargetAlias >>>> was excluded from the SendTargets response. Since it would be >>>> optional >>>> the target can decide if there are any security issues or FUD with >>>> sending it or not. >>>> >>>> The benefit is it avoids the rather clumsy sequence of doing a >>>> (discovery) login and logout to each target found in the original >>>> unnamed discovery session just to provoke the target into sending >>>> the >>>> TargetAlias as part of the login phase. >>>> >>>> However, it cannot just be added now without potentially breaking >>>> some >>>> initiators which are not expecting it, or are actively ensuring >>>> it is >>>> not sent. >>>> >>>> Perhaps a new IO,LO,Declarative key could be introduced for use >>>> by the >>>> initiator to indicate its willingness to accept TargetAlias as >>>> part of >>>> the SendTarget's response? >>>> >>>> Cheers >>>> Ken >>>> >>>>> -----Original Message----- >>>>> From: David Weibel [mailto:David.Weibel@Sun.COM] >>>>> Sent: 26 May 2006 08:11 >>>>> To: ips@ietf.org >>>>> Subject: [Ips] TargetAlias in SendTarget response >>>>> >>>>> >>>>> I was wondering what people would think about adding the >>>>> allowed and suggested use of TargetAlias during a SendTargets >>>>> response. This would be an optional component of the response. >>>>> The goal would be to send the alias earlier in the discovery >>>>> process so the initiator software could also present it earlier >>>>> to the user. >>>>> >>>>> This would require the ammendment of Appendix D. "No text >>>>> keys other than TargetName and TargetAddress are permitted >>>>> within a SendTargets response." Along with some additional >>>>> text. >>>>> >>>>> _______________________________________________ >>>>> Ips mailing list >>>>> Ips@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/ips >>>>> >>>> >>>> _______________________________________________ >>>> Ips mailing list >>>> Ips@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/ips >>>> >>>> >>>> _______________________________________________ >>>> Ips mailing list >>>> Ips@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/ips >>> >>> ---- >>> Rick McNeal >>> >>> A good friend will come and bail you out of jail...but, a true >>> friend will be sitting next to you saying, "Damn...that was fun! " >>> >>> >>> >>> >>> _______________________________________________ >>> Ips mailing list >>> Ips@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ips >> > > ---- > Rick McNeal > > A good friend will come and bail you out of jail...but, a true friend > will be sitting next to you saying, "Damn...that was fun! " > > > > > _______________________________________________ > 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 ---- Rick McNeal A good friend will come and bail you out of jail ... but, a true friend will be sitting next to you saying, "Damn ... that was fun!" _______________________________________________ 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 Wed May 31 13:19:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlUM2-0003aT-R7; Wed, 31 May 2006 13:19:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlUM0-0003YK-PU for ips@ietf.org; Wed, 31 May 2006 13:19:32 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlULz-0001sC-7K for ips@ietf.org; Wed, 31 May 2006 13:19:32 -0400 Received: from fe-amer-10.sun.com ([192.18.108.184]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k4VHJUmO002538 for ; Wed, 31 May 2006 11:19:30 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J0500A014366Z00@mail-amer.sun.com> (original mail from Rick.McNeal@Sun.COM) for ips@ietf.org; Wed, 31 May 2006 11:19:30 -0600 (MDT) Received: from [172.20.25.120] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J0500DF144HQHRN@mail-amer.sun.com>; Wed, 31 May 2006 11:19:30 -0600 (MDT) Date: Wed, 31 May 2006 11:19:04 -0600 From: Rick McNeal Subject: Re: [Ips] TargetAlias in SendTarget response In-reply-to: <05AADEB492F5824996D28D504686739902AC538D@CORPUSMX40A.corp.emc.com> To: Sears_Bill@emc.com Message-id: <81DA94E3-63E7-4373-8AB4-9E4489A3C3C2@Sun.COM> MIME-version: 1.0 X-Mailer: Apple Mail (2.749.3) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: <05AADEB492F5824996D28D504686739902AC538D@CORPUSMX40A.corp.emc.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8068004c042dabd7f1301bcc80e039df 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: , Errors-To: ips-bounces@ietf.org I read appendix D the same way, but I'm not proposing that the key is not sent in the Text message PDU which would violate the spec. The key is sent during the login phase. So it would send InitiatorName=iqn.xyz SessionType=Discovery X#sendaliasinfo=true For targets which don't understand this proposed key they are expected to ignore it like any other X* key which they don't understand. On May 31, 2006, at 11:08 AM, Sears_Bill@emc.com wrote: > Only problem I see is that spec isnt very lenient on what keys may > be sent > during Discovery: > > Appendix D: > A SendTargets command consists of a single Text request PDU. > This PDU contains exactly one text key and value. The text key MUST > be SendTargets. The expected response depends upon the value, as > well as whether the session is a discovery or operational session. > > The language 'exactly one text key abd value' here is troublesome. > A simple > target that gets anything but a Sendtargets= key during > login may > simply fail login rather than respond to that key with NotUnderstood. > > > Bill > > > > > -----Original Message----- > From: Rick McNeal [mailto:Rick.McNeal@Sun.COM] > Sent: Wednesday, May 31, 2006 12:48 PM > To: Jacob_Cherian@Dell.com > Cc: ips@ietf.org > Subject: Re: [Ips] TargetAlias in SendTarget response > > I must not have made myself clear. The expectation would be that the > target would only send the TargetAlias if a key was sent first by the > Intiator. For example Sun's initiator could send: > > X-com.sun.sendaliases=true > > during the login phase when the SessionType=Discovery. The Solaris > target would then add the TargetAlias information to a > SendTargets=All response only if that value were true. This wouldn't > cause any other initiators or targets to break since they > (initiators) either will not send the key or understand the key > (targets). > > If other folks feel that such a feature is worth prompting then I'll > write up a proposal to create a new X#sendaliasinfo=true type key. > > On May 31, 2006, at 9:52 AM, Jacob_Cherian@Dell.com wrote: > >> If the purpose is to find the alias of a target in a discovery >> session, >> wouldn't it be better to define a new text key >> SendTargetAlias="Target >> Name". This would not break existing implementations (either >> initiator >> or target). >> >> Legacy targets (those that do not support this key) would just reject >> the request. Legacy initiators would never issue it. >> >> Jacob Cherian >> >> >> >> -----Original Message----- >> From: Rick McNeal [mailto:Rick.McNeal@Sun.COM] >> Sent: Wednesday, May 31, 2006 8:18 AM >> To: Eddy Quicksall >> Cc: ips@ietf.org; David Weibel; Sandars,Ken >> Subject: Re: [Ips] TargetAlias in SendTarget response >> >> During a discovery session the TargetName is not sent because it's >> not known. The thought was that in the text response for the >> SendTargets=All the target could return: >> >> TargetName=iqn.xxxx >> TargetAlias=fubar >> TargetAddress=yyyy (1 or more) >> >> To do this without changing the specification means adding a new key >> which is sent by the initiator. >> >> On May 31, 2006, at 7:08 AM, Eddy Quicksall wrote: >> >>> Weren't you looking for a way to display the target alias of the >>> target that was used for discovery? If so then TargetName would not >>> need to be sent. >>> >>> Or are you saying that for every target reported there would be a >>> TargetAlias? >>> >>> Eddy >>> >>> ----- Original Message ----- From: "Rick McNeal" >>> >>> To: "Eddy Quicksall" >>> Cc: ; "David Weibel" ; >>> "Sandars,Ken" >>> Sent: Wednesday, May 31, 2006 8:40 AM >>> Subject: Re: [Ips] TargetAlias in SendTarget response >>> >>> >>>> Since the TargetName is not required during the discovery session >>>> how would a target know which TargetAlias to return? Not to >>>> mention that during a discovery session there could be many >>>> targets which are discovered. >>>> >>>> It seems like using having an extra key sent by the initiator >>>> during the discovery session would be the simplest method. >>>> >>>> On May 30, 2006, at 5:31 PM, Eddy Quicksall wrote: >>>> >>>>> TargetAlias would be allowed in a discovery session if it is not >>>>> in response to the SendTargets key. >>>>> >>>>> Would that be OK? Then there would be no need to change the spec. >>>>> >>>>> Eddy >>>>> >>>>> ----- Original Message ----- From: "Sandars, Ken" >>>>> >>>>> To: "David Weibel" ; >>>>> Sent: Thursday, May 25, 2006 10:46 PM >>>>> Subject: RE: [Ips] TargetAlias in SendTarget response >>>>> >>>>> >>>>> Hi David, >>>>> >>>>> It's certainly a nice idea, and I cannot remember why the >>>>> TargetAlias >>>>> was excluded from the SendTargets response. Since it would be >>>>> optional >>>>> the target can decide if there are any security issues or FUD with >>>>> sending it or not. >>>>> >>>>> The benefit is it avoids the rather clumsy sequence of doing a >>>>> (discovery) login and logout to each target found in the original >>>>> unnamed discovery session just to provoke the target into sending >>>>> the >>>>> TargetAlias as part of the login phase. >>>>> >>>>> However, it cannot just be added now without potentially breaking >>>>> some >>>>> initiators which are not expecting it, or are actively ensuring >>>>> it is >>>>> not sent. >>>>> >>>>> Perhaps a new IO,LO,Declarative key could be introduced for use >>>>> by the >>>>> initiator to indicate its willingness to accept TargetAlias as >>>>> part of >>>>> the SendTarget's response? >>>>> >>>>> Cheers >>>>> Ken >>>>> >>>>>> -----Original Message----- >>>>>> From: David Weibel [mailto:David.Weibel@Sun.COM] >>>>>> Sent: 26 May 2006 08:11 >>>>>> To: ips@ietf.org >>>>>> Subject: [Ips] TargetAlias in SendTarget response >>>>>> >>>>>> >>>>>> I was wondering what people would think about adding the >>>>>> allowed and suggested use of TargetAlias during a SendTargets >>>>>> response. This would be an optional component of the response. >>>>>> The goal would be to send the alias earlier in the discovery >>>>>> process so the initiator software could also present it earlier >>>>>> to the user. >>>>>> >>>>>> This would require the ammendment of Appendix D. "No text >>>>>> keys other than TargetName and TargetAddress are permitted >>>>>> within a SendTargets response." Along with some additional >>>>>> text. >>>>>> >>>>>> _______________________________________________ >>>>>> Ips mailing list >>>>>> Ips@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/ips >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Ips mailing list >>>>> Ips@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/ips >>>>> >>>>> >>>>> _______________________________________________ >>>>> Ips mailing list >>>>> Ips@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/ips >>>> >>>> ---- >>>> Rick McNeal >>>> >>>> A good friend will come and bail you out of jail...but, a true >>>> friend will be sitting next to you saying, "Damn...that was fun! " >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Ips mailing list >>>> Ips@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/ips >>> >> >> ---- >> Rick McNeal >> >> A good friend will come and bail you out of jail...but, a true friend >> will be sitting next to you saying, "Damn...that was fun! " >> >> >> >> >> _______________________________________________ >> 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 > > ---- > Rick McNeal > > A good friend will come and bail you out of jail ... but, a true > friend will be sitting next to you saying, "Damn ... that was fun!" > > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips ---- Rick McNeal A good friend will come and bail you out of jail ... but, a true friend will be sitting next to you saying, "Damn ... that was fun!" _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed May 31 13:26:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlUSV-0005xf-9B; Wed, 31 May 2006 13:26:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlUSU-0005xa-F4 for ips@ietf.org; Wed, 31 May 2006 13:26:14 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlUST-0002O2-Td for ips@ietf.org; Wed, 31 May 2006 13:26:14 -0400 Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k4VHQDfG007327 for ; Wed, 31 May 2006 11:26:13 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J050010145F5W00@mail-amer.sun.com> (original mail from Rick.McNeal@Sun.COM) for ips@ietf.org; Wed, 31 May 2006 11:26:13 -0600 (MDT) Received: from [172.20.25.120] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J0500CVR4FOBNB4@mail-amer.sun.com>; Wed, 31 May 2006 11:26:12 -0600 (MDT) Date: Wed, 31 May 2006 11:26:10 -0600 From: Rick McNeal Subject: Re: [Ips] TargetAlias in SendTarget response In-reply-to: <81DA94E3-63E7-4373-8AB4-9E4489A3C3C2@Sun.COM> To: Sears_Bill@emc.com Message-id: <12709D10-7DBC-4F4D-A4CC-AF8D34D56BE9@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.749.3) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: <05AADEB492F5824996D28D504686739902AC538D@CORPUSMX40A.corp.emc.com> <81DA94E3-63E7-4373-8AB4-9E4489A3C3C2@Sun.COM> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 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: , Errors-To: ips-bounces@ietf.org Ugh. The following should have read. ".. I'm not proposing that the key is sent in the Text message PDU..." On May 31, 2006, at 11:19 AM, Rick McNeal wrote: > I read appendix D the same way, but I'm not proposing that the key > is not sent in the Text message PDU which would violate the spec. > The key is sent during the login phase. So it would send > > InitiatorName=iqn.xyz > SessionType=Discovery > X#sendaliasinfo=true > > For targets which don't understand this proposed key they are > expected to ignore it like any other X* key which they don't > understand. > > On May 31, 2006, at 11:08 AM, Sears_Bill@emc.com wrote: > >> Only problem I see is that spec isnt very lenient on what keys may >> be sent >> during Discovery: >> >> Appendix D: >> A SendTargets command consists of a single Text request PDU. >> This PDU contains exactly one text key and value. The text key MUST >> be SendTargets. The expected response depends upon the value, as >> well as whether the session is a discovery or operational session. >> >> The language 'exactly one text key abd value' here is >> troublesome. A simple >> target that gets anything but a Sendtargets= key during >> login may >> simply fail login rather than respond to that key with NotUnderstood. >> >> >> Bill >> >> >> >> >> -----Original Message----- >> From: Rick McNeal [mailto:Rick.McNeal@Sun.COM] >> Sent: Wednesday, May 31, 2006 12:48 PM >> To: Jacob_Cherian@Dell.com >> Cc: ips@ietf.org >> Subject: Re: [Ips] TargetAlias in SendTarget response >> >> I must not have made myself clear. The expectation would be that the >> target would only send the TargetAlias if a key was sent first by the >> Intiator. For example Sun's initiator could send: >> >> X-com.sun.sendaliases=true >> >> during the login phase when the SessionType=Discovery. The Solaris >> target would then add the TargetAlias information to a >> SendTargets=All response only if that value were true. This wouldn't >> cause any other initiators or targets to break since they >> (initiators) either will not send the key or understand the key >> (targets). >> >> If other folks feel that such a feature is worth prompting then I'll >> write up a proposal to create a new X#sendaliasinfo=true type key. >> >> On May 31, 2006, at 9:52 AM, Jacob_Cherian@Dell.com wrote: >> >>> If the purpose is to find the alias of a target in a discovery >>> session, >>> wouldn't it be better to define a new text key >>> SendTargetAlias="Target >>> Name". This would not break existing implementations (either >>> initiator >>> or target). >>> >>> Legacy targets (those that do not support this key) would just >>> reject >>> the request. Legacy initiators would never issue it. >>> >>> Jacob Cherian >>> >>> >>> >>> -----Original Message----- >>> From: Rick McNeal [mailto:Rick.McNeal@Sun.COM] >>> Sent: Wednesday, May 31, 2006 8:18 AM >>> To: Eddy Quicksall >>> Cc: ips@ietf.org; David Weibel; Sandars,Ken >>> Subject: Re: [Ips] TargetAlias in SendTarget response >>> >>> During a discovery session the TargetName is not sent because it's >>> not known. The thought was that in the text response for the >>> SendTargets=All the target could return: >>> >>> TargetName=iqn.xxxx >>> TargetAlias=fubar >>> TargetAddress=yyyy (1 or more) >>> >>> To do this without changing the specification means adding a new key >>> which is sent by the initiator. >>> >>> On May 31, 2006, at 7:08 AM, Eddy Quicksall wrote: >>> >>>> Weren't you looking for a way to display the target alias of the >>>> target that was used for discovery? If so then TargetName would not >>>> need to be sent. >>>> >>>> Or are you saying that for every target reported there would be a >>>> TargetAlias? >>>> >>>> Eddy >>>> >>>> ----- Original Message ----- From: "Rick McNeal" >>>> >>>> To: "Eddy Quicksall" >>>> Cc: ; "David Weibel" ; >>>> "Sandars,Ken" >>>> Sent: Wednesday, May 31, 2006 8:40 AM >>>> Subject: Re: [Ips] TargetAlias in SendTarget response >>>> >>>> >>>>> Since the TargetName is not required during the discovery session >>>>> how would a target know which TargetAlias to return? Not to >>>>> mention that during a discovery session there could be many >>>>> targets which are discovered. >>>>> >>>>> It seems like using having an extra key sent by the initiator >>>>> during the discovery session would be the simplest method. >>>>> >>>>> On May 30, 2006, at 5:31 PM, Eddy Quicksall wrote: >>>>> >>>>>> TargetAlias would be allowed in a discovery session if it is not >>>>>> in response to the SendTargets key. >>>>>> >>>>>> Would that be OK? Then there would be no need to change the spec. >>>>>> >>>>>> Eddy >>>>>> >>>>>> ----- Original Message ----- From: "Sandars, Ken" >>>>>> >>>>>> To: "David Weibel" ; >>>>>> Sent: Thursday, May 25, 2006 10:46 PM >>>>>> Subject: RE: [Ips] TargetAlias in SendTarget response >>>>>> >>>>>> >>>>>> Hi David, >>>>>> >>>>>> It's certainly a nice idea, and I cannot remember why the >>>>>> TargetAlias >>>>>> was excluded from the SendTargets response. Since it would be >>>>>> optional >>>>>> the target can decide if there are any security issues or FUD >>>>>> with >>>>>> sending it or not. >>>>>> >>>>>> The benefit is it avoids the rather clumsy sequence of doing a >>>>>> (discovery) login and logout to each target found in the original >>>>>> unnamed discovery session just to provoke the target into sending >>>>>> the >>>>>> TargetAlias as part of the login phase. >>>>>> >>>>>> However, it cannot just be added now without potentially breaking >>>>>> some >>>>>> initiators which are not expecting it, or are actively ensuring >>>>>> it is >>>>>> not sent. >>>>>> >>>>>> Perhaps a new IO,LO,Declarative key could be introduced for use >>>>>> by the >>>>>> initiator to indicate its willingness to accept TargetAlias as >>>>>> part of >>>>>> the SendTarget's response? >>>>>> >>>>>> Cheers >>>>>> Ken >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: David Weibel [mailto:David.Weibel@Sun.COM] >>>>>>> Sent: 26 May 2006 08:11 >>>>>>> To: ips@ietf.org >>>>>>> Subject: [Ips] TargetAlias in SendTarget response >>>>>>> >>>>>>> >>>>>>> I was wondering what people would think about adding the >>>>>>> allowed and suggested use of TargetAlias during a SendTargets >>>>>>> response. This would be an optional component of the response. >>>>>>> The goal would be to send the alias earlier in the discovery >>>>>>> process so the initiator software could also present it earlier >>>>>>> to the user. >>>>>>> >>>>>>> This would require the ammendment of Appendix D. "No text >>>>>>> keys other than TargetName and TargetAddress are permitted >>>>>>> within a SendTargets response." Along with some additional >>>>>>> text. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ips mailing list >>>>>>> Ips@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/ips >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Ips mailing list >>>>>> Ips@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/ips >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Ips mailing list >>>>>> Ips@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/ips >>>>> >>>>> ---- >>>>> Rick McNeal >>>>> >>>>> A good friend will come and bail you out of jail...but, a true >>>>> friend will be sitting next to you saying, "Damn...that was fun! " >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Ips mailing list >>>>> Ips@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/ips >>>> >>> >>> ---- >>> Rick McNeal >>> >>> A good friend will come and bail you out of jail...but, a true >>> friend >>> will be sitting next to you saying, "Damn...that was fun! " >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >> >> ---- >> Rick McNeal >> >> A good friend will come and bail you out of jail ... but, a true >> friend will be sitting next to you saying, "Damn ... that was fun!" >> >> >> >> _______________________________________________ >> Ips mailing list >> Ips@ietf.org >> https://www1.ietf.org/mailman/listinfo/ips > > ---- > Rick McNeal > > A good friend will come and bail you out of jail ... but, a true > friend will be sitting next to you saying, "Damn ... that was fun!" > > ---- Rick McNeal A good friend will come and bail you out of jail ... but, a true friend will be sitting next to you saying, "Damn ... that was fun!" _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed May 31 22:12:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flcg4-00029H-Ji; Wed, 31 May 2006 22:12:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flcg3-00028U-1Y for ips@ietf.org; Wed, 31 May 2006 22:12:47 -0400 Received: from mtagate5.de.ibm.com ([195.212.29.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlcVt-0008Ea-TG for ips@ietf.org; Wed, 31 May 2006 22:02:19 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate5.de.ibm.com (8.13.6/8.13.6) with ESMTP id k5122HZv084328 for ; Thu, 1 Jun 2006 02:02:17 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k512464j055660 for ; Thu, 1 Jun 2006 04:04:06 +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 k5122GhS013040 for ; Thu, 1 Jun 2006 04:02:16 +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 k5122GEl013037; Thu, 1 Jun 2006 04:02:16 +0200 In-Reply-To: <05AADEB492F5824996D28D504686739902AC538D@CORPUSMX40A.corp.emc.com> To: Sears_Bill@emc.com Subject: RE: [Ips] TargetAlias in SendTarget response MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 August 18, 2005 From: Julian Satran Message-ID: Date: Wed, 31 May 2006 22:04:04 -0400 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.1HF123 | April 14, 2006) at 01/06/2006 05:04:05, Serialize complete at 01/06/2006 05:04:05 X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Rick.McNeal@Sun.COM, 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="===============1113790229==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============1113790229== Content-Type: multipart/alternative; boundary="=_alternative 008359EF8525717F_=" This is a multipart message in MIME format. --=_alternative 008359EF8525717F_= Content-Type: text/plain; charset="US-ASCII" The spec authors did not intend to encourage the use of discovery sessions - except for bootstraping a management infrastructure. As for the specific TargetAlias you can get it in two steps - first a regular discovery then a "targeted discovery" (icluding the target name). Software will take that path to support targets that don't understand the new key so why introduce the new key? Julo --=_alternative 008359EF8525717F_= Content-Type: text/html; charset="US-ASCII"
The spec authors did not intend to encourage the use of discovery sessions - except for bootstraping a management infrastructure.
As for the specific TargetAlias you can get it in two steps - first a regular discovery then a "targeted discovery" (icluding the target name).
Software will take that path to support targets that don't understand the new key so why introduce the new key?

Julo --=_alternative 008359EF8525717F_=-- --===============1113790229== 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 --===============1113790229==--