From ips-bounces@ietf.org Thu Jun 01 10:23:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flo55-0002xJ-Li; Thu, 01 Jun 2006 10:23:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flo54-0002xE-Qi for ips@ietf.org; Thu, 01 Jun 2006 10:23:22 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flo50-0007r7-PR for ips@ietf.org; Thu, 01 Jun 2006 10:23:22 -0400 Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k51ENIEx013718 for ; Thu, 1 Jun 2006 08:23:18 -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 <0J0600801Q08I100@mail-amer.sun.com> (original mail from David.Weibel@Sun.COM) for ips@ietf.org; Thu, 01 Jun 2006 08:23:18 -0600 (MDT) Received: from [129.147.9.28] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J0600CYKQMTBNL4@mail-amer.sun.com>; Thu, 01 Jun 2006 08:23:18 -0600 (MDT) Date: Thu, 01 Jun 2006 08:23:16 -0600 From: David Weibel Subject: Re: [Ips] TargetAlias in SendTarget response In-reply-to: To: Julian Satran Message-id: <447EF854.5010309@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 References: User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050322) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Rick.McNeal@Sun.COM, Sears_Bill@emc.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: , Errors-To: ips-bounces@ietf.org Julian Satran wrote: > 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? It is understood this is already supported in a multi step way within the current iSCSI specification. If a target returns an initiator a list of 100 targets via a SendTargets=All and the initiator turns around and logs in and out of each target to just get the TargetAlias this leads to poor performance. The suggested change cuts this process to one step when possible and directly improves management performance. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Jun 01 11:06:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flokh-0002v6-Ne; Thu, 01 Jun 2006 11:06:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flokg-0002v1-Gq for ips@ietf.org; Thu, 01 Jun 2006 11:06:22 -0400 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flokf-0004cy-09 for ips@ietf.org; Thu, 01 Jun 2006 11:06:22 -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 k51F6KQk110312 for ; Thu, 1 Jun 2006 15:06:20 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 k51F8ASW059700 for ; Thu, 1 Jun 2006 17:08:10 +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 k51F6Jid023853 for ; Thu, 1 Jun 2006 17:06:20 +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 k51F6JQJ023842; Thu, 1 Jun 2006 17:06:19 +0200 In-Reply-To: <447EF854.5010309@sun.com> To: David Weibel 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: Thu, 1 Jun 2006 11:08:08 -0400 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.1HF123 | April 14, 2006) at 01/06/2006 18:08:09, Serialize complete at 01/06/2006 18:08:09 X-Spam-Score: 0.1 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: Rick.McNeal@Sun.COM, ips@ietf.org, Sears_Bill@emc.com, David.Weibel@Sun.COM 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="===============0705122383==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============0705122383== Content-Type: multipart/alternative; boundary="=_alternative 0052E61085257180_=" This is a multipart message in MIME format. --=_alternative 0052E61085257180_= Content-Type: text/plain; charset="US-ASCII" So we are talking milliseconds instead of microseconds for very long lasting (hours, days) sessions. I am not sure I would support a public key. Julo David Weibel Sent by: David.Weibel@Sun.COM 01/06/06 10:23 To Julian Satran/Haifa/IBM@IBMIL cc Sears_Bill@emc.com, Rick.McNeal@Sun.COM, ips@ietf.org Subject Re: [Ips] TargetAlias in SendTarget response Julian Satran wrote: > 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? It is understood this is already supported in a multi step way within the current iSCSI specification. If a target returns an initiator a list of 100 targets via a SendTargets=All and the initiator turns around and logs in and out of each target to just get the TargetAlias this leads to poor performance. The suggested change cuts this process to one step when possible and directly improves management performance. --=_alternative 0052E61085257180_= Content-Type: text/html; charset="US-ASCII"
So we are talking milliseconds instead of microseconds for very long lasting (hours, days) sessions.
I am not sure I would support a public key.

Julo


David Weibel <David.Weibel@Sun.COM>
Sent by: David.Weibel@Sun.COM

01/06/06 10:23

To
Julian Satran/Haifa/IBM@IBMIL
cc
Sears_Bill@emc.com, Rick.McNeal@Sun.COM, ips@ietf.org
Subject
Re: [Ips] TargetAlias in SendTarget response





Julian Satran wrote:

> 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?

It is understood this is already supported in a multi step way within the
current iSCSI specification.

If a target returns an initiator a list of 100 targets via a SendTargets=All
and the initiator turns around and logs in and out of each target to just
get the TargetAlias this leads to poor performance.  The suggested change
cuts this process to one step when possible and directly improves management
performance.
--=_alternative 0052E61085257180_=-- --===============0705122383== 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 --===============0705122383==-- From ips-bounces@ietf.org Fri Jun 02 11:23:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmBUP-0004WW-FS; Fri, 02 Jun 2006 11:23:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmBUO-0004WR-LT for ips@ietf.org; Fri, 02 Jun 2006 11:23:04 -0400 Received: from sccrmhc13.comcast.net ([63.240.77.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmBUL-0007R4-FH for ips@ietf.org; Fri, 02 Jun 2006 11:23:04 -0400 Received: from ivvtdkv0981 (unknown[64.238.111.98]) by comcast.net (sccrmhc13) with SMTP id <2006060215230001300kt4i0e>; Fri, 2 Jun 2006 15:23:00 +0000 Message-ID: <000b01c68658$6f580000$3401a8c0@ivivity.com> From: "Eddy Quicksall" To: Date: Fri, 2 Jun 2006 11:23:00 -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: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [Ips] TargetAddress during FFP 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="===============0294484357==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0294484357== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C68636.E7B28470" This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C68636.E7B28470 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable What should the initiator do if it receives a TargetAddress=3D
= during Full Feature Phase? Eddy ------=_NextPart_000_0008_01C68636.E7B28470 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
What should the initiator do if it receives a=20 TargetAddress=3D<address> during Full Feature Phase?
 
Eddy
------=_NextPart_000_0008_01C68636.E7B28470-- --===============0294484357== 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 --===============0294484357==-- From ips-bounces@ietf.org Fri Jun 02 15:57:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmFlt-00024c-1h; Fri, 02 Jun 2006 15:57:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmFlo-000246-CD for ips@ietf.org; Fri, 02 Jun 2006 15:57:20 -0400 Received: from web51911.mail.yahoo.com ([206.190.48.74]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FmFlm-0005Tx-U8 for ips@ietf.org; Fri, 02 Jun 2006 15:57:20 -0400 Received: (qmail 43743 invoked by uid 60001); 2 Jun 2006 19:57:18 -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=qOExVwZZIuSPIYdf6/n9p0gdANpHSauojTRXymfVyguTABfM+AVK5T5P6dPN8iK5dDYY8QTUygqgEFyOjTuqXi1DNco1OMecRD7IFdAZ+dJaFY6nauqgRiODvXt7y8uYI18Ff+d9e8HyAC0zU0Rjt1Ou4HVuIgdiuzh6+A7NFtw= ; Message-ID: <20060602195718.43741.qmail@web51911.mail.yahoo.com> Received: from [161.114.64.75] by web51911.mail.yahoo.com via HTTP; Fri, 02 Jun 2006 12:57:18 PDT Date: Fri, 2 Jun 2006 12:57:18 -0700 (PDT) From: "Mallikarjun C." Subject: RE: [Ips] [iSER] Connection_Handle question To: ips@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 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 > We first implemented DA, including necessary > extensions to it. > We then had to ditch it altogether, due to a > different iSCSI implementation. Sorry if that was a surprise, but it is quite expected. Section 6 in DA draft specifically cautions that DA is neither a wire protocol nor an API definition. So realizing the DA interaction patterns across implementations is inherently implementation-specific. Mallikarjun --- Dan Bar Dov wrote: > 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 > 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. > > Dan > > > -----Original Message----- > > From: Mallikarjun C. > [mailto:cb_mallikarjun@yahoo.com] > > Sent: Friday, May 26, 2006 8:06 PM > > To: ips@ietf.org > > Subject: Re: [Ips] [iSER] Connection_Handle > question > > > > 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 > > > __________________________________________________ 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 marcibonds@nod32.com Sat Jun 03 11:46:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmYL2-0002RF-Ku for ips-archive@lists.ietf.org; Sat, 03 Jun 2006 11:46:56 -0400 Received: from [124.199.60.187] (helo=BABY) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmYL1-0007L9-5M for ips-archive@lists.ietf.org; Sat, 03 Jun 2006 11:46:56 -0400 Message-Id: <000d01c6871a$fbcc2f80$72565261@czbvwl> From: "elise keyes" To: "worthy raines" Subject: Over paying, just refinnace, lake sheepshead Date: Sat, 03 Jun 2006 10:42:17 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C6871A.FBCC2F80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.1 (++++) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C6871A.FBCC2F80 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable How much are you paying for your Home? To much?=20 You have been pre-approved to fill out for a ref inance laon,=20 if you need some cash to spend ANY way you like, or simply wish=20 to LOWER your monthly payments by a third or more, etc. We skip the middle man to save hundreds with deals we have!=20 This offer is for you, we DONT CARE about your credit.=20 Apply online now for your instant quote. Stop over paying...=20 http://bayanmc.org/d2/ oak fly shingle bolt hairy-handed storm current shooting coat strong-decked side-graft bread bag six-shooter couch grass half snipe self-sow dung fly slave-cultured canal-built fire bucket ski pole blond-haired brass-smith sail fluke stub-toed close-set Anti-anglican easy-spoken fruit sorter take-home pay well-batted large-fruited fellow member self-sow trestle bridge ------=_NextPart_000_000D_01C6871A.FBCC2F80 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
How much are you paying for your Home? To much?
You have been pre-approved to fill out for a ref inance laon,
if you need some cash to spend ANY way you like, or simply wish
to LOWER your monthly payments by a third or more, etc.

We skip the middle man to save hundreds with deals we have!
This offer is for you, we DONT CARE about your credit.

Apply online now for your instant quote. Stop over paying...

http://bayanmc.org/d2/

oak fly shingle bolt hairy-handed storm current shooting coat
strong-decked side-graft
bread bag six-shooter couch grass half snipe self-sow dung fly
slave-cultured canal-built fire bucket ski pole blond-haired
brass-smith sail fluke stub-toed
close-set Anti-anglican easy-spoken
fruit sorter take-home pay well-batted large-fruited fellow member
self-sow trestle bridge
= ------=_NextPart_000_000D_01C6871A.FBCC2F80-- From ips-bounces@ietf.org Tue Jun 06 18:34:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnk7z-00085B-Jq; Tue, 06 Jun 2006 18:34:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnk7y-000856-Gc for ips@ietf.org; Tue, 06 Jun 2006 18:34:22 -0400 Received: from web51910.mail.yahoo.com ([206.190.48.73]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fnk7x-0004UL-5x for ips@ietf.org; Tue, 06 Jun 2006 18:34:22 -0400 Received: (qmail 37846 invoked by uid 60001); 6 Jun 2006 22:34:20 -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=1GtF1AjnuGznWyY6ofAX+En+QDFFnlSYrko0qwGwJlooJnCMnvCdxglwqXwNXrwetenY5wQcO1Y29sNYYix0kJ2UOMkKXIiUZobrjzZjVVVbMuxYdPearYO7RLYmSHhF99EqgOzW+iQKYP6O3+vPZZdvR6bxOvrdQeURU8LaNzk= ; Message-ID: <20060606223420.37844.qmail@web51910.mail.yahoo.com> Received: from [15.235.153.101] by web51910.mail.yahoo.com via HTTP; Tue, 06 Jun 2006 15:34:20 PDT Date: Tue, 6 Jun 2006 15:34:20 -0700 (PDT) From: "Mallikarjun C." Subject: Re: [Ips] TargetAlias in SendTarget response To: ips@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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 have some appreciation for the long discovery times in large SANs. However, volume-level discovery consumes the bulk of today's discovery time rather than target device-level discovery. So while I see the proposed optimization for device-level discovery, I am not sure it is compelling enough for me. Mallikarjun --- Julian Satran wrote: > So we are talking milliseconds instead of > microseconds for very long > lasting (hours, days) sessions. > I am not sure I would support a public key. > > Julo > > > > David Weibel > Sent by: David.Weibel@Sun.COM > 01/06/06 10:23 > > To > Julian Satran/Haifa/IBM@IBMIL > cc > Sears_Bill@emc.com, Rick.McNeal@Sun.COM, > ips@ietf.org > Subject > Re: [Ips] TargetAlias in SendTarget response > > > > > > > Julian Satran wrote: > > > 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? > > It is understood this is already supported in a > multi step way within the > current iSCSI specification. > > If a target returns an initiator a list of 100 > targets via a > SendTargets=All > and the initiator turns around and logs in and out > of each target to just > get the TargetAlias this leads to poor performance. > The suggested change > cuts this process to one step when possible and > directly improves > management > performance. > > > _______________________________________________ > 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 Wed Jun 07 07:57:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnwf2-0002f3-H8; Wed, 07 Jun 2006 07:57:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnwf0-0002ex-PP for ips@ietf.org; Wed, 07 Jun 2006 07:57:18 -0400 Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnwf0-0000uK-2V for ips@ietf.org; Wed, 07 Jun 2006 07:57:18 -0400 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate2.de.ibm.com (8.13.6/8.13.6) with ESMTP id k57BvGui099226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 7 Jun 2006 11:57:17 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1507.megacenter.de.ibm.com (8.13.6/NCO/VER7.0) with ESMTP id k57BxC0c045434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 7 Jun 2006 13:59:14 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k57BvDfR006263 for ; Wed, 7 Jun 2006 13:57:13 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k57BvDln006257 for ; Wed, 7 Jun 2006 13:57:13 +0200 In-Reply-To: <20060606223420.37844.qmail@web51910.mail.yahoo.com> To: "Mallikarjun C." 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, 7 Jun 2006 14:59:09 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.1HF123 | April 14, 2006) at 07/06/2006 14:59:11, Serialize complete at 07/06/2006 14:59:11 X-Spam-Score: 0.1 (/) 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: , Content-Type: multipart/mixed; boundary="===============0672603273==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============0672603273== Content-Type: multipart/alternative; boundary="=_alternative 0041A7CDC2257186_=" This is a multipart message in MIME format. --=_alternative 0041A7CDC2257186_= Content-Type: text/plain; charset="US-ASCII" I concur with Mallikarjun and I would like to add that the major reason for my opposition to any inline discovery was that for any installation of a nontrivial size having clients machines (initiators) discover targets is a bad solution. Clients should know only about "resource managers" (a few of them) and those are the ones that keep track of resources. The reason that we have the Sendtargets and the discovery sessions is that some people thought that a "resource manager" would be hard to justify in small environments - although providing an iSNS or SLP server is not difficult even in the tiniest setting. Julo "Mallikarjun C." 07/06/06 01:34 To ips@ietf.org cc Subject Re: [Ips] TargetAlias in SendTarget response I have some appreciation for the long discovery times in large SANs. However, volume-level discovery consumes the bulk of today's discovery time rather than target device-level discovery. So while I see the proposed optimization for device-level discovery, I am not sure it is compelling enough for me. Mallikarjun --- Julian Satran wrote: > So we are talking milliseconds instead of > microseconds for very long > lasting (hours, days) sessions. > I am not sure I would support a public key. > > Julo > > > > David Weibel > Sent by: David.Weibel@Sun.COM > 01/06/06 10:23 > > To > Julian Satran/Haifa/IBM@IBMIL > cc > Sears_Bill@emc.com, Rick.McNeal@Sun.COM, > ips@ietf.org > Subject > Re: [Ips] TargetAlias in SendTarget response > > > > > > > Julian Satran wrote: > > > 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? > > It is understood this is already supported in a > multi step way within the > current iSCSI specification. > > If a target returns an initiator a list of 100 > targets via a > SendTargets=All > and the initiator turns around and logs in and out > of each target to just > get the TargetAlias this leads to poor performance. > The suggested change > cuts this process to one step when possible and > directly improves > management > performance. > > > _______________________________________________ > 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 --=_alternative 0041A7CDC2257186_= Content-Type: text/html; charset="US-ASCII"
I concur with Mallikarjun and I would like to add that the major reason for my opposition to any inline discovery was that for any installation of a nontrivial size having clients machines (initiators) discover targets is a bad solution. Clients should know only about "resource managers" (a few of them) and those are the ones that keep track  of resources. The reason that we have the Sendtargets and the discovery sessions is that some people thought that a "resource manager" would be hard to justify in small environments - although providing an iSNS or SLP server is not difficult even in the tiniest setting.

Julo


"Mallikarjun C." <cb_mallikarjun@yahoo.com>

07/06/06 01:34

To
ips@ietf.org
cc
Subject
Re: [Ips] TargetAlias in SendTarget response





I have some appreciation for the long discovery times
in large SANs.  However, volume-level discovery
consumes the bulk of today's discovery time rather
than target device-level discovery.  So while I see
the proposed optimization for device-level discovery,
I am not sure it is compelling enough for me.

Mallikarjun



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

> So we are talking milliseconds instead of
> microseconds for very long
> lasting (hours, days) sessions.
> I am not sure I would support a public key.
>
> Julo
>
>
>
> David Weibel <David.Weibel@Sun.COM>
> Sent by: David.Weibel@Sun.COM
> 01/06/06 10:23
>
> To
> Julian Satran/Haifa/IBM@IBMIL
> cc
> Sears_Bill@emc.com, Rick.McNeal@Sun.COM,
> ips@ietf.org
> Subject
> Re: [Ips] TargetAlias in SendTarget response
>
>
>
>
>
>
> Julian Satran wrote:
>
> > 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?
>
> It is understood this is already supported in a
> multi step way within the
> current iSCSI specification.
>
> If a target returns an initiator a list of 100
> targets via a
> SendTargets=All
> and the initiator turns around and logs in and out
> of each target to just
> get the TargetAlias this leads to poor performance.
> The suggested change
> cuts this process to one step when possible and
> directly improves
> management
> performance.
>
> > _______________________________________________
> 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
--=_alternative 0041A7CDC2257186_=-- --===============0672603273== 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 --===============0672603273==-- From ips-bounces@ietf.org Wed Jun 07 08:58:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnxc5-0005XR-AQ; Wed, 07 Jun 2006 08:58:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnxc2-0005Ux-ET for ips@ietf.org; Wed, 07 Jun 2006 08:58:18 -0400 Received: from bay115-f33.bay115.hotmail.com ([65.54.250.43] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnxc1-0006RH-78 for ips@ietf.org; Wed, 07 Jun 2006 08:58:18 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 7 Jun 2006 05:58:16 -0700 Message-ID: Received: from 65.54.250.200 by by115fd.bay115.hotmail.msn.com with HTTP; Wed, 07 Jun 2006 12:58:12 GMT X-Originating-IP: [65.70.202.126] X-Originating-Email: [sma78759@hotmail.com] X-Sender: sma78759@hotmail.com From: "Steve Ma" To: ips@ietf.org Bcc: Date: Wed, 07 Jun 2006 12:58:12 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 07 Jun 2006 12:58:16.0556 (UTC) FILETIME=[0B14FAC0:01C68A32] X-Spam-Score: 2.1 (++) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Subject: [Ips] (no subject) 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 unsubscribe* _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Jun 07 12:00:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo0Ru-0003eM-RL; Wed, 07 Jun 2006 12:00:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo0Rt-0003e2-8x for ips@ietf.org; Wed, 07 Jun 2006 12:00:01 -0400 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo0Rm-0002Ul-JX for ips@ietf.org; Wed, 07 Jun 2006 12:00:01 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k57FwvXg004043; Wed, 7 Jun 2006 10:58:58 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 7 Jun 2006 17:58:56 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550A338214@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Kevin Gibbons'" , "'David Black (E-mail)'" , "'Scott Kipp'" , "'gramkumar@gmail.com'" Date: Wed, 7 Jun 2006 17:58:49 +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: 66ff42a56498684039efb58366a4b354 Cc: "Dan Romascanu \(E-mail\)" , "'ips@ietf.org'" Subject: [Ips] RE: MIB Doctor review (part-2) for: draft-ietf-ips-isns-mib-09.tx t 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 [copied Dan Romascanu; not sure if he is on IPS mlist] Sorry it took a while. My excuse is that the MIB module alone is over 3000 lines long, not small. I am also not an IPS expert, so I did have to go and check 4171 many times. I am still not able to fit the whole picture of tables with all their aspects in my head. May I assume that the subject matter experts have done that or will do so? part-1 is appended at the bottom, so people have it all in one email if such is easier. - My last point in part 1 was: > - 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. that Description clause states as a last point: If SNMP is not allowed to view or modify the list of control nodes, then this managed object SHALL be set to noSnmpAccess." so does that mean that if the value is noSnmpAccess that there then are no entries to be shown in the isnsCntlNodeIscsiTable? The description clause of isnsCntlNodeIscsiTable says so. So it would be good to repeat that here in the DESCRIPTION clause of isnsSrvrInstCntrlNodeAuth as well (I think). Maybe it should also state that isnsCntlNodeFcPortTable is empty in that case. By the way, it might be good to also explain that SnmpAccess is read-only (although that shouldbe clear seeing that the two tables are both read only. - When I looked at IsnsDdDdsModificationBitmap again, I was somewhat surprised by bit field zero: instance. Although this MIB does not allow modification of DD's and DDS's, SNMP may be used to modify them via another MIB. 0 SNMP protocol is allowed to modify DD's/DDS's This MIB module is read-only as you say. SOme other MIB module may allow changes. Mmm... is it then logical to express in this MIB module if such can be possibly be done somewhere else? Is that somewhere else on the same system as where this MIB module is instantiated? If not, how easy is it to represent that here (if at all possible)?? Further, I see that everytime this TC is used as a SYNTAX, the same sort of DESCRIPTION clause gets repeated. The idea of a TC is to describe the semantics ONCE and not to repeat that many times (with the risk of creating inconsistencies or conflicts or ambiguity). So for example, I would limit the DESCRIPTION clause in isnsSrvrInstUpdateDdDdsSpprtd as follows: isnsSrvrInstUpdateDdDdsSpprtd OBJECT-TYPE SYNTAX IsnsDdDdsModificationBitmap MAX-ACCESS read-only STATUS current DESCRIPTION "The methods that this iSNS Server instance supports to modify Discovery Domains and Discovery Domain Sets." REFERENCE "RFC 4171, Section 3.4" ::= { isnsSrvrInstEntry 17 } If you agree, pls look at other uses of ths (and other) TCs as well. - isnsNumObjTable OBJECT-TYPE SYNTAX SEQUENCE OF IsnsNumObjEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table providing the number of registered objects of each type in the iSNS Server instance. This table is optional to implement. The number of entries is dependent upon the number of iSNS Server instances being managed." ::= { isnsSrvrInfo 2 } The fact that this table is "optional" should not be stated here in the DESCRIPTION clause. Nether should in the DESCRIPTION clause of isnsServerNumObjGroup OBJECT-GROUP be stated that: associated with a registered Entity. These managed objects are optional to implement." The fact if objects are optional should be expressed by properly grouping them (which I think has been done) in an OBJECT-GROUP and then make that OBJECT-GROUP and optional group in the MODULE-COMPLIANCE. The latter has not been done, because: isnsIscsiServerCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Initial compliance statement for an iSNS Server providing support to iSCSI clients." MODULE -- this module MANDATORY-GROUPS { isnsServerAttributesGroup, isnsServerIscsiCntlNodeGroup, isnsServerIscsiDdsDdObjGroup, isnsServerRegIscsiObjGroup, isnsServerNumObjGroup, isnsNotificationsObjGroup, isnsServerNotificationGroup } ::= { isnsCompliances 1 } shows that those claims in the DESCRIPTION clauses are INCORRECT. The above MODULE-COMPLIACNE shows this group as a MANDATORY-GROUP. In fact in the 2nd MODULE-COMPLIANCE, the group is also listed as MANDATORY. So it seems it is always mandatory according to the currently know MODULE-COMPLIANCE statements. Pls remove also the "optional" language in isnsRegEntityNumObjTable - I wonder if the following would be better represented by a SYNTAX of Gauge32: IsnsNumObjEntry ::= SEQUENCE { isnsNumDds Unsigned32, isnsNumDd Unsigned32, isnsNumEntities Unsigned32, isnsNumPortals Unsigned32, isnsNumPortalGroups Unsigned32, isnsNumIscsiNodes Unsigned32, isnsNumFcPorts Unsigned32, isnsNumFcNodes Unsigned32 } There are probably other objects that are better represented as a Gauge32 as well. I can live with Unsigned32 though. Question for my understanding: Are these counters intended to help determine the max-repetitions for a getbulk? same for objects in isnsRegEntityNumObjTable - isnsCntlNodeFcPortName OBJECT-TYPE SYNTAX FcNameIdOrZero MAX-ACCESS not-accessible STATUS current DESCRIPTION "The FC Port WWN that can and/or is acting as a control node for the specified iSNS Server. Zero is not a valid value for this managed object. This managed object, combined with the isnsSrvrInstIndex, is the key for this table." ::= { isnsCntlNodeFcPortEntry 1 } I think it is better to s/Zero/A zero length string/ - In addition to my earlier comment on IsnsDdsStatusId ::= TEXTUAL-CONVENTION As far as I see, it is only used once. So that begs the question why it is a TC. But even so, in the case where it is used in this MIB module: isnsDdsStatus OBJECT-TYPE SYNTAX IsnsDdsStatusId MAX-ACCESS read-only 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. If set to false then the DDS is disabled." REFERENCE "RFC 4171, Section 6" DEFVAL { { enabled } } ::= { isnsDdsEntry 3 } It seems to me that it would be more appropriate to rename the isnsDdsStatus objct to isnsDdsEnabled and *re-(use the TruthValue TC from RFC2579. - naming consistency: IsnsDdIscsiMemberEntry::= SEQUENCE { isnsDdMemberIscsiIdx IsnsNodeIndexId, isnsDdMemberIscsiName SnmpAdminString, isnsDdMemberIsRegistered TruthValue } why are they not named: IsnsDdIscsiMemberEntry::= SEQUENCE { isnsDdIscsiMemberIdx IsnsNodeIndexId, isnsDdIscsiMemberName SnmpAdminString, isnsDdIscsiMemberIsRegistered TruthValue } I would myself also rename isnsDdIscsiMemberIdx to isnsDdIscsiMemberIndex - naming consistency IsnsDdPortalMemberEntry ::= SEQUENCE { isnsDdMemberPortalIdx IsnsPortalIndexId, isnsDdMemberPortalAddrType InetAddressType, isnsDdMemberPortalAddr InetAddress, isnsDdMemberPortalPortType IsnsPortalPortTypeId, isnsDdMemberPortalPort InetPortNumber, isnsDdMemberPortalIsRegistered TruthValue } I would start all names with isnsDPortalMember. - isnsDdMemberPortalAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The Inet Address for the portal." According to RFC4001, you MUST specify which object of SYNTAX InetAddressType specifies/controls the format of an InetAddress object. I guess it is clear that isnsDdMemberPortalAddrType is that object. But pls make that statement in description clause. Is dns a valid type or does it need to be supported? If not, may wnt to express that in MODULE-COMPLIANCE. If yes, may want to say somethingas to when that dns name is resolved (as required per rfc4001)? Maybe it is never a dns name (if I understand that it is max 16 octets as per sect 6 of rfc4171) Maybe it is only IPv4 and/or IPv6? You could add that to the SYNTAX of the InetAddressType object if it will never be different. same for: isnsRegEntityMgtAddr and maybe others? pls check. - isnsDdMemberPortalPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-only STATUS current DESCRIPTION "The port number for the portal. Whether the portal type is TCP or UDP is indicated by isnsDdPortalPortType." Is a port number of zero valid? And if so, then what does it mean? If not, then maybe use SYNTAX InetPortNumber (1..65535) same for: isnsRegPortalPort maybe others? pls check - naming consitency IsnsDdFcPortMemberEntry ::= SEQUENCE { isnsDdMemberFcPortName FcNameIdOrZero, isnsDdMemberFcIsRegistered TruthValue } I would start the names with isnsDdFcPort.. - isnsDdMemberFcPortName and isnsDdId are the key for this table. Zero is not a valid value for this managed object." I guess you mean: a Zero length string is not a valie value? This issue is in several (if not all) object DESCRIPTIONs of objects with SYNTAX FcNameIdOrZero. - isnsRegEntityVersionMin OBJECT-TYPE SYNTAX Unsigned32 ( 0 .. 65535 ) MAX-ACCESS read-only STATUS current DESCRIPTION "The iSNS Entity Protocol Version Range minimum value. A value of x'FF' is a wildcard value indicating no minimum to the protocol versions supported by this Entity. Entity registrations with isnsRegEntityProtocol set to No Protocol always have a minimum version of 0." are you sure you mean a value of x'FF'?? That is value 255 in decimal, maybe you mean that you want to use x'FFFF' which is the value 65535? In that case, I think I would express it as: SYNTAX Unsigned32 ( 0 .. 65534 | 65535 ) and use the value 65535 in de DESCRIPTION clause instead of some hex representation. same for: isnsRegEntityVersionMax - isnsRegEntityRegPeriod Pls add a UNITS clause: UNITS "seconds" - isnsRegPortalEsiInterval Pls add UNITS clause. here the DESCRIPTION clause does not even say in what units this is measured. - isnsRegFcPortType OBJECT-TYPE SYNTAX Unsigned32 ( 0 .. 65535 ) MAX-ACCESS read-only STATUS current DESCRIPTION "The FC Port Port Type as defined in the iSNS Specification, RFC 4171, and the Fibre Channel Generic Services Specification. Current values are as shown below: unknown (0), nPort (1), nlPort (2), fNlPort (3), fPort (129), -- x'81' flPort (130), -- x'82' ePort (132), -- x'84' bPort (133), -- x'85' mFcpPort (65297), -- x'FF11' iFcpPort (65298), -- x'FF12' unknownEnd (65535) ." Would this not be better an ENUM. I understand you would want to break the rule/guidline to start at 1 and to be consecutive. But an ENUM seems so much nicer, no? - isnsRegFcPortFc4Types OBJECT-TYPE SYNTAX OCTET STRING (SIZE (32)) MAX-ACCESS read-only STATUS current DESCRIPTION "The FC Port FC-4 Types as defined in the iSNS Specification, RFC 4171." REFERENCE "RFC 4171, Section 6" ::= { isnsRegFcPortEntry 10 } The size seems to allow for 8 types? Is that correct? How do I know? I do not find an explanation in sect 6 of 4171 for that either. - isnsRegFcPortFc4Descr OBJECT-TYPE SYNTAX OCTET STRING(SIZE(0..255)) MAX-ACCESS read-only accoding to RFC4171, sect 6: FC-4 Descriptor 4-256 so how does a 256-size value fit into 255-size string? should minumum size be 4 octets? So I would expect a SYNTAX of: SYNTAX OCTET STRING(SIZE(4..256)) and RFC4171 sect 6.6.10 speaks about it being a NULL terminated UTF-8 string, so maybe the best SYNTAX would be SYNTAX SnmpAdminString (SIZE(4..255)) and then add in DESCRIPTION clause that the termninating NULL is not included in the object (as you have done for some other UTF-8 based objects). - for: isnsInstInfo OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..80)) MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Textual information about the iSNS Server notification. An example is: iSNS Server Started, information that would be included in the appropriate notification." ::= { isnsNotificationsInfo 1 } It is nice that it is SnmpAdminString (i.e. UTF-8) so that you can represent international human readable text. But in some scripts, one character can occupy up to 5 or 6 octets. So a max size of 80 allows for some 15 or so characters. Why do we want to limit this size to 80? Why can we not allow up to 255 (the max size of an SnmpAdminString) ??? more nits/typos etc. - IsnsScnBitmapId ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The State Change Notification (SCN) bitmap for a node as defined in the iSNS Specification, RFC 4171. A set bit (1) indicates the type of SCN for the bitmap as follows: Bit Field Flag Description --------- ---------------- 0 INITIATOR AND SELF INFORMATION ONLY 1 TARGET AND SELF INFORMATION ONLY 2 MANAGEMENT REGISTRATION/SCN 3 REGISTERED OBJECT REMOVED 4 REGISTERED OBJECT ADDED 5 REGISTERED OBJECT UPDATED 6 DD/DDS MEMBER REMOVED (MGT REG/SCN ONLY) 7 DD/DDS MEMBER ADDED (MGT REG/SCN ONLY) " Why are you using all the UPPER CASE TEXT ?? Makes me go back in time to IBM Mainframe MVS and JCL times. - I really wonder why isnsCntlNodeIscsiNodeIdx is not named isnsCntlNodeIscsiNodeIndex. It adds 2 characters to the descriptor, but gives the name so much more meaning. Maybe it is just me. - in DESCRIPTION clause of: isnsCntlNodeIscsiNodeName the storage node. The iSCSI Name can not be longer then should be "can not be longer than: ?? - I do not understand why isnsAddrTypeNotifctn, isnsAddrNotifctn, isnsTcpPortNotifctn, isnsUdpPortNotifctn are not named isnsAddrTypeNotification, isnsAddrNotification, isnsTcpPortNotification, isnsUdpPortNotificationn in other words I can not see the tradeoff between a clear descriptor and a shorter descriptor here. For me the longer name would win. So is there an explanation why you use the shorter descriptor names? This theme of unexplanatory/not-understandable abbreviations for descriptor names or label names occurs many times. I will not continue to list them. I suggest that the editors and WG take a serious look at this and use clearer names whereever possible. - isnsDdsSymbolicName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..255)) The SnmpAdminString has exactly the same range, so it is superfluous to repeat it here. So I would do: isnsDdsSymbolicName OBJECT-TYPE SYNTAX SnmpAdminString - same for isnsDdsMemberSymName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..255)) and isnsRegEntityEID OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..255)) and maybe others. Pls check. Bert > -----Original Message----- > From: Wijnen, Bert (Bert) > Sent: Wednesday, May 10, 2006 23:17 > To: Kevin Gibbons; David Black (E-mail); Scott Kipp; > gramkumar@gmail.com > Cc: ips@ietf.org > Subject: MIB Doctor review (part-1) for: > draft-ietf-ips-isns-mib-09.txt > > > 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 Wed Jun 07 13:25:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo1mq-0008H7-FW; Wed, 07 Jun 2006 13:25:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo1mp-0008H2-Md for ips@ietf.org; Wed, 07 Jun 2006 13:25:43 -0400 Received: from rwcrmhc11.comcast.net ([216.148.227.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo1mo-0005OZ-Cw for ips@ietf.org; Wed, 07 Jun 2006 13:25:43 -0400 Received: from ivvtdkv0981 (c-66-177-56-218.hsd1.fl.comcast.net[66.177.56.218]) by comcast.net (rwcrmhc11) with SMTP id <20060607172541m1100hcva2e>; Wed, 7 Jun 2006 17:25:41 +0000 Message-ID: <003c01c68a57$66966d00$06031eac@ivivity.com> From: "Eddy Quicksall" To: References: <000b01c68658$6f580000$3401a8c0@ivivity.com> Subject: Re: [Ips] TargetAddress during FFP Date: Wed, 7 Jun 2006 13:25:40 -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: c3a18ef96977fc9bcc21a621cbf1174b 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="===============0967033161==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0967033161== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0039_01C68A35.DEBC9B00" This is a multi-part message in MIME format. ------=_NextPart_000_0039_01C68A35.DEBC9B00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I don't see a response for this. Does anyone know what to do? i.e., = should the initiator logout and use the new address, just record the new = address for later logins or just ignore it? ----- Original Message -----=20 From: Eddy Quicksall=20 To: ips@ietf.org=20 Sent: Friday, June 02, 2006 11:23 AM Subject: [Ips] TargetAddress during FFP What should the initiator do if it receives a = TargetAddress=3D
during Full Feature Phase? Eddy -------------------------------------------------------------------------= ----- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------=_NextPart_000_0039_01C68A35.DEBC9B00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I don't see a response for this. Does anyone know = what to do?=20 i.e., should the initiator logout and use the new address, just record = the new=20 address for later logins or just ignore it?
----- Original Message -----
From:=20 Eddy = Quicksall=20
Sent: Friday, June 02, 2006 = 11:23=20 AM
Subject: [Ips] TargetAddress = during=20 FFP

What should the initiator do if it receives a=20 TargetAddress=3D<address> during Full Feature = Phase?
 
Eddy

_______________________________________________
Ips mailing=20 list
Ips@ietf.org
https://www1.ietf.org= /mailman/listinfo/ips
------=_NextPart_000_0039_01C68A35.DEBC9B00-- --===============0967033161== 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 --===============0967033161==-- From ips-bounces@ietf.org Thu Jun 08 01:10:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoCn7-0003XX-5e; Thu, 08 Jun 2006 01:10:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoCn5-0003Vg-1U for ips@ietf.org; Thu, 08 Jun 2006 01:10:43 -0400 Received: from mail-gw3.adaptec.com ([216.52.22.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoCn3-0003wl-JR for ips@ietf.org; Thu, 08 Jun 2006 01:10:43 -0400 Received: from aime2k03.adaptec.com (aime2k03.adaptec.com [10.25.8.43]) by mail-gw3.adaptec.com (Spam Firewall) with ESMTP id 7B2813E7B4; Wed, 7 Jun 2006 22:10:37 -0700 (PDT) Received: from aime2k302.adaptec.com ([10.25.8.48]) by aime2k03.adaptec.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 7 Jun 2006 22:10:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ips] TargetAddress during FFP Date: Wed, 7 Jun 2006 22:10:33 -0700 Message-ID: <368FBF3D8437A748BA8222526BF9309975CECB@aime2k302.adaptec.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] TargetAddress during FFP Thread-Index: AcaKV3Pg9R6EbAXuRMCS1H9kArIakgAYJGLQ From: "Sandars, Ken" To: "Eddy Quicksall" , X-OriginalArrivalTime: 08 Jun 2006 05:10:37.0427 (UTC) FILETIME=[E0F36C30:01C68AB9] X-Virus-Scanned: by Barracuda Spam Firewall at adaptec.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 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="===============0257755068==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0257755068== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C68AB9.E07398A9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C68AB9.E07398A9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Eddy, =20 I'm assuming the TargetAddress=3D is being sent in a Text response PDU by the target. In your scenario, does the initiator send a Text request PDU? If so, what key(s) are in it? =20 The definition of the key indicates there is nothing illegal about sending it. Unfortunately, since you are describing a scenario which is neither a part of a SendTargets response or a part of Login redirect response, there is no defined action for the initiator. Hopefully the choice is to not crash! =20 I think the appropriate thing to do is to ignore the key, unless there are other aspects of the Text negotiation which are broken. =20 Cheers Ken =20 -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall_iVivity_iSCSI@Comcast.net]=20 Sent: 08 June 2006 03:26 To: ips@ietf.org Subject: Re: [Ips] TargetAddress during FFP I don't see a response for this. Does anyone know what to do? i.e., should the initiator logout and use the new address, just record the new address for later logins or just ignore it? ----- Original Message -----=20 From: Eddy Quicksall =20 To: ips@ietf.org=20 Sent: Friday, June 02, 2006 11:23 AM Subject: [Ips] TargetAddress during FFP What should the initiator do if it receives a TargetAddress=3D
during Full Feature Phase? =20 Eddy _____ =20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------_=_NextPart_001_01C68AB9.E07398A9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Eddy,
 
I'm=20 assuming the TargetAddress=3D<blah> is being sent in a Text = response PDU by=20 the target. In your scenario, does the initiator send a Text request = PDU? If so,=20 what key(s) are in it?
 
The=20 definition of the key indicates there is nothing illegal about sending = it.=20 Unfortunately, since you are describing a scenario which is neither a = part of a=20 SendTargets response or a part of Login redirect response, there is = no=20 defined action for the initiator. Hopefully the choice is to not=20 crash!
 
I=20 think the appropriate thing to do is to ignore the key, unless there are = other=20 aspects of the Text negotiation which are broken.
 
Cheers
Ken
 
-----Original Message-----
From: Eddy = Quicksall=20 [mailto:eddy_quicksall_iVivity_iSCSI@Comcast.net]
Sent: 08 = June=20 2006 03:26
To: ips@ietf.org
Subject: Re: [Ips]=20 TargetAddress during FFP

I don't see a response for this. Does anyone know = what to=20 do? i.e., should the initiator logout and use the new address, just = record the=20 new address for later logins or just ignore it?
----- Original Message -----
From:=20 Eddy = Quicksall=20
Sent: Friday, June 02, 2006 = 11:23=20 AM
Subject: [Ips] TargetAddress = during=20 FFP

What should the initiator do if it receives a=20 TargetAddress=3D<address> during Full Feature = Phase?
 
Eddy

_______________________________________________
Ips = mailing=20 list
Ips@ietf.org
https://www1.ietf.org= /mailman/listinfo/ips
------_=_NextPart_001_01C68AB9.E07398A9-- --===============0257755068== 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 --===============0257755068==-- From ips-bounces@ietf.org Thu Jun 08 07:18:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoIWv-0004jM-Qy; Thu, 08 Jun 2006 07:18:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoIWu-0004jH-EI for ips@ietf.org; Thu, 08 Jun 2006 07:18:24 -0400 Received: from rwcrmhc14.comcast.net ([204.127.192.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoIWt-0007F7-VA for ips@ietf.org; Thu, 08 Jun 2006 07:18:24 -0400 Received: from ivvtdkv0981 (c-66-177-56-218.hsd1.fl.comcast.net[66.177.56.218]) by comcast.net (rwcrmhc14) with SMTP id <20060608111822m1400dhd5ee>; Thu, 8 Jun 2006 11:18:22 +0000 Message-ID: <000d01c68aed$40e4da60$06031eac@ivivity.com> From: "Eddy Quicksall" To: "Sandars, Ken" , References: <368FBF3D8437A748BA8222526BF9309975CECB@aime2k302.adaptec.com> Subject: Re: [Ips] TargetAddress during FFP Date: Thu, 8 Jun 2006 07:18:21 -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: 03fb21b15d5177c512a4caa19876f30a 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="===============0665842084==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0665842084== Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01C68ACB.B8F7CE80" This is a multi-part message in MIME format. ------=_NextPart_000_000A_01C68ACB.B8F7CE80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MessageActually I asked the question purposely out of the context of = SendTargets because I could not find anything in the spec that required = the TargetAddress to be a response to SendTargets. In both cases I would = have the same question. I was more wondering what the community does or = expects under the two cases. I'm currently ignoring it but thinking of recording the new address and = in the event of a new login using the new address for that. For example, = the target may want to send a new target address and then send a request = to logout; the new login would use the new target address. Eddy ----- Original Message -----=20 From: Sandars, Ken=20 To: Eddy Quicksall ; ips@ietf.org=20 Sent: Thursday, June 08, 2006 1:10 AM Subject: RE: [Ips] TargetAddress during FFP Hi Eddy, I'm assuming the TargetAddress=3D is being sent in a Text = response PDU by the target. In your scenario, does the initiator send a = Text request PDU? If so, what key(s) are in it? The definition of the key indicates there is nothing illegal about = sending it. Unfortunately, since you are describing a scenario which is = neither a part of a SendTargets response or a part of Login redirect = response, there is no defined action for the initiator. Hopefully the = choice is to not crash! I think the appropriate thing to do is to ignore the key, unless there = are other aspects of the Text negotiation which are broken. Cheers Ken -----Original Message----- From: Eddy Quicksall = [mailto:eddy_quicksall_iVivity_iSCSI@Comcast.net]=20 Sent: 08 June 2006 03:26 To: ips@ietf.org Subject: Re: [Ips] TargetAddress during FFP I don't see a response for this. Does anyone know what to do? i.e., = should the initiator logout and use the new address, just record the new = address for later logins or just ignore it? ----- Original Message -----=20 From: Eddy Quicksall=20 To: ips@ietf.org=20 Sent: Friday, June 02, 2006 11:23 AM Subject: [Ips] TargetAddress during FFP What should the initiator do if it receives a = TargetAddress=3D
during Full Feature Phase? 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 ------=_NextPart_000_000A_01C68ACB.B8F7CE80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Actually I asked the question purposely out of = the=20 context of SendTargets because I could not find anything in the spec = that=20 required the TargetAddress to be a response to SendTargets. In both = cases I=20 would have the same question. I was more wondering what the community = does or=20 expects under the two cases.
 
I'm currently ignoring it but thinking of recording = the new=20 address and in the event of a new login using the new address for that. = For=20 example, the target may want to send a new target address and then send = a=20 request to logout; the new login would use the new target = address.
 
Eddy
----- Original Message -----
From:=20 Sandars, Ken
To: Eddy = Quicksall ; ips@ietf.org =
Sent: Thursday, June 08, 2006 = 1:10=20 AM
Subject: RE: [Ips] = TargetAddress during=20 FFP

Hi=20 Eddy,
 
I'm=20 assuming the TargetAddress=3D<blah> is being sent in a Text = response PDU=20 by the target. In your scenario, does the initiator send a Text = request PDU?=20 If so, what key(s) are in it?
 
The=20 definition of the key indicates there is nothing illegal about sending = it.=20 Unfortunately, since you are describing a scenario which is neither a = part of=20 a SendTargets response or a part of Login redirect response, = there is no=20 defined action for the initiator. Hopefully the choice is to not=20 crash!
 
I=20 think the appropriate thing to do is to ignore the key, unless there = are other=20 aspects of the Text negotiation which are broken.
 
Cheers
Ken
 
-----Original Message-----
From: = Eddy Quicksall=20 [mailto:eddy_quicksall_iVivity_iSCSI@Comcast.net]
Sent: = 08 June=20 2006 03:26
To: ips@ietf.org
Subject: Re: [Ips]=20 TargetAddress during FFP

I don't see a response for this. Does anyone = know what to=20 do? i.e., should the initiator logout and use the new address, just = record=20 the new address for later logins or just ignore it?
----- Original Message ----- =
From:=20 Eddy = Quicksall=20
Sent: Friday, June 02, 2006 = 11:23=20 AM
Subject: [Ips] = TargetAddress during=20 FFP

What should the initiator do if it receives a=20 TargetAddress=3D<address> during Full Feature = Phase?
 
Eddy

_______________________________________________
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_000A_01C68ACB.B8F7CE80-- --===============0665842084== 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 --===============0665842084==-- From ips-bounces@ietf.org Thu Jun 08 09:55:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoKzD-0007OJ-UL; Thu, 08 Jun 2006 09:55:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoKzC-0007Lt-Mv for ips@ietf.org; Thu, 08 Jun 2006 09:55:46 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoKzB-0006rk-9O for ips@ietf.org; Thu, 08 Jun 2006 09:55:46 -0400 Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k58DtiKZ026361 for ; Thu, 8 Jun 2006 07:55:44 -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 <0J0J00D01NEZJK00@mail-amer.sun.com> (original mail from David.Weibel@Sun.COM) for ips@ietf.org; Thu, 08 Jun 2006 07:55:44 -0600 (MDT) Received: from [129.147.9.28] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J0J009PVO0WLTK0@mail-amer.sun.com>; Thu, 08 Jun 2006 07:55:44 -0600 (MDT) Date: Thu, 08 Jun 2006 07:55:43 -0600 From: David Weibel Subject: Re: [Ips] TargetAddress during FFP In-reply-to: <000d01c68aed$40e4da60$06031eac@ivivity.com> To: Eddy Quicksall Message-id: <44882C5F.1040901@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 References: <368FBF3D8437A748BA8222526BF9309975CECB@aime2k302.adaptec.com> <000d01c68aed$40e4da60$06031eac@ivivity.com> User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050322) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ips@ietf.org, "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 TargetAddress is typically received during a FullFeature Login Response of 01/01 (Requested ITN has moved temporarily) or 01/02 (Requested ITN has moved permanently). I am curious what the intended behavior outside of those two use cases is for TargetAddress. Currently, I do record it for the next reconnect but don't use it as an immediate redirection like the 01/01 and 01/02 describe. I have never encountered a Target that does the later case. I have seen targets doing both the 01/01 and 01/02. Eddy Quicksall wrote: > What should the initiator do if it receives a > TargetAddress=
during Full Feature Phase? > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Jun 08 19:48:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoUEH-0004Uz-Qd; Thu, 08 Jun 2006 19:47:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoUEF-0004UX-Su for ips@ietf.org; Thu, 08 Jun 2006 19:47:55 -0400 Received: from gate02out.mcdata.com ([208.47.132.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoUED-00089j-Pu for ips@ietf.org; Thu, 08 Jun 2006 19:47:55 -0400 Received: from MC4GATE02.mcdata.com ([172.16.11.207]) by GATE02out.mcdata.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jun 2006 17:47:53 -0600 Received: from MC4EXCH01.mcdata.com ([172.16.11.123]) by MC4GATE02.mcdata.com with InterScan Message Security Suite; Thu, 08 Jun 2006 17:47:52 -0600 Received: from SCEXCH01.mcdata.com ([172.19.161.171]) by MC4EXCH01.mcdata.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jun 2006 17:47:51 -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 Date: Thu, 8 Jun 2006 16:47:49 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MIB Doctor review (part-2) for: draft-ietf-ips-isns-mib-09.txt Thread-Index: AcaKS5AmRW3hTxYWTtqzQdr1F1G1dABCjGHw From: "Kevin Gibbons" To: "Wijnen, Bert \(Bert\)" , "David Black \(E-mail\)" , "Scott Kipp" , X-OriginalArrivalTime: 08 Jun 2006 23:47:51.0468 (UTC) FILETIME=[F45A56C0:01C68B55] X-imss-version: 2.040 X-imss-result: Passed X-imss-scanInfo: M:P L:E SM:0 X-imss-tmaseResult: TT:0 TS:0.0000 TC:00 TRN:0 TV:3.52.1006(14496.001) X-imss-scores: Clean:99.90000 C:2 M:4 S:5 R:5 X-imss-settings: Baseline:3 C:2 M:2 S:2 R:2 (0.5000 0.5000) X-Spam-Score: 0.0 (/) X-Scan-Signature: 052f5f7988f6d35f983a2680181d544b Cc: "Dan Romascanu \(E-mail\)" , ips@ietf.org Subject: [Ips] RE: MIB Doctor review (part-2) 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 Bert, Thanks for the feedback. GD Ramkumar has been working on the first part of your review. It is also taking us time to work through the feedback. Having it in two phases has helped. Thanks again, Kevin -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=0D Sent: Wednesday, June 07, 2006 8:59 AM To: Kevin Gibbons; 'David Black (E-mail)'; Scott Kipp; 'gramkumar@gmail.com' Cc: 'ips@ietf.org'; Dan Romascanu (E-mail) Subject: RE: MIB Doctor review (part-2) for: draft-ietf-ips-isns-mib-09.txt [copied Dan Romascanu; not sure if he is on IPS mlist] Sorry it took a while. My excuse is that the MIB module alone is over 3000 lines long, not small. I am also not an IPS=0D expert, so I did have to go and check 4171 many times.=0D I am still not able to fit the whole picture of tables with all their aspects in my head. May I assume that the subject=0D matter experts have done that or will do so? part-1 is appended at the bottom, so people have it all in one email if such is easier. - My last point in part 1 was: > - 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. that Description clause states as a last point: If SNMP is not allowed to view or modify the list of control nodes, then this managed object SHALL be set to noSnmpAccess." so does that mean that if the value is noSnmpAccess that there then are no entries to be shown in the isnsCntlNodeIscsiTable? The description clause of isnsCntlNodeIscsiTable says so. So it would be good to repeat that here in the DESCRIPTION clause of isnsSrvrInstCntrlNodeAuth as well (I think). Maybe it should also state that isnsCntlNodeFcPortTable is empty in that case. By the way, it might be good to also explain that SnmpAccess is read-only (although that shouldbe clear seeing that the two tables are both read only. - When I looked at IsnsDdDdsModificationBitmap again, I was somewhat surprised by bit field zero: instance. Although this MIB does not allow modification of DD's and DDS's, SNMP may be used to modify them via another MIB. 0 SNMP protocol is allowed to modify DD's/DDS's This MIB module is read-only as you say. SOme other MIB module may allow changes. Mmm... is it then logical to express in this MIB module if such can be possibly be done somewhere else? Is=0D that somewhere else on the same system as where this MIB module=0D is instantiated? If not, how easy is it to represent that here (if at all possible)?? Further, I see that everytime this TC is used as a SYNTAX, the same sort of DESCRIPTION clause gets repeated. The idea of a TC is to describe the semantics ONCE and not to repeat that many times (with the risk of creating inconsistencies or conflicts or ambiguity). So for example, I would limit the DESCRIPTION clause in isnsSrvrInstUpdateDdDdsSpprtd as follows: isnsSrvrInstUpdateDdDdsSpprtd OBJECT-TYPE SYNTAX IsnsDdDdsModificationBitmap MAX-ACCESS read-only STATUS current DESCRIPTION "The methods that this iSNS Server instance supports to modify Discovery Domains and Discovery Domain Sets." REFERENCE "RFC 4171, Section 3.4" ::=3D { isnsSrvrInstEntry 17 } If you agree, pls look at other uses of ths (and other) TCs as well. - isnsNumObjTable OBJECT-TYPE SYNTAX SEQUENCE OF IsnsNumObjEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table providing the number of registered objects of each type in the iSNS Server instance. This table is optional to implement. The number of entries is dependent upon the number of iSNS Server instances being managed." ::=3D { isnsSrvrInfo 2 } The fact that this table is "optional" should not be stated here in the DESCRIPTION clause. Nether should in the DESCRIPTION clause of isnsServerNumObjGroup OBJECT-GROUP be stated that: associated with a registered Entity. These managed objects are optional to implement." The fact if objects are optional should be expressed by properly grouping them (which I think has been done) in an OBJECT-GROUP and then make that OBJECT-GROUP and optional group in the MODULE-COMPLIANCE. The latter has not been done, because: isnsIscsiServerCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Initial compliance statement for an iSNS Server providing support to iSCSI clients." MODULE -- this module MANDATORY-GROUPS { isnsServerAttributesGroup, isnsServerIscsiCntlNodeGroup, isnsServerIscsiDdsDdObjGroup, isnsServerRegIscsiObjGroup, isnsServerNumObjGroup, isnsNotificationsObjGroup, isnsServerNotificationGroup } ::=3D { isnsCompliances 1 } shows that those claims in the DESCRIPTION clauses are INCORRECT. The above MODULE-COMPLIACNE shows this group as a MANDATORY-GROUP. In fact in the 2nd MODULE-COMPLIANCE, the group is also listed as MANDATORY. So it seems it is always mandatory according to the currently know MODULE-COMPLIANCE statements. Pls remove also the "optional" language in isnsRegEntityNumObjTable - I wonder if the following would be better represented by a SYNTAX of Gauge32: IsnsNumObjEntry ::=3D SEQUENCE { isnsNumDds Unsigned32, isnsNumDd Unsigned32, isnsNumEntities Unsigned32, isnsNumPortals Unsigned32, isnsNumPortalGroups Unsigned32, isnsNumIscsiNodes Unsigned32, isnsNumFcPorts Unsigned32, isnsNumFcNodes Unsigned32 } There are probably other objects that are better represented as a Gauge32=0D as well. I can live with Unsigned32 though. =0D Question for my understanding: Are these counters intended to help determine the max-repetitions for a getbulk? same for objects in isnsRegEntityNumObjTable - isnsCntlNodeFcPortName OBJECT-TYPE SYNTAX FcNameIdOrZero MAX-ACCESS not-accessible STATUS current DESCRIPTION "The FC Port WWN that can and/or is acting as a control node for the specified iSNS Server. Zero is not a valid value for this managed object. This managed object, combined with the isnsSrvrInstIndex, is the key for this table." ::=3D { isnsCntlNodeFcPortEntry 1 } I think it is better to s/Zero/A zero length string/ - In addition to my earlier comment on IsnsDdsStatusId ::=3D TEXTUAL-CONVENTION As far as I see, it is only used once. So that begs the question why it is a TC.=0D But even so, in the case where it is used in this MIB module: isnsDdsStatus OBJECT-TYPE SYNTAX IsnsDdsStatusId MAX-ACCESS read-only 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. If set to false then the DDS is disabled." REFERENCE "RFC 4171, Section 6" DEFVAL { { enabled } } ::=3D { isnsDdsEntry 3 } It seems to me that it would be more appropriate to rename the isnsDdsStatus objct to isnsDdsEnabled and *re-(use the TruthValue TC from RFC2579. - naming consistency: IsnsDdIscsiMemberEntry::=3D SEQUENCE { isnsDdMemberIscsiIdx IsnsNodeIndexId, isnsDdMemberIscsiName SnmpAdminString, isnsDdMemberIsRegistered TruthValue } why are they not named: IsnsDdIscsiMemberEntry::=3D SEQUENCE { isnsDdIscsiMemberIdx IsnsNodeIndexId, isnsDdIscsiMemberName SnmpAdminString, isnsDdIscsiMemberIsRegistered TruthValue } I would myself also rename isnsDdIscsiMemberIdx to isnsDdIscsiMemberIndex - naming consistency IsnsDdPortalMemberEntry ::=3D SEQUENCE { isnsDdMemberPortalIdx IsnsPortalIndexId, isnsDdMemberPortalAddrType InetAddressType, isnsDdMemberPortalAddr InetAddress, isnsDdMemberPortalPortType IsnsPortalPortTypeId, isnsDdMemberPortalPort InetPortNumber, isnsDdMemberPortalIsRegistered TruthValue } I would start all names with isnsDPortalMember. - isnsDdMemberPortalAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The Inet Address for the portal." =0D According to RFC4001, you MUST specify which object of SYNTAX=0D InetAddressType specifies/controls the format of an InetAddress object. I guess it is clear that isnsDdMemberPortalAddrType is that object. But pls make that statement in description clause. Is dns a valid type or does it need to be supported?=0D If not, may wnt to express that in MODULE-COMPLIANCE. If yes, may want to say somethingas to when that dns name is=0D resolved (as required per rfc4001)? Maybe it is never a dns name (if I understand that it is max 16 octets as per sect 6 of rfc4171) Maybe it is only IPv4 and/or IPv6? You could add that to the SYNTAX of the InetAddressType object if it will never be different. same for: isnsRegEntityMgtAddr and maybe others? pls check. - isnsDdMemberPortalPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-only STATUS current DESCRIPTION "The port number for the portal. Whether the portal type is TCP or UDP is indicated by isnsDdPortalPortType." Is a port number of zero valid? And if so, then what does it mean? If not, then maybe use SYNTAX InetPortNumber (1..65535) same for: isnsRegPortalPort maybe others? pls check - naming consitency IsnsDdFcPortMemberEntry ::=3D SEQUENCE { isnsDdMemberFcPortName FcNameIdOrZero, isnsDdMemberFcIsRegistered TruthValue } I would start the names with isnsDdFcPort.. - isnsDdMemberFcPortName and isnsDdId are the key for this table. Zero is not a valid value for this managed object." I guess you mean: a Zero length string is not a valie value? This issue is in several (if not all) object DESCRIPTIONs of objects with SYNTAX FcNameIdOrZero. - isnsRegEntityVersionMin OBJECT-TYPE SYNTAX Unsigned32 ( 0 .. 65535 ) MAX-ACCESS read-only STATUS current DESCRIPTION "The iSNS Entity Protocol Version Range minimum value. A value of x'FF' is a wildcard value indicating no minimum to the protocol versions supported by this Entity. Entity registrations with isnsRegEntityProtocol set to No Protocol always have a minimum version of 0." are you sure you mean a value of x'FF'?? That is value 255 in decimal, maybe you mean that you want to use x'FFFF' which is the value 65535? In that case, I think I would express it as: SYNTAX Unsigned32 ( 0 .. 65534 | 65535 ) and use the value 65535 in de DESCRIPTION clause instead of some hex representation. same for: isnsRegEntityVersionMax - isnsRegEntityRegPeriod Pls add a UNITS clause: UNITS "seconds" - isnsRegPortalEsiInterval Pls add UNITS clause. here the DESCRIPTION clause does not even say in what units this is measured. - isnsRegFcPortType OBJECT-TYPE SYNTAX Unsigned32 ( 0 .. 65535 ) MAX-ACCESS read-only STATUS current DESCRIPTION "The FC Port Port Type as defined in the iSNS Specification, RFC 4171, and the Fibre Channel Generic Services Specification. Current values are as shown below: unknown (0), nPort (1), nlPort (2), fNlPort (3), fPort (129), -- x'81' flPort (130), -- x'82' ePort (132), -- x'84' bPort (133), -- x'85' mFcpPort (65297), -- x'FF11' iFcpPort (65298), -- x'FF12' unknownEnd (65535) ." Would this not be better an ENUM. I understand you would want to break the rule/guidline to start at 1 and to be consecutive. But an ENUM seems so much nicer, no? - isnsRegFcPortFc4Types OBJECT-TYPE SYNTAX OCTET STRING (SIZE (32)) MAX-ACCESS read-only STATUS current DESCRIPTION "The FC Port FC-4 Types as defined in the iSNS Specification, RFC 4171." REFERENCE "RFC 4171, Section 6" ::=3D { isnsRegFcPortEntry 10 } The size seems to allow for 8 types? Is that correct? How do I know? I do not find an explanation in sect 6 of 4171 for that either. - isnsRegFcPortFc4Descr OBJECT-TYPE SYNTAX OCTET STRING(SIZE(0..255)) MAX-ACCESS read-only accoding to RFC4171, sect 6: FC-4 Descriptor 4-256 so how does a 256-size value fit into 255-size string? should minumum size be 4 octets? So I would expect a SYNTAX of:=0D SYNTAX OCTET STRING(SIZE(4..256)) and RFC4171 sect 6.6.10 speaks about it being a NULL terminated UTF-8 string, so maybe the best SYNTAX would be SYNTAX SnmpAdminString (SIZE(4..255)) and then add in DESCRIPTION clause that the termninating NULL is not included in the object (as you have done for some other UTF-8 based objects). - for: isnsInstInfo OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..80)) MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Textual information about the iSNS Server notification. An example is: iSNS Server Started, information that would be included in the appropriate notification." ::=3D { isnsNotificationsInfo 1 } It is nice that it is SnmpAdminString (i.e. UTF-8) so that you can represent international human readable text. But in some scripts,=0D one character can occupy up to 5 or 6 octets. So a max size of 80 allows for some 15 or so characters. Why do we want to limit this size to 80? Why can we not allow up to 255 (the max size of an SnmpAdminString) ??? more nits/typos etc. - IsnsScnBitmapId ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "The State Change Notification (SCN) bitmap for a node as defined in the iSNS Specification, RFC 4171. A set bit (1) indicates the type of SCN for the bitmap as follows: Bit Field Flag Description --------- ---------------- 0 INITIATOR AND SELF INFORMATION ONLY 1 TARGET AND SELF INFORMATION ONLY 2 MANAGEMENT REGISTRATION/SCN 3 REGISTERED OBJECT REMOVED 4 REGISTERED OBJECT ADDED 5 REGISTERED OBJECT UPDATED 6 DD/DDS MEMBER REMOVED (MGT REG/SCN ONLY) 7 DD/DDS MEMBER ADDED (MGT REG/SCN ONLY) "=0D Why are you using all the UPPER CASE TEXT ?? Makes me go back in time to IBM Mainframe MVS and JCL times. - I really wonder why isnsCntlNodeIscsiNodeIdx is not named isnsCntlNodeIscsiNodeIndex. It adds 2 characters to the descriptor, but gives the name so much more meaning. Maybe it is just me. - in DESCRIPTION clause of: isnsCntlNodeIscsiNodeName the storage node. The iSCSI Name can not be longer then should be "can not be longer than: ?? - I do not understand why isnsAddrTypeNotifctn, isnsAddrNotifctn, isnsTcpPortNotifctn, isnsUdpPortNotifctn are not named isnsAddrTypeNotification, isnsAddrNotification, isnsTcpPortNotification, isnsUdpPortNotificationn in other words I can not see the tradeoff between a clear descriptor and a shorter descriptor here. For me the longer name would win. So is there an explanation why you use the shorter descriptor names? This theme of unexplanatory/not-understandable abbreviations for=0D descriptor names or label names occurs many times. I will not continue to list them. I suggest that the editors and WG take a serious look at this and use clearer names whereever possible. - isnsDdsSymbolicName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..255)) The SnmpAdminString has exactly the same range, so it is superfluous to repeat it here. So I would do: isnsDdsSymbolicName OBJECT-TYPE SYNTAX SnmpAdminString - same for isnsDdsMemberSymName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..255)) and isnsRegEntityEID OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..255)) and maybe others. Pls check. Bert > -----Original Message----- > From: Wijnen, Bert (Bert) > Sent: Wednesday, May 10, 2006 23:17 > To: Kevin Gibbons; David Black (E-mail); Scott Kipp;=0D > gramkumar@gmail.com > Cc: ips@ietf.org > Subject: MIB Doctor review (part-1) for:=0D > draft-ietf-ips-isns-mib-09.txt >=0D >=0D > Dan asked for a volunteer for MIB doctor review, and > I offered to do so. Here is my review part-1: >=0D > - Syntax checking > SMICng tells me: > W: f(isns.mi2), (2626,19) Row "isnsRegFcNodePortEntry" does not=0D > have a consistent indexing scheme - cannot specify an index > item from additional "base row" isnsRegFcNodeEntry, since=0D > can have only one "base row" which is isnsRegFcPortEntry > W: f(isns.mi2), (294,7) Textual convention "IsnsNodeIndexIdOrZero" > defined but not used >=0D > Both are probably OK as long as you are sure that this is what you=0D > intend for the first warning. For the second warning one could wonder=0D > wht the TC was defined if it is not (yet?) used. Maybe another MIB=0D > module is using it? >=0D > - smilint has no complaints. >=0D > - I am somehwat confused by: > IsnsEntityProtocolId ::=3D TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "The type of protocol that is supported by this entity. >=0D > 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=0D > would not be better > to move this to an IANA maintained MIB module that is kept=0D > in sync with the > registry that IANA already must maintain, i.e. the registry at > http://www.iana.org/assignments/isns-parameters ? >=0D > - I also get confused by: > IsnsPortalGroupTagIdOrZero ::=3D 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. >=0D > - When I see IsnsPortalSecurityBitmapId ::=3D TEXTUAL-CONVENTION > Then I first wonde if this is an "Id" (Identifier?) of if the name > would better be > IsnsPortalSecurityBitmap ::=3D 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 ?? >=0D > - 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: >=0D > "This textual convention is an extension of the > IsnsNodeIndexId > textual convention. The latter defines a greater than zero=0D > value used to identify an IsnsNode. This extension=0D > 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." >=0D > - 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. >=0D > - IsnsCosBitmapId is it an Id (Indetifier?)? > Same question on mapping bits >=0D > - Same for IsnsScnBitmapId >=0D > - Same for: IsnsSrvrDscvryMthdId > Seems like a map of (supported?) methods as opposed to an ID. >=0D > - 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" > ::=3D { isnsSrvrInstEntry 5 } > =0D > 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"? >=0D > - 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.=0D > 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=0D > something else? >=0D > - isnsSrvrInstDiscMcGrp > Whever you define an object with SYNTAX of InetAddress, > then (according > to the DESCRIPTION clasue of InetAddress in RFC4001), you=0D > MUST state=0D > 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.=0D > 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=0D > object then > better be the "zero length string" as opposed to "empty". What does > "empty" mean? >=0D > I would personally rename isnsSrvrInstDiscMcGrp to > isnsSrvrInstDiscMcGrpAddress >=0D > - W.r.t. isnsSrvrInstDiscMcGrpType and isnsSrvrInstDiscMcGrp, I think=0D > one could say some more about the allowed InetAddressTypes > (if not in the > DESCRIPTION clauses of these objects themselves, then at least in a=0D > OBJECT clause in the MODULE-COMPLIANCE statements.=0D > If I understand things correctly, it has to be an IP=0D > 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). >=0D > - isnsSrvrInstEsiNonRespThrshld, isnsSrvrInstEnblCntrlNdeMgtScn and=0D > 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 ?? >=0D > - I can't say that I find the DESCRIPTION clause for > isnsSrvrInstCntrlNodeAuth > very well written. I still need to review the other tables=0D > it is pointing > to, so I can't say much more yet. >=0D > nits/typos/consistency/questions: >=0D > - I wonder why IsnsDdsStatusId ::=3D TEXTUAL-CONVENTION > is not just named IsnsDdsStatus ::=3D TEXTUAL-CONVENTION > I.e. I do nto see why it is an Id (Identifier?)?? > Further, IsnsDdsStatusId ::=3D TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "The bitmap indicating the status of a Discovery Domain > Set (DDS) registered in the iSNS. > Bit Status > --------- --------- > 0 enabled >=0D > 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 >=0D > - For consistency, I would rename DdFeatureBitmapId ::=3D=0D > TEXTUAL-CONVENTION > to IsnsDdFeatureBitmapId=0D > ::=3D TEXTUAL-CONVENTION > or even better: IsnsDdFeatureBitmap =0D > ::=3D TEXTUAL-CONVENTION > again, I do not see how this is an Id (Identifier?)?? >=0D > - isnsSrvrInstEsiNonRespThrshld ... is this an Id > (Indetifier?) or is it a threshold. > From the descritpion clause it seems it is the latter. So I=0D > would rename to > isnsSrvrInstEsiNonRespThrsh=0D > 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=0D > (readers) are not all Americans > or native English speakers. In fact this whole doc uses=0D > (for my taste) far to > much (strange) abbreviations for object descriptors and=0D > labels. But who is me. >=0D > - 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. >=0D > admin/bureaucracy: >=0D > - You may want to check the occurences of "MIB", which in > many cases woul be > better stated as "MIB module". >=0D > - references/citations: > !! Contains embedded space: > P001 L134: network [RFC 4171]. It has the capability=0D > to group devices into >=0D > !! Contains embedded space: > P001 L264: Specification [RFC 4171], a DDS can be=0D > enabled or disabled, >=0D > !! Contains embedded space: > P001 L307: As described in iSCSI [RFC 3347], Portal=0D > Groups provide a >=0D > The first two are indeed just what it says, namely a blank > in between > RFC and the actual number. In the references section, you=0D > list it as [RFC4171] > without a space. >=0D > The 3rd does have an embadded space too, but also, that RFC does not > show up in the references section. >=0D SPECIAL NOTICE=0D All information transmitted hereby is intended only for the use of the addressee(s) named above and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of confidential and privileged information is prohibited. If the reader of this message is not the intended recipient(s) or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that you must not read this transmission and that= disclosure, copying, printing, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. Anyone who receives confidential and privileged information in error should notify us immediately by telephone and mail the original message to us at the above address and destroy all copies. To the extent any portion of= this communication contains public information, no such restrictions apply to= that information. (gate02) _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Jun 09 11:52:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FojHb-0007Kj-2X; Fri, 09 Jun 2006 11:52:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FobGo-0002Kg-89 for ips@ietf.org; Fri, 09 Jun 2006 03:19:02 -0400 Received: from nz-out-0102.google.com ([64.233.162.192]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FobGm-0003DJ-AJ for ips@ietf.org; Fri, 09 Jun 2006 03:19:02 -0400 Received: by nz-out-0102.google.com with SMTP id o1so574281nzf for ; Fri, 09 Jun 2006 00:18:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=oB+sPUrRV6euotrOgN2Bit49FmqK86HUeRAkD8LowXTfEWd4fcKXAP8VI3nbbAtKWlfFwhP0BTZask7nFpZukEpOgBbUcHmXpL6pOv8v/+cA6vKvq7SbL5BkFHKc/EkMXB4j0PtfRrbmaf2WmX4uCDMuQYXjBEgf98GA+JN0Nmw= Received: by 10.36.118.11 with SMTP id q11mr3560179nzc; Fri, 09 Jun 2006 00:18:59 -0700 (PDT) Received: by 10.36.126.12 with HTTP; Fri, 9 Jun 2006 00:18:59 -0700 (PDT) Message-ID: <2c36e16e0606090018s49dbad14m11603fc4489cc4b7@mail.gmail.com> Date: Fri, 9 Jun 2006 00:18:59 -0700 From: "G.D. Ramkumar" To: "Kevin Gibbons" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 47d6e33caab9a47557c20591160ac87c X-Mailman-Approved-At: Fri, 09 Jun 2006 11:52:22 -0400 Cc: "Wijnen, Bert \(Bert\)" , ips@ietf.org, "Dan Romascanu \(E-mail\)" , "David Black \(E-mail\)" , Scott Kipp Subject: [Ips] Re: MIB Doctor review (part-2) for: draft-ietf-ips-isns-mib-09.txt X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gramkumar@stanfordalumni.org List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org I am done with one round of changes based on the first part of the review, and will distribute among authors for a review. Regards, Ram On 6/8/06, Kevin Gibbons wrote: > > Bert, > > Thanks for the feedback. GD Ramkumar has been working on the first part > of your review. It is also taking us time to work through the feedback. > Having it in two phases has helped. > > Thanks again, Kevin > > > > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Wednesday, June 07, 2006 8:59 AM > To: Kevin Gibbons; 'David Black (E-mail)'; Scott Kipp; > 'gramkumar@gmail.com' > Cc: 'ips@ietf.org'; Dan Romascanu (E-mail) > Subject: RE: MIB Doctor review (part-2) for: > draft-ietf-ips-isns-mib-09.txt > > > [copied Dan Romascanu; not sure if he is on IPS mlist] > > Sorry it took a while. My excuse is that the MIB module alone is over > 3000 lines long, not small. I am also not an IPS > expert, so I did have to go and check 4171 many times. > I am still not able to fit the whole picture of tables with > all their aspects in my head. May I assume that the subject > matter experts have done that or will do so? > > part-1 is appended at the bottom, so people have it all in one email if > such is easier. > > - My last point in part 1 was: > > - 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. > > that Description clause states as a last point: > If SNMP is not allowed to view or modify the list of control > nodes, then this managed object SHALL be set to > noSnmpAccess." > so does that mean that if the value is noSnmpAccess that there > then are no entries to be shown in the isnsCntlNodeIscsiTable? > The description clause of isnsCntlNodeIscsiTable says so. > So it would be good to repeat that here in the DESCRIPTION > clause of isnsSrvrInstCntrlNodeAuth as well (I think). > Maybe it should also state that isnsCntlNodeFcPortTable > is empty in that case. > By the way, it might be good to also explain that SnmpAccess > is read-only (although that shouldbe clear seeing that the > two tables are both read only. > > - When I looked at IsnsDdDdsModificationBitmap again, I was > somewhat surprised by bit field zero: > instance. Although this MIB does not allow modification > of DD's and DDS's, SNMP may be used to modify them via > another MIB. > 0 SNMP protocol is allowed to modify > DD's/DDS's > This MIB module is read-only as you say. SOme other MIB module > may allow changes. Mmm... is it then logical to express in this > MIB module if such can be possibly be done somewhere else? Is > that somewhere else on the same system as where this MIB module > is instantiated? If not, how easy is it to represent that here > (if at all possible)?? > > Further, I see that everytime this TC is used as a SYNTAX, the > same sort of DESCRIPTION clause gets repeated. The idea of a TC > is to describe the semantics ONCE and not to repeat that many > times (with the risk of creating inconsistencies or conflicts > or ambiguity). So for example, I would limit the DESCRIPTION > clause in isnsSrvrInstUpdateDdDdsSpprtd as follows: > > isnsSrvrInstUpdateDdDdsSpprtd OBJECT-TYPE > SYNTAX IsnsDdDdsModificationBitmap > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The methods that this iSNS Server instance supports > to modify Discovery Domains and Discovery Domain Sets." > REFERENCE "RFC 4171, Section 3.4" > ::= { isnsSrvrInstEntry 17 } > > If you agree, pls look at other uses of ths (and other) TCs as well. > > - isnsNumObjTable OBJECT-TYPE > SYNTAX SEQUENCE OF > IsnsNumObjEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Table providing the number of registered objects of each > type in the iSNS Server instance. This table is optional > to implement. The number of entries is dependent upon the > number of iSNS Server instances being managed." > ::= { isnsSrvrInfo 2 } > > The fact that this table is "optional" should not be stated here > in the DESCRIPTION clause. Nether should in the DESCRIPTION clause > of isnsServerNumObjGroup OBJECT-GROUP > be stated that: > associated with a registered Entity. These managed objects > are optional to implement." > The fact if objects are optional should be expressed by properly > grouping them (which I think has been done) in an OBJECT-GROUP and > then make that OBJECT-GROUP and optional group in the > MODULE-COMPLIANCE. > The latter has not been done, because: > isnsIscsiServerCompliance MODULE-COMPLIANCE > STATUS current > DESCRIPTION > "Initial compliance statement for an iSNS Server > providing support to iSCSI clients." > MODULE -- this module > MANDATORY-GROUPS { > isnsServerAttributesGroup, > isnsServerIscsiCntlNodeGroup, > isnsServerIscsiDdsDdObjGroup, > isnsServerRegIscsiObjGroup, > isnsServerNumObjGroup, > isnsNotificationsObjGroup, > isnsServerNotificationGroup > } > ::= { isnsCompliances 1 } > shows that those claims in the DESCRIPTION clauses are INCORRECT. > The above MODULE-COMPLIACNE shows this group as a MANDATORY-GROUP. > In fact in the 2nd MODULE-COMPLIANCE, the group is also listed as > MANDATORY. So it seems it is always mandatory according to the > currently know MODULE-COMPLIANCE statements. > > Pls remove also the "optional" language in isnsRegEntityNumObjTable > > - I wonder if the following would be better represented by a SYNTAX > of Gauge32: > IsnsNumObjEntry ::= SEQUENCE { > isnsNumDds Unsigned32, > isnsNumDd Unsigned32, > isnsNumEntities Unsigned32, > isnsNumPortals Unsigned32, > isnsNumPortalGroups Unsigned32, > isnsNumIscsiNodes Unsigned32, > isnsNumFcPorts Unsigned32, > isnsNumFcNodes Unsigned32 > } > There are probably other objects that are better represented as a > Gauge32 > as well. I can live with Unsigned32 though. > > Question for my understanding: Are these counters intended to help > determine > the max-repetitions for a getbulk? > > same for objects in isnsRegEntityNumObjTable > > - isnsCntlNodeFcPortName OBJECT-TYPE > SYNTAX FcNameIdOrZero > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The FC Port WWN that can and/or is acting as a control > node for the specified iSNS Server. Zero is not a valid > value for this managed object. This managed object, > combined with the isnsSrvrInstIndex, is the key for this > table." > ::= { isnsCntlNodeFcPortEntry 1 } > > I think it is better to s/Zero/A zero length string/ > > - In addition to my earlier comment on > IsnsDdsStatusId ::= TEXTUAL-CONVENTION > As far as I see, it is only used once. So that begs the question > why it is a TC. > But even so, in the case where it is used in this MIB module: > isnsDdsStatus OBJECT-TYPE > SYNTAX IsnsDdsStatusId > MAX-ACCESS read-only > 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. If set > to false then the DDS is disabled." > REFERENCE "RFC 4171, Section 6" > DEFVAL { { enabled } } > ::= { isnsDdsEntry 3 } > > It seems to me that it would be more appropriate to rename the > isnsDdsStatus objct to isnsDdsEnabled and *re-(use the TruthValue > TC from RFC2579. > > - naming consistency: > IsnsDdIscsiMemberEntry::= > SEQUENCE { > isnsDdMemberIscsiIdx IsnsNodeIndexId, > isnsDdMemberIscsiName SnmpAdminString, > isnsDdMemberIsRegistered TruthValue > } > why are they not named: > IsnsDdIscsiMemberEntry::= > SEQUENCE { > isnsDdIscsiMemberIdx IsnsNodeIndexId, > isnsDdIscsiMemberName SnmpAdminString, > isnsDdIscsiMemberIsRegistered TruthValue > } > > I would myself also rename isnsDdIscsiMemberIdx to > isnsDdIscsiMemberIndex > > - naming consistency > IsnsDdPortalMemberEntry ::= > SEQUENCE { > isnsDdMemberPortalIdx IsnsPortalIndexId, > isnsDdMemberPortalAddrType InetAddressType, > isnsDdMemberPortalAddr InetAddress, > isnsDdMemberPortalPortType IsnsPortalPortTypeId, > isnsDdMemberPortalPort InetPortNumber, > isnsDdMemberPortalIsRegistered TruthValue > } > I would start all names with isnsDPortalMember. > > - isnsDdMemberPortalAddr OBJECT-TYPE > SYNTAX InetAddress > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The Inet Address for the portal." > > According to RFC4001, you MUST specify which object of SYNTAX > InetAddressType specifies/controls the format of an InetAddress > object. I guess it is clear that isnsDdMemberPortalAddrType is > that object. But pls make that statement in description clause. > Is dns a valid type or does it need to be supported? > If not, may wnt to express that in MODULE-COMPLIANCE. > If yes, may want to say somethingas to when that dns name is > resolved (as required per rfc4001)? > Maybe it is never a dns name (if I understand that it is max 16 > octets > as per sect 6 of rfc4171) Maybe it is only IPv4 and/or IPv6? > You could add that to the SYNTAX of the InetAddressType object if > it will never be different. > > same for: isnsRegEntityMgtAddr > > and maybe others? pls check. > > - isnsDdMemberPortalPort OBJECT-TYPE > SYNTAX InetPortNumber > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The port number for the portal. Whether the portal > type is TCP or UDP is indicated by isnsDdPortalPortType." > > Is a port number of zero valid? And if so, then what does it mean? > If not, then maybe use > SYNTAX InetPortNumber (1..65535) > > same for: isnsRegPortalPort > > maybe others? pls check > > - naming consitency > IsnsDdFcPortMemberEntry ::= > SEQUENCE { > isnsDdMemberFcPortName FcNameIdOrZero, > isnsDdMemberFcIsRegistered TruthValue > } > I would start the names with isnsDdFcPort.. > > - isnsDdMemberFcPortName > and isnsDdId are the key for this table. Zero is not a > valid value for this managed object." > I guess you mean: a Zero length string is not a valie value? > > This issue is in several (if not all) object DESCRIPTIONs > of objects with SYNTAX FcNameIdOrZero. > > - isnsRegEntityVersionMin OBJECT-TYPE > SYNTAX Unsigned32 ( 0 .. 65535 ) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The iSNS Entity Protocol Version Range minimum value. A > value of x'FF' is a wildcard value indicating no minimum to > the protocol versions supported by this Entity. Entity > registrations with isnsRegEntityProtocol set to No Protocol > always have a minimum version of 0." > > are you sure you mean a value of x'FF'?? That is value 255 in decimal, > maybe you mean that you want to use x'FFFF' which is the value 65535? > In that case, I think I would express it as: > SYNTAX Unsigned32 ( 0 .. 65534 | 65535 ) > and use the value 65535 in de DESCRIPTION clause instead of some > hex representation. > > same for: isnsRegEntityVersionMax > > - isnsRegEntityRegPeriod > Pls add a UNITS clause: > UNITS "seconds" > > - isnsRegPortalEsiInterval > Pls add UNITS clause. here the DESCRIPTION clause does not even say > in what units this is measured. > > - isnsRegFcPortType OBJECT-TYPE > SYNTAX Unsigned32 ( 0 .. 65535 ) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The FC Port Port Type as defined in the iSNS Specification, > RFC 4171, and the Fibre Channel Generic Services > Specification. Current values are as shown below: > unknown (0), > nPort (1), > nlPort (2), > fNlPort (3), > fPort (129), -- x'81' > flPort (130), -- x'82' > ePort (132), -- x'84' > bPort (133), -- x'85' > mFcpPort (65297), -- x'FF11' > iFcpPort (65298), -- x'FF12' > unknownEnd (65535) > ." > > Would this not be better an ENUM. I understand you would want to > break the rule/guidline to start at 1 and to be consecutive. But > an ENUM seems so much nicer, no? > > - isnsRegFcPortFc4Types OBJECT-TYPE > SYNTAX OCTET STRING (SIZE (32)) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The FC Port FC-4 Types as defined in the iSNS > Specification, RFC 4171." > REFERENCE "RFC 4171, Section 6" > ::= { isnsRegFcPortEntry 10 } > > The size seems to allow for 8 types? > Is that correct? How do I know? I do not find an explanation in > sect 6 of 4171 for that either. > > - isnsRegFcPortFc4Descr OBJECT-TYPE > SYNTAX OCTET STRING(SIZE(0..255)) > MAX-ACCESS read-only > > accoding to RFC4171, sect 6: > FC-4 Descriptor 4-256 > > so how does a 256-size value fit into 255-size string? > should minumum size be 4 octets? > So I would expect a SYNTAX of: > SYNTAX OCTET STRING(SIZE(4..256)) > > and RFC4171 sect 6.6.10 speaks about it being a NULL terminated > UTF-8 string, so maybe the best SYNTAX would be > SYNTAX SnmpAdminString (SIZE(4..255)) > and then add in DESCRIPTION clause that the termninating NULL is > not included in the object (as you have done for some other UTF-8 > based objects). > > - for: > isnsInstInfo OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE (0..80)) > MAX-ACCESS accessible-for-notify > STATUS current > DESCRIPTION > "Textual information about the iSNS Server notification. > An example is: iSNS Server Started, information that > would be included in the appropriate notification." > ::= { isnsNotificationsInfo 1 } > > It is nice that it is SnmpAdminString (i.e. UTF-8) so that you can > represent international human readable text. But in some scripts, > one character can occupy up to 5 or 6 octets. So a max size of 80 > allows for some 15 or so characters. Why do we want to limit this > size to 80? Why can we not allow up to 255 (the max size of an > SnmpAdminString) ??? > > more nits/typos etc. > > - IsnsScnBitmapId ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "The State Change Notification (SCN) bitmap for a node as > defined in the iSNS Specification, RFC 4171. A set bit (1) > indicates the type of SCN for the bitmap as follows: > > Bit Field Flag Description > --------- ---------------- > 0 INITIATOR AND SELF INFORMATION ONLY > 1 TARGET AND SELF INFORMATION ONLY > 2 MANAGEMENT REGISTRATION/SCN > 3 REGISTERED OBJECT REMOVED > 4 REGISTERED OBJECT ADDED > 5 REGISTERED OBJECT UPDATED > 6 DD/DDS MEMBER REMOVED (MGT REG/SCN > ONLY) > 7 DD/DDS MEMBER ADDED (MGT REG/SCN > ONLY) > " > > Why are you using all the UPPER CASE TEXT ?? > Makes me go back in time to IBM Mainframe MVS and JCL times. > > - I really wonder why isnsCntlNodeIscsiNodeIdx is not named > isnsCntlNodeIscsiNodeIndex. It adds 2 characters to the descriptor, > but gives the name so much more meaning. > Maybe it is just me. > > - in DESCRIPTION clause of: isnsCntlNodeIscsiNodeName > the storage node. The iSCSI Name can not be longer then > should be "can not be longer than: ?? > > - I do not understand why > isnsAddrTypeNotifctn, > isnsAddrNotifctn, > isnsTcpPortNotifctn, > isnsUdpPortNotifctn > are not named > isnsAddrTypeNotification, > isnsAddrNotification, > isnsTcpPortNotification, > isnsUdpPortNotificationn > in other words I can not see the tradeoff between a clear descriptor > and > a shorter descriptor here. For me the longer name would win. So is > there > an explanation why you use the shorter descriptor names? > > This theme of unexplanatory/not-understandable abbreviations for > descriptor names or label names occurs many times. I will not continue > to > list them. I suggest that the editors and WG take a serious look at > this > and use clearer names whereever possible. > > - isnsDdsSymbolicName OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE (0..255)) > The SnmpAdminString has exactly the same range, so it is superfluous > to > repeat it here. So I would do: > isnsDdsSymbolicName OBJECT-TYPE > SYNTAX SnmpAdminString > > - same for > isnsDdsMemberSymName OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE (0..255)) > and > isnsRegEntityEID OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE (0..255)) > and maybe others. Pls check. > > > Bert > > -----Original Message----- > > From: Wijnen, Bert (Bert) > > Sent: Wednesday, May 10, 2006 23:17 > > To: Kevin Gibbons; David Black (E-mail); Scott Kipp; > > gramkumar@gmail.com > > Cc: ips@ietf.org > > Subject: MIB Doctor review (part-1) for: > > draft-ietf-ips-isns-mib-09.txt > > > > > > 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. > > > > SPECIAL NOTICE > > All information transmitted hereby is intended only for the use of the > addressee(s) named above and may contain confidential and privileged > information. Any unauthorized review, use, disclosure or distribution > of confidential and privileged information is prohibited. If the reader > of this message is not the intended recipient(s) or the employee or agent > responsible for delivering the message to the intended recipient, you are > hereby notified that you must not read this transmission and that disclosure, > copying, printing, distribution or use of any of the information contained > in or attached to this transmission is STRICTLY PROHIBITED. > > Anyone who receives confidential and privileged information in error should > notify us immediately by telephone and mail the original message to us at > the above address and destroy all copies. To the extent any portion of this > communication contains public information, no such restrictions apply to that > information. (gate02) > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From batshevapurcell@randomhouse.com Fri Jun 09 15:43:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FomtM-00054x-2Z for ips-archive@lists.ietf.org; Fri, 09 Jun 2006 15:43:36 -0400 Received: from [201.138.119.126] (helo=BABY) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FomtG-00020z-RO for ips-archive@lists.ietf.org; Fri, 09 Jun 2006 15:43:36 -0400 Message-Id: <007b01c68bf3$73a2ca00$7ec44961@taztqu> From: "penelope herman" To: "bryana barry" Subject: Refinnace your loan, seven-eyes Date: Fri, 09 Jun 2006 14:36:58 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007B_01C68BF3.73A2CA00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.4 (++++) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 This is a multi-part message in MIME format. ------=_NextPart_000_007B_01C68BF3.73A2CA00 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable How much are you paying for your Home? To much?=20 You have been pre-approved to fill out for a ref inance laon,=20 if you need some cash to spend ANY way you like, or simply wish=20 to LOWER your monthly payments by a third or more, etc. We skip the middle man to save hundreds with deals we have!=20 This offer is for you, we DONT CARE about your credit.=20 Apply online now for your instant quote. Stop over paying...=20 http://bodyst.org/d2/ velvet-leaved moon-loved cattle raising war drum triple-line radio proximity fuze twice-doubled well-hoofed sword cutlery weather gauge musette bag sole sewer pill slab friction washer Gitchi manito horse rough stone-dust ground jasmine sticky-eyed wire weaver teeth-grinding ear fungus money-mad staff vine battle place service clasp sun bear carpet opener brood bud thyme-flavored re-recollection ------=_NextPart_000_007B_01C68BF3.73A2CA00 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
How much are you paying for your Home? To much?
You have been pre-approved to fill out for a ref inance laon,
if you need some cash to spend ANY way you like, or simply wish
to LOWER your monthly payments by a third or more, etc.

We skip the middle man to save hundreds with deals we have!
This offer is for you, we DONT CARE about your credit.

Apply online now for your instant quote. Stop over paying...

http://bodyst.org/d2/

velvet-leaved moon-loved cattle raising war drum triple-line
radio proximity fuze twice-doubled
well-hoofed sword cutlery weather gauge musette bag sole sewer pill slab
friction washer Gitchi manito horse rough stone-dust ground jasmine
sticky-eyed wire weaver teeth-grinding
ear fungus money-mad staff vine
battle place service clasp sun bear carpet opener brood bud
thyme-flavored re-recollection
= ------=_NextPart_000_007B_01C68BF3.73A2CA00-- From ips-bounces@ietf.org Tue Jun 13 02:48:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq2h5-0005RB-WB; Tue, 13 Jun 2006 02:48:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq2h4-0005R6-LC for ips@ietf.org; Tue, 13 Jun 2006 02:48:06 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq2h3-0004jQ-DS for ips@ietf.org; Tue, 13 Jun 2006 02:48:06 -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 k5D6m2FI018522 for ; Tue, 13 Jun 2006 02:48:05 -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 k5D6luaw020170 for ; Tue, 13 Jun 2006 02:48:01 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Jun 2006 02:47:44 -0400 Message-ID: From: Black_David@emc.com To: ips@ietf.org Date: Tue, 13 Jun 2006 02:47:38 -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.4.0.264935, Antispam-Data: 2006.6.12.231432 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: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Ips] Preliminary Montreal meeting info 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 Final agenda will be published next Monday, June 19th. Here's the preliminary schedule for the ips meeting and other meetings in that timeslot. WEDNESDAY, July 12, 2006 1510-1610 Afternoon Session II Room 519A APP atompub Atom Publishing Format and Protocol WG Room 513C-F INT mipshop Mobility for IP: Performance, Signaling and Handoff Optimization WG Room 515 OPS grow Global Routing Operations WG Room 518AB RTG pim Protocol Independent Multicast WG Room 519B SEC isms Integrated Security Model for SNMP WG Room 513B TSV ips IP Storage WG Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Jun 16 08:37:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrDa2-00085y-Io; Fri, 16 Jun 2006 08:37:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrDa0-00085s-IX for ips@ietf.org; Fri, 16 Jun 2006 08:37:40 -0400 Received: from web33408.mail.mud.yahoo.com ([68.142.206.140]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FrDZy-0000nL-Ql for ips@ietf.org; Fri, 16 Jun 2006 08:37:40 -0400 Received: (qmail 29076 invoked by uid 60001); 16 Jun 2006 12:37: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=hkI+z6TFRLp63zZGvQ7OShRCXjrhI6GIrxoe6+EEW9G2hor1NcsxBGAoGfnP7oPt2SYi+x55lX5iFkqYTkCjH02tlQZUrjwNQh9mIVes7gnGvfiWxVwgMXS4nwhfKPzyKrml+hDRJqmQA9DYE/gLwYhxbuFyLb3Uud2aY38CVTo= ; Message-ID: <20060616123738.29074.qmail@web33408.mail.mud.yahoo.com> Received: from [61.12.16.146] by web33408.mail.mud.yahoo.com via HTTP; Fri, 16 Jun 2006 05:37:38 PDT Date: Fri, 16 Jun 2006 05:37:38 -0700 (PDT) From: Praveen Madhavan To: ips@ietf.org In-Reply-To: MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Subject: [Ips] Reg: Bidirectional command format ? 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="===============2113582769==" Errors-To: ips-bounces@ietf.org --===============2113582769== Content-Type: multipart/alternative; boundary="0-876837187-1150461458=:29011" Content-Transfer-Encoding: 8bit --0-876837187-1150461458=:29011 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Folks, Can any one point me the frame format of bidirectional command in case of iSCSI & FCP ?.. I was trying to route bidirectional command recv'd from iSCSI initiator to FC Target.. Here is the iSCSI PDU format for bi-direct command recv from initiator ------------------------------------------------------------------------------------------------ | BHS(48bytes) | | R & W bit set to ONE, | | Expected xfer len = 0x200 | | Total AHS Length = 2(8bytes) | | SCSI CDB = Write(10) Transfer length = 00 01 ( 512 bytes) | ------------------------------------------------------------------------------------------------| | AHS ( 8 bytes) | | Expected Read data length = 0x200(512 bytes) | -------------------------------------------------------------------------------------------------- Here is the FCP format for bi-direct command that i frame for sending it to target. ------------------------------------------------------------------------------------------------ | FC-Header (24bytes) | |------------------------------------------------------------------------------------------------ | FCP-Header(36 bytes) | | R & W bit set to ONE, | | Additional CDB length = 0 | | SCSI CDB = Write(10) Transfer length = 00 01 ( 512 bytes) | | FCP_DL = 0x200 ( 512 bytes) | | FCP_BIDIRECTIONAL_READ_DL = 0x200(512) | -------------------------------------------------------------------------------------------------| Well, I am not quite sure about the CDB values in case Bidir commands.. Will Bi directional cmds use Write CDB(10) or Read CDB (10) ? .. How can i control following bidi- operation in case of iSCSI & FCP ? 1.bidirectional command with read before write operation 2.bidirectional command with write before read operation -Praveen --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. --0-876837187-1150461458=:29011 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Folks,

Can any one point me the frame format of bidirectional command in case of iSCSI & FCP ?.. I was trying to route bidirectional command recv'd from iSCSI initiator to FC Target..

Here is the iSCSI PDU format for bi-direct command recv from initiator
------------------------------------------------------------------------------------------------
|        BHS(48bytes)                                                                    |
|        R & W bit set to ONE,                                                        |
|        Expected xfer len = 0x200                                                  |  
|        Total AHS Length = 2(8bytes)                                             |
|        SCSI CDB = Write(10)  Transfer length = 00 01 ( 512 bytes)  |
 ------------------------------------------------------------------------------------------------|     
|        AHS ( 8 bytes)                                                                   |
|        Expected Read data length = 0x200(512 bytes)                    |
--------------------------------------------------------------------------------------------------

Here is the FCP format for bi-direct command that i frame for sending it to target.

------------------------------------------------------------------------------------------------
|        FC-Header (24bytes)                                                          |
|------------------------------------------------------------------------------------------------
|        FCP-Header(36 bytes)                                                        |
|         R & W bit set to ONE,                                                       | 
|        Additional CDB length = 0                                                   |
|        SCSI CDB = Write(10)  Transfer length = 00 01 ( 512 bytes)   |
|        FCP_DL  = 0x200 ( 512 bytes)                                             |
|        FCP_BIDIRECTIONAL_READ_DL = 0x200(512)                     |
 -------------------------------------------------------------------------------------------------|     

Well, I am not quite sure about the CDB values in case Bidir commands..
Will Bi directional cmds use Write CDB(10) or Read CDB (10) ? ..

How can i control following bidi- operation in case of iSCSI & FCP ?
1.bidirectional command with read before write operation
2.bidirectional command with write before read operation

-Praveen

New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. --0-876837187-1150461458=:29011-- --===============2113582769== 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 --===============2113582769==-- From ips-bounces@ietf.org Fri Jun 16 15:05:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrJcv-0001eN-EZ; Fri, 16 Jun 2006 15:05:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrJcu-0001eI-AQ for ips@ietf.org; Fri, 16 Jun 2006 15:05:04 -0400 Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrJct-0006tF-0z for ips@ietf.org; Fri, 16 Jun 2006 15:05:04 -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 E13B88719B; Fri, 16 Jun 2006 15:05:01 -0400 (EDT) In-Reply-To: <20060616123738.29074.qmail@web33408.mail.mud.yahoo.com> References: <20060616123738.29074.qmail@web33408.mail.mud.yahoo.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <25A8B0FE-94C3-4474-8EE8-32AA2DC90CE6@wasabisystems.com> Content-Transfer-Encoding: 7bit From: William Studenmund Subject: Re: [Ips] Reg: Bidirectional command format ? Date: Fri, 16 Jun 2006 12:04:52 -0700 To: Praveen Madhavan X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jun 16, 2006, at 5:37 AM, Praveen Madhavan wrote: > Hi Folks, > > Can any one point me the frame format of bidirectional command in > case of iSCSI & FCP ?.. I was trying to route bidirectional command > recv'd from iSCSI initiator to FC Target.. > > Here is the iSCSI PDU format for bi-direct command recv from initiator > ---------------------------------------------------------------------- > -------------------------- > | BHS > (48bytes) > | > | R & W bit set to > ONE, | > | Expected xfer len = > 0x200 | > | Total AHS Length = 2 > (8bytes) | > | SCSI CDB = Write(10) Transfer length = 00 01 ( 512 bytes) | > > ---------------------------------------------------------------------- > --------------------------| > | AHS ( 8 > bytes) > | > | Expected Read data length = 0x200(512 > bytes) | > ---------------------------------------------------------------------- > ---------------------------- > > Here is the FCP format for bi-direct command that i frame for > sending it to target. > > ---------------------------------------------------------------------- > -------------------------- > | FC-Header > (24bytes) | > |--------------------------------------------------------------------- > --------------------------- > | FCP-Header(36 > bytes) | > | R & W bit set to > ONE, | > | Additional CDB length = > 0 | > | SCSI CDB = Write(10) Transfer length = 00 01 ( 512 > bytes) | > | FCP_DL = 0x200 ( 512 > bytes) | > | FCP_BIDIRECTIONAL_READ_DL = 0x200(512) | > > ---------------------------------------------------------------------- > ---------------------------| > > Well, I am not quite sure about the CDB values in case Bidir > commands.. > Will Bi directional cmds use Write CDB(10) or Read CDB (10) ? .. No. Read and Write in normal sizes (6, 10, 12, 16) are unidirectional. Each specific command has either no data phase (test unit ready), has at most a data-out phase (Write for instance), at most a data-in phase (Read), or is bidirectional. > How can i control following bidi- operation in case of iSCSI & FCP ? > 1.bidirectional command with read before write operation > 2.bidirectional command with write before read operation You really don't need to do anything different for BiDi commands, other than be able to keep both a Write and a Read residual. As you note, the SCSI Command Request will indicate what data phases the initiator expects, you need only map them along. How does the target announce/control data flow in FCP? You need only pass that information on to the iSCSI layer. If the FCP target sends you data, then you send the initiator a bunch of Data-In PDUs. However it is that FCP controls data openings translates into R2Ts to the iSCSI initiator. Take care, Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEkwDZDJT2Egh26K0RAjqYAJ4yfTh+dkihI/Ha0RGhZN5NJ22zUQCfRc1L 7fPzAAxZZUa3mX6JsaEMPYs= =a55F -----END PGP SIGNATURE----- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Jun 19 17:17:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsR7D-0005NF-7C; Mon, 19 Jun 2006 17:16:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsR7B-0005J4-S4 for ips@ietf.org; Mon, 19 Jun 2006 17:16:57 -0400 Received: from rwcrmhc11.comcast.net ([204.127.192.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsR7A-00019v-Gp for ips@ietf.org; Mon, 19 Jun 2006 17:16:57 -0400 Received: from ivvtdkv0981 (c-66-177-56-218.hsd1.fl.comcast.net[66.177.56.218]) by comcast.net (rwcrmhc11) with SMTP id <20060619211654m1100b290de>; Mon, 19 Jun 2006 21:16:55 +0000 Message-ID: <000801c693e5$b1208490$06031eac@ivivity.com> From: "Eddy Quicksall" To: "William Studenmund" , "Praveen Madhavan" References: <20060616123738.29074.qmail@web33408.mail.mud.yahoo.com> <25A8B0FE-94C3-4474-8EE8-32AA2DC90CE6@wasabisystems.com> Subject: Re: [Ips] Reg: Bidirectional command format ? Date: Mon, 19 Jun 2006 17:16:53 -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: c83ccb5cc10e751496398f1233ca9c3a 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 Is anyone aware of any bidi SCSI commands? Eddy ----- Original Message ----- From: "William Studenmund" To: "Praveen Madhavan" Cc: Sent: Friday, June 16, 2006 3:04 PM Subject: Re: [Ips] Reg: Bidirectional command format ? > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Jun 16, 2006, at 5:37 AM, Praveen Madhavan wrote: > >> Hi Folks, >> >> Can any one point me the frame format of bidirectional command in >> case of iSCSI & FCP ?.. I was trying to route bidirectional command >> recv'd from iSCSI initiator to FC Target.. >> >> Here is the iSCSI PDU format for bi-direct command recv from initiator >> ---------------------------------------------------------------------- >> -------------------------- >> | BHS >> (48bytes) >> | >> | R & W bit set to >> ONE, | >> | Expected xfer len = >> 0x200 | >> | Total AHS Length = 2 >> (8bytes) | >> | SCSI CDB = Write(10) Transfer length = 00 01 ( 512 bytes) | >> >> ---------------------------------------------------------------------- >> --------------------------| >> | AHS ( 8 >> bytes) >> | >> | Expected Read data length = 0x200(512 >> bytes) | >> ---------------------------------------------------------------------- >> ---------------------------- >> >> Here is the FCP format for bi-direct command that i frame for >> sending it to target. >> >> ---------------------------------------------------------------------- >> -------------------------- >> | FC-Header >> (24bytes) | >> |--------------------------------------------------------------------- >> --------------------------- >> | FCP-Header(36 >> bytes) | >> | R & W bit set to >> ONE, | >> | Additional CDB length = >> 0 | >> | SCSI CDB = Write(10) Transfer length = 00 01 ( 512 >> bytes) | >> | FCP_DL = 0x200 ( 512 >> bytes) | >> | FCP_BIDIRECTIONAL_READ_DL = 0x200(512) | >> >> ---------------------------------------------------------------------- >> ---------------------------| >> >> Well, I am not quite sure about the CDB values in case Bidir >> commands.. >> Will Bi directional cmds use Write CDB(10) or Read CDB (10) ? .. > > No. Read and Write in normal sizes (6, 10, 12, 16) are unidirectional. > > Each specific command has either no data phase (test unit ready), has > at most a data-out phase (Write for instance), at most a data-in > phase (Read), or is bidirectional. > >> How can i control following bidi- operation in case of iSCSI & FCP ? >> 1.bidirectional command with read before write operation >> 2.bidirectional command with write before read operation > > You really don't need to do anything different for BiDi commands, > other than be able to keep both a Write and a Read residual. As you > note, the SCSI Command Request will indicate what data phases the > initiator expects, you need only map them along. > > How does the target announce/control data flow in FCP? You need only > pass that information on to the iSCSI layer. If the FCP target sends > you data, then you send the initiator a bunch of Data-In PDUs. > However it is that FCP controls data openings translates into R2Ts to > the iSCSI initiator. > > Take care, > > Bill > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.1 (Darwin) > > iD8DBQFEkwDZDJT2Egh26K0RAjqYAJ4yfTh+dkihI/Ha0RGhZN5NJ22zUQCfRc1L > 7fPzAAxZZUa3mX6JsaEMPYs= > =a55F > -----END PGP SIGNATURE----- > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Jun 19 17:26:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsRGg-0000ZQ-Rn; Mon, 19 Jun 2006 17:26:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsRGf-0000YD-2U for ips@ietf.org; Mon, 19 Jun 2006 17:26:45 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsRGa-0001QN-Le for ips@ietf.org; Mon, 19 Jun 2006 17:26:45 -0400 Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k5JLQeQc022738 for ; Mon, 19 Jun 2006 15:26:40 -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 <0J1400E01M7V3Y00@mail-amer.sun.com> (original mail from Paul.Vonbehren@Sun.COM) for ips@ietf.org; Mon, 19 Jun 2006 15:26:40 -0600 (MDT) Received: from [129.147.50.114] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J1400JW6M8FXXE2@mail-amer.sun.com>; Mon, 19 Jun 2006 15:26:40 -0600 (MDT) Date: Mon, 19 Jun 2006 15:26:47 -0600 From: Paul von Behren Subject: Re: [Ips] Reg: Bidirectional command format ? In-reply-to: <000801c693e5$b1208490$06031eac@ivivity.com> To: Eddy Quicksall Message-id: <44971697.2060405@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 References: <20060616123738.29074.qmail@web33408.mail.mud.yahoo.com> <25A8B0FE-94C3-4474-8EE8-32AA2DC90CE6@wasabisystems.com> <000801c693e5$b1208490$06031eac@ivivity.com> User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: William Studenmund , 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 Eddy Quicksall wrote: > Is anyone aware of any bidi SCSI commands? Look at the OSD command set (on the T10 site). I think all the OSD commands are bidi. I think that's the only command set now with bidi commands. Paul > > Eddy > > ----- Original Message ----- From: "William Studenmund" > > To: "Praveen Madhavan" > Cc: > Sent: Friday, June 16, 2006 3:04 PM > Subject: Re: [Ips] Reg: Bidirectional command format ? > > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On Jun 16, 2006, at 5:37 AM, Praveen Madhavan wrote: >> >>> Hi Folks, >>> >>> Can any one point me the frame format of bidirectional command in >>> case of iSCSI & FCP ?.. I was trying to route bidirectional command >>> recv'd from iSCSI initiator to FC Target.. >>> >>> Here is the iSCSI PDU format for bi-direct command recv from initiator >>> ---------------------------------------------------------------------- >>> -------------------------- >>> | BHS >>> (48bytes) >>> | >>> | R & W bit set to >>> ONE, | >>> | Expected xfer len = >>> 0x200 | >>> | Total AHS Length = 2 >>> (8bytes) | >>> | SCSI CDB = Write(10) Transfer length = 00 01 ( 512 bytes) | >>> >>> ---------------------------------------------------------------------- >>> --------------------------| >>> | AHS ( 8 >>> bytes) >>> | >>> | Expected Read data length = 0x200(512 >>> bytes) | >>> ---------------------------------------------------------------------- >>> ---------------------------- >>> >>> Here is the FCP format for bi-direct command that i frame for >>> sending it to target. >>> >>> ---------------------------------------------------------------------- >>> -------------------------- >>> | FC-Header >>> (24bytes) | >>> |--------------------------------------------------------------------- >>> --------------------------- >>> | FCP-Header(36 >>> bytes) | >>> | R & W bit set to >>> ONE, | >>> | Additional CDB length = >>> 0 | >>> | SCSI CDB = Write(10) Transfer length = 00 01 ( 512 >>> bytes) | >>> | FCP_DL = 0x200 ( 512 >>> bytes) | >>> | FCP_BIDIRECTIONAL_READ_DL = 0x200(512) | >>> >>> ---------------------------------------------------------------------- >>> ---------------------------| >>> >>> Well, I am not quite sure about the CDB values in case Bidir >>> commands.. >>> Will Bi directional cmds use Write CDB(10) or Read CDB (10) ? .. >> >> >> No. Read and Write in normal sizes (6, 10, 12, 16) are unidirectional. >> >> Each specific command has either no data phase (test unit ready), >> has at most a data-out phase (Write for instance), at most a >> data-in phase (Read), or is bidirectional. >> >>> How can i control following bidi- operation in case of iSCSI & FCP ? >>> 1.bidirectional command with read before write operation >>> 2.bidirectional command with write before read operation >> >> >> You really don't need to do anything different for BiDi commands, >> other than be able to keep both a Write and a Read residual. As you >> note, the SCSI Command Request will indicate what data phases the >> initiator expects, you need only map them along. >> >> How does the target announce/control data flow in FCP? You need only >> pass that information on to the iSCSI layer. If the FCP target sends >> you data, then you send the initiator a bunch of Data-In PDUs. >> However it is that FCP controls data openings translates into R2Ts >> to the iSCSI initiator. >> >> Take care, >> >> Bill >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.1 (Darwin) >> >> iD8DBQFEkwDZDJT2Egh26K0RAjqYAJ4yfTh+dkihI/Ha0RGhZN5NJ22zUQCfRc1L >> 7fPzAAxZZUa3mX6JsaEMPYs= >> =a55F >> -----END PGP SIGNATURE----- >> >> _______________________________________________ >> 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 Tue Jun 20 02:09:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsZQk-00005a-6t; Tue, 20 Jun 2006 02:09:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsZQi-0008Tn-Ij for ips@ietf.org; Tue, 20 Jun 2006 02:09:40 -0400 Received: from elasmtp-mealy.atl.sa.earthlink.net ([209.86.89.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsZHo-0007V7-4S for ips@ietf.org; Tue, 20 Jun 2006 02:00:29 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=o+7ZpoQQtVfibwFLbbhYI1LJqIuJMA7PpDL9acVqymT1zq78/BOfZl9nYKnlZsp8; h=Received:Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To:References:Mime-Version:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [70.68.164.201] (helo=NTW.earthlink.net) by elasmtp-mealy.atl.sa.earthlink.net with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1FsZHi-0004OV-E4; Tue, 20 Jun 2006 02:00:22 -0400 Message-Id: <6.2.1.2.0.20060619225518.02cb5898@pop.earthlink.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 19 Jun 2006 23:00:04 -0700 To: Paul von Behren , Eddy Quicksall From: Neil Wanamaker Subject: Re: [Ips] Reg: Bidirectional command format ? In-Reply-To: <44971697.2060405@sun.com> References: <20060616123738.29074.qmail@web33408.mail.mud.yahoo.com> <25A8B0FE-94C3-4474-8EE8-32AA2DC90CE6@wasabisystems.com> <000801c693e5$b1208490$06031eac@ivivity.com> <44971697.2060405@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ELNK-Trace: 47bda5c2758b839774bf435c0eb9d478268772c7f119d22b3a2676e630351b1e1fddfc615990b8c6350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 70.68.164.201 X-Spam-Score: 0.6 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb 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: , Errors-To: ips-bounces@ietf.org At 02:26 PM 6/19/2006, Paul von Behren wrote: >Eddy Quicksall wrote: > >>Is anyone aware of any bidi SCSI commands? > > >Look at the OSD command set (on the T10 site). I think all the OSD >commands are bidi. I think that's the only command set now with bidi commands. Try XDWRITEREAD in SBC-2. Neil Wanamaker PMC-Sierra 100-2700 Production Way Burnaby, BC >Paul > >> >>Eddy >> >>----- Original Message ----- From: "William Studenmund" >> >>To: "Praveen Madhavan" >>Cc: >>Sent: Friday, June 16, 2006 3:04 PM >>Subject: Re: [Ips] Reg: Bidirectional command format ? >> >> >>>-----BEGIN PGP SIGNED MESSAGE----- >>>Hash: SHA1 >>> >>>On Jun 16, 2006, at 5:37 AM, Praveen Madhavan wrote: >>> >>>>Hi Folks, >>>> >>>>Can any one point me the frame format of bidirectional command in >>>>case of iSCSI & FCP ?.. I was trying to route bidirectional command >>>>recv'd from iSCSI initiator to FC Target.. >>>> >>>>Here is the iSCSI PDU format for bi-direct command recv from initiator >>>>---------------------------------------------------------------------- >>>>-------------------------- >>>>| BHS >>>>(48bytes) >>>> | >>>>| R & W bit set to >>>>ONE, | >>>>| Expected xfer len = >>>>0x200 | >>>>| Total AHS Length = 2 >>>>(8bytes) | >>>>| SCSI CDB = Write(10) Transfer length = 00 01 ( 512 bytes) | >>>> >>>>---------------------------------------------------------------------- >>>>--------------------------| >>>>| AHS ( 8 >>>>bytes) >>>> | >>>>| Expected Read data length = 0x200(512 >>>>bytes) | >>>>---------------------------------------------------------------------- >>>>---------------------------- >>>> >>>>Here is the FCP format for bi-direct command that i frame for >>>>sending it to target. >>>> >>>>---------------------------------------------------------------------- >>>>-------------------------- >>>>| FC-Header >>>>(24bytes) | >>>>|--------------------------------------------------------------------- >>>>--------------------------- >>>>| FCP-Header(36 >>>>bytes) | >>>>| R & W bit set to >>>>ONE, | >>>>| Additional CDB length = >>>>0 | >>>>| SCSI CDB = Write(10) Transfer length = 00 01 ( 512 >>>>bytes) | >>>>| FCP_DL = 0x200 ( 512 >>>>bytes) | >>>>| FCP_BIDIRECTIONAL_READ_DL = 0x200(512) | >>>> >>>>---------------------------------------------------------------------- >>>>---------------------------| >>>> >>>>Well, I am not quite sure about the CDB values in case Bidir >>>>commands.. >>>>Will Bi directional cmds use Write CDB(10) or Read CDB (10) ? .. >>> >>> >>>No. Read and Write in normal sizes (6, 10, 12, 16) are unidirectional. >>> >>>Each specific command has either no data phase (test unit ready), >>>has at most a data-out phase (Write for instance), at most a >>>data-in phase (Read), or is bidirectional. >>> >>>>How can i control following bidi- operation in case of iSCSI & FCP ? >>>>1.bidirectional command with read before write operation >>>>2.bidirectional command with write before read operation >>> >>> >>>You really don't need to do anything different for BiDi commands, >>>other than be able to keep both a Write and a Read residual. As you >>>note, the SCSI Command Request will indicate what data phases the >>>initiator expects, you need only map them along. >>> >>>How does the target announce/control data flow in FCP? You need only >>>pass that information on to the iSCSI layer. If the FCP target sends >>>you data, then you send the initiator a bunch of Data-In PDUs. >>>However it is that FCP controls data openings translates into R2Ts >>>to the iSCSI initiator. >>> >>>Take care, >>> >>>Bill >>>-----BEGIN PGP SIGNATURE----- >>>Version: GnuPG v1.4.1 (Darwin) >>> >>>iD8DBQFEkwDZDJT2Egh26K0RAjqYAJ4yfTh+dkihI/Ha0RGhZN5NJ22zUQCfRc1L >>>7fPzAAxZZUa3mX6JsaEMPYs= >>>=a55F >>>-----END PGP SIGNATURE----- >>> >>>_______________________________________________ >>>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 Neil Wanamaker ntw20@earthlink.net 512.917.9712 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Jun 22 00:06:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtGSQ-0001OP-Qa; Thu, 22 Jun 2006 00:06:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtGSQ-0001Ke-1h for ips@ietf.org; Thu, 22 Jun 2006 00:06:18 -0400 Received: from rwcrmhc11.comcast.net ([204.127.192.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtGSO-0008PI-QA for ips@ietf.org; Thu, 22 Jun 2006 00:06:18 -0400 Received: from ivvtdkv0981 (c-66-177-56-218.hsd1.fl.comcast.net[66.177.56.218]) by comcast.net (rwcrmhc11) with SMTP id <20060622040615m1100b3d3de>; Thu, 22 Jun 2006 04:06:15 +0000 Message-ID: <002001c695b1$362e1ea0$06031eac@ivivity.com> From: "Eddy Quicksall" To: Date: Thu, 22 Jun 2006 00:06:11 -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] iSER test platform 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="===============2028581946==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============2028581946== Content-Type: multipart/alternative; boundary="----=_NextPart_000_001D_01C6958F.AB51BB00" This is a multi-part message in MIME format. ------=_NextPart_000_001D_01C6958F.AB51BB00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Does anyone know of an iSER initiator that is available to test with? A = software version would be best for now. Eddy ------=_NextPart_000_001D_01C6958F.AB51BB00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Does anyone know of an iSER initiator that is = available to=20 test with? A software version would be best for now.
 
Eddy
------=_NextPart_000_001D_01C6958F.AB51BB00-- --===============2028581946== 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 --===============2028581946==-- From ips-bounces@ietf.org Sun Jun 25 21:51:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FugFj-0002dy-U0; Sun, 25 Jun 2006 21:51:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtqQM-0001Ha-3b for ips@ietf.org; Fri, 23 Jun 2006 14:30:34 -0400 Received: from mm04snlnto.sandia.gov ([132.175.109.21] helo=sentry.sandia.gov) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtqQI-0002B4-IU for ips@ietf.org; Fri, 23 Jun 2006 14:30:34 -0400 Received: from 132.175.109.1 by sentry.sandia.gov with ESMTP (Tumbleweed MMS SMTP Relay 01 (Email Firewall v6.2.2)); Fri, 23 Jun 2006 12:30:18 -0600 X-Server-Uuid: 4A6F66F3-3BA9-40FF-AC33-461A8279D6D5 Received: from ca.sandia.gov (california.sandia.gov [146.246.250.1]) by mailgate.sandia.gov (8.13.6/8.13.6) with ESMTP id k5NIUEEu008978; Fri, 23 Jun 2006 12:30:14 -0600 (MDT) Received: from hycswlaptop (hycsw-laptop.ca.sandia.gov [146.246.248.38]) by ca.sandia.gov (8.13.6/8.13.6) with ESMTP id k5NIUE36030742; Fri, 23 Jun 2006 11:30:14 -0700 (PDT) Message-ID: <007801c696f3$11746d60$26f8f692@hycswlaptop> From: "Helen Chen" To: "Eddy Quicksall" , ips@ietf.org References: <002001c695b1$362e1ea0$06031eac@ivivity.com> Subject: Re: [Ips] iSER test platform Date: Fri, 23 Jun 2006 11:30:09 -0700 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.6.23.111432 X-TMWD-Spam-Summary: TS=20060623183018; SEV=2.0.2; DFV=A2006062305; IFV=2.0.4,4.0-8; RPD=4.00.0004; ENG=IBF; RPDID=NA; CAT=NONE; CON=NONE X-MMS-Spam-Filter-ID: A2006062305_4.00.0004_4.0-8 X-WSS-ID: 6882ECB027K6718305-01-01 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 X-Mailman-Approved-At: Sun, 25 Jun 2006 21:51:02 -0400 Cc: hycsw@ca.sandia.gov 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="===============0953215009==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0953215009== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0075_01C696B8.623E3270" This is a multi-part message in MIME format. ------=_NextPart_000_0075_01C696B8.623E3270 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable An iSER initiator on is available on the OpenFabric website = (https://openib.org/tiki/tiki-indes.php). Currently it is only working = on IB as beta release. iWARP support is projected in the 4th quarter of = 06. Helen ----- Original Message -----=20 From: Eddy Quicksall=20 To: ips@ietf.org=20 Sent: Wednesday, June 21, 2006 9:06 PM Subject: [Ips] iSER test platform Does anyone know of an iSER initiator that is available to test with? = A software version would be best for now. Eddy -------------------------------------------------------------------------= ----- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------=_NextPart_000_0075_01C696B8.623E3270 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
An iSER initiator on is available on = the OpenFabric=20 website (https://openib.org/tiki/t= iki-indes.php). =20 Currently it is only working on IB as beta release.  iWARP support = is=20 projected in the 4th quarter of 06.
 
Helen
----- Original Message -----
From:=20 Eddy = Quicksall=20
Sent: Wednesday, June 21, 2006 = 9:06=20 PM
Subject: [Ips] iSER test = platform

Does anyone know of an iSER initiator that is = available to=20 test with? A software version would be best for now.
 
Eddy

_______________________________________________
Ips mailing=20 list
Ips@ietf.org
https://www1.ietf.org= /mailman/listinfo/ips
------=_NextPart_000_0075_01C696B8.623E3270-- --===============0953215009== 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 --===============0953215009==-- From ips-bounces@ietf.org Mon Jun 26 21:29:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv2OI-0005O4-1N; Mon, 26 Jun 2006 21:29:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv2OG-0005Nz-30 for ips@ietf.org; Mon, 26 Jun 2006 21:29:20 -0400 Received: from pat.qlogic.com ([198.70.193.2] helo=avexch1.qlogic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv2OD-00088m-Mg for ips@ietf.org; Mon, 26 Jun 2006 21:29:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 26 Jun 2006 18:29:16 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: iSCSI ExpStatSN, StatSN question Thread-Index: AcaZiRq4+Zv6PHycRdeYZ7ssMuKPQQ== From: "Dean Scoville" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Subject: [Ips] iSCSI ExpStatSN, StatSN 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="===============1607953505==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1607953505== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69989.1AA59B52" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69989.1AA59B52 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I would like help interpreting the following paragraph from iSCSI RFC = 3720,=20 Section 3.2.2.2: "A large absolute difference between StatSN and ExpStatSN may = indicate a failed connection. Initiators MUST undertake recovery actions if = the=20 difference is greater than an implementation defined constant that = MUST NOT exceed 2**31-1." I don't understand what is meant by "absolute difference"... For the = purposes of=20 this discussion, assume the "implementation defined constant" to be = 2**31-1,=20 which is the largest allowed value... regardless of whether you consider = this a "reasonable" choice for the constant. In this case, which of the following would require recovery actions, and = why? a) ExpStatSn=3DFFFFFFFFh, and initiator receives StatSn=3D0. (i.e., = missing one StatSN) b) ExpStatSn=3D0, and initiator receives StatSn=3DFFFFFFFFh. (i.e., = duplicate StatSN) c) ExpStatSn=3D0, and initiator receives StatSn=3D7FFFFFFFh. (i.e., = missing lots of StatSNs) d) ExpStatSn=3D0, and initiator receives StatSn=3D80000000h. (missing or = duplicate?) e) ExpStatSn=3D0, and initiator receives StatSn=3D80000001h. (i.e., very = old duplicate StatSN) thanks, Dean Scoville ------_=_NextPart_001_01C69989.1AA59B52 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable iSCSI ExpStatSN, StatSN question

I would like help interpreting the = following paragraph from iSCSI RFC 3720,
Section 3.2.2.2:

     "A large = absolute difference between StatSN and ExpStatSN may indicate
     a failed = connection.  Initiators MUST undertake recovery actions if the =
     difference is = greater than an implementation defined constant that MUST NOT
     exceed = 2**31-1."

I don't understand what is meant by = "absolute difference"... For the purposes of
this discussion, assume the = "implementation defined constant" to be 2**31-1,
which is the largest allowed value... = regardless of whether you consider this a
"reasonable" choice for the = constant.

In this case, which of the following = would require recovery actions, and why?

a) ExpStatSn=3DFFFFFFFFh, and initiator = receives StatSn=3D0. (i.e., missing one StatSN)

b) ExpStatSn=3D0, and initiator = receives StatSn=3DFFFFFFFFh. (i.e., duplicate StatSN)

c) ExpStatSn=3D0, and initiator = receives StatSn=3D7FFFFFFFh. (i.e., missing lots of StatSNs)

d) ExpStatSn=3D0, and initiator = receives StatSn=3D80000000h. (missing or duplicate?)

e) ExpStatSn=3D0, and initiator = receives StatSn=3D80000001h. (i.e., very old duplicate StatSN)


thanks,

Dean Scoville

------_=_NextPart_001_01C69989.1AA59B52-- --===============1607953505== 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 --===============1607953505==-- From ips-bounces@ietf.org Wed Jun 28 02:44:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvTmf-0001mH-UX; Wed, 28 Jun 2006 02:44:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvTmN-0001lv-81 for ips@ietf.org; Wed, 28 Jun 2006 02:44:03 -0400 Received: from pat.qlogic.com ([198.70.193.2] helo=avexch1.qlogic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvTmM-0001cH-Gt for ips@ietf.org; Wed, 28 Jun 2006 02:44:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Re: [Ips] iSCSI ExpStatSN, StatSN question Date: Tue, 27 Jun 2006 23:44:01 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: iSCSI ExpStatSN, StatSN question Thread-Index: AcaZiRq4+Zv6PHycRdeYZ7ssMuKPQQA653AA From: "Dean Scoville" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b21264b25b2584da3ddf2bd579ca48f 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="===============1245469638==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1245469638== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69A7E.3D71A356" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69A7E.3D71A356 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Rather than simply ask the question, here is how I interpret the=20 paragraph... any comments? =20 The "absolute difference" must of course take into account sequence=20 number wrapping, so for example, the absolute difference between=20 FFFFFFFFh and 0h is 1, just as the absolute difference between=20 0h and 1h is 1 and the absolute difference between 0h and FFFFFFFFh is 1. When an initiator receives a PDU containing a StatSN value,=20 it takes one of the following 3 actions: =20 action 1:=20 If the StatSN is more than the "implementation defined constant" away = from the ExpStatSN (in a positive or negative direction), then the = initiator should consider the connection failed and close it. Otherwise, the=20 initiator performs error recovery as described below for action 2 or = 3. =20 action 2: When the initiator's ExpStatSN is greater than the received StatSN=20 (based on serial arithmetic), the initiator discards the PDU = containing the duplicate status and may send a PDU to the target (NOP-Out, or other PDU containing the current ExpStatSN) to update the target's=20 knowledge of the status already received by the initiator. =20 action 3: When ExpStatSN is less than the received StatSN (based on serial=20 arithmetic), the initiator can SNACK for the missing status (or close the connection, depending on error recovery level). =20 In response to my original question, when the "implementation defined constant" is 2**31-1, the threshold is such that the initiator would = perform error recovery in all cases except when the absolute difference is = 2**31, which is the only StatSN that is out of range given the implementation's chosen constant. The behavior would be as follows: =20 a) ExpStatSn=3DFFFFFFFFh, and initiator receives StatSn=3D0. (i.e., = missing one StatSN) - take action 3, because missing StatSN is within range. =20 b) ExpStatSn=3D0h, and initiator receives StatSn=3DFFFFFFFFh. (i.e., = duplicate StatSN) - take action 2, because duplicate StatSN is within range. =20 c) ExpStatSn=3D0h, and initiator receives StatSn=3D7FFFFFFFh. (i.e., = missing lots of StatSNs) - take action 3, because missing StatSNs are within range. =20 d) ExpStatSn=3D0h, and initiator receives StatSn=3D80000000h. (missing = or duplicate?) - take action 1, because received StatSN is out of range. =20 e) ExpStatSn=3D0h, and initiator receives StatSn=3D80000001h. (i.e., = very old duplicate StatSN) - take action 2, because duplicate StatSN is within range. Other "implementation defined constants" would vary the range of=20 acceptable StatSN values. At the other extreme, a "implementation defined constant" of 0 would cause the initiator to close the connection whenever a PDU containing a StatSN value that does not match the=20 initiator's ExpStatSN is received. =20 Any comments? Does this seem like a valid interpretation? =20 Thanks, =20 Dean=20 =20 -----Original Message----- From: Dean Scoville [mailto:dean.scoville@qlogic.com] Sent: Monday, June 26, 2006 6:29 PM To: ips@ietf.org Subject: [Ips] iSCSI ExpStatSN, StatSN question I would like help interpreting the following paragraph from iSCSI RFC = 3720,=20 Section 3.2.2.2:=20 "A large absolute difference between StatSN and ExpStatSN may = indicate=20 a failed connection. Initiators MUST undertake recovery actions if = the=20 difference is greater than an implementation defined constant that = MUST NOT=20 exceed 2**31-1."=20 I don't understand what is meant by "absolute difference"... For the = purposes of=20 this discussion, assume the "implementation defined constant" to be = 2**31-1,=20 which is the largest allowed value... regardless of whether you consider = this a=20 "reasonable" choice for the constant.=20 In this case, which of the following would require recovery actions, and = why?=20 a) ExpStatSn=3DFFFFFFFFh, and initiator receives StatSn=3D0. (i.e., = missing one StatSN)=20 b) ExpStatSn=3D0, and initiator receives StatSn=3DFFFFFFFFh. (i.e., = duplicate StatSN)=20 c) ExpStatSn=3D0, and initiator receives StatSn=3D7FFFFFFFh. (i.e., = missing lots of StatSNs)=20 d) ExpStatSn=3D0, and initiator receives StatSn=3D80000000h. (missing or = duplicate?)=20 e) ExpStatSn=3D0, and initiator receives StatSn=3D80000001h. (i.e., very = old duplicate StatSN)=20 thanks,=20 Dean Scoville=20 ------_=_NextPart_001_01C69A7E.3D71A356 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable iSCSI ExpStatSN, StatSN question
Rather=20 than simply ask the question, here is how I interpret the =
paragraph... any = comments?
 
The "absolute difference" must of=20 course take into account = sequence=20
number=20 wrapping, so for example, the absolute difference = between=20
FFFFFFFFh and 0h is 1, just as the absolute=20 difference between
0h and=20 1h is 1 and the absolute difference between 0h and=20 FFFFFFFFh
is=20 1. When an initiator receives a PDU containing a = StatSN value,=20
it takes one of the following 3=20 actions:
 
action=20 1: 
   If the StatSN is = more than the=20 "implementation defined constant" away
   from the ExpStatSN (in a = positive or=20 negative direction), then the initiator
 =20  should consider the connection failed and close it. = Otherwise, the=20
   initiator performs error=20 recovery as described below for = action 2 or=20 3.
 
action=20 2:
   When the initiator's = ExpStatSN is=20 greater than the received StatSN =
   (based on=20 serial arithmetic), the initiator = discards the PDU=20 containing
 =20  the duplicate status and = may = send a PDU to=20 the target (NOP-Out, or
 =20  other PDU containing the current ExpStatSN) to=20 update the target's 
   knowledge=20 of the status already received by = the=20 initiator.
 
action 3:
   When ExpStatSN is = less than the received StatSN (based on serial=20
   arithmetic), the initiator can SNACK for the missing=20 status (or close
 =20  the connection, depending on error=20 recovery level).
 
In=20 response to my original question, when the "implementation=20 defined
constant" is 2**31-1, the threshold is such = that the=20 initiator would perform
error=20 recovery in all cases except when the absolute difference is=20 2**31,
which=20 is the only StatSN that is out of range given=20 the implementation's
chosen=20 constant. The behavior would be as = follows:
 
a)=20 ExpStatSn=3DFFFFFFFFh, and initiator receives StatSn=3D0. (i.e., missing = one=20 StatSN)
    - take action 3, = because=20 missing StatSN is within=20 range.
 
b) ExpStatSn=3D0h, and initiator receives = StatSn=3DFFFFFFFFh. (i.e., duplicate=20 StatSN)
    - take action 2,=20 because duplicate StatSN is within range.
 
c) ExpStatSn=3D0h, and initiator receives = StatSn=3D7FFFFFFFh.=20 (i.e., missing lots of = StatSNs)
    - take action 3,=20 because missing StatSNs are within range.
 
=
d) ExpStatSn=3D0h, and initiator receives = StatSn=3D80000000h. (missing or=20 duplicate?)
    - take action 1, = because=20 received StatSN is out of range.
 
e)=20 ExpStatSn=3D0h, and initiator = receives=20 StatSn=3D80000001h. (i.e., very old duplicate StatSN)
    - take action 2,=20 because duplicate StatSN is within=20 range.

Other=20 "implementation defined constants" would vary the range=20 of 
acceptable StatSN values. At the other extreme, a=20 "implementation
defined constant" of 0 would cause the initiator to = close the=20 connection
whenever a PDU containing = a StatSN=20 value that does not match the
initiator's ExpStatSN is = received.
 
Any comments? Does this seem like a valid=20 interpretation?
 
Thanks,
 
Dean 
 
 -----Original=20 Message-----
From: Dean Scoville=20 [mailto:dean.scoville@qlogic.com]
Sent: Monday, June 26, 2006 = 6:29=20 PM
To: ips@ietf.org
Subject: [Ips] iSCSI ExpStatSN, = StatSN=20 question

I would like help interpreting the = following=20 paragraph from iSCSI RFC 3720,
Section=20 3.2.2.2:

     "A large = absolute difference=20 between StatSN and ExpStatSN may indicate
     a failed connection.  Initiators = MUST=20 undertake recovery actions if the
     difference is greater than an = implementation=20 defined constant that MUST NOT
     exceed 2**31-1."

I don't understand what is meant by = "absolute=20 difference"... For the purposes of
this=20 discussion, assume the "implementation defined constant" to be 2**31-1,=20
which is the largest allowed = value...=20 regardless of whether you consider this a
"reasonable" choice for the constant.

In this case, which of the following = would require=20 recovery actions, and why?

a) ExpStatSn=3DFFFFFFFFh, and initiator = receives=20 StatSn=3D0. (i.e., missing one StatSN)

b) ExpStatSn=3D0, and initiator receives=20 StatSn=3DFFFFFFFFh. (i.e., duplicate StatSN)

c) ExpStatSn=3D0, and initiator receives=20 StatSn=3D7FFFFFFFh. (i.e., missing lots of StatSNs)

d) ExpStatSn=3D0, and initiator receives=20 StatSn=3D80000000h. (missing or duplicate?)

e) ExpStatSn=3D0, and initiator receives=20 StatSn=3D80000001h. (i.e., very old duplicate StatSN)


thanks,

Dean Scoville

------_=_NextPart_001_01C69A7E.3D71A356-- --===============1245469638== 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 --===============1245469638==-- From ips-bounces@ietf.org Thu Jun 29 20:13:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw6dH-0000Gk-BU; Thu, 29 Jun 2006 20:13:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw6dG-0000Gf-VH for ips@ietf.org; Thu, 29 Jun 2006 20:13:14 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw6dE-0007G1-Nb for ips@ietf.org; Thu, 29 Jun 2006 20:13:14 -0400 Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by mexforward.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5U0DCgH016227 for ; Thu, 29 Jun 2006 20:13:12 -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 k5U0DB2e025325 for ; Thu, 29 Jun 2006 20:13:11 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 29 Jun 2006 20:13:11 -0400 Message-ID: From: Black_David@emc.com To: ips@ietf.org Date: Thu, 29 Jun 2006 20:13:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.6.29.165433 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: 2409bba43e9c8d580670fda8b695204a Cc: Black_David@emc.com Subject: [Ips] Montreal agenda items 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 major goal of the Montreal meeting of the IPS WG will be to understand what needs to be done to: draft-ietf-ips-iscsi-nodearch-key-00.txt I would hope to run a WG Last Call on this draft sometime after Montreal. There will be a status report on the implementation guide draft, but I know of no issues with that draft requiring WG discussion. The iSNS MIB will not be on the agenda - it's still awaiting revision based on Expert Review (MIB Doctor) comments. If there are any other drafts that should be part of the ips Montreal meeting, please send me a request with the draft name and purpose of discussion in the meeting. The ips meeting in Montreal is on Wednesday, July 12: Room 513B TSV ips IP Storage WG 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