From exim@www1.ietf.org Sun May 2 14:22:56 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24852 for ; Sun, 2 May 2004 14:22:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKLZk-0008G2-NM for ips-archive@odin.ietf.org; Sun, 02 May 2004 14:20:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i42IKSxi031738 for ips-archive@odin.ietf.org; Sun, 2 May 2004 14:20:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKLNw-0005hu-Il for ips-web-archive@optimus.ietf.org; Sun, 02 May 2004 14:08:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24429 for ; Sun, 2 May 2004 14:08:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKLNu-0001Ek-6e for ips-web-archive@ietf.org; Sun, 02 May 2004 14:08:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKLN3-00010G-00 for ips-web-archive@ietf.org; Sun, 02 May 2004 14:07:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKLMS-0000kb-00 for ips-web-archive@ietf.org; Sun, 02 May 2004 14:06:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKLGv-0003sx-GZ; Sun, 02 May 2004 14:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKLF6-0003I6-O1 for ips@optimus.ietf.org; Sun, 02 May 2004 13:59:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24025 for ; Sun, 2 May 2004 13:59:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKLF4-0006j8-C3 for ips@ietf.org; Sun, 02 May 2004 13:59:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKLE7-0006Tu-00 for ips@ietf.org; Sun, 02 May 2004 13:58:08 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BKLDM-00061v-00; Sun, 02 May 2004 13:57:20 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 02 May 2004 10:10:44 +0000 Received: from cypher.cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i42HulW9020971; Sun, 2 May 2004 10:56:47 -0700 (PDT) Received: (from kzm@localhost) by cypher.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id KAA06786; Sun, 2 May 2004 10:56:46 -0700 (PDT) From: Keith McCloghrie Message-Id: <200405021756.KAA06786@cypher.cisco.com> Subject: Re: [Ips] Proposal to remove "dynamic" port type for FcPortType To: rsnively@Brocade.COM (Robert Snively) Date: Sun, 2 May 2004 10:56:46 -0700 (PDT) Cc: kzm@cisco.com (Keith McCloghrie), ips@ietf.org, t11_5@mail.t11.org, t11_3@mail.t11.org, imss@ietf.org In-Reply-To: <191DA4FAE235D24C9BCC8D50F6B17AB90933BB@hq-ex-11.brocade.com> from "Robert Snively" at Apr 30, 2004 09:57:36 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Bob, No, a MIB is not just a specification of syntax; a MIB is required to define the semantics of objects also. Otherwise, the MIB has no value to a management application. So, a MIB with your "pre-specified type values" *would* undergo a change (in semantics) as and when T11 defined the semantics. However, I agree with your recognition of the future need for: a) "ports with a negotiation algorithm", as well as b) "ports with a pre-established fixed type". Since we cannot (see above) pre-define such types, if we removed 'dyanmic' then both of these categories would have to be lumped together under 'other'. The reason to retain 'dynamic' is to allow a management application to distinguish between these two types. I don't understand the strong opposition to allowing such a distinction. How can anyone object to giving a management application more accurate information ?? Perhaps the problem is that I've failed to define/explain them properly, or perhaps it's the word "dynamic" that you don't like. So, how about we take the two current enumerations 'other' and 'dynamic' and replace them with these two: 'otherFixed' -- a fixed type (known to the agent) which is not one of these types: 'nPort', 'nlPort' 'fPort' 'flPort' 'ePort' or 'bPort'. 'otherNegotiate' -- a type (known to the agent), which is subject to on-the-wire determination (e.g., by negotiation), but which is not one of these types: 'gPort', 'glPort', 'fnlPort'. Keith. PS. I can't locate the definitions of 'gPort' and 'glPort'. I note that 'fnlPort' is defined in sections 3.2.19 and 6.2.3.3.2 (Table 127) of GS-4, and I would have expected to find G_Port and GL_Port in the same/corresponding sections, but they're not. Please can you provide me with a document name and section number reference for these two. Or, am I mistaken in assuming that these new types have been approved by T11 Ballot ?? > Using David Black's consensus call, I will focus on > the "dynamic" question. > > I am in agreement with Mike O'Donnell's > analysis of "unknown" and "other". I support his > conclusions on "dynamic" (i.e. that it should be > removed as a port type). > > Keith McLoughrie indicates that dynamic is useful > for future proofing. I believe that the most effective > mechanism for future proofing would be to remove > "dynamic" as a type, then provide a certain number > of pre-specified type values for future assignment > by INCITS TC T11 standards. That way, the MIB can remain unchanged and > the > values be picked up by future T11 standards if they > are ever required. The number of such values should > be small, since any large number of future variants would > probably require modification to the MIB anyway. > > That allows both for future definition of ports with a > negotiation algorithm and ports with a pre-established > fixed type, something that "dynamic" does not. > > Robert Snively > > Brocade Communications Systems, Inc. > 1745 Technology Drive > San Jose, CA 95110 > > +1 408 333 8135 > rsnively@brocade.com > > > > > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Sun May 2 14:42:00 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25658 for ; Sun, 2 May 2004 14:42:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKLmV-0004qK-AX for ips-archive@odin.ietf.org; Sun, 02 May 2004 14:33:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i42IXdA9018611 for ips-archive@odin.ietf.org; Sun, 2 May 2004 14:33:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKLfL-0003AA-VT for ips-web-archive@optimus.ietf.org; Sun, 02 May 2004 14:26:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25047 for ; Sun, 2 May 2004 14:26:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKLfJ-0005cY-IJ for ips-web-archive@ietf.org; Sun, 02 May 2004 14:26:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKLeO-0005Nb-00 for ips-web-archive@ietf.org; Sun, 02 May 2004 14:25:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKLdq-00058f-00 for ips-web-archive@ietf.org; Sun, 02 May 2004 14:24:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKLbF-000097-71; Sun, 02 May 2004 14:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKLQh-00060k-DE for ips@optimus.ietf.org; Sun, 02 May 2004 14:11:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24495 for ; Sun, 2 May 2004 14:11:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKLQf-0001wM-0D for ips@ietf.org; Sun, 02 May 2004 14:11:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKLPg-0001gj-00 for ips@ietf.org; Sun, 02 May 2004 14:10:04 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BKLOj-0001FC-00; Sun, 02 May 2004 14:09:05 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 02 May 2004 10:22:30 +0000 Received: from cypher.cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i42I8WW9028489; Sun, 2 May 2004 11:08:32 -0700 (PDT) Received: (from kzm@localhost) by cypher.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id LAA07745; Sun, 2 May 2004 11:08:32 -0700 (PDT) From: Keith McCloghrie Message-Id: <200405021808.LAA07745@cypher.cisco.com> Subject: Re: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for FcPortType To: mike.o'donnell@mcdata.com (Mike O'Donnell) Date: Sun, 2 May 2004 11:08:32 -0700 (PDT) Cc: Black_David@emc.com, kzm@cisco.com, rsnively@Brocade.COM, ips@ietf.org, t11_5@mail.t11.org, t11_3@mail.t11.org, imss@ietf.org In-Reply-To: <95C56F83F771C041B4EC26C4DAEEC942D4B434@MC4EXCH03.mcdata.com> from "Mike O'Donnell" at Apr 30, 2004 10:06:24 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mike, > >"I think Keith is correct that not having a standard to reference is > > insufficient to remove "dynamic", as this would also entail > > also removing "other" and "unknown", which does not appear to > > be a desired outcome. > > "Other" and "Unknown" are (as is stated) used to indicate that (for > the case of 'other') the agent can determine the port type and it is > NOT any of those types identified in the MIB. "Unknown" indicates the > agent is unable to ascertain its type (be it any of those identified or > other). It is an accepted mechanism in MIB's to provide an agent a > mechanism to report it as such. > > Based on the above, I don't accept the logic that because 'other' and > 'unknown' are not specified in any standard and that dynamic is ALSO > not specified in any standard then "other" an "unknown" should also be > removed from the MIB. I think you've inverted the logic that I intended to convey; let me try again: "there's no reference for 'dynamic'" is an insufficient reason to remove it, because if that reason only was sufficient then 'other' and 'unknown' would also have to be removed. which would clearly be a mistake. > As for the use of dynamic, it is my opinion that if the specified > states of a port can be determined (and documented in the MIB), then > dynamic has no value. And, from an implementor's perspective, if > dynamic is added to the MIB, when does one report "dynamic" versus > G-port, GL_port, FNL_port (or other specified port types)? > > If it is to 'future-proof' the MIB, what does 'future_port_type' (aka > 'dynamic') tell me that 'other' does not? Help me understand. Maybe > someone can point to where this has been successfully implemented (not > just documented) in other MIBs so we can use this as a model for > future-proofing our FC MIB's. As an application vendor, "dynamic" > doesn't add any additional value as specified today. I am obviously guilty of doing a poor job of editing the MIB. Please see my message to Bob Snieveley for what I hope is a better definition which will answer your questions. Keith. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon May 3 13:50:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16414 for ; Mon, 3 May 2004 13:50:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKhMO-0005jM-2V for ips-archive@odin.ietf.org; Mon, 03 May 2004 13:36:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43Ha8o9022028 for ips-archive@odin.ietf.org; Mon, 3 May 2004 13:36:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKhIF-0004TM-Cz for ips-web-archive@optimus.ietf.org; Mon, 03 May 2004 13:31:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15275 for ; Mon, 3 May 2004 13:31:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKhID-0004KI-CN for ips-web-archive@ietf.org; Mon, 03 May 2004 13:31:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKhHI-0004Eo-00 for ips-web-archive@ietf.org; Mon, 03 May 2004 13:30:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKhGz-00049Z-00 for ips-web-archive@ietf.org; Mon, 03 May 2004 13:30:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKh1z-00013u-PM; Mon, 03 May 2004 13:15:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKgu8-0006vy-JJ for ips@optimus.ietf.org; Mon, 03 May 2004 13:06:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14223 for ; Mon, 3 May 2004 13:06:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKgu6-000230-RZ for ips@ietf.org; Mon, 03 May 2004 13:06:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKgtM-0001tx-00 for ips@ietf.org; Mon, 03 May 2004 13:06:09 -0400 Received: from f112.brocade.com ([66.243.153.112] helo=blasphemy.brocade.com) by ietf-mx with esmtp (Exim 4.12) id 1BKgsG-0001eU-00; Mon, 03 May 2004 13:05:00 -0400 Received: from hq-ex-11.corp.brocade.com (hq-ex-11 [192.168.38.58]) by blasphemy.brocade.com (Postfix) with ESMTP id C663714272; Mon, 3 May 2004 10:04:26 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for FcPortType Date: Mon, 3 May 2004 10:04:26 -0700 Message-ID: <191DA4FAE235D24C9BCC8D50F6B17AB9609498@hq-ex-11.brocade.com> Thread-Topic: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for FcPortType Thread-Index: AcQwpc8h8uE+sIDiR/2GAEAQPO8bzAAii75Q From: "Robert Snively" To: "Keith McCloghrie" Cc: , , , Content-Transfer-Encoding: quoted-printable Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable The point is that it provides absolutely no information that is not present in the "other" category. If you don't know in what sense it is dynamic and what resolutions and algorithms are necessary to resolve its dynamic behavior to some other behavior, you have gained no information about the port. "vendor specific other" might be a more useful value than dynamic, because that indicates that there is a mechanism to determine the "otherness" of the port through vendor=20 specific behaviors, where the vendor and model are known from other information in the MIB. "Dynamic" does not even have that grace. Bob > -----Original Message----- > From: t11_5-bounce@mailman.listserve.com > [mailto:t11_5-bounce@mailman.listserve.com]On Behalf Of Keith=20 > McCloghrie > Sent: Sunday, May 02, 2004 10:57 AM > To: Robert Snively > Cc: kzm@cisco.com; ips@ietf.org; t11_5@mail.t11.org;=20 > t11_3@mail.t11.org; > imss@ietf.org > Subject: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for > FcPortType >=20 >=20 > INCITS T11.5 Mail Reflector > ******************************** >=20 > Bob, >=20 > No, a MIB is not just a specification of syntax; a MIB is required=20 > to define the semantics of objects also. Otherwise, the MIB has no > value to a management application. So, a MIB with your "pre-specified > type values" *would* undergo a change (in semantics) as and when T11 > defined the semantics. >=20 > However, I agree with your recognition of the future need for: >=20 > a) "ports with a negotiation algorithm", as well as > b) "ports with a pre-established fixed type". >=20 > Since we cannot (see above) pre-define such types, if we removed > 'dyanmic' then both of these categories would have to be lumped > together under 'other'. The reason to retain 'dynamic' is to allow a > management application to distinguish between these two=20 > types. I don't > understand the strong opposition to allowing such a distinction. How > can anyone object to giving a management application more accurate > information ?? >=20 > Perhaps the problem is that I've failed to define/explain them > properly, or perhaps it's the word "dynamic" that you don't like. > So, how about we take the two current enumerations 'other'=20 > and 'dynamic' > and replace them with these two: >=20 > 'otherFixed' -- a fixed type (known to the agent) which is not one of > these types: 'nPort', 'nlPort' 'fPort' 'flPort'=20 > 'ePort' or 'bPort'. > 'otherNegotiate' -- a type (known to the agent), which is subject to > on-the-wire determination (e.g., by negotiation), but which is > not one of these types: 'gPort', 'glPort', 'fnlPort'. >=20 > Keith. >=20 > PS. I can't locate the definitions of 'gPort' and 'glPort'. I note > that 'fnlPort' is defined in sections 3.2.19 and 6.2.3.3.2 (Table 127) > of GS-4, and I would have expected to find G_Port and GL_Port in the > same/corresponding sections, but they're not. Please can you provide > me with a document name and section number reference for these two. > Or, am I mistaken in assuming that these new types have been approved > by T11 Ballot ?? >=20 >=20 > > Using David Black's consensus call, I will focus on=20 > > the "dynamic" question. > >=20 > > I am in agreement with Mike O'Donnell's=20 > > analysis of "unknown" and "other". I support his > > conclusions on "dynamic" (i.e. that it should be > > removed as a port type). > >=20 > > Keith McLoughrie indicates that dynamic is useful > > for future proofing. I believe that the most effective > > mechanism for future proofing would be to remove > > "dynamic" as a type, then provide a certain number > > of pre-specified type values for future assignment > > by INCITS TC T11 standards. That way, the MIB can remain=20 > unchanged and > > the > > values be picked up by future T11 standards if they > > are ever required. The number of such values should > > be small, since any large number of future variants would > > probably require modification to the MIB anyway. > >=20 > > That allows both for future definition of ports with a=20 > > negotiation algorithm and ports with a pre-established=20 > > fixed type, something that "dynamic" does not. > >=20 > > Robert Snively > >=20 > > Brocade Communications Systems, Inc. > > 1745 Technology Drive > > San Jose, CA 95110 > >=20 > > +1 408 333 8135 > > rsnively@brocade.com=20 > >=20 > >=20 > >=20 > >=20 > >=20 >=20 >=20 >=20 > To Unsubscribe: > mailto:t11_5-request@mail.t11.org?subject=3Dunsubscribe >=20 >=20 >=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon May 3 14:54:14 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20237 for ; Mon, 3 May 2004 14:54:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKiLX-0004Xd-Vy for ips-archive@odin.ietf.org; Mon, 03 May 2004 14:39:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43IdJUJ017457 for ips-archive@odin.ietf.org; Mon, 3 May 2004 14:39:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKiGH-0002ZI-P3 for ips-web-archive@optimus.ietf.org; Mon, 03 May 2004 14:33:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18962 for ; Mon, 3 May 2004 14:33:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKiGF-0003Ut-4j for ips-web-archive@ietf.org; Mon, 03 May 2004 14:33:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKiFP-0003OY-00 for ips-web-archive@ietf.org; Mon, 03 May 2004 14:33:00 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKiEp-0003Gk-00 for ips-web-archive@ietf.org; Mon, 03 May 2004 14:32:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKhzx-0006gH-Gb; Mon, 03 May 2004 14:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKhs5-0004yX-8S for ips@optimus.ietf.org; Mon, 03 May 2004 14:08:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17308 for ; Mon, 3 May 2004 14:08:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKhs2-0000SM-NU for ips@ietf.org; Mon, 03 May 2004 14:08:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKhrD-0000Ma-00 for ips@ietf.org; Mon, 03 May 2004 14:08:00 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BKhqg-0000GF-00; Mon, 03 May 2004 14:07:26 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 03 May 2004 10:21:00 +0000 Received: from cypher.cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i43I6mSu012631; Mon, 3 May 2004 11:06:51 -0700 (PDT) Received: (from kzm@localhost) by cypher.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id LAA03462; Mon, 3 May 2004 11:06:48 -0700 (PDT) From: Keith McCloghrie Message-Id: <200405031806.LAA03462@cypher.cisco.com> Subject: Re: [imss] RE: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for FcPortType To: rsnively@Brocade.COM (Robert Snively) Date: Mon, 3 May 2004 11:06:48 -0700 (PDT) Cc: kzm@cisco.com (Keith McCloghrie), ips@ietf.org, t11_5@mail.t11.org, t11_3@mail.t11.org, imss@ietf.org In-Reply-To: <191DA4FAE235D24C9BCC8D50F6B17AB9609498@hq-ex-11.brocade.com> from "Robert Snively" at May 03, 2004 10:04:26 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > The point is that it provides absolutely no information > that is not present in the "other" category. If you don't know > in what sense it is dynamic and what resolutions and algorithms > are necessary to resolve its dynamic behavior to some other > behavior, you have gained no information about the port. But it does, and you do gain information. Obviously, I am still failing to make you understand. Perhaps it's the word "fixed" which is now the problem; so, let me try again: 'otherFixed' -- a type which is known to the agent a priori and the port does not perform on-the-wire determination/negotiation, and is not one of these types: 'nPort', 'nlPort', 'fPort' 'flPort', 'ePort' or 'bPort'. 'otherNegotiate' -- the port type is determined via on-the-wire determination/negotiation, and is not one of these types: 'gPort', 'glPort', 'fnlPort'. Note: one of these is via on-the-wire determination/negotiation and one is not. By definition, they ARE different. > "vendor specific other" might be a more useful value than > dynamic, because that indicates that there is a mechanism > to determine the "otherness" of the port through vendor > specific behaviors, where the vendor and model are known from other > information in the MIB. "Dynamic" does not even have that > grace. No, no, no. Please don't read vendor-specific into this; it is not relevant. You didn't answer my question on whether the new types have been approved by T11 Ballot yet. Let me assume that they haven't, and that someone objects to adding them on that basis, then such ports would have to be represented by 'otherNegotiate' not by 'otherFixed'. So, no, 'otherNegotiate' is not vendor-specific. Keith. > Bob > > > -----Original Message----- > > From: t11_5-bounce@mailman.listserve.com > > [mailto:t11_5-bounce@mailman.listserve.com]On Behalf Of Keith > > McCloghrie > > Sent: Sunday, May 02, 2004 10:57 AM > > To: Robert Snively > > Cc: kzm@cisco.com; ips@ietf.org; t11_5@mail.t11.org; > > t11_3@mail.t11.org; > > imss@ietf.org > > Subject: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for > > FcPortType > > > > > > INCITS T11.5 Mail Reflector > > ******************************** > > > > Bob, > > > > No, a MIB is not just a specification of syntax; a MIB is required > > to define the semantics of objects also. Otherwise, the MIB has no > > value to a management application. So, a MIB with your "pre-specified > > type values" *would* undergo a change (in semantics) as and when T11 > > defined the semantics. > > > > However, I agree with your recognition of the future need for: > > > > a) "ports with a negotiation algorithm", as well as > > b) "ports with a pre-established fixed type". > > > > Since we cannot (see above) pre-define such types, if we removed > > 'dyanmic' then both of these categories would have to be lumped > > together under 'other'. The reason to retain 'dynamic' is to allow a > > management application to distinguish between these two > > types. I don't > > understand the strong opposition to allowing such a distinction. How > > can anyone object to giving a management application more accurate > > information ?? > > > > Perhaps the problem is that I've failed to define/explain them > > properly, or perhaps it's the word "dynamic" that you don't like. > > So, how about we take the two current enumerations 'other' > > and 'dynamic' > > and replace them with these two: > > > > 'otherFixed' -- a fixed type (known to the agent) which is not one of > > these types: 'nPort', 'nlPort' 'fPort' 'flPort' > > 'ePort' or 'bPort'. > > 'otherNegotiate' -- a type (known to the agent), which is subject to > > on-the-wire determination (e.g., by negotiation), but which is > > not one of these types: 'gPort', 'glPort', 'fnlPort'. > > > > Keith. > > > > PS. I can't locate the definitions of 'gPort' and 'glPort'. I note > > that 'fnlPort' is defined in sections 3.2.19 and 6.2.3.3.2 (Table 127) > > of GS-4, and I would have expected to find G_Port and GL_Port in the > > same/corresponding sections, but they're not. Please can you provide > > me with a document name and section number reference for these two. > > Or, am I mistaken in assuming that these new types have been approved > > by T11 Ballot ?? > > > > > > > Using David Black's consensus call, I will focus on > > > the "dynamic" question. > > > > > > I am in agreement with Mike O'Donnell's > > > analysis of "unknown" and "other". I support his > > > conclusions on "dynamic" (i.e. that it should be > > > removed as a port type). > > > > > > Keith McLoughrie indicates that dynamic is useful > > > for future proofing. I believe that the most effective > > > mechanism for future proofing would be to remove > > > "dynamic" as a type, then provide a certain number > > > of pre-specified type values for future assignment > > > by INCITS TC T11 standards. That way, the MIB can remain > > unchanged and > > > the > > > values be picked up by future T11 standards if they > > > are ever required. The number of such values should > > > be small, since any large number of future variants would > > > probably require modification to the MIB anyway. > > > > > > That allows both for future definition of ports with a > > > negotiation algorithm and ports with a pre-established > > > fixed type, something that "dynamic" does not. > > > > > > Robert Snively > > > > > > Brocade Communications Systems, Inc. > > > 1745 Technology Drive > > > San Jose, CA 95110 > > > > > > +1 408 333 8135 > > > rsnively@brocade.com > > > > > > > > > > > > > > > > > > > > > > > To Unsubscribe: > > mailto:t11_5-request@mail.t11.org?subject=unsubscribe > > > > > > > > _______________________________________________ > imss mailing list > imss@ietf.org > https://www1.ietf.org/mailman/listinfo/imss > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon May 3 15:19:35 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23325 for ; Mon, 3 May 2004 15:19:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKimY-0000QP-TC for ips-archive@odin.ietf.org; Mon, 03 May 2004 15:07:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43J7EeC001594 for ips-archive@odin.ietf.org; Mon, 3 May 2004 15:07:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKiiW-0005Si-J5 for ips-web-archive@optimus.ietf.org; Mon, 03 May 2004 15:03:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20733 for ; Mon, 3 May 2004 15:02:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKiiS-0006w0-Hm for ips-web-archive@ietf.org; Mon, 03 May 2004 15:03:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKiha-0006oj-00 for ips-web-archive@ietf.org; Mon, 03 May 2004 15:02:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKigj-0006hC-00 for ips-web-archive@ietf.org; Mon, 03 May 2004 15:01:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKiML-0004fs-0y; Mon, 03 May 2004 14:40:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKiFE-0002M3-Jc for ips@optimus.ietf.org; Mon, 03 May 2004 14:32:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18769 for ; Mon, 3 May 2004 14:32:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKiFB-0003Mf-Vn for ips@ietf.org; Mon, 03 May 2004 14:32:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKiEE-0003Cy-00 for ips@ietf.org; Mon, 03 May 2004 14:31:47 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BKiDF-0002zb-00; Mon, 03 May 2004 14:30:46 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 03 May 2004 10:43:09 +0000 Received: from cypher.cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i43IUDW9020416; Mon, 3 May 2004 11:30:13 -0700 (PDT) Received: (from kzm@localhost) by cypher.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id LAA14218; Mon, 3 May 2004 11:30:12 -0700 (PDT) From: Keith McCloghrie Message-Id: <200405031830.LAA14218@cypher.cisco.com> Subject: Re: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for FcPortType To: jcrandal@Brocade.COM (John Crandall) Date: Mon, 3 May 2004 11:30:12 -0700 (PDT) Cc: kzm@cisco.com (Keith McCloghrie), ips@ietf.org, t11_5@mail.t11.org, t11_3@mail.t11.org, imss@ietf.org, rsnively@Brocade.COM (Robert Snively) In-Reply-To: <191DA4FAE235D24C9BCC8D50F6B17AB9451E37@hq-ex-11.brocade.com> from "John Crandall" at May 03, 2004 11:14:28 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi John, I see them now (and I'll assume the GS-4 editor has an action-item to do the corresponding update to reflect the new values). Thanks, Keith. > Kieth, > > The definition of G and GL port are in FC-SW-3 (the latest revision). > > The text is: > > 3.1.45 G_Port: A generic Fabric Port that may function either as an > E_Port, or as an F_Port. > 3.1.46 GL_Port: A generic Fabric Port that may function either as an > E_Port, or as an Fx_Port. > > John > > -----Original Message----- > From: t11_5-bounce@mailman.listserve.com > [mailto:t11_5-bounce@mailman.listserve.com]On Behalf Of Robert Snively > Sent: Monday, May 03, 2004 10:04 AM > To: Keith McCloghrie > Cc: ips@ietf.org; t11_5@mail.t11.org; t11_3@mail.t11.org; imss@ietf.org > Subject: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for > FcPortType > > > INCITS T11.5 Mail Reflector > ******************************** > > The point is that it provides absolutely no information > that is not present in the "other" category. If you don't know > in what sense it is dynamic and what resolutions and algorithms > are necessary to resolve its dynamic behavior to some other > behavior, you have gained no information about the port. > > "vendor specific other" might be a more useful value than > dynamic, because that indicates that there is a mechanism > to determine the "otherness" of the port through vendor > specific behaviors, where the vendor and model are known from other > information in the MIB. "Dynamic" does not even have that > grace. > > Bob > > > -----Original Message----- > > From: t11_5-bounce@mailman.listserve.com > > [mailto:t11_5-bounce@mailman.listserve.com]On Behalf Of Keith > > McCloghrie > > Sent: Sunday, May 02, 2004 10:57 AM > > To: Robert Snively > > Cc: kzm@cisco.com; ips@ietf.org; t11_5@mail.t11.org; > > t11_3@mail.t11.org; > > imss@ietf.org > > Subject: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for > > FcPortType > > > > > > INCITS T11.5 Mail Reflector > > ******************************** > > > > Bob, > > > > No, a MIB is not just a specification of syntax; a MIB is required > > to define the semantics of objects also. Otherwise, the MIB has no > > value to a management application. So, a MIB with your "pre-specified > > type values" *would* undergo a change (in semantics) as and when T11 > > defined the semantics. > > > > However, I agree with your recognition of the future need for: > > > > a) "ports with a negotiation algorithm", as well as > > b) "ports with a pre-established fixed type". > > > > Since we cannot (see above) pre-define such types, if we removed > > 'dyanmic' then both of these categories would have to be lumped > > together under 'other'. The reason to retain 'dynamic' is to allow a > > management application to distinguish between these two > > types. I don't > > understand the strong opposition to allowing such a distinction. How > > can anyone object to giving a management application more accurate > > information ?? > > > > Perhaps the problem is that I've failed to define/explain them > > properly, or perhaps it's the word "dynamic" that you don't like. > > So, how about we take the two current enumerations 'other' > > and 'dynamic' > > and replace them with these two: > > > > 'otherFixed' -- a fixed type (known to the agent) which is not one of > > these types: 'nPort', 'nlPort' 'fPort' 'flPort' > > 'ePort' or 'bPort'. > > 'otherNegotiate' -- a type (known to the agent), which is subject to > > on-the-wire determination (e.g., by negotiation), but which is > > not one of these types: 'gPort', 'glPort', 'fnlPort'. > > > > Keith. > > > > PS. I can't locate the definitions of 'gPort' and 'glPort'. I note > > that 'fnlPort' is defined in sections 3.2.19 and 6.2.3.3.2 (Table 127) > > of GS-4, and I would have expected to find G_Port and GL_Port in the > > same/corresponding sections, but they're not. Please can you provide > > me with a document name and section number reference for these two. > > Or, am I mistaken in assuming that these new types have been approved > > by T11 Ballot ?? > > > > > > > Using David Black's consensus call, I will focus on > > > the "dynamic" question. > > > > > > I am in agreement with Mike O'Donnell's > > > analysis of "unknown" and "other". I support his > > > conclusions on "dynamic" (i.e. that it should be > > > removed as a port type). > > > > > > Keith McLoughrie indicates that dynamic is useful > > > for future proofing. I believe that the most effective > > > mechanism for future proofing would be to remove > > > "dynamic" as a type, then provide a certain number > > > of pre-specified type values for future assignment > > > by INCITS TC T11 standards. That way, the MIB can remain > > unchanged and > > > the > > > values be picked up by future T11 standards if they > > > are ever required. The number of such values should > > > be small, since any large number of future variants would > > > probably require modification to the MIB anyway. > > > > > > That allows both for future definition of ports with a > > > negotiation algorithm and ports with a pre-established > > > fixed type, something that "dynamic" does not. > > > > > > Robert Snively > > > > > > Brocade Communications Systems, Inc. > > > 1745 Technology Drive > > > San Jose, CA 95110 > > > > > > +1 408 333 8135 > > > rsnively@brocade.com > > > > > > > > > > > > > > > > > > > > > > > To Unsubscribe: > > mailto:t11_5-request@mail.t11.org?subject=unsubscribe > > > > > > > > > To Unsubscribe: > mailto:t11_5-request@mail.t11.org?subject=subscribe > > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon May 3 15:35:17 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24451 for ; Mon, 3 May 2004 15:35:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKj7o-0005Xj-8H for ips-archive@odin.ietf.org; Mon, 03 May 2004 15:29:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43JTCRh021305 for ips-archive@odin.ietf.org; Mon, 3 May 2004 15:29:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKivx-0002Qe-8m for ips-web-archive@optimus.ietf.org; Mon, 03 May 2004 15:16:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22898 for ; Mon, 3 May 2004 15:16:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKivw-000126-0n for ips-web-archive@ietf.org; Mon, 03 May 2004 15:16:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKiv8-0000ty-00 for ips-web-archive@ietf.org; Mon, 03 May 2004 15:16:07 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKiuE-0000mP-00 for ips-web-archive@ietf.org; Mon, 03 May 2004 15:15:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKijc-0006Zm-2U; Mon, 03 May 2004 15:04:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKiUq-0006bd-5q for ips@optimus.ietf.org; Mon, 03 May 2004 14:48:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19997 for ; Mon, 3 May 2004 14:48:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKiUn-0005IK-AB for ips@ietf.org; Mon, 03 May 2004 14:48:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKiTx-0005Bv-00 for ips@ietf.org; Mon, 03 May 2004 14:48:02 -0400 Received: from mcjekyll.mcdata.com ([144.49.6.25] helo=380GATE01out.mcdata.com) by ietf-mx with esmtp (Exim 4.12) id 1BKiT7-0004yK-00; Mon, 03 May 2004 14:47:09 -0400 Received: from 380GATE01.mcdata.com ([172.18.1.72]) by 380GATE01out.mcdata.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 3 May 2004 12:47:22 -0600 Received: from MC4EXCH03.mcdata.com ([172.16.11.122]) by 380GATE01 with InterScan Messaging Security Suite; Mon, 03 May 2004 12:47:21 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for FcPortType Date: Mon, 3 May 2004 12:47:21 -0600 Message-ID: <95C56F83F771C041B4EC26C4DAEEC942F2A7A4@MC4EXCH03.mcdata.com> Thread-Topic: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for FcPortType Thread-Index: AcQwpc8h8uE+sIDiR/2GAEAQPO8bzAAii75QAAIXTXA= From: "Mike O'Donnell" To: "Robert Snively" , "Keith McCloghrie" Cc: , , , X-OriginalArrivalTime: 03 May 2004 18:47:22.0551 (UTC) FILETIME=[11DB6C70:01C4313F] Content-Transfer-Encoding: quoted-printable Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Might I recommend we provide what the requirement is? I'm reading (at= least) two different things here: 1. A desire to 'future-proof' the MIB with respect to port types.=20 I may be misintepreting Keith's request, but I understood that was what you= meant by 'dynamic' (which I semantically dislike for this use). The= heartburn I have with this is that when we define the 2nd 'new' port type= in the future, 'dynamic' becomes ambiguous (unless we create a range as= was previously suggested). I do agree that defining new port types should= explicitly define their semantics. 2. A mechanism to convey vendor specific port types. For case number 2, 'vendor specific other' seems to fulfill a method for= allowing a vendor to implement an 'other' port type (recall that 'other'= means the agent can and has determined the port type) and the client may= issue subsequent queries to determine what the 'vendor unique port' type= is and make some sense from that information. Keith, am I anywhere close to understanding your needs for 'dynamic'? Or= is it both case 1 and 2 above? or? Mike O =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 Michael E. O'Donnell=20 Director Software Architecture=20 McDATA Corporation=20 4 McDATA Parkway=20 Broomfield, Colorado 80021=20 720.558.4142 (office)=20 303.570.3631 (cel)=20 mike.o'donnell@mcdata.com=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -----Original Message----- From: Robert Snively [mailto:rsnively@Brocade.COM] Sent: Monday, May 03, 2004 11:04 AM To: Keith McCloghrie Cc: ips@ietf.org; t11_5@mail.t11.org; t11_3@mail.t11.org; imss@ietf.org Subject: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for FcPortType INCITS T11.5 Mail Reflector ******************************** The point is that it provides absolutely no information that is not present in the "other" category. If you don't know in what sense it is dynamic and what resolutions and algorithms are necessary to resolve its dynamic behavior to some other behavior, you have gained no information about the port. "vendor specific other" might be a more useful value than dynamic, because that indicates that there is a mechanism to determine the "otherness" of the port through vendor=20 specific behaviors, where the vendor and model are known from other information in the MIB. "Dynamic" does not even have that grace. Bob > -----Original Message----- > From: t11_5-bounce@mailman.listserve.com > [mailto:t11_5-bounce@mailman.listserve.com]On Behalf Of Keith=20 > McCloghrie > Sent: Sunday, May 02, 2004 10:57 AM > To: Robert Snively > Cc: kzm@cisco.com; ips@ietf.org; t11_5@mail.t11.org;=20 > t11_3@mail.t11.org; > imss@ietf.org > Subject: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for > FcPortType >=20 >=20 > INCITS T11.5 Mail Reflector > ******************************** >=20 > Bob, >=20 > No, a MIB is not just a specification of syntax; a MIB is required=20 > to define the semantics of objects also. Otherwise, the MIB has no > value to a management application. So, a MIB with your "pre-specified > type values" *would* undergo a change (in semantics) as and when T11 > defined the semantics. >=20 > However, I agree with your recognition of the future need for: >=20 > a) "ports with a negotiation algorithm", as well as > b) "ports with a pre-established fixed type". >=20 > Since we cannot (see above) pre-define such types, if we removed > 'dyanmic' then both of these categories would have to be lumped > together under 'other'. The reason to retain 'dynamic' is to allow a > management application to distinguish between these two=20 > types. I don't > understand the strong opposition to allowing such a distinction. How > can anyone object to giving a management application more accurate > information ?? >=20 > Perhaps the problem is that I've failed to define/explain them > properly, or perhaps it's the word "dynamic" that you don't like. > So, how about we take the two current enumerations 'other'=20 > and 'dynamic' > and replace them with these two: >=20 > 'otherFixed' -- a fixed type (known to the agent) which is not one of > these types: 'nPort', 'nlPort' 'fPort' 'flPort'=20 > 'ePort' or 'bPort'. > 'otherNegotiate' -- a type (known to the agent), which is subject to > on-the-wire determination (e.g., by negotiation), but which is > not one of these types: 'gPort', 'glPort', 'fnlPort'. >=20 > Keith. >=20 > PS. I can't locate the definitions of 'gPort' and 'glPort'. I note > that 'fnlPort' is defined in sections 3.2.19 and 6.2.3.3.2 (Table 127) > of GS-4, and I would have expected to find G_Port and GL_Port in the > same/corresponding sections, but they're not. Please can you provide > me with a document name and section number reference for these two. > Or, am I mistaken in assuming that these new types have been approved > by T11 Ballot ?? >=20 >=20 > > Using David Black's consensus call, I will focus on=20 > > the "dynamic" question. > >=20 > > I am in agreement with Mike O'Donnell's=20 > > analysis of "unknown" and "other". I support his > > conclusions on "dynamic" (i.e. that it should be > > removed as a port type). > >=20 > > Keith McLoughrie indicates that dynamic is useful > > for future proofing. I believe that the most effective > > mechanism for future proofing would be to remove > > "dynamic" as a type, then provide a certain number > > of pre-specified type values for future assignment > > by INCITS TC T11 standards. That way, the MIB can remain=20 > unchanged and > > the > > values be picked up by future T11 standards if they > > are ever required. The number of such values should > > be small, since any large number of future variants would > > probably require modification to the MIB anyway. > >=20 > > That allows both for future definition of ports with a=20 > > negotiation algorithm and ports with a pre-established=20 > > fixed type, something that "dynamic" does not. > >=20 > > Robert Snively > >=20 > > Brocade Communications Systems, Inc. > > 1745 Technology Drive > > San Jose, CA 95110 > >=20 > > +1 408 333 8135 > > rsnively@brocade.com=20 > >=20 > >=20 > >=20 > >=20 > >=20 >=20 >=20 >=20 > To Unsubscribe: > mailto:t11_5-request@mail.t11.org?subject=3Dunsubscribe >=20 >=20 >=20 To Unsubscribe: mailto:t11_5-request@mail.t11.org?subject=3Dsubscribe SPECIAL NOTICE=20 All information transmitted hereby is intended only for the use of the=20 addressee(s) named above and may contain confidential and privileged=20 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=20 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=20 PROHIBITED. Anyone who receives confidential and privileged information in error should= =20 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=20 apply to that information. (gate01) _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon May 3 17:05:12 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01519 for ; Mon, 3 May 2004 17:05:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKjft-0006y2-76 for ips-archive@odin.ietf.org; Mon, 03 May 2004 16:04:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43K4PoP026783 for ips-archive@odin.ietf.org; Mon, 3 May 2004 16:04:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKjZc-0005lN-Gf for ips-web-archive@optimus.ietf.org; Mon, 03 May 2004 15:57:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25811 for ; Mon, 3 May 2004 15:57:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKjZa-0005jk-UZ for ips-web-archive@ietf.org; Mon, 03 May 2004 15:57:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKjYe-0005dj-00 for ips-web-archive@ietf.org; Mon, 03 May 2004 15:56:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKjYL-0005Xb-00 for ips-web-archive@ietf.org; Mon, 03 May 2004 15:56:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKjGL-0007fK-6h; Mon, 03 May 2004 15:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKhzk-0006fB-92 for ips@optimus.ietf.org; Mon, 03 May 2004 14:16:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17891 for ; Mon, 3 May 2004 14:16:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKhzh-0001RG-Q6 for ips@ietf.org; Mon, 03 May 2004 14:16:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKhyp-0001Jc-00 for ips@ietf.org; Mon, 03 May 2004 14:15:52 -0400 Received: from f112.brocade.com ([66.243.153.112] helo=blasphemy.brocade.com) by ietf-mx with esmtp (Exim 4.12) id 1BKhxy-00015B-00; Mon, 03 May 2004 14:14:59 -0400 Received: from hq-ex-11.corp.brocade.com (hq-ex-11 [192.168.38.58]) by blasphemy.brocade.com (Postfix) with ESMTP id 477891426B; Mon, 3 May 2004 11:14:28 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for FcPortType Date: Mon, 3 May 2004 11:14:28 -0700 Message-ID: <191DA4FAE235D24C9BCC8D50F6B17AB9451E37@hq-ex-11.brocade.com> Thread-Topic: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for FcPortType Thread-Index: AcQwpc8h8uE+sIDiR/2GAEAQPO8bzAAii75QAAKMqIA= From: "John Crandall" To: "Keith McCloghrie" Cc: , , , , "Robert Snively" Content-Transfer-Encoding: quoted-printable Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Kieth, The definition of G and GL port are in FC-SW-3 (the latest revision). The text is: 3.1.45 G_Port: A generic Fabric Port that may function either as an E_Port, or as an F_Port. 3.1.46 GL_Port: A generic Fabric Port that may function either as an E_Port, or as an Fx_Port. John -----Original Message----- From: t11_5-bounce@mailman.listserve.com [mailto:t11_5-bounce@mailman.listserve.com]On Behalf Of Robert Snively Sent: Monday, May 03, 2004 10:04 AM To: Keith McCloghrie Cc: ips@ietf.org; t11_5@mail.t11.org; t11_3@mail.t11.org; imss@ietf.org Subject: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for FcPortType INCITS T11.5 Mail Reflector ******************************** The point is that it provides absolutely no information that is not present in the "other" category. If you don't know in what sense it is dynamic and what resolutions and algorithms are necessary to resolve its dynamic behavior to some other behavior, you have gained no information about the port. "vendor specific other" might be a more useful value than dynamic, because that indicates that there is a mechanism to determine the "otherness" of the port through vendor=20 specific behaviors, where the vendor and model are known from other information in the MIB. "Dynamic" does not even have that grace. Bob > -----Original Message----- > From: t11_5-bounce@mailman.listserve.com > [mailto:t11_5-bounce@mailman.listserve.com]On Behalf Of Keith=20 > McCloghrie > Sent: Sunday, May 02, 2004 10:57 AM > To: Robert Snively > Cc: kzm@cisco.com; ips@ietf.org; t11_5@mail.t11.org;=20 > t11_3@mail.t11.org; > imss@ietf.org > Subject: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for > FcPortType >=20 >=20 > INCITS T11.5 Mail Reflector > ******************************** >=20 > Bob, >=20 > No, a MIB is not just a specification of syntax; a MIB is required=20 > to define the semantics of objects also. Otherwise, the MIB has no > value to a management application. So, a MIB with your "pre-specified > type values" *would* undergo a change (in semantics) as and when T11 > defined the semantics. >=20 > However, I agree with your recognition of the future need for: >=20 > a) "ports with a negotiation algorithm", as well as > b) "ports with a pre-established fixed type". >=20 > Since we cannot (see above) pre-define such types, if we removed > 'dyanmic' then both of these categories would have to be lumped > together under 'other'. The reason to retain 'dynamic' is to allow a > management application to distinguish between these two=20 > types. I don't > understand the strong opposition to allowing such a distinction. How > can anyone object to giving a management application more accurate > information ?? >=20 > Perhaps the problem is that I've failed to define/explain them > properly, or perhaps it's the word "dynamic" that you don't like. > So, how about we take the two current enumerations 'other'=20 > and 'dynamic' > and replace them with these two: >=20 > 'otherFixed' -- a fixed type (known to the agent) which is not one of > these types: 'nPort', 'nlPort' 'fPort' 'flPort'=20 > 'ePort' or 'bPort'. > 'otherNegotiate' -- a type (known to the agent), which is subject to > on-the-wire determination (e.g., by negotiation), but which is > not one of these types: 'gPort', 'glPort', 'fnlPort'. >=20 > Keith. >=20 > PS. I can't locate the definitions of 'gPort' and 'glPort'. I note > that 'fnlPort' is defined in sections 3.2.19 and 6.2.3.3.2 (Table 127) > of GS-4, and I would have expected to find G_Port and GL_Port in the > same/corresponding sections, but they're not. Please can you provide > me with a document name and section number reference for these two. > Or, am I mistaken in assuming that these new types have been approved > by T11 Ballot ?? >=20 >=20 > > Using David Black's consensus call, I will focus on=20 > > the "dynamic" question. > >=20 > > I am in agreement with Mike O'Donnell's=20 > > analysis of "unknown" and "other". I support his > > conclusions on "dynamic" (i.e. that it should be > > removed as a port type). > >=20 > > Keith McLoughrie indicates that dynamic is useful > > for future proofing. I believe that the most effective > > mechanism for future proofing would be to remove > > "dynamic" as a type, then provide a certain number > > of pre-specified type values for future assignment > > by INCITS TC T11 standards. That way, the MIB can remain=20 > unchanged and > > the > > values be picked up by future T11 standards if they > > are ever required. The number of such values should > > be small, since any large number of future variants would > > probably require modification to the MIB anyway. > >=20 > > That allows both for future definition of ports with a=20 > > negotiation algorithm and ports with a pre-established=20 > > fixed type, something that "dynamic" does not. > >=20 > > Robert Snively > >=20 > > Brocade Communications Systems, Inc. > > 1745 Technology Drive > > San Jose, CA 95110 > >=20 > > +1 408 333 8135 > > rsnively@brocade.com=20 > >=20 > >=20 > >=20 > >=20 > >=20 >=20 >=20 >=20 > To Unsubscribe: > mailto:t11_5-request@mail.t11.org?subject=3Dunsubscribe >=20 >=20 >=20 To Unsubscribe: mailto:t11_5-request@mail.t11.org?subject=3Dsubscribe _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon May 3 20:28:47 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13459 for ; Mon, 3 May 2004 20:28:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKnlJ-0002Cp-Lz for ips-archive@odin.ietf.org; Mon, 03 May 2004 20:26:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i440QH6C008474 for ips-archive@odin.ietf.org; Mon, 3 May 2004 20:26:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKniC-0001ih-Bn for ips-web-archive@optimus.ietf.org; Mon, 03 May 2004 20:23:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13230 for ; Mon, 3 May 2004 20:23:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKniA-00050g-8v for ips-web-archive@ietf.org; Mon, 03 May 2004 20:23:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKnhG-0004tI-00 for ips-web-archive@ietf.org; Mon, 03 May 2004 20:22:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKngT-0004m5-00 for ips-web-archive@ietf.org; Mon, 03 May 2004 20:21:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKneI-0000vg-Bq; Mon, 03 May 2004 20:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKncL-0000Wf-8G for ips@optimus.ietf.org; Mon, 03 May 2004 20:17:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12997 for ; Mon, 3 May 2004 20:16:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKncJ-00049j-3R for ips@ietf.org; Mon, 03 May 2004 20:16:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKnbO-00042Y-00 for ips@ietf.org; Mon, 03 May 2004 20:16:03 -0400 Received: from mcjekyll.mcdata.com ([144.49.6.25] helo=380GATE01out.mcdata.com) by ietf-mx with esmtp (Exim 4.12) id 1BKnag-0003od-00; Mon, 03 May 2004 20:15:19 -0400 Received: from 380GATE01.mcdata.com ([172.18.1.72]) by 380GATE01out.mcdata.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 3 May 2004 18:15:32 -0600 Received: from MC4EXCH03.mcdata.com ([172.16.11.122]) by 380GATE01 with InterScan Messaging Security Suite; Mon, 03 May 2004 18:15:32 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for FcPortType Date: Mon, 3 May 2004 18:15:32 -0600 Message-ID: <95C56F83F771C041B4EC26C4DAEEC942F2A7B2@MC4EXCH03.mcdata.com> Thread-Topic: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for FcPortType Thread-Index: AcQxYlDG6N7rGqc4TS2Dsx0v+WlufwABk6tw From: "Mike O'Donnell" To: "Keith McCloghrie" , "John Crandall" Cc: , , , , "Robert Snively" X-OriginalArrivalTime: 04 May 2004 00:15:32.0975 (UTC) FILETIME=[EA43AFF0:01C4316C] Content-Transfer-Encoding: quoted-printable Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Keith, Your request is reasonable. We can review such a requirement in GS-5 (gs-4= is all but complete and work is now underway in GS-5). =20 But after a quick inspection of GS-4, the reason port type of G and GL are= not specified is that in the GS-4 context they have no meaning (and I'm= certain any of my GS-4 counterparts will correct me if I'm wrong!). = Operations in GS-4 are relative to the negotiated state of a port (i.e.= F_port, E_Port, B_port...etc); not the potential state of a port (G or= GL). For example, you can't register a G_port (and even if you could, I'm= uncertain what any client would do with that information in the GS-4= context). Hence this why there is no definition needed in GS_4 (or GS-5).= If we need to add them for completeness we can discuss. =20 Having said that, we can return to the orginal discussion on the need for= 'Dynamic'. Regards, Mike O -----Original Message----- From: Keith McCloghrie [mailto:kzm@cisco.com] Sent: Monday, May 03, 2004 12:30 PM To: John Crandall Cc: Keith McCloghrie; ips@ietf.org; t11_5@mail.t11.org; t11_3@mail.t11.org; imss@ietf.org; Robert Snively Subject: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for FcPortType INCITS T11.5 Mail Reflector ******************************** Hi John, I see them now (and I'll assume the GS-4 editor has an action-item to do the corresponding update to reflect the new values). Thanks, Keith. =20 > Kieth, >=20 > The definition of G and GL port are in FC-SW-3 (the latest revision). >=20 > The text is: >=20 > 3.1.45 G_Port: A generic Fabric Port that may function either as an > E_Port, or as an F_Port. > 3.1.46 GL_Port: A generic Fabric Port that may function either as an > E_Port, or as an Fx_Port. >=20 > John >=20 > -----Original Message----- > From: t11_5-bounce@mailman.listserve.com > [mailto:t11_5-bounce@mailman.listserve.com]On Behalf Of Robert Snively > Sent: Monday, May 03, 2004 10:04 AM > To: Keith McCloghrie > Cc: ips@ietf.org; t11_5@mail.t11.org; t11_3@mail.t11.org; imss@ietf.org > Subject: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for > FcPortType >=20 >=20 > INCITS T11.5 Mail Reflector > ******************************** >=20 > The point is that it provides absolutely no information > that is not present in the "other" category. If you don't know > in what sense it is dynamic and what resolutions and algorithms > are necessary to resolve its dynamic behavior to some other > behavior, you have gained no information about the port. >=20 > "vendor specific other" might be a more useful value than > dynamic, because that indicates that there is a mechanism > to determine the "otherness" of the port through vendor=20 > specific behaviors, where the vendor and model are known from other > information in the MIB. "Dynamic" does not even have that > grace. >=20 > Bob >=20 > > -----Original Message----- > > From: t11_5-bounce@mailman.listserve.com > > [mailto:t11_5-bounce@mailman.listserve.com]On Behalf Of Keith=20 > > McCloghrie > > Sent: Sunday, May 02, 2004 10:57 AM > > To: Robert Snively > > Cc: kzm@cisco.com; ips@ietf.org; t11_5@mail.t11.org;=20 > > t11_3@mail.t11.org; > > imss@ietf.org > > Subject: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for > > FcPortType > >=20 > >=20 > > INCITS T11.5 Mail Reflector > > ******************************** > >=20 > > Bob, > >=20 > > No, a MIB is not just a specification of syntax; a MIB is required=20 > > to define the semantics of objects also. Otherwise, the MIB has no > > value to a management application. So, a MIB with your "pre-specified > > type values" *would* undergo a change (in semantics) as and when T11 > > defined the semantics. > >=20 > > However, I agree with your recognition of the future need for: > >=20 > > a) "ports with a negotiation algorithm", as well as > > b) "ports with a pre-established fixed type". > >=20 > > Since we cannot (see above) pre-define such types, if we removed > > 'dyanmic' then both of these categories would have to be lumped > > together under 'other'. The reason to retain 'dynamic' is to allow a > > management application to distinguish between these two=20 > > types. I don't > > understand the strong opposition to allowing such a distinction. How > > can anyone object to giving a management application more accurate > > information ?? > >=20 > > Perhaps the problem is that I've failed to define/explain them > > properly, or perhaps it's the word "dynamic" that you don't like. > > So, how about we take the two current enumerations 'other'=20 > > and 'dynamic' > > and replace them with these two: > >=20 > > 'otherFixed' -- a fixed type (known to the agent) which is not one of > > these types: 'nPort', 'nlPort' 'fPort' 'flPort'=20 > > 'ePort' or 'bPort'. > > 'otherNegotiate' -- a type (known to the agent), which is subject to > > on-the-wire determination (e.g., by negotiation), but which is > > not one of these types: 'gPort', 'glPort', 'fnlPort'. > >=20 > > Keith. > >=20 > > PS. I can't locate the definitions of 'gPort' and 'glPort'. I note > > that 'fnlPort' is defined in sections 3.2.19 and 6.2.3.3.2 (Table 127) > > of GS-4, and I would have expected to find G_Port and GL_Port in the > > same/corresponding sections, but they're not. Please can you provide > > me with a document name and section number reference for these two. > > Or, am I mistaken in assuming that these new types have been approved > > by T11 Ballot ?? > >=20 > >=20 > > > Using David Black's consensus call, I will focus on=20 > > > the "dynamic" question. > > >=20 > > > I am in agreement with Mike O'Donnell's=20 > > > analysis of "unknown" and "other". I support his > > > conclusions on "dynamic" (i.e. that it should be > > > removed as a port type). > > >=20 > > > Keith McLoughrie indicates that dynamic is useful > > > for future proofing. I believe that the most effective > > > mechanism for future proofing would be to remove > > > "dynamic" as a type, then provide a certain number > > > of pre-specified type values for future assignment > > > by INCITS TC T11 standards. That way, the MIB can remain=20 > > unchanged and > > > the > > > values be picked up by future T11 standards if they > > > are ever required. The number of such values should > > > be small, since any large number of future variants would > > > probably require modification to the MIB anyway. > > >=20 > > > That allows both for future definition of ports with a=20 > > > negotiation algorithm and ports with a pre-established=20 > > > fixed type, something that "dynamic" does not. > > >=20 > > > Robert Snively > > >=20 > > > Brocade Communications Systems, Inc. > > > 1745 Technology Drive > > > San Jose, CA 95110 > > >=20 > > > +1 408 333 8135 > > > rsnively@brocade.com=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > >=20 > >=20 > >=20 > > To Unsubscribe: > > mailto:t11_5-request@mail.t11.org?subject=3Dunsubscribe > >=20 > >=20 > >=20 >=20 >=20 > To Unsubscribe: > mailto:t11_5-request@mail.t11.org?subject=3Dsubscribe >=20 >=20 To Unsubscribe: mailto:t11_5-request@mail.t11.org?subject=3Dunsubscribe SPECIAL NOTICE=20 All information transmitted hereby is intended only for the use of the=20 addressee(s) named above and may contain confidential and privileged=20 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=20 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=20 PROHIBITED. Anyone who receives confidential and privileged information in error should= =20 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=20 apply to that information. (gate01) _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon May 3 23:13:32 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18930 for ; Mon, 3 May 2004 23:13:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKqLN-0007Rb-E9 for ips-archive@odin.ietf.org; Mon, 03 May 2004 23:11:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i443Bfj6028608 for ips-archive@odin.ietf.org; Mon, 3 May 2004 23:11:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKqKU-0007Cn-Oh for ips-web-archive@optimus.ietf.org; Mon, 03 May 2004 23:10:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18733 for ; Mon, 3 May 2004 23:10:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKqKQ-00031p-Sx for ips-web-archive@ietf.org; Mon, 03 May 2004 23:10:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKqIA-0002oj-00 for ips-web-archive@ietf.org; Mon, 03 May 2004 23:08:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKqFP-0002Sr-00 for ips-web-archive@ietf.org; Mon, 03 May 2004 23:05:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKqD0-0005X8-Bq; Mon, 03 May 2004 23:03:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKqBH-0005De-8r for ips@optimus.ietf.org; Mon, 03 May 2004 23:01:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18311 for ; Mon, 3 May 2004 23:01:10 -0400 (EDT) From: elizabeth.rodriguez@dothill.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKqBD-0001zf-MN for ips@ietf.org; Mon, 03 May 2004 23:01:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKqAL-0001r7-00 for ips@ietf.org; Mon, 03 May 2004 23:00:18 -0400 Received: from mail.dothill.com ([155.254.128.7] helo=dothill.com) by ietf-mx with esmtp (Exim 4.12) id 1BKq9R-0001hC-00; Mon, 03 May 2004 22:59:21 -0400 Received: from exchange.artecon.com (exchange [206.6.182.75]) by dothill.com (8.12.9+Sun/8.12.5) with ESMTP id i442tEjP020583; Mon, 3 May 2004 19:55:14 -0700 (PDT) Received: by EXCHANGE with Internet Mail Service (5.5.2653.19) id ; Mon, 3 May 2004 19:58:18 -0700 Message-ID: To: kzm@cisco.com, rsnively@Brocade.COM Cc: ips@ietf.org, t11_5@mail.t11.org, t11_3@mail.t11.org, imss@ietf.org Subject: RE: [T11.5] Re: [imss] RE: Re: [Ips] Proposal to remove "dynamic" port type for FcPortType Date: Mon, 3 May 2004 20:00:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Hi all, Instead of using a numerated list directly embedded in the MIB, could we address this issue through the creation of an IANA registry? Essentially, what this discussion comes down to is how do we future-proof the MIB. I believe that thru the use of a registry we may be able to accomplish Keith's goal without creating a MIB type that does not have a definition in today's T11 standards. Once new port types are defined by T11, a new port type could be assigned in the registry to correspond to that type for use in this MIB. I am not yet sure about the precedence for use of IANA registries with MIBs, and that is something I would need to consult with the transport and operations Area Directors, but is this an acceptable solution to everyone? Thanks, Elizabeth Rodriguez -----Original Message----- From: Keith McCloghrie [mailto:kzm@cisco.com] Sent: Monday, May 03, 2004 11:07 AM To: rsnively@Brocade.COM Cc: kzm@cisco.com; ips@ietf.org; t11_5@mail.t11.org; t11_3@mail.t11.org; imss@ietf.org Subject: [T11.5] Re: [imss] RE: Re: [Ips] Proposal to remove "dynamic" port type for FcPortType INCITS T11.5 Mail Reflector ******************************** > The point is that it provides absolutely no information > that is not present in the "other" category. If you don't know > in what sense it is dynamic and what resolutions and algorithms > are necessary to resolve its dynamic behavior to some other > behavior, you have gained no information about the port. But it does, and you do gain information. Obviously, I am still failing to make you understand. Perhaps it's the word "fixed" which is now the problem; so, let me try again: 'otherFixed' -- a type which is known to the agent a priori and the port does not perform on-the-wire determination/negotiation, and is not one of these types: 'nPort', 'nlPort', 'fPort' 'flPort', 'ePort' or 'bPort'. 'otherNegotiate' -- the port type is determined via on-the-wire determination/negotiation, and is not one of these types: 'gPort', 'glPort', 'fnlPort'. Note: one of these is via on-the-wire determination/negotiation and one is not. By definition, they ARE different. > "vendor specific other" might be a more useful value than > dynamic, because that indicates that there is a mechanism > to determine the "otherness" of the port through vendor > specific behaviors, where the vendor and model are known from other > information in the MIB. "Dynamic" does not even have that > grace. No, no, no. Please don't read vendor-specific into this; it is not relevant. You didn't answer my question on whether the new types have been approved by T11 Ballot yet. Let me assume that they haven't, and that someone objects to adding them on that basis, then such ports would have to be represented by 'otherNegotiate' not by 'otherFixed'. So, no, 'otherNegotiate' is not vendor-specific. Keith. > Bob > > > -----Original Message----- > > From: t11_5-bounce@mailman.listserve.com > > [mailto:t11_5-bounce@mailman.listserve.com]On Behalf Of Keith > > McCloghrie > > Sent: Sunday, May 02, 2004 10:57 AM > > To: Robert Snively > > Cc: kzm@cisco.com; ips@ietf.org; t11_5@mail.t11.org; > > t11_3@mail.t11.org; > > imss@ietf.org > > Subject: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for > > FcPortType > > > > > > INCITS T11.5 Mail Reflector > > ******************************** > > > > Bob, > > > > No, a MIB is not just a specification of syntax; a MIB is required > > to define the semantics of objects also. Otherwise, the MIB has no > > value to a management application. So, a MIB with your "pre-specified > > type values" *would* undergo a change (in semantics) as and when T11 > > defined the semantics. > > > > However, I agree with your recognition of the future need for: > > > > a) "ports with a negotiation algorithm", as well as > > b) "ports with a pre-established fixed type". > > > > Since we cannot (see above) pre-define such types, if we removed > > 'dyanmic' then both of these categories would have to be lumped > > together under 'other'. The reason to retain 'dynamic' is to allow a > > management application to distinguish between these two > > types. I don't > > understand the strong opposition to allowing such a distinction. How > > can anyone object to giving a management application more accurate > > information ?? > > > > Perhaps the problem is that I've failed to define/explain them > > properly, or perhaps it's the word "dynamic" that you don't like. > > So, how about we take the two current enumerations 'other' > > and 'dynamic' > > and replace them with these two: > > > > 'otherFixed' -- a fixed type (known to the agent) which is not one of > > these types: 'nPort', 'nlPort' 'fPort' 'flPort' > > 'ePort' or 'bPort'. > > 'otherNegotiate' -- a type (known to the agent), which is subject to > > on-the-wire determination (e.g., by negotiation), but which is > > not one of these types: 'gPort', 'glPort', 'fnlPort'. > > > > Keith. > > > > PS. I can't locate the definitions of 'gPort' and 'glPort'. I note > > that 'fnlPort' is defined in sections 3.2.19 and 6.2.3.3.2 (Table 127) > > of GS-4, and I would have expected to find G_Port and GL_Port in the > > same/corresponding sections, but they're not. Please can you provide > > me with a document name and section number reference for these two. > > Or, am I mistaken in assuming that these new types have been approved > > by T11 Ballot ?? > > > > > > > Using David Black's consensus call, I will focus on > > > the "dynamic" question. > > > > > > I am in agreement with Mike O'Donnell's > > > analysis of "unknown" and "other". I support his > > > conclusions on "dynamic" (i.e. that it should be > > > removed as a port type). > > > > > > Keith McLoughrie indicates that dynamic is useful > > > for future proofing. I believe that the most effective > > > mechanism for future proofing would be to remove > > > "dynamic" as a type, then provide a certain number > > > of pre-specified type values for future assignment > > > by INCITS TC T11 standards. That way, the MIB can remain > > unchanged and > > > the > > > values be picked up by future T11 standards if they > > > are ever required. The number of such values should > > > be small, since any large number of future variants would > > > probably require modification to the MIB anyway. > > > > > > That allows both for future definition of ports with a > > > negotiation algorithm and ports with a pre-established > > > fixed type, something that "dynamic" does not. > > > > > > Robert Snively > > > > > > Brocade Communications Systems, Inc. > > > 1745 Technology Drive > > > San Jose, CA 95110 > > > > > > +1 408 333 8135 > > > rsnively@brocade.com > > > > > > > > > > > > > > > > > > > > > > > To Unsubscribe: > > mailto:t11_5-request@mail.t11.org?subject=unsubscribe > > > > > > > > _______________________________________________ > imss mailing list > imss@ietf.org > https://www1.ietf.org/mailman/listinfo/imss > To Unsubscribe: mailto:t11_5-request@mail.t11.org?subject=unsubscribe _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue May 4 09:45:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01121 for ; Tue, 4 May 2004 09:45:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL065-00012r-D2 for ips-archive@odin.ietf.org; Tue, 04 May 2004 09:36:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44DaX3B004018 for ips-archive@odin.ietf.org; Tue, 4 May 2004 09:36:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL02K-0008BZ-Uf for ips-web-archive@optimus.ietf.org; Tue, 04 May 2004 09:32:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00485 for ; Tue, 4 May 2004 09:32:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL02J-0002A8-44 for ips-web-archive@ietf.org; Tue, 04 May 2004 09:32:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL01S-00027N-00 for ips-web-archive@ietf.org; Tue, 04 May 2004 09:31:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL00z-00023o-00 for ips-web-archive@ietf.org; Tue, 04 May 2004 09:31:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKzuy-0006VY-M7; Tue, 04 May 2004 09:25:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKzta-0006C6-Ei for ips@optimus.ietf.org; Tue, 04 May 2004 09:23:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00014 for ; Tue, 4 May 2004 09:23:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKztY-0001bo-Pc for ips@ietf.org; Tue, 04 May 2004 09:23:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKzsk-0001Y8-00 for ips@ietf.org; Tue, 04 May 2004 09:22:47 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BKzs0-0001RY-00; Tue, 04 May 2004 09:22:00 -0400 Received: from cypher.cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i44DLRSu012703; Tue, 4 May 2004 06:21:27 -0700 (PDT) Received: (from kzm@localhost) by cypher.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id GAA10574; Tue, 4 May 2004 06:21:26 -0700 (PDT) From: Keith McCloghrie Message-Id: <200405041321.GAA10574@cypher.cisco.com> Subject: Re: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for FcPortType6 To: mike.o'donnell@mcdata.com (Mike O'Donnell) Date: Tue, 4 May 2004 06:21:26 -0700 (PDT) Cc: kzm@cisco.com (Keith McCloghrie), jcrandal@Brocade.COM (John Crandall), ips@ietf.org, t11_5@mail.t11.org, t11_3@mail.t11.org, imss@ietf.org, rsnively@Brocade.COM (Robert Snively) In-Reply-To: <95C56F83F771C041B4EC26C4DAEEC942F2A7B2@MC4EXCH03.mcdata.com> from "Mike O'Donnell" at May 03, 2004 06:15:32 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,OFFERS_ETC autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mike, You raise a good point. It is natural for any "negotiation" to happen as part of the first flurry of messages on a link. That is, by the time the port is exchanging messages with the Fabric Config Server it will have finished any negotiation (and/or other determination). For example, I note that SW-3 says: "A G_Port determines through Port Initialization whether it operates as an E_Port or as an F_Port." In the case of the MIB, we have both fcmPortAdminType and fcmPortOperType. My expectation is that fcmPortAdminType will reflect the fact that the port is a G_Port or GL-Port, even after the "negotiation", but fcmPortOperType will reflect the result of the "negotiation". If you agree, I would propose to add a few words to the DESCRIPTIONs which note that. In the case of GS-4, its text doesn't seem to distinguish whether the specified values are for PortOperType or PortAdminType (and it's unclear to me whether a port is only ever registered by itself, or whether it can be registered via some other port). Thus, I'm happy to leave the issue of whether GS-4 represents AdminType and/or OperType as as an item for T11 to discuss, but my input would be to ask for some text in the document to be added to explain the issue, even if no new values are defined. Thanks, Keith. > Keith, > > Your request is reasonable. We can review such a requirement in GS-5 > (gs-4 is all but complete and work is now underway in GS-5). > > But after a quick inspection of GS-4, the reason port type of G and > GL are not specified is that in the GS-4 context they have no meaning > (and I'm certain any of my GS-4 counterparts will correct me if I'm > wrong!). Operations in GS-4 are relative to the negotiated state of a > port (i.e. F_port, E_Port, B_port...etc); not the potential state of a > port (G or GL). For example, you can't register a G_port (and even if > you could, I'm uncertain what any client would do with that information > in the GS-4 context). Hence this why there is no definition needed in > GS_4 (or GS-5). If we need to add them for completeness we can discuss. > > Having said that, we can return to the orginal discussion on the need for 'Dynamic'. > > Regards, > > Mike O > > > -----Original Message----- > From: Keith McCloghrie [mailto:kzm@cisco.com] > Sent: Monday, May 03, 2004 12:30 PM > To: John Crandall > Cc: Keith McCloghrie; ips@ietf.org; t11_5@mail.t11.org; > t11_3@mail.t11.org; imss@ietf.org; Robert Snively > Subject: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for > FcPortType > > > INCITS T11.5 Mail Reflector > ******************************** > > Hi John, > > I see them now (and I'll assume the GS-4 editor has an action-item > to do the corresponding update to reflect the new values). > > Thanks, > Keith. > > > Kieth, > > > > The definition of G and GL port are in FC-SW-3 (the latest revision). > > > > The text is: > > > > 3.1.45 G_Port: A generic Fabric Port that may function either as an > > E_Port, or as an F_Port. > > 3.1.46 GL_Port: A generic Fabric Port that may function either as an > > E_Port, or as an Fx_Port. > > > > John > > > > -----Original Message----- > > From: t11_5-bounce@mailman.listserve.com > > [mailto:t11_5-bounce@mailman.listserve.com]On Behalf Of Robert Snively > > Sent: Monday, May 03, 2004 10:04 AM > > To: Keith McCloghrie > > Cc: ips@ietf.org; t11_5@mail.t11.org; t11_3@mail.t11.org; imss@ietf.org > > Subject: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for > > FcPortType > > > > > > INCITS T11.5 Mail Reflector > > ******************************** > > > > The point is that it provides absolutely no information > > that is not present in the "other" category. If you don't know > > in what sense it is dynamic and what resolutions and algorithms > > are necessary to resolve its dynamic behavior to some other > > behavior, you have gained no information about the port. > > > > "vendor specific other" might be a more useful value than > > dynamic, because that indicates that there is a mechanism > > to determine the "otherness" of the port through vendor > > specific behaviors, where the vendor and model are known from other > > information in the MIB. "Dynamic" does not even have that > > grace. > > > > Bob > > > > > -----Original Message----- > > > From: t11_5-bounce@mailman.listserve.com > > > [mailto:t11_5-bounce@mailman.listserve.com]On Behalf Of Keith > > > McCloghrie > > > Sent: Sunday, May 02, 2004 10:57 AM > > > To: Robert Snively > > > Cc: kzm@cisco.com; ips@ietf.org; t11_5@mail.t11.org; > > > t11_3@mail.t11.org; > > > imss@ietf.org > > > Subject: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for > > > FcPortType > > > > > > > > > INCITS T11.5 Mail Reflector > > > ******************************** > > > > > > Bob, > > > > > > No, a MIB is not just a specification of syntax; a MIB is required > > > to define the semantics of objects also. Otherwise, the MIB has no > > > value to a management application. So, a MIB with your "pre-specified > > > type values" *would* undergo a change (in semantics) as and when T11 > > > defined the semantics. > > > > > > However, I agree with your recognition of the future need for: > > > > > > a) "ports with a negotiation algorithm", as well as > > > b) "ports with a pre-established fixed type". > > > > > > Since we cannot (see above) pre-define such types, if we removed > > > 'dyanmic' then both of these categories would have to be lumped > > > together under 'other'. The reason to retain 'dynamic' is to allow a > > > management application to distinguish between these two > > > types. I don't > > > understand the strong opposition to allowing such a distinction. How > > > can anyone object to giving a management application more accurate > > > information ?? > > > > > > Perhaps the problem is that I've failed to define/explain them > > > properly, or perhaps it's the word "dynamic" that you don't like. > > > So, how about we take the two current enumerations 'other' > > > and 'dynamic' > > > and replace them with these two: > > > > > > 'otherFixed' -- a fixed type (known to the agent) which is not one of > > > these types: 'nPort', 'nlPort' 'fPort' 'flPort' > > > 'ePort' or 'bPort'. > > > 'otherNegotiate' -- a type (known to the agent), which is subject to > > > on-the-wire determination (e.g., by negotiation), but which is > > > not one of these types: 'gPort', 'glPort', 'fnlPort'. > > > > > > Keith. > > > > > > PS. I can't locate the definitions of 'gPort' and 'glPort'. I note > > > that 'fnlPort' is defined in sections 3.2.19 and 6.2.3.3.2 (Table 127) > > > of GS-4, and I would have expected to find G_Port and GL_Port in the > > > same/corresponding sections, but they're not. Please can you provide > > > me with a document name and section number reference for these two. > > > Or, am I mistaken in assuming that these new types have been approved > > > by T11 Ballot ?? > > > > > > > > > > Using David Black's consensus call, I will focus on > > > > the "dynamic" question. > > > > > > > > I am in agreement with Mike O'Donnell's > > > > analysis of "unknown" and "other". I support his > > > > conclusions on "dynamic" (i.e. that it should be > > > > removed as a port type). > > > > > > > > Keith McLoughrie indicates that dynamic is useful > > > > for future proofing. I believe that the most effective > > > > mechanism for future proofing would be to remove > > > > "dynamic" as a type, then provide a certain number > > > > of pre-specified type values for future assignment > > > > by INCITS TC T11 standards. That way, the MIB can remain > > > unchanged and > > > > the > > > > values be picked up by future T11 standards if they > > > > are ever required. The number of such values should > > > > be small, since any large number of future variants would > > > > probably require modification to the MIB anyway. > > > > > > > > That allows both for future definition of ports with a > > > > negotiation algorithm and ports with a pre-established > > > > fixed type, something that "dynamic" does not. > > > > > > > > Robert Snively > > > > > > > > Brocade Communications Systems, Inc. > > > > 1745 Technology Drive > > > > San Jose, CA 95110 > > > > > > > > +1 408 333 8135 > > > > rsnively@brocade.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To Unsubscribe: > > > mailto:t11_5-request@mail.t11.org?subject=unsubscribe > > > > > > > > > > > > > > > To Unsubscribe: > > mailto:t11_5-request@mail.t11.org?subject=subscribe > > > > > > > > To Unsubscribe: > mailto:t11_5-request@mail.t11.org?subject=unsubscribe > > > 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. (gate01) > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue May 4 10:03:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02305 for ; Tue, 4 May 2004 10:03:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL0Se-0007Uu-Sn for ips-archive@odin.ietf.org; Tue, 04 May 2004 09:59:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44DxqRp028821 for ips-archive@odin.ietf.org; Tue, 4 May 2004 09:59:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL0Pb-0006VP-Ls for ips-web-archive@optimus.ietf.org; Tue, 04 May 2004 09:56:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01850 for ; Tue, 4 May 2004 09:56:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL0PZ-0003my-Of for ips-web-archive@ietf.org; Tue, 04 May 2004 09:56:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL0Oh-0003ia-00 for ips-web-archive@ietf.org; Tue, 04 May 2004 09:55:48 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL0O8-0003eH-00 for ips-web-archive@ietf.org; Tue, 04 May 2004 09:55:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL0FH-00044y-TN; Tue, 04 May 2004 09:46:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL0Cw-0003Lo-UP for ips@optimus.ietf.org; Tue, 04 May 2004 09:43:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00997 for ; Tue, 4 May 2004 09:43:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL0Cv-0002qZ-4X for ips@ietf.org; Tue, 04 May 2004 09:43:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL0C4-0002n7-00 for ips@ietf.org; Tue, 04 May 2004 09:42:46 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BL0Bm-0002jh-00; Tue, 04 May 2004 09:42:26 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 04 May 2004 05:54:58 +0000 Received: from cypher.cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i44DfqW9016697; Tue, 4 May 2004 06:41:52 -0700 (PDT) Received: (from kzm@localhost) by cypher.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id GAA14428; Tue, 4 May 2004 06:41:52 -0700 (PDT) From: Keith McCloghrie Message-Id: <200405041341.GAA14428@cypher.cisco.com> Subject: Re: [T11.5] Re: [imss] RE: Re: [Ips] Proposal to remove "dynamic" To: elizabeth.rodriguez@dothill.com Date: Tue, 4 May 2004 06:41:52 -0700 (PDT) Cc: kzm@cisco.com, rsnively@Brocade.COM, ips@ietf.org, t11_5@mail.t11.org, t11_3@mail.t11.org, imss@ietf.org In-Reply-To: from "elizabeth.rodriguez@dothill.com" at May 03, 2004 08:00:47 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Elizabeth, There are a couple of cases where IANA assigns enumerated values in a MIB, e.g., http://www.iana.org/assignments/ianaiftype-mib lists the latest version of the IANAifType TC which includes all the latest IANA assignments (including the last one of 'fcipLink' which I believe was requested by this WG.) Having IANA do this is necessary when the rate of new assignments is relatively high (e.g., there are now 224 values defined for IANAifType), but it has the downside that it increases the number of steps required to locate the latest assignments. To find the above URL, the primary author of that MIB had to go to the IANA web-page and figure out how to navigate through several web-pages in order to find it. It's much simpler for network adminstrators and/or management application writers to find the assignments when they are listed in the RFC's version of the MIB. In other words, I believe whether or not to have a IANA registry for a particular enumerated value in a MIB is a trade-off: worthwhile only if the rate of new assignments is high. In this case, Bob and Mike are in a much better position to know whether the rate of defining new port types is liable to be high. Keith. > Hi all, > > Instead of using a numerated list directly embedded in the MIB, could we > address this issue through the creation of an IANA registry? > > Essentially, what this discussion comes down to is how do we future-proof > the MIB. I believe that thru the use of a registry we may be able to > accomplish Keith's goal without creating a MIB type that does not have a > definition in today's T11 standards. Once new port types are defined by > T11, a new port type could be assigned in the registry to correspond to that > type for use in this MIB. > > I am not yet sure about the precedence for use of IANA registries with MIBs, > and that is something I would need to consult with the transport and > operations Area Directors, but is this an acceptable solution to everyone? > > Thanks, > > Elizabeth Rodriguez > > -----Original Message----- > From: Keith McCloghrie [mailto:kzm@cisco.com] > Sent: Monday, May 03, 2004 11:07 AM > To: rsnively@Brocade.COM > Cc: kzm@cisco.com; ips@ietf.org; t11_5@mail.t11.org; t11_3@mail.t11.org; > imss@ietf.org > Subject: [T11.5] Re: [imss] RE: Re: [Ips] Proposal to remove "dynamic" port > type for FcPortType > > INCITS T11.5 Mail Reflector > ******************************** > > > The point is that it provides absolutely no information > > that is not present in the "other" category. If you don't know > > in what sense it is dynamic and what resolutions and algorithms > > are necessary to resolve its dynamic behavior to some other > > behavior, you have gained no information about the port. > > But it does, and you do gain information. Obviously, I am still > failing to make you understand. Perhaps it's the word "fixed" > which is now the problem; so, let me try again: > > 'otherFixed' -- a type which is known to the agent a priori and > the port does not perform on-the-wire > determination/negotiation, and is not one of these > types: 'nPort', 'nlPort', 'fPort' 'flPort', 'ePort' > or 'bPort'. > 'otherNegotiate' -- the port type is determined via on-the-wire > determination/negotiation, and is not one of these > types: 'gPort', 'glPort', 'fnlPort'. > > Note: one of these is via on-the-wire determination/negotiation > and one is not. By definition, they ARE different. > > > "vendor specific other" might be a more useful value than > > dynamic, because that indicates that there is a mechanism > > to determine the "otherness" of the port through vendor > > specific behaviors, where the vendor and model are known from other > > information in the MIB. "Dynamic" does not even have that > > grace. > > No, no, no. Please don't read vendor-specific into this; it is not > relevant. You didn't answer my question on whether the new types have > been approved by T11 Ballot yet. Let me assume that they haven't, and > that someone objects to adding them on that basis, then such ports > would have to be represented by 'otherNegotiate' not by 'otherFixed'. > So, no, 'otherNegotiate' is not vendor-specific. > > Keith. > > > Bob > > > > > -----Original Message----- > > > From: t11_5-bounce@mailman.listserve.com > > > [mailto:t11_5-bounce@mailman.listserve.com]On Behalf Of Keith > > > McCloghrie > > > Sent: Sunday, May 02, 2004 10:57 AM > > > To: Robert Snively > > > Cc: kzm@cisco.com; ips@ietf.org; t11_5@mail.t11.org; > > > t11_3@mail.t11.org; > > > imss@ietf.org > > > Subject: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for > > > FcPortType > > > > > > > > > INCITS T11.5 Mail Reflector > > > ******************************** > > > > > > Bob, > > > > > > No, a MIB is not just a specification of syntax; a MIB is required > > > to define the semantics of objects also. Otherwise, the MIB has no > > > value to a management application. So, a MIB with your "pre-specified > > > type values" *would* undergo a change (in semantics) as and when T11 > > > defined the semantics. > > > > > > However, I agree with your recognition of the future need for: > > > > > > a) "ports with a negotiation algorithm", as well as > > > b) "ports with a pre-established fixed type". > > > > > > Since we cannot (see above) pre-define such types, if we removed > > > 'dyanmic' then both of these categories would have to be lumped > > > together under 'other'. The reason to retain 'dynamic' is to allow a > > > management application to distinguish between these two > > > types. I don't > > > understand the strong opposition to allowing such a distinction. How > > > can anyone object to giving a management application more accurate > > > information ?? > > > > > > Perhaps the problem is that I've failed to define/explain them > > > properly, or perhaps it's the word "dynamic" that you don't like. > > > So, how about we take the two current enumerations 'other' > > > and 'dynamic' > > > and replace them with these two: > > > > > > 'otherFixed' -- a fixed type (known to the agent) which is not one of > > > these types: 'nPort', 'nlPort' 'fPort' 'flPort' > > > 'ePort' or 'bPort'. > > > 'otherNegotiate' -- a type (known to the agent), which is subject to > > > on-the-wire determination (e.g., by negotiation), but which is > > > not one of these types: 'gPort', 'glPort', 'fnlPort'. > > > > > > Keith. > > > > > > PS. I can't locate the definitions of 'gPort' and 'glPort'. I note > > > that 'fnlPort' is defined in sections 3.2.19 and 6.2.3.3.2 (Table 127) > > > of GS-4, and I would have expected to find G_Port and GL_Port in the > > > same/corresponding sections, but they're not. Please can you provide > > > me with a document name and section number reference for these two. > > > Or, am I mistaken in assuming that these new types have been approved > > > by T11 Ballot ?? > > > > > > > > > > Using David Black's consensus call, I will focus on > > > > the "dynamic" question. > > > > > > > > I am in agreement with Mike O'Donnell's > > > > analysis of "unknown" and "other". I support his > > > > conclusions on "dynamic" (i.e. that it should be > > > > removed as a port type). > > > > > > > > Keith McLoughrie indicates that dynamic is useful > > > > for future proofing. I believe that the most effective > > > > mechanism for future proofing would be to remove > > > > "dynamic" as a type, then provide a certain number > > > > of pre-specified type values for future assignment > > > > by INCITS TC T11 standards. That way, the MIB can remain > > > unchanged and > > > > the > > > > values be picked up by future T11 standards if they > > > > are ever required. The number of such values should > > > > be small, since any large number of future variants would > > > > probably require modification to the MIB anyway. > > > > > > > > That allows both for future definition of ports with a > > > > negotiation algorithm and ports with a pre-established > > > > fixed type, something that "dynamic" does not. > > > > > > > > Robert Snively > > > > > > > > Brocade Communications Systems, Inc. > > > > 1745 Technology Drive > > > > San Jose, CA 95110 > > > > > > > > +1 408 333 8135 > > > > rsnively@brocade.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To Unsubscribe: > > > mailto:t11_5-request@mail.t11.org?subject=unsubscribe > > > > > > > > > > > > > _______________________________________________ > > imss mailing list > > imss@ietf.org > > https://www1.ietf.org/mailman/listinfo/imss > > > > > > To Unsubscribe: > mailto:t11_5-request@mail.t11.org?subject=unsubscribe > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue May 4 13:04:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12905 for ; Tue, 4 May 2004 13:04:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL3BM-0002i5-2r for ips-archive@odin.ietf.org; Tue, 04 May 2004 12:54:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44GsC28010411 for ips-archive@odin.ietf.org; Tue, 4 May 2004 12:54:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL38B-00012S-Gj for ips-web-archive@optimus.ietf.org; Tue, 04 May 2004 12:50:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12217 for ; Tue, 4 May 2004 12:50:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL389-0002BT-Uf for ips-web-archive@ietf.org; Tue, 04 May 2004 12:50:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL377-00025m-00 for ips-web-archive@ietf.org; Tue, 04 May 2004 12:49:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL36g-00020h-00 for ips-web-archive@ietf.org; Tue, 04 May 2004 12:49:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL2wk-000716-Qi; Tue, 04 May 2004 12:39:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL2sZ-0005Ce-Ol for ips@optimus.ietf.org; Tue, 04 May 2004 12:34:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11691 for ; Tue, 4 May 2004 12:34:44 -0400 (EDT) From: Black_David@emc.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL2sY-0000vo-3c for ips@ietf.org; Tue, 04 May 2004 12:34:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL2rf-0000qc-00 for ips@ietf.org; Tue, 04 May 2004 12:33:52 -0400 Received: from maho3msx2.isus.emc.com ([128.221.11.32] helo=MAHO3MSX2.corp.emc.com) by ietf-mx with esmtp (Exim 4.12) id 1BL2qq-0000fY-00; Tue, 04 May 2004 12:33:00 -0400 Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 May 2004 12:32:23 -0400 Message-ID: To: kzm@cisco.com Cc: ips@ietf.org, t11_5@mail.t11.org, t11_3@mail.t11.org, imss@ietf.org, Black_David@emc.com Subject: RE: [T11.5] Re: [imss] RE: Re: [Ips] Proposal to remove "dynamic" Date: Tue, 4 May 2004 12:32:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 ----- IANA registry > In other words, I believe whether or not to have a > IANA registry for a particular enumerated value in a MIB is a > trade-off: worthwhile only if the rate of new assignments is high. > > In this case, Bob and Mike are in a much better position to know > whether the rate of defining new port types is liable to be high. I like the idea of an IANA registry, but for a couple of reasons other than a potentially high rate of defining new port types: (1) Fast turnaround: A new port type could be added to an IANA registry in a matter of weeks after T11 determines that it is appropriate. Publishing a revised RFC takes months, even under ideal conditions, and conditions have not been ideal lately ... (2) Proper review: As part of setting up the registry, we can define the process for adding entries, allowing us to give IANA explicit written instructions on how to obtain T11's concurrence on allocations of new entries. This would be an aspect of Expert Review (cf. RFC 2434), and I would also impose a Specification Required requirement that can be satisfied by a T11 working version of a standard under development, (but not a proposal - I think it's fair to require that T11 have voted to incorporate the proposed new port type). I would expect a relatively low rate of new port type definitions (handful per year at most). If this makes sense, Elizabeth, Bob and I are at the T10 meetings in Monterey, and can easily work out how IANA should interact with T11 in the next few days. ----- MIB types The distinction between otherFixed and otherDynamic (otherNegotiate) may be useful because: - otherFixed means that the port type is not on the list and the port will not auto-negotiate to become some other type (and specifically won't become one of the known types on the list). - otherDynamic (or otherNegotiate) means that the port type is not on the list, but can auto-negotiate, which could result in it becoming one of the listed types (or some otherFixed type). Assuming that virtual fabric trunking/tagging goes forward in T11, two examples of port types that are likely to exist are: - a trunked tagged E_Port (like an E_Port, but carries traffic that's tagged with virtual fabric tags). This would be an otherFixed prior to its addition to the enumeration. - a new type of G_Port that could become a trunked E_Port, in addition to all the other things that an existing G_Port can become. This would be an otherDynamic (otherNegotiate) prior to its addition to the enumeration. Do people think this distinction is useful? If it's useful, then we'd need to change "dynamic" to "otherDynamic" and "other" to "otherFixed". Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: ips-admin@ietf.org [mailto:ips-admin@ietf.org] On > Behalf Of Keith McCloghrie > Sent: Tuesday, May 04, 2004 9:42 AM > To: elizabeth.rodriguez@dothill.com > Cc: kzm@cisco.com; rsnively@Brocade.COM; ips@ietf.org; > t11_5@mail.t11.org; t11_3@mail.t11.org; imss@ietf.org > Subject: Re: [T11.5] Re: [imss] RE: Re: [Ips] Proposal to > remove "dynamic" > > > Hi Elizabeth, > > There are a couple of cases where IANA assigns enumerated values in > a MIB, e.g., http://www.iana.org/assignments/ianaiftype-mib lists the > latest version of the IANAifType TC which includes all the latest IANA > assignments (including the last one of 'fcipLink' which I believe was > requested by this WG.) > > Having IANA do this is necessary when the rate of new assignments is > relatively high (e.g., there are now 224 values defined for > IANAifType), > but it has the downside that it increases the number of steps required > to locate the latest assignments. To find the above URL, the primary > author of that MIB had to go to the IANA web-page and figure out how > to navigate through several web-pages in order to find it. It's much > simpler for network adminstrators and/or management application > writers to find the assignments when they are listed in the RFC's > version of the MIB. In other words, I believe whether or not > to have a > IANA registry for a particular enumerated value in a MIB is a > trade-off: worthwhile only if the rate of new assignments is high. > > In this case, Bob and Mike are in a much better position to know > whether the rate of defining new port types is liable to be high. > > Keith. > > > Hi all, > > > > Instead of using a numerated list directly embedded in the > MIB, could we > > address this issue through the creation of an IANA registry? > > > > Essentially, what this discussion comes down to is how do > we future-proof > > the MIB. I believe that thru the use of a registry we may > be able to > > accomplish Keith's goal without creating a MIB type that > does not have a > > definition in today's T11 standards. Once new port types > are defined by > > T11, a new port type could be assigned in the registry to > correspond to that > > type for use in this MIB. > > > > I am not yet sure about the precedence for use of IANA > registries with MIBs, > > and that is something I would need to consult with the transport and > > operations Area Directors, but is this an acceptable > solution to everyone? > > > > Thanks, > > > > Elizabeth Rodriguez > > > > -----Original Message----- > > From: Keith McCloghrie [mailto:kzm@cisco.com] > > Sent: Monday, May 03, 2004 11:07 AM > > To: rsnively@Brocade.COM > > Cc: kzm@cisco.com; ips@ietf.org; t11_5@mail.t11.org; > t11_3@mail.t11.org; > > imss@ietf.org > > Subject: [T11.5] Re: [imss] RE: Re: [Ips] Proposal to > remove "dynamic" port > > type for FcPortType > > > > INCITS T11.5 Mail Reflector > > ******************************** > > > > > The point is that it provides absolutely no information > > > that is not present in the "other" category. If you don't know > > > in what sense it is dynamic and what resolutions and algorithms > > > are necessary to resolve its dynamic behavior to some other > > > behavior, you have gained no information about the port. > > > > But it does, and you do gain information. Obviously, I am still > > failing to make you understand. Perhaps it's the word "fixed" > > which is now the problem; so, let me try again: > > > > 'otherFixed' -- a type which is known to the agent a priori and > > the port does not perform on-the-wire > > determination/negotiation, and is not one of these > > types: 'nPort', 'nlPort', 'fPort' 'flPort', 'ePort' > > or 'bPort'. > > 'otherNegotiate' -- the port type is determined via on-the-wire > > determination/negotiation, and is not one of these > > types: 'gPort', 'glPort', 'fnlPort'. > > > > Note: one of these is via on-the-wire determination/negotiation > > and one is not. By definition, they ARE different. > > > > > "vendor specific other" might be a more useful value than > > > dynamic, because that indicates that there is a mechanism > > > to determine the "otherness" of the port through vendor > > > specific behaviors, where the vendor and model are known > from other > > > information in the MIB. "Dynamic" does not even have that > > > grace. > > > > No, no, no. Please don't read vendor-specific into this; it is not > > relevant. You didn't answer my question on whether the new > types have > > been approved by T11 Ballot yet. Let me assume that they > haven't, and > > that someone objects to adding them on that basis, then such ports > > would have to be represented by 'otherNegotiate' not by > 'otherFixed'. > > So, no, 'otherNegotiate' is not vendor-specific. > > > > Keith. [... snip ...] _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue May 4 13:19:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13967 for ; Tue, 4 May 2004 13:19:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL3Z5-0001eO-05 for ips-archive@odin.ietf.org; Tue, 04 May 2004 13:18:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44HIg3v006340 for ips-archive@odin.ietf.org; Tue, 4 May 2004 13:18:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL3WR-0000ki-1L for ips-web-archive@optimus.ietf.org; Tue, 04 May 2004 13:15:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13668 for ; Tue, 4 May 2004 13:15:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL3WP-0004pW-3V for ips-web-archive@ietf.org; Tue, 04 May 2004 13:15:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL3VK-0004jq-00 for ips-web-archive@ietf.org; Tue, 04 May 2004 13:14:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL3Ui-0004ec-00 for ips-web-archive@ietf.org; Tue, 04 May 2004 13:14:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL3Lr-0005iB-NE; Tue, 04 May 2004 13:05:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL3C1-0002vk-Tl for ips@optimus.ietf.org; Tue, 04 May 2004 12:54:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12403 for ; Tue, 4 May 2004 12:54:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL3C0-0002al-7d for ips@ietf.org; Tue, 04 May 2004 12:54:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL3B3-0002TP-00 for ips@ietf.org; Tue, 04 May 2004 12:53:55 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BL3AK-0002IK-00; Tue, 04 May 2004 12:53:08 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 04 May 2004 09:06:50 +0000 Received: from cypher.cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i44GqUW9011538; Tue, 4 May 2004 09:52:30 -0700 (PDT) Received: (from kzm@localhost) by cypher.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id JAA16468; Tue, 4 May 2004 09:52:30 -0700 (PDT) From: Keith McCloghrie Message-Id: <200405041652.JAA16468@cypher.cisco.com> Subject: Re: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for FcPortType To: mike.o'donnell@mcdata.com (Mike O'Donnell) Date: Tue, 4 May 2004 09:52:30 -0700 (PDT) Cc: rsnively@Brocade.COM (Robert Snively), kzm@cisco.com (Keith McCloghrie), ips@ietf.org, t11_5@mail.t11.org, t11_3@mail.t11.org, imss@ietf.org In-Reply-To: <95C56F83F771C041B4EC26C4DAEEC942F2A7A4@MC4EXCH03.mcdata.com> from "Mike O'Donnell" at May 03, 2004 12:47:21 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,OFFERS_ETC autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mike, While I do want to split 'other' into two enumerations, it is only Bob Sniveley who has proposed "vendor specific other", which is absolutely NOT the way I want to cut it, because (as I said before) I want something which can be used for a future T11-specified type which is: a) not specified in the MIB (and after the RFC is published it will at least 3 years and probably more like 5 years (or never!!) before we could get an update published), and b) which results in an on-the-wire negotiation and/or determination of the type. Elizabeth understands want I'm asking for, because her suggestion of a registry is more than sufficient to meet my "requirement"; the question is whether a registration is necessary. The truth is that I don't really have a "requirement"; before this latest flurry of messages, the MIB contained 'dynamic'; as we add the new types, I still see potential future value in something like 'dynamic'; thus, it makes sense to me to keep it, renamed to whatever you like. Keith. PS. I fear that I have been repeating in one message what I have previously said in another message; if anyone else thinks that also, then I apologise to them, but ... > Might I recommend we provide what the requirement is? I'm reading (at least) two different things here: > > 1. A desire to 'future-proof' the MIB with respect to port types. > > I may be misintepreting Keith's request, but I understood that was what you meant by 'dynamic' (which I semantically dislike for this use). The heartburn I have with this is that when we define the 2nd 'new' port type in the future, 'dynamic' becomes ambiguous (unless we create a range as was previously suggested). I do agree that defining new port types should explicitly define their semantics. > > 2. A mechanism to convey vendor specific port types. > > For case number 2, 'vendor specific other' seems to fulfill a method for allowing a vendor to implement an 'other' port type (recall that 'other' means the agent can and has determined the port type) and the client may issue subsequent queries to determine what the 'vendor unique port' type is and make some sense from that information. > > Keith, am I anywhere close to understanding your needs for 'dynamic'? Or is it both case 1 and 2 above? or? > > Mike O > > ====================== > Michael E. O'Donnell > Director Software Architecture > McDATA Corporation > 4 McDATA Parkway > Broomfield, Colorado 80021 > 720.558.4142 (office) > 303.570.3631 (cel) > mike.o'donnell@mcdata.com > ====================== > > > > > -----Original Message----- > From: Robert Snively [mailto:rsnively@Brocade.COM] > Sent: Monday, May 03, 2004 11:04 AM > To: Keith McCloghrie > Cc: ips@ietf.org; t11_5@mail.t11.org; t11_3@mail.t11.org; imss@ietf.org > Subject: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for > FcPortType > > > INCITS T11.5 Mail Reflector > ******************************** > > The point is that it provides absolutely no information > that is not present in the "other" category. If you don't know > in what sense it is dynamic and what resolutions and algorithms > are necessary to resolve its dynamic behavior to some other > behavior, you have gained no information about the port. > > "vendor specific other" might be a more useful value than > dynamic, because that indicates that there is a mechanism > to determine the "otherness" of the port through vendor > specific behaviors, where the vendor and model are known from other > information in the MIB. "Dynamic" does not even have that > grace. > > Bob > > > -----Original Message----- > > From: t11_5-bounce@mailman.listserve.com > > [mailto:t11_5-bounce@mailman.listserve.com]On Behalf Of Keith > > McCloghrie > > Sent: Sunday, May 02, 2004 10:57 AM > > To: Robert Snively > > Cc: kzm@cisco.com; ips@ietf.org; t11_5@mail.t11.org; > > t11_3@mail.t11.org; > > imss@ietf.org > > Subject: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for > > FcPortType > > > > > > INCITS T11.5 Mail Reflector > > ******************************** > > > > Bob, > > > > No, a MIB is not just a specification of syntax; a MIB is required > > to define the semantics of objects also. Otherwise, the MIB has no > > value to a management application. So, a MIB with your "pre-specified > > type values" *would* undergo a change (in semantics) as and when T11 > > defined the semantics. > > > > However, I agree with your recognition of the future need for: > > > > a) "ports with a negotiation algorithm", as well as > > b) "ports with a pre-established fixed type". > > > > Since we cannot (see above) pre-define such types, if we removed > > 'dyanmic' then both of these categories would have to be lumped > > together under 'other'. The reason to retain 'dynamic' is to allow a > > management application to distinguish between these two > > types. I don't > > understand the strong opposition to allowing such a distinction. How > > can anyone object to giving a management application more accurate > > information ?? > > > > Perhaps the problem is that I've failed to define/explain them > > properly, or perhaps it's the word "dynamic" that you don't like. > > So, how about we take the two current enumerations 'other' > > and 'dynamic' > > and replace them with these two: > > > > 'otherFixed' -- a fixed type (known to the agent) which is not one of > > these types: 'nPort', 'nlPort' 'fPort' 'flPort' > > 'ePort' or 'bPort'. > > 'otherNegotiate' -- a type (known to the agent), which is subject to > > on-the-wire determination (e.g., by negotiation), but which is > > not one of these types: 'gPort', 'glPort', 'fnlPort'. > > > > Keith. > > > > PS. I can't locate the definitions of 'gPort' and 'glPort'. I note > > that 'fnlPort' is defined in sections 3.2.19 and 6.2.3.3.2 (Table 127) > > of GS-4, and I would have expected to find G_Port and GL_Port in the > > same/corresponding sections, but they're not. Please can you provide > > me with a document name and section number reference for these two. > > Or, am I mistaken in assuming that these new types have been approved > > by T11 Ballot ?? > > > > > > > Using David Black's consensus call, I will focus on > > > the "dynamic" question. > > > > > > I am in agreement with Mike O'Donnell's > > > analysis of "unknown" and "other". I support his > > > conclusions on "dynamic" (i.e. that it should be > > > removed as a port type). > > > > > > Keith McLoughrie indicates that dynamic is useful > > > for future proofing. I believe that the most effective > > > mechanism for future proofing would be to remove > > > "dynamic" as a type, then provide a certain number > > > of pre-specified type values for future assignment > > > by INCITS TC T11 standards. That way, the MIB can remain > > unchanged and > > > the > > > values be picked up by future T11 standards if they > > > are ever required. The number of such values should > > > be small, since any large number of future variants would > > > probably require modification to the MIB anyway. > > > > > > That allows both for future definition of ports with a > > > negotiation algorithm and ports with a pre-established > > > fixed type, something that "dynamic" does not. > > > > > > Robert Snively > > > > > > Brocade Communications Systems, Inc. > > > 1745 Technology Drive > > > San Jose, CA 95110 > > > > > > +1 408 333 8135 > > > rsnively@brocade.com > > > > > > > > > > > > > > > > > > > > > > > To Unsubscribe: > > mailto:t11_5-request@mail.t11.org?subject=unsubscribe > > > > > > > > > To Unsubscribe: > mailto:t11_5-request@mail.t11.org?subject=subscribe > > > 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. (gate01) > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue May 4 13:39:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14951 for ; Tue, 4 May 2004 13:39:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL3mV-0005kh-Lm for ips-archive@odin.ietf.org; Tue, 04 May 2004 13:32:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44HWZEJ022112 for ips-archive@odin.ietf.org; Tue, 4 May 2004 13:32:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL3hw-0003lI-GJ for ips-web-archive@optimus.ietf.org; Tue, 04 May 2004 13:27:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14500 for ; Tue, 4 May 2004 13:27:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL3hu-00064p-Fh for ips-web-archive@ietf.org; Tue, 04 May 2004 13:27:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL3gz-0005yr-00 for ips-web-archive@ietf.org; Tue, 04 May 2004 13:26:54 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL3gN-0005ss-00 for ips-web-archive@ietf.org; Tue, 04 May 2004 13:26:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL3ZR-0001o1-OP; Tue, 04 May 2004 13:19:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL3SR-0008Kp-Dv for ips@optimus.ietf.org; Tue, 04 May 2004 13:11:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13449 for ; Tue, 4 May 2004 13:11:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL3SP-0004Pu-KK for ips@ietf.org; Tue, 04 May 2004 13:11:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL3Rb-0004IP-00 for ips@ietf.org; Tue, 04 May 2004 13:11:00 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BL3Qj-00043h-00; Tue, 04 May 2004 13:10:05 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 04 May 2004 09:23:53 +0000 Received: from cypher.cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i44H9WW9010114; Tue, 4 May 2004 10:09:32 -0700 (PDT) Received: (from kzm@localhost) by cypher.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id KAA27856; Tue, 4 May 2004 10:09:32 -0700 (PDT) From: Keith McCloghrie Message-Id: <200405041709.KAA27856@cypher.cisco.com> Subject: Re: [T11.5] Re: [imss] RE: Re: [Ips] Proposal to remove "dynamic" To: Black_David@emc.com Date: Tue, 4 May 2004 10:09:32 -0700 (PDT) Cc: kzm@cisco.com, ips@ietf.org, t11_5@mail.t11.org, t11_3@mail.t11.org, imss@ietf.org In-Reply-To: from "Black_David@emc.com" at May 04, 2004 12:32:22 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit David, Thank-you. I have already given my input on the questions you ask. I'm happy to leave you to determine the consensus on these issues. Keith. > ----- IANA registry > > > In other words, I believe whether or not to have a > > IANA registry for a particular enumerated value in a MIB is a > > trade-off: worthwhile only if the rate of new assignments is high. > > > > In this case, Bob and Mike are in a much better position to know > > whether the rate of defining new port types is liable to be high. > > I like the idea of an IANA registry, but for a couple of reasons > other than a potentially high rate of defining new port types: > > (1) Fast turnaround: A new port type could be added to an IANA > registry in a matter of weeks after T11 determines that > it is appropriate. Publishing a revised RFC takes months, > even under ideal conditions, and conditions have not been > ideal lately ... > (2) Proper review: As part of setting up the registry, we can > define the process for adding entries, allowing us to give > IANA explicit written instructions on how to obtain T11's > concurrence on allocations of new entries. This would be an > aspect of Expert Review (cf. RFC 2434), and I would also impose > a Specification Required requirement that can be satisfied > by a T11 working version of a standard under development, > (but not a proposal - I think it's fair to require that T11 > have voted to incorporate the proposed new port type). > > I would expect a relatively low rate of new port type definitions > (handful per year at most). > > If this makes sense, Elizabeth, Bob and I are at the T10 meetings > in Monterey, and can easily work out how IANA should interact with > T11 in the next few days. > > ----- MIB types > > The distinction between otherFixed and otherDynamic (otherNegotiate) > may be useful because: > > - otherFixed means that the port type is not on the list and > the port will not auto-negotiate to become some other type > (and specifically won't become one of the known types on > the list). > - otherDynamic (or otherNegotiate) means that the port type is > not on the list, but can auto-negotiate, which could result > in it becoming one of the listed types (or some otherFixed type). > > Assuming that virtual fabric trunking/tagging goes forward in T11, > two examples of port types that are likely to exist are: > > - a trunked tagged E_Port (like an E_Port, but carries traffic > that's tagged with virtual fabric tags). This would be > an otherFixed prior to its addition to the enumeration. > - a new type of G_Port that could become a trunked E_Port, in > addition to all the other things that an existing G_Port > can become. This would be an otherDynamic (otherNegotiate) > prior to its addition to the enumeration. > > Do people think this distinction is useful? If it's useful, then > we'd need to change "dynamic" to "otherDynamic" and "other" to > "otherFixed". > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > > > -----Original Message----- > > From: ips-admin@ietf.org [mailto:ips-admin@ietf.org] On > > Behalf Of Keith McCloghrie > > Sent: Tuesday, May 04, 2004 9:42 AM > > To: elizabeth.rodriguez@dothill.com > > Cc: kzm@cisco.com; rsnively@Brocade.COM; ips@ietf.org; > > t11_5@mail.t11.org; t11_3@mail.t11.org; imss@ietf.org > > Subject: Re: [T11.5] Re: [imss] RE: Re: [Ips] Proposal to > > remove "dynamic" > > > > > > Hi Elizabeth, > > > > There are a couple of cases where IANA assigns enumerated values in > > a MIB, e.g., http://www.iana.org/assignments/ianaiftype-mib lists the > > latest version of the IANAifType TC which includes all the latest IANA > > assignments (including the last one of 'fcipLink' which I believe was > > requested by this WG.) > > > > Having IANA do this is necessary when the rate of new assignments is > > relatively high (e.g., there are now 224 values defined for > > IANAifType), > > but it has the downside that it increases the number of steps required > > to locate the latest assignments. To find the above URL, the primary > > author of that MIB had to go to the IANA web-page and figure out how > > to navigate through several web-pages in order to find it. It's much > > simpler for network adminstrators and/or management application > > writers to find the assignments when they are listed in the RFC's > > version of the MIB. In other words, I believe whether or not > > to have a > > IANA registry for a particular enumerated value in a MIB is a > > trade-off: worthwhile only if the rate of new assignments is high. > > > > In this case, Bob and Mike are in a much better position to know > > whether the rate of defining new port types is liable to be high. > > > > Keith. > > > > > Hi all, > > > > > > Instead of using a numerated list directly embedded in the > > MIB, could we > > > address this issue through the creation of an IANA registry? > > > > > > Essentially, what this discussion comes down to is how do > > we future-proof > > > the MIB. I believe that thru the use of a registry we may > > be able to > > > accomplish Keith's goal without creating a MIB type that > > does not have a > > > definition in today's T11 standards. Once new port types > > are defined by > > > T11, a new port type could be assigned in the registry to > > correspond to that > > > type for use in this MIB. > > > > > > I am not yet sure about the precedence for use of IANA > > registries with MIBs, > > > and that is something I would need to consult with the transport and > > > operations Area Directors, but is this an acceptable > > solution to everyone? > > > > > > Thanks, > > > > > > Elizabeth Rodriguez > > > > > > -----Original Message----- > > > From: Keith McCloghrie [mailto:kzm@cisco.com] > > > Sent: Monday, May 03, 2004 11:07 AM > > > To: rsnively@Brocade.COM > > > Cc: kzm@cisco.com; ips@ietf.org; t11_5@mail.t11.org; > > t11_3@mail.t11.org; > > > imss@ietf.org > > > Subject: [T11.5] Re: [imss] RE: Re: [Ips] Proposal to > > remove "dynamic" port > > > type for FcPortType > > > > > > INCITS T11.5 Mail Reflector > > > ******************************** > > > > > > > The point is that it provides absolutely no information > > > > that is not present in the "other" category. If you don't know > > > > in what sense it is dynamic and what resolutions and algorithms > > > > are necessary to resolve its dynamic behavior to some other > > > > behavior, you have gained no information about the port. > > > > > > But it does, and you do gain information. Obviously, I am still > > > failing to make you understand. Perhaps it's the word "fixed" > > > which is now the problem; so, let me try again: > > > > > > 'otherFixed' -- a type which is known to the agent a priori and > > > the port does not perform on-the-wire > > > determination/negotiation, and is not one of these > > > types: 'nPort', 'nlPort', 'fPort' 'flPort', 'ePort' > > > or 'bPort'. > > > 'otherNegotiate' -- the port type is determined via on-the-wire > > > determination/negotiation, and is not one of these > > > types: 'gPort', 'glPort', 'fnlPort'. > > > > > > Note: one of these is via on-the-wire determination/negotiation > > > and one is not. By definition, they ARE different. > > > > > > > "vendor specific other" might be a more useful value than > > > > dynamic, because that indicates that there is a mechanism > > > > to determine the "otherness" of the port through vendor > > > > specific behaviors, where the vendor and model are known > > from other > > > > information in the MIB. "Dynamic" does not even have that > > > > grace. > > > > > > No, no, no. Please don't read vendor-specific into this; it is not > > > relevant. You didn't answer my question on whether the new > > types have > > > been approved by T11 Ballot yet. Let me assume that they > > haven't, and > > > that someone objects to adding them on that basis, then such ports > > > would have to be represented by 'otherNegotiate' not by > > 'otherFixed'. > > > So, no, 'otherNegotiate' is not vendor-specific. > > > > > > Keith. > > [... snip ...] > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue May 4 14:26:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17927 for ; Tue, 4 May 2004 14:26:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL4Rj-0003vx-2e for ips-archive@odin.ietf.org; Tue, 04 May 2004 14:15:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44IFBHl015116 for ips-archive@odin.ietf.org; Tue, 4 May 2004 14:15:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL4OU-0002db-Sy for ips-web-archive@optimus.ietf.org; Tue, 04 May 2004 14:11:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16864 for ; Tue, 4 May 2004 14:11:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL4OS-0002o3-ER for ips-web-archive@ietf.org; Tue, 04 May 2004 14:11:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL4Nf-0002is-00 for ips-web-archive@ietf.org; Tue, 04 May 2004 14:11:00 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL4N6-0002cz-00 for ips-web-archive@ietf.org; Tue, 04 May 2004 14:10:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL4BE-0006gY-UD; Tue, 04 May 2004 13:58:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL45B-0002cS-7U for ips@optimus.ietf.org; Tue, 04 May 2004 13:51:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15676 for ; Tue, 4 May 2004 13:51:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL458-0000eA-T5 for ips@ietf.org; Tue, 04 May 2004 13:51:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL448-0000Xu-00 for ips@ietf.org; Tue, 04 May 2004 13:50:50 -0400 Received: from f112.brocade.com ([66.243.153.112] helo=blasphemy.brocade.com) by ietf-mx with esmtp (Exim 4.12) id 1BL43H-0000NP-00; Tue, 04 May 2004 13:49:55 -0400 Received: from hq-ex-11.corp.brocade.com (hq-ex-11 [192.168.38.58]) by blasphemy.brocade.com (Postfix) with ESMTP id B9C4114291; Tue, 4 May 2004 10:49:24 -0700 (PDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [T11.5] Re: [imss] RE: Re: [Ips] Proposal to remove "dynamic" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Tue, 4 May 2004 10:49:24 -0700 Message-ID: <191DA4FAE235D24C9BCC8D50F6B17AB90933BF@hq-ex-11.brocade.com> Thread-Topic: [T11.5] Re: [imss] RE: Re: [Ips] Proposal to remove "dynamic" Thread-Index: AcQx/COtfqz1lxgxQ3KdlcQ/i+BuRQAAcCqg From: "Robert Snively" To: "Keith McCloghrie" , Cc: , , , Content-Transfer-Encoding: quoted-printable Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable This has become far-reaching over the last few contributions. I believe an IANA registry would be a straightforward mechanism to allow rapid authorized updates of port types, eliminating whatever need might actually exist for the undefined port type "dynamic". I see no downside to this. I agree with David that the number of contributions per year would be low, but the necessity for rapid update independent of an RFC action would be high, making the registry an attractive solution. I believe that the "otherFixed" and "otherDynamic" could be eliminated as a result of this, since "other" would exist as a temporary denomination for ports not yet defined in the registry or for ports that are proprietary and never will make it to the registry. I see no benefit in distinguishing them, since simply by their "otherness" they must be identified by mechanisms outside the MIB. Once the "otherness" is identified, it will quickly become clear whether they are dynamic or not. I believe that a significant number of the so-called "Port Types" mentioned below (perhaps including the trunked ports and the tagged ports) should really be considered as a "port type" plus a "port capability". The port type is negotiated early on, and the resulting port type (E_Port or F_Port) then gets to negotiate one or more additional capabilities (say tagging and/or trunking) at a higher level, essentially turning on or off one or more "port capabilities". Essentially, this is like a menu. You want pancakes (E_Ports), then you want syrup or=20 sauce on top (trunked or tagged). Otherwise, you have to have a separate IANA registry for an E_Port, a trunked E_Port, a tagged E_Port, and a trunked and tagged E_Port, all of which were defined by two levels of negotiation from=20 a G_Port. Not a pretty scene. Bob Snively > -----Original Message----- > From: imss-admin@ietf.org [mailto:imss-admin@ietf.org]On=20 > Behalf Of Keith > McCloghrie > Sent: Tuesday, May 04, 2004 10:10 AM > To: Black_David@emc.com > Cc: kzm@cisco.com; ips@ietf.org; t11_5@mail.t11.org;=20 > t11_3@mail.t11.org; > imss@ietf.org > Subject: Re: [T11.5] Re: [imss] RE: Re: [Ips] Proposal to remove > "dynamic" >=20 >=20 > David, >=20 > Thank-you. >=20 > I have already given my input on the questions you ask. I'm happy to > leave you to determine the consensus on these issues. >=20 > Keith. >=20 > > ----- IANA registry > >=20 > > > In other words, I believe whether or not to have a > > > IANA registry for a particular enumerated value in a MIB is a > > > trade-off: worthwhile only if the rate of new=20 > assignments is high. > > >=20 > > > In this case, Bob and Mike are in a much better position to know > > > whether the rate of defining new port types is liable to be high. > >=20 > > I like the idea of an IANA registry, but for a couple of reasons > > other than a potentially high rate of defining new port types: > >=20 > > (1) Fast turnaround: A new port type could be added to an IANA > > registry in a matter of weeks after T11 determines that > > it is appropriate. Publishing a revised RFC takes months, > > even under ideal conditions, and conditions have not been > > ideal lately ... > > (2) Proper review: As part of setting up the registry, we can > > define the process for adding entries, allowing us to give > > IANA explicit written instructions on how to obtain T11's > > concurrence on allocations of new entries. This would be an > > aspect of Expert Review (cf. RFC 2434), and I would also impose > > a Specification Required requirement that can be satisfied > > by a T11 working version of a standard under development, > > (but not a proposal - I think it's fair to require that T11 > > have voted to incorporate the proposed new port type). > >=20 > > I would expect a relatively low rate of new port type definitions > > (handful per year at most). > >=20 > > If this makes sense, Elizabeth, Bob and I are at the T10 meetings > > in Monterey, and can easily work out how IANA should interact with > > T11 in the next few days. > >=20 > > ----- MIB types > >=20 > > The distinction between otherFixed and otherDynamic (otherNegotiate) > > may be useful because: > >=20 > > - otherFixed means that the port type is not on the list and > > the port will not auto-negotiate to become some other type > > (and specifically won't become one of the known types on > > the list). > > - otherDynamic (or otherNegotiate) means that the port type is > > not on the list, but can auto-negotiate, which could result > > in it becoming one of the listed types (or some=20 > otherFixed type). > >=20 > > Assuming that virtual fabric trunking/tagging goes forward in T11, > > two examples of port types that are likely to exist are: > >=20 > > - a trunked tagged E_Port (like an E_Port, but carries traffic > > that's tagged with virtual fabric tags). This would be > > an otherFixed prior to its addition to the enumeration. > > - a new type of G_Port that could become a trunked E_Port, in > > addition to all the other things that an existing G_Port > > can become. This would be an otherDynamic (otherNegotiate) > > prior to its addition to the enumeration. > >=20 > > Do people think this distinction is useful? If it's useful, then > > we'd need to change "dynamic" to "otherDynamic" and "other" to > > "otherFixed". > >=20 > > 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 > > ---------------------------------------------------- > >=20 > > > -----Original Message----- > > > From: ips-admin@ietf.org [mailto:ips-admin@ietf.org] On=20 > > > Behalf Of Keith McCloghrie > > > Sent: Tuesday, May 04, 2004 9:42 AM > > > To: elizabeth.rodriguez@dothill.com > > > Cc: kzm@cisco.com; rsnively@Brocade.COM; ips@ietf.org;=20 > > > t11_5@mail.t11.org; t11_3@mail.t11.org; imss@ietf.org > > > Subject: Re: [T11.5] Re: [imss] RE: Re: [Ips] Proposal to=20 > > > remove "dynamic" > > >=20 > > >=20 > > > Hi Elizabeth, > > > =20 > > > There are a couple of cases where IANA assigns enumerated=20 > values in > > > a MIB, e.g.,=20 > http://www.iana.org/assignments/ianaiftype-mib lists the > > > latest version of the IANAifType TC which includes all=20 > the latest IANA > > > assignments (including the last one of 'fcipLink' which I=20 > believe was > > > requested by this WG.) > > >=20 > > > Having IANA do this is necessary when the rate of new=20 > assignments is > > > relatively high (e.g., there are now 224 values defined for=20 > > > IANAifType), > > > but it has the downside that it increases the number of=20 > steps required > > > to locate the latest assignments. To find the above URL,=20 > the primary > > > author of that MIB had to go to the IANA web-page and=20 > figure out how > > > to navigate through several web-pages in order to find=20 > it. It's much > > > simpler for network adminstrators and/or management application > > > writers to find the assignments when they are listed in the RFC's > > > version of the MIB. In other words, I believe whether or not=20 > > > to have a > > > IANA registry for a particular enumerated value in a MIB is a > > > trade-off: worthwhile only if the rate of new=20 > assignments is high. > > >=20 > > > In this case, Bob and Mike are in a much better position to know > > > whether the rate of defining new port types is liable to be high. > > >=20 > > > Keith. > > >=20 > > > > Hi all, > > > >=20 > > > > Instead of using a numerated list directly embedded in the=20 > > > MIB, could we > > > > address this issue through the creation of an IANA registry? > > > >=20 > > > > Essentially, what this discussion comes down to is how do=20 > > > we future-proof > > > > the MIB. I believe that thru the use of a registry we may=20 > > > be able to > > > > accomplish Keith's goal without creating a MIB type that=20 > > > does not have a > > > > definition in today's T11 standards. Once new port types=20 > > > are defined by > > > > T11, a new port type could be assigned in the registry to=20 > > > correspond to that > > > > type for use in this MIB. > > > >=20 > > > > I am not yet sure about the precedence for use of IANA=20 > > > registries with MIBs, > > > > and that is something I would need to consult with the=20 > transport and > > > > operations Area Directors, but is this an acceptable=20 > > > solution to everyone? > > > >=20 > > > > Thanks, > > > >=20 > > > > Elizabeth Rodriguez=20 > > > >=20 > > > > -----Original Message----- > > > > From: Keith McCloghrie [mailto:kzm@cisco.com]=20 > > > > Sent: Monday, May 03, 2004 11:07 AM > > > > To: rsnively@Brocade.COM > > > > Cc: kzm@cisco.com; ips@ietf.org; t11_5@mail.t11.org;=20 > > > t11_3@mail.t11.org; > > > > imss@ietf.org > > > > Subject: [T11.5] Re: [imss] RE: Re: [Ips] Proposal to=20 > > > remove "dynamic" port > > > > type for FcPortType > > > >=20 > > > > INCITS T11.5 Mail Reflector > > > > ******************************** > > > >=20 > > > > > The point is that it provides absolutely no information > > > > > that is not present in the "other" category. If you=20 > don't know > > > > > in what sense it is dynamic and what resolutions and=20 > algorithms > > > > > are necessary to resolve its dynamic behavior to some other > > > > > behavior, you have gained no information about the port. > > > >=20 > > > > But it does, and you do gain information. Obviously, I am still > > > > failing to make you understand. Perhaps it's the word "fixed" > > > > which is now the problem; so, let me try again: > > > >=20 > > > > 'otherFixed' -- a type which is known to the agent a priori and > > > > the port does not perform on-the-wire > > > > determination/negotiation, and is not=20 > one of these > > > > types: 'nPort', 'nlPort', 'fPort'=20 > 'flPort', 'ePort' > > > > or 'bPort'. > > > > 'otherNegotiate' -- the port type is determined via on-the-wire > > > > determination/negotiation, and is not=20 > one of these > > > > types: 'gPort', 'glPort', 'fnlPort'. > > > >=20 > > > > Note: one of these is via on-the-wire determination/negotiation > > > > and one is not. By definition, they ARE different. > > > > =20 > > > > > "vendor specific other" might be a more useful value than > > > > > dynamic, because that indicates that there is a mechanism > > > > > to determine the "otherness" of the port through vendor=20 > > > > > specific behaviors, where the vendor and model are known=20 > > > from other > > > > > information in the MIB. "Dynamic" does not even have that > > > > > grace. > > > > =20 > > > > No, no, no. Please don't read vendor-specific into=20 > this; it is not > > > > relevant. You didn't answer my question on whether the new=20 > > > types have > > > > been approved by T11 Ballot yet. Let me assume that they=20 > > > haven't, and > > > > that someone objects to adding them on that basis, then=20 > such ports > > > > would have to be represented by 'otherNegotiate' not by=20 > > > 'otherFixed'. > > > > So, no, 'otherNegotiate' is not vendor-specific. > > > >=20 > > > > Keith. > >=20 > > [... snip ...] > >=20 >=20 >=20 > _______________________________________________ > imss mailing list > imss@ietf.org > https://www1.ietf.org/mailman/listinfo/imss >=20 >=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue May 4 16:27:32 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27199 for ; Tue, 4 May 2004 16:27:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL6RY-0004FR-0p for ips-archive@odin.ietf.org; Tue, 04 May 2004 16:23:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44KN7ZN016327 for ips-archive@odin.ietf.org; Tue, 4 May 2004 16:23:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL6OS-0003Qw-2I for ips-web-archive@optimus.ietf.org; Tue, 04 May 2004 16:19:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26860 for ; Tue, 4 May 2004 16:19:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL6OQ-0002Lf-4P for ips-web-archive@ietf.org; Tue, 04 May 2004 16:19:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL6Nh-0002FH-00 for ips-web-archive@ietf.org; Tue, 04 May 2004 16:19:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL6Mq-00027I-00 for ips-web-archive@ietf.org; Tue, 04 May 2004 16:18:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL6Du-0000KR-QV; Tue, 04 May 2004 16:09:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL677-0006aZ-6j for ips@optimus.ietf.org; Tue, 04 May 2004 16:02:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25937 for ; Tue, 4 May 2004 16:01:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL675-0000ES-FS for ips@ietf.org; Tue, 04 May 2004 16:01:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL669-00007T-00 for ips@ietf.org; Tue, 04 May 2004 16:01:03 -0400 Received: from mcjekyll.mcdata.com ([144.49.6.25] helo=380GATE01out.mcdata.com) by ietf-mx with esmtp (Exim 4.12) id 1BL65m-0007nl-00; Tue, 04 May 2004 16:00:38 -0400 Received: from 380GATE01.mcdata.com ([172.18.1.72]) by 380GATE01out.mcdata.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 4 May 2004 14:00:58 -0600 Received: from MC4EXCH04.mcdata.com ([172.16.11.131]) by 380GATE01 with InterScan Messaging Security Suite; Tue, 04 May 2004 14:00:58 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [T11.5] Re: [imss] RE: Re: [Ips] Proposal to remove "dynamic" Date: Tue, 4 May 2004 14:00:57 -0600 Message-ID: <7F2E4853290B7C47B26CFCED52E86FE57AB07E@MC4EXCH04.mcdata.com> Thread-Topic: [T11.5] Re: [imss] RE: Re: [Ips] Proposal to remove "dynamic" Thread-Index: AcQx/COtfqz1lxgxQ3KdlcQ/i+BuRQAAcCqgAARJRDA= From: "Larry Hofer" To: "Robert Snively" , "Keith McCloghrie" , Cc: , , , , "Larry Hofer" X-OriginalArrivalTime: 04 May 2004 20:00:58.0487 (UTC) FILETIME=[845F8870:01C43212] Content-Transfer-Encoding: quoted-printable Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Bob brings up an interesting point about capabilities. It seems to me, that= it needs to be well understood whether the information in this (these)= particular field(s) are just for reporting the topology or more than that.= Are actions to be taken by software based on what the capabilities are= (or what the current operating state of the port is)? Are capabilities= distinguishable from current operating state? Port states today would be= "offline, online, failed, etc." Or might a new capabilities' operating= state also be, "active or inactive"? It would make sense to me to separate= capabilities from current operating state of a capability, as both may be= useful. So seems like what the TYPE, CAPABILITIES, and CAPABILITY OPERATING STATE= are would be different questions. And that an application might be= interested in answering all those questions. For example, port speeds= report current operating state (which speed) when that type of capability= information is queried.=20 Larry Hofer -----Original Message----- From: Robert Snively [mailto:rsnively@Brocade.COM] Sent: Tuesday, May 04, 2004 11:49 AM To: Keith McCloghrie; Black_David@emc.com Cc: ips@ietf.org; t11_5@mail.t11.org; t11_3@mail.t11.org; imss@ietf.org Subject: [T11.5] Re: [imss] RE: Re: [Ips] Proposal to remove "dynamic" INCITS T11.5 Mail Reflector ******************************** This has become far-reaching over the last few contributions. I believe an IANA registry would be a straightforward mechanism to allow rapid authorized updates of port types, eliminating whatever need might actually exist for the undefined port type "dynamic". I see no downside to this. I agree with David that the number of contributions per year would be low, but the necessity for rapid update independent of an RFC action would be high, making the registry an attractive solution. I believe that the "otherFixed" and "otherDynamic" could be eliminated as a result of this, since "other" would exist as a temporary denomination for ports not yet defined in the registry or for ports that are proprietary and never will make it to the registry. I see no benefit in distinguishing them, since simply by their "otherness" they must be identified by mechanisms outside the MIB. Once the "otherness" is identified, it will quickly become clear whether they are dynamic or not. I believe that a significant number of the so-called "Port Types" mentioned below (perhaps including the trunked ports and the tagged ports) should really be considered as a "port type" plus a "port capability". The port type is negotiated early on, and the resulting port type (E_Port or F_Port) then gets to negotiate one or more additional capabilities (say tagging and/or trunking) at a higher level, essentially turning on or off one or more "port capabilities". Essentially, this is like a menu. You want pancakes (E_Ports), then you want syrup or=20 sauce on top (trunked or tagged). Otherwise, you have to have a separate IANA registry for an E_Port, a trunked E_Port, a tagged E_Port, and a trunked and tagged E_Port, all of which were defined by two levels of negotiation from=20 a G_Port. Not a pretty scene. Bob Snively > -----Original Message----- > From: imss-admin@ietf.org [mailto:imss-admin@ietf.org]On=20 > Behalf Of Keith > McCloghrie > Sent: Tuesday, May 04, 2004 10:10 AM > To: Black_David@emc.com > Cc: kzm@cisco.com; ips@ietf.org; t11_5@mail.t11.org;=20 > t11_3@mail.t11.org; > imss@ietf.org > Subject: Re: [T11.5] Re: [imss] RE: Re: [Ips] Proposal to remove > "dynamic" >=20 >=20 > David, >=20 > Thank-you. >=20 > I have already given my input on the questions you ask. I'm happy to > leave you to determine the consensus on these issues. >=20 > Keith. >=20 > > ----- IANA registry > >=20 > > > In other words, I believe whether or not to have a > > > IANA registry for a particular enumerated value in a MIB is a > > > trade-off: worthwhile only if the rate of new=20 > assignments is high. > > >=20 > > > In this case, Bob and Mike are in a much better position to know > > > whether the rate of defining new port types is liable to be high. > >=20 > > I like the idea of an IANA registry, but for a couple of reasons > > other than a potentially high rate of defining new port types: > >=20 > > (1) Fast turnaround: A new port type could be added to an IANA > > registry in a matter of weeks after T11 determines that > > it is appropriate. Publishing a revised RFC takes months, > > even under ideal conditions, and conditions have not been > > ideal lately ... > > (2) Proper review: As part of setting up the registry, we can > > define the process for adding entries, allowing us to give > > IANA explicit written instructions on how to obtain T11's > > concurrence on allocations of new entries. This would be an > > aspect of Expert Review (cf. RFC 2434), and I would also impose > > a Specification Required requirement that can be satisfied > > by a T11 working version of a standard under development, > > (but not a proposal - I think it's fair to require that T11 > > have voted to incorporate the proposed new port type). > >=20 > > I would expect a relatively low rate of new port type definitions > > (handful per year at most). > >=20 > > If this makes sense, Elizabeth, Bob and I are at the T10 meetings > > in Monterey, and can easily work out how IANA should interact with > > T11 in the next few days. > >=20 > > ----- MIB types > >=20 > > The distinction between otherFixed and otherDynamic (otherNegotiate) > > may be useful because: > >=20 > > - otherFixed means that the port type is not on the list and > > the port will not auto-negotiate to become some other type > > (and specifically won't become one of the known types on > > the list). > > - otherDynamic (or otherNegotiate) means that the port type is > > not on the list, but can auto-negotiate, which could result > > in it becoming one of the listed types (or some=20 > otherFixed type). > >=20 > > Assuming that virtual fabric trunking/tagging goes forward in T11, > > two examples of port types that are likely to exist are: > >=20 > > - a trunked tagged E_Port (like an E_Port, but carries traffic > > that's tagged with virtual fabric tags). This would be > > an otherFixed prior to its addition to the enumeration. > > - a new type of G_Port that could become a trunked E_Port, in > > addition to all the other things that an existing G_Port > > can become. This would be an otherDynamic (otherNegotiate) > > prior to its addition to the enumeration. > >=20 > > Do people think this distinction is useful? If it's useful, then > > we'd need to change "dynamic" to "otherDynamic" and "other" to > > "otherFixed". > >=20 > > 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 > > ---------------------------------------------------- > >=20 > > > -----Original Message----- > > > From: ips-admin@ietf.org [mailto:ips-admin@ietf.org] On=20 > > > Behalf Of Keith McCloghrie > > > Sent: Tuesday, May 04, 2004 9:42 AM > > > To: elizabeth.rodriguez@dothill.com > > > Cc: kzm@cisco.com; rsnively@Brocade.COM; ips@ietf.org;=20 > > > t11_5@mail.t11.org; t11_3@mail.t11.org; imss@ietf.org > > > Subject: Re: [T11.5] Re: [imss] RE: Re: [Ips] Proposal to=20 > > > remove "dynamic" > > >=20 > > >=20 > > > Hi Elizabeth, > > > =20 > > > There are a couple of cases where IANA assigns enumerated=20 > values in > > > a MIB, e.g.,=20 > http://www.iana.org/assignments/ianaiftype-mib lists the > > > latest version of the IANAifType TC which includes all=20 > the latest IANA > > > assignments (including the last one of 'fcipLink' which I=20 > believe was > > > requested by this WG.) > > >=20 > > > Having IANA do this is necessary when the rate of new=20 > assignments is > > > relatively high (e.g., there are now 224 values defined for=20 > > > IANAifType), > > > but it has the downside that it increases the number of=20 > steps required > > > to locate the latest assignments. To find the above URL,=20 > the primary > > > author of that MIB had to go to the IANA web-page and=20 > figure out how > > > to navigate through several web-pages in order to find=20 > it. It's much > > > simpler for network adminstrators and/or management application > > > writers to find the assignments when they are listed in the RFC's > > > version of the MIB. In other words, I believe whether or not=20 > > > to have a > > > IANA registry for a particular enumerated value in a MIB is a > > > trade-off: worthwhile only if the rate of new=20 > assignments is high. > > >=20 > > > In this case, Bob and Mike are in a much better position to know > > > whether the rate of defining new port types is liable to be high. > > >=20 > > > Keith. > > >=20 > > > > Hi all, > > > >=20 > > > > Instead of using a numerated list directly embedded in the=20 > > > MIB, could we > > > > address this issue through the creation of an IANA registry? > > > >=20 > > > > Essentially, what this discussion comes down to is how do=20 > > > we future-proof > > > > the MIB. I believe that thru the use of a registry we may=20 > > > be able to > > > > accomplish Keith's goal without creating a MIB type that=20 > > > does not have a > > > > definition in today's T11 standards. Once new port types=20 > > > are defined by > > > > T11, a new port type could be assigned in the registry to=20 > > > correspond to that > > > > type for use in this MIB. > > > >=20 > > > > I am not yet sure about the precedence for use of IANA=20 > > > registries with MIBs, > > > > and that is something I would need to consult with the=20 > transport and > > > > operations Area Directors, but is this an acceptable=20 > > > solution to everyone? > > > >=20 > > > > Thanks, > > > >=20 > > > > Elizabeth Rodriguez=20 > > > >=20 > > > > -----Original Message----- > > > > From: Keith McCloghrie [mailto:kzm@cisco.com]=20 > > > > Sent: Monday, May 03, 2004 11:07 AM > > > > To: rsnively@Brocade.COM > > > > Cc: kzm@cisco.com; ips@ietf.org; t11_5@mail.t11.org;=20 > > > t11_3@mail.t11.org; > > > > imss@ietf.org > > > > Subject: [T11.5] Re: [imss] RE: Re: [Ips] Proposal to=20 > > > remove "dynamic" port > > > > type for FcPortType > > > >=20 > > > > INCITS T11.5 Mail Reflector > > > > ******************************** > > > >=20 > > > > > The point is that it provides absolutely no information > > > > > that is not present in the "other" category. If you=20 > don't know > > > > > in what sense it is dynamic and what resolutions and=20 > algorithms > > > > > are necessary to resolve its dynamic behavior to some other > > > > > behavior, you have gained no information about the port. > > > >=20 > > > > But it does, and you do gain information. Obviously, I am still > > > > failing to make you understand. Perhaps it's the word "fixed" > > > > which is now the problem; so, let me try again: > > > >=20 > > > > 'otherFixed' -- a type which is known to the agent a priori and > > > > the port does not perform on-the-wire > > > > determination/negotiation, and is not=20 > one of these > > > > types: 'nPort', 'nlPort', 'fPort'=20 > 'flPort', 'ePort' > > > > or 'bPort'. > > > > 'otherNegotiate' -- the port type is determined via on-the-wire > > > > determination/negotiation, and is not=20 > one of these > > > > types: 'gPort', 'glPort', 'fnlPort'. > > > >=20 > > > > Note: one of these is via on-the-wire determination/negotiation > > > > and one is not. By definition, they ARE different. > > > > =20 > > > > > "vendor specific other" might be a more useful value than > > > > > dynamic, because that indicates that there is a mechanism > > > > > to determine the "otherness" of the port through vendor=20 > > > > > specific behaviors, where the vendor and model are known=20 > > > from other > > > > > information in the MIB. "Dynamic" does not even have that > > > > > grace. > > > > =20 > > > > No, no, no. Please don't read vendor-specific into=20 > this; it is not > > > > relevant. You didn't answer my question on whether the new=20 > > > types have > > > > been approved by T11 Ballot yet. Let me assume that they=20 > > > haven't, and > > > > that someone objects to adding them on that basis, then=20 > such ports > > > > would have to be represented by 'otherNegotiate' not by=20 > > > 'otherFixed'. > > > > So, no, 'otherNegotiate' is not vendor-specific. > > > >=20 > > > > Keith. > >=20 > > [... snip ...] > >=20 >=20 >=20 > _______________________________________________ > imss mailing list > imss@ietf.org > https://www1.ietf.org/mailman/listinfo/imss >=20 >=20 To Unsubscribe: mailto:t11_5-request@mail.t11.org?subject=3Dsubscribe SPECIAL NOTICE=20 All information transmitted hereby is intended only for the use of the=20 addressee(s) named above and may contain confidential and privileged=20 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=20 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=20 PROHIBITED. Anyone who receives confidential and privileged information in error should= =20 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=20 apply to that information. (gate01) _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed May 5 08:26:30 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09880 for ; Wed, 5 May 2004 08:26:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLLPj-0002wp-LW for ips-archive@odin.ietf.org; Wed, 05 May 2004 08:22:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45CMFoS011323 for ips-archive@odin.ietf.org; Wed, 5 May 2004 08:22:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLLLD-0001ra-5c for ips-web-archive@optimus.ietf.org; Wed, 05 May 2004 08:17:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09662 for ; Wed, 5 May 2004 08:17:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLLLC-0000Q9-63 for ips-web-archive@ietf.org; Wed, 05 May 2004 08:17:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLLKD-0000DB-00 for ips-web-archive@ietf.org; Wed, 05 May 2004 08:16:34 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLLJc-00000B-00 for ips-web-archive@ietf.org; Wed, 05 May 2004 08:15:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLLFp-0000Lz-H8; Wed, 05 May 2004 08:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLLCa-0007lA-4E for ips@optimus.ietf.org; Wed, 05 May 2004 08:08:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09457 for ; Wed, 5 May 2004 08:08:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLLCZ-0006HT-5j for ips@ietf.org; Wed, 05 May 2004 08:08:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLLBY-00064P-00 for ips@ietf.org; Wed, 05 May 2004 08:07:37 -0400 Received: from mail3.giantloop.com ([65.77.112.31] helo=mail-be.giantloop.com) by ietf-mx with esmtp (Exim 4.12) id 1BLLB7-0005rU-00 for ips@ietf.org; Wed, 05 May 2004 08:07:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 May 2004 08:06:38 -0400 Message-ID: <6CA85554A071E54FAE763836FA1CD744070844@mail-be.centrepath.com> Thread-Topic: expiration of FCIP draft Thread-Index: AcQymWteXaYz56AqQQWvpzQKs71Ubg== From: "Mullen, Tom" To: Content-Transfer-Encoding: quoted-printable Subject: [Ips] expiration of FCIP draft Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Could someone direct me to a pertinent period in the archives that would give me some background on what happened to the FCIP draft. >From the outside looking in, it seems to have died on the vine. (Or expended during a food fight.) Thanks in advance. cat flames > /dev/null Tom Mullen Principal Engineer CentrePath 781 902 5093=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed May 5 12:57:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25626 for ; Wed, 5 May 2004 12:57:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLPVB-0000CZ-Qu for ips-archive@odin.ietf.org; Wed, 05 May 2004 12:44:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45Gi9vY000767 for ips-archive@odin.ietf.org; Wed, 5 May 2004 12:44:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLPPv-00063p-D2 for ips-web-archive@optimus.ietf.org; Wed, 05 May 2004 12:38:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24662 for ; Wed, 5 May 2004 12:38:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLPPt-0003XW-P3 for ips-web-archive@ietf.org; Wed, 05 May 2004 12:38:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLPOu-0003Ga-00 for ips-web-archive@ietf.org; Wed, 05 May 2004 12:37:41 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLPNs-0002pH-00 for ips-web-archive@ietf.org; Wed, 05 May 2004 12:36:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLPDe-0001N5-St; Wed, 05 May 2004 12:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLOwz-00028o-8L for ips@optimus.ietf.org; Wed, 05 May 2004 12:08:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22977 for ; Wed, 5 May 2004 12:08:46 -0400 (EDT) From: Black_David@emc.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLOwx-0003E0-Tm for ips@ietf.org; Wed, 05 May 2004 12:08:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLOw7-0002z0-00 for ips@ietf.org; Wed, 05 May 2004 12:07:56 -0400 Received: from mxic2.corp.emc.com ([128.221.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1BLOvX-0002gp-00 for ips@ietf.org; Wed, 05 May 2004 12:07:19 -0400 Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 May 2004 12:06:45 -0400 Message-ID: To: tom.mullen@centrepath.com, ips@ietf.org Subject: RE: [Ips] expiration of FCIP draft Date: Wed, 5 May 2004 12:06:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 > Could someone direct me to a pertinent period in the archives that would > give me some background on what happened to the FCIP draft. > > From the outside looking in, it seems to have died on the vine. > (Or expended during a food fight.) It's in the RFC Editor queue waiting for IESG re-review of the FCIP-SLP draft. Here's a link to the draft state tracker: https://datatracker.ietf.org/public/pidtracker.cgi Please check this before making statements like "died on the vine". The fact that it's waiting for FCIP-SLP is a little more difficult to determine - one has to search for the draft name in the RFC Editor publication queue: http://www.rfc-editor.org/queue.html 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 exim@www1.ietf.org Wed May 5 18:00:26 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13926 for ; Wed, 5 May 2004 18:00:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLUPk-00025r-V7 for ips-archive@odin.ietf.org; Wed, 05 May 2004 17:58:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45Lwqv7008015 for ips-archive@odin.ietf.org; Wed, 5 May 2004 17:58:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLUJ8-000848-Jw for ips-web-archive@optimus.ietf.org; Wed, 05 May 2004 17:52:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13515 for ; Wed, 5 May 2004 17:51:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLUJ5-0007j3-Sr for ips-web-archive@ietf.org; Wed, 05 May 2004 17:51:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLUIA-0007Ro-00 for ips-web-archive@ietf.org; Wed, 05 May 2004 17:51:02 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLUHc-0007Ah-00 for ips-web-archive@ietf.org; Wed, 05 May 2004 17:50:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLUBM-00055p-UR; Wed, 05 May 2004 17:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLPt4-0000RP-SL for ips@optimus.ietf.org; Wed, 05 May 2004 13:08:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26502 for ; Wed, 5 May 2004 13:08:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLPt2-0003t8-U9 for ips@ietf.org; Wed, 05 May 2004 13:08:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLPs4-0003dS-00 for ips@ietf.org; Wed, 05 May 2004 13:07:49 -0400 Received: from bay10-f108.bay10.hotmail.com ([64.4.37.108] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BLPrY-0003Lb-00 for ips@ietf.org; Wed, 05 May 2004 13:07:16 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 5 May 2004 10:06:41 -0700 Received: from 66.134.214.28 by by10fd.bay10.hotmail.msn.com with HTTP; Wed, 05 May 2004 17:06:40 GMT X-Originating-IP: [66.134.214.28] X-Originating-Email: [rmangamuri@hotmail.com] X-Sender: rmangamuri@hotmail.com From: "Ramesh Mangamuri" To: ips@ietf.org Date: Wed, 05 May 2004 22:36:40 +0530 Mime-Version: 1.0 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 05 May 2004 17:06:41.0619 (UTC) FILETIME=[5601DA30:01C432C3] Subject: [Ips] Nop-In Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.5 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY autolearn=no version=2.60


Hello,
 
When a target initiates a Nop-In expecting a Nop-out respone from an initiator, does it has to set the Immediate bit to 1 ?
 
-Ramesh

Send flowers in 24 hours! At MSN Shopping. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed May 5 18:22:36 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15937 for ; Wed, 5 May 2004 18:22:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLUih-0007DR-6w for ips-archive@odin.ietf.org; Wed, 05 May 2004 18:18:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45MIRkH027735 for ips-archive@odin.ietf.org; Wed, 5 May 2004 18:18:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLUaY-0001oq-2T for ips-web-archive@optimus.ietf.org; Wed, 05 May 2004 18:10:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14894 for ; Wed, 5 May 2004 18:09:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLUaV-0005Gr-9j for ips-web-archive@ietf.org; Wed, 05 May 2004 18:09:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLUZX-0004zc-00 for ips-web-archive@ietf.org; Wed, 05 May 2004 18:08:59 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLUYf-0004iK-00 for ips-web-archive@ietf.org; Wed, 05 May 2004 18:08:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLUVi-00073F-7M; Wed, 05 May 2004 18:05:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLUTs-0005s2-2e for ips@optimus.ietf.org; Wed, 05 May 2004 18:03:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14077 for ; Wed, 5 May 2004 18:03:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLUTp-000396-B6 for ips@ietf.org; Wed, 05 May 2004 18:03:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLUSo-0002pd-00 for ips@ietf.org; Wed, 05 May 2004 18:02:03 -0400 Received: from email.crossroads.com ([65.68.235.6]) by ietf-mx with smtp (Exim 4.12) id 1BLURs-0002Fo-00 for ips@ietf.org; Wed, 05 May 2004 18:01:04 -0400 Received: from mailnode1.COMMSTOR.Crossroads.com ([192.168.1.249]) by email.crossroads.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 5 May 2004 17:00:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] Nop-In Date: Wed, 5 May 2004 17:00:33 -0500 Message-ID: <43F5E8AE07F17C47BC16F7A159E9E7006BA7@mailnode1.commstor.crossroads.com> Thread-Topic: [Ips] Nop-In Thread-Index: AcQy6u/bJYerFWi0Sxy5WVU3AQqnlwAAEQuQ From: "Buck Landry" To: "Ramesh Mangamuri" , X-OriginalArrivalTime: 05 May 2004 22:00:34.0144 (UTC) FILETIME=[63CFA600:01C432EC] Content-Transfer-Encoding: quoted-printable Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable If you check the RFC (10.19), you'll notice Nop-In has no "immediate = bit" to set. (and neither do the other responses) I bit for the Nop-Out "ping response" is governed by 10.18.1 .. the short answer is "no". --buck -----Original Message----- From: ips-admin@ietf.org [mailto:ips-admin@ietf.org]On Behalf Of Ramesh = Mangamuri Sent: Wednesday, May 05, 2004 12:07 PM To: ips@ietf.org Subject: [Ips] Nop-In Hello, When a target initiates a Nop-In expecting a Nop-out respone from an = initiator, does it has to set the Immediate bit to 1 ? -Ramesh Send flowers in 24 hours! At MSN Shopping. = _______________________________________________ Ips mailing list = Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed May 5 18:30:44 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16333 for ; Wed, 5 May 2004 18:30:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLUqf-0002Oz-2j for ips-archive@odin.ietf.org; Wed, 05 May 2004 18:26:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45MQfR8009229 for ips-archive@odin.ietf.org; Wed, 5 May 2004 18:26:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLUjG-0007gF-V2 for ips-web-archive@optimus.ietf.org; Wed, 05 May 2004 18:19:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15660 for ; Wed, 5 May 2004 18:18:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLUjE-00004e-2b for ips-web-archive@ietf.org; Wed, 05 May 2004 18:19:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLUiE-0007aZ-00 for ips-web-archive@ietf.org; Wed, 05 May 2004 18:17:58 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLUhD-0007I2-00 for ips-web-archive@ietf.org; Wed, 05 May 2004 18:16:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLUaX-0001om-TZ; Wed, 05 May 2004 18:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLUWe-0007QU-Qr for ips@optimus.ietf.org; Wed, 05 May 2004 18:06:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14414 for ; Wed, 5 May 2004 18:05:56 -0400 (EDT) From: Black_David@emc.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLUWb-00044c-TW for ips@ietf.org; Wed, 05 May 2004 18:05:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLUVc-0003k6-00 for ips@ietf.org; Wed, 05 May 2004 18:04:57 -0400 Received: from mxic2.corp.emc.com ([128.221.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1BLUUc-00039u-00 for ips@ietf.org; Wed, 05 May 2004 18:03:54 -0400 Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 May 2004 18:03:12 -0400 Message-ID: To: ips@ietf.org Subject: RE: [Ips] Nop-In Date: Wed, 5 May 2004 18:03:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 > When a target initiates a Nop-In expecting a Nop-out response from an > initiator, does it has to set the Immediate bit to 1 ? The "Immediate bit" does not exist in Nop-In. See the diagram in Section 10.19 in RFC 3720. The "Immediate bit" only affects Target command processing - it would have no meaning when received by an Initiator, hence it doesn't exist and should be ignored by the Initiator. 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 exim@www1.ietf.org Thu May 6 10:54:34 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18085 for ; Thu, 6 May 2004 10:54:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLk7K-0006By-0Y for ips-archive@odin.ietf.org; Thu, 06 May 2004 10:44:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46EirQK023802 for ips-archive@odin.ietf.org; Thu, 6 May 2004 10:44:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLk3S-0004av-Gv for ips-web-archive@optimus.ietf.org; Thu, 06 May 2004 10:40:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17388 for ; Thu, 6 May 2004 10:40:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLk3Q-0004vw-5q for ips-web-archive@ietf.org; Thu, 06 May 2004 10:40:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLk1L-0004PA-00 for ips-web-archive@ietf.org; Thu, 06 May 2004 10:38:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLk0D-0003dF-00 for ips-web-archive@ietf.org; Thu, 06 May 2004 10:37:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLjs0-0008Qy-De; Thu, 06 May 2004 10:29:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLjnx-0006ap-FM for ips@optimus.ietf.org; Thu, 06 May 2004 10:24:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16446 for ; Thu, 6 May 2004 10:24:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLjnv-0006Dp-0G for ips@ietf.org; Thu, 06 May 2004 10:24:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLjn2-0005o9-00 for ips@ietf.org; Thu, 06 May 2004 10:23:57 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1BLjmT-0005Nd-00 for ips@ietf.org; Thu, 06 May 2004 10:23:21 -0400 Received: from phys-giza-1 ([129.147.4.102]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i46EMp6b025467 for ; Thu, 6 May 2004 07:22:51 -0700 (PDT) Received: from conversion-daemon.giza-mail1.Central.Sun.COM by giza-mail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) id <0HXA00K01PCNHC@giza-mail1.Central.Sun.COM> for ips@ietf.org; Thu, 06 May 2004 08:22:51 -0600 (MDT) Received: from [172.20.24.175] by giza-mail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HXA006ZHQLMTN@giza-mail1.Central.Sun.COM> for ips@ietf.org; Thu, 06 May 2004 08:22:34 -0600 (MDT) Date: Thu, 06 May 2004 08:22:48 -0600 From: David Weibel To: ips@ietf.org Message-id: MIME-version: 1.0 (Apple Message framework v613) X-Mailer: Apple Mail (2.613) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Subject: [Ips] draft 20 -> rfc document with change bars Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Is there a iSCSI document that contains change bars between draft 20 and the RFC. If so can someone please point me to it's location. Thanks -dcw _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu May 6 13:27:49 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04573 for ; Thu, 6 May 2004 13:27:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLmP5-00044A-E6 for ips-archive@odin.ietf.org; Thu, 06 May 2004 13:11:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46HBNgF015625 for ips-archive@odin.ietf.org; Thu, 6 May 2004 13:11:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLlmd-00059c-G0 for ips-web-archive@optimus.ietf.org; Thu, 06 May 2004 12:31:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27231 for ; Thu, 6 May 2004 12:31:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLlmc-00067C-0q for ips-web-archive@ietf.org; Thu, 06 May 2004 12:31:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLlj8-0004vK-00 for ips-web-archive@ietf.org; Thu, 06 May 2004 12:28:03 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BLlhJ-00043a-01 for ips-web-archive@ietf.org; Thu, 06 May 2004 12:26:09 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BLlf0-0001Ob-8B for ips-web-archive@ietf.org; Thu, 06 May 2004 12:23:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLkvH-0008Im-AW; Thu, 06 May 2004 11:36:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLknD-0003uT-3m for ips@optimus.ietf.org; Thu, 06 May 2004 11:28:11 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20122; Thu, 6 May 2004 11:28:08 -0400 (EDT) Message-Id: <200405061528.LAA20122@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ips@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 06 May 2004 11:28:08 -0400 Subject: [Ips] I-D ACTION:draft-ietf-ips-iscsi-slp-08.txt Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : Finding iSCSI Targets and Name Servers Using SLP Author(s) : M. Bakke, et al. Filename : draft-ietf-ips-iscsi-slp-08.txt Pages : 23 Date : 2004-5-4 The iSCSI protocol provides a way for hosts to access SCSI devices over an IP network. This document defines the use of the Service Location Protocol (SLP) by iSCSI hosts, devices, and management services, along with the SLP service type templates that describe the services they provide. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-slp-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-iscsi-slp-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-iscsi-slp-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-5-6113429.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-slp-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-slp-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-6113429.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu May 6 13:37:10 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06094 for ; Thu, 6 May 2004 13:37:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLmbZ-0005pd-Le for ips-archive@odin.ietf.org; Thu, 06 May 2004 13:24:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46HOHch022413 for ips-archive@odin.ietf.org; Thu, 6 May 2004 13:24:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLmNr-0002sD-Sn for ips-web-archive@optimus.ietf.org; Thu, 06 May 2004 13:10:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01776 for ; Thu, 6 May 2004 13:10:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLmNq-0007Bv-09 for ips-web-archive@ietf.org; Thu, 06 May 2004 13:10:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLmLQ-0006Da-00 for ips-web-archive@ietf.org; Thu, 06 May 2004 13:07:37 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BLmKG-0005hL-00 for ips-web-archive@ietf.org; Thu, 06 May 2004 13:06:24 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BLmKI-0002DN-15 for ips-web-archive@ietf.org; Thu, 06 May 2004 13:06:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLlNG-0007H8-JJ; Thu, 06 May 2004 12:05:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLku3-00078l-Bc for ips@optimus.ietf.org; Thu, 06 May 2004 11:35:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20580 for ; Thu, 6 May 2004 11:35:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLku2-000511-6n for ips@ietf.org; Thu, 06 May 2004 11:35:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLkt0-0004YX-00 for ips@ietf.org; Thu, 06 May 2004 11:34:10 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx with esmtp (Exim 4.12) id 1BLksD-00046Y-00 for ips@ietf.org; Thu, 06 May 2004 11:33:21 -0400 Received: from phys-giza-1 ([129.147.4.102]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i46FVxsV001320 for ; Thu, 6 May 2004 09:32:03 -0600 (MDT) Received: from conversion-daemon.giza-mail1.Central.Sun.COM by giza-mail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) id <0HXA00J01TDNC0@giza-mail1.Central.Sun.COM> for ips@ietf.org; Thu, 06 May 2004 09:33:18 -0600 (MDT) Received: from [172.20.24.175] by giza-mail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HXA00K9XTVG1A@giza-mail1.Central.Sun.COM> for ips@ietf.org; Thu, 06 May 2004 09:33:16 -0600 (MDT) Date: Thu, 06 May 2004 09:33:30 -0600 From: David Weibel Subject: Re: [Ips] draft 20 -> rfc document with change bars In-reply-to: To: ips@ietf.org Message-id: MIME-version: 1.0 (Apple Message framework v613) X-Mailer: Apple Mail (2.613) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: Content-Transfer-Encoding: 7BIT Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Never mind. I found a text copy of draft 20 and did the diff. On May 6, 2004, at 8:22 AM, David Weibel wrote: > Is there a iSCSI document that contains change bars between > draft 20 and the RFC. If so can someone please point me to > it's location. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu May 6 14:36:13 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09947 for ; Thu, 6 May 2004 14:36:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLnZs-0002X9-P6 for ips-archive@odin.ietf.org; Thu, 06 May 2004 14:26:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46IQaHP009739 for ips-archive@odin.ietf.org; Thu, 6 May 2004 14:26:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLnQj-0006xk-MK for ips-web-archive@optimus.ietf.org; Thu, 06 May 2004 14:17:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08713 for ; Thu, 6 May 2004 14:17:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLnQh-0005K3-5g for ips-web-archive@ietf.org; Thu, 06 May 2004 14:17:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLnPj-0004uZ-00 for ips-web-archive@ietf.org; Thu, 06 May 2004 14:16:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLnPI-0004Uo-00 for ips-web-archive@ietf.org; Thu, 06 May 2004 14:15:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLnE1-0000mS-Ig; Thu, 06 May 2004 14:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLn1c-0003b4-CD for ips@optimus.ietf.org; Thu, 06 May 2004 13:51:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07055 for ; Thu, 6 May 2004 13:51:09 -0400 (EDT) From: Black_David@emc.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLn1a-0001nN-3P for ips@ietf.org; Thu, 06 May 2004 13:51:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLn0f-0001M4-00 for ips@ietf.org; Thu, 06 May 2004 13:50:14 -0400 Received: from mxic2.corp.emc.com ([128.221.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1BLn04-0000rh-00; Thu, 06 May 2004 13:49:36 -0400 Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 May 2004 13:48:57 -0400 Message-ID: To: ips@ietf.org Cc: t11_5@mail.t11.org, t11_3@mail.t11.org, imss@ietf.org Date: Thu, 6 May 2004 13:48:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Ips] FC Mgmt MIB: "dynamic" FC port type resolution Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Here's what the IPS WG chairs (David and Elizabeth) have to say on resolution of the issues around the "dynamic" FC port type in the current FC Mgmt MIB draft: ----- Support for future FC port types An IANA registry for FC Port Types is the right approach, and the revised version of the FC Mgmt MIB draft will need to contain the initial contents of the registry (including the new values for the G, GL and F/NL ports) in addition to instructing IANA to create the registry. The registry also needs to contain an experimental/private use range - where to put this is somewhat arbitrary as we have a 32 bit integer, and T11 is unlikely to define a large number of port types. So, let's put that range at 10,000 - 99,999 and mark all larger values as RESERVED. Newly added FC port types would continue the current enumeration - the likelihood of this ever reaching 3 digits is small. Since the purpose of the registry is to record FC port types as specified and standardized by T11, T11 approval of additions to the registry is in order. This will be in addition to Expert Review and Specification Required (cf. RFC 2434; the WG chairs will work out the exact text to accomplish this with the Area Directors and provide it to the FC Mgmt MIB draft editor. ----- Future of the "dynamic" port type Having seen no one other than Keith speak up in favor of "dynamic" or a second "other" type, the WG chairs believe the rough consensus of the ips WG to be that the "other" type suffices for FC port types that can be identified but do not have explicit values. Keith's objections to this are noted, and this rough consensus is called over those objections. Anyone else who objects to this should post to the list. In the initial contents of the IANA FC port type registry, the value 3 is to be RESERVED, and IANA is to be instructed not to (re)allocate that value in the future. ----- Port Capabilities vs. Types Whether future functional additions to FC ports are realized as new FC port types vs. capabilities added to existing port types is fundamentally an issue for T11 to determine. The IETF will follow the direction that T11 sets in this area. Thanks, --David (for David and Elizabeth, ips WG co-chairs) ---------------------------------------------------- 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 exim@www1.ietf.org Sun May 9 03:23:25 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21178 for ; Sun, 9 May 2004 03:23:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMics-0004UZ-88 for ips-archive@odin.ietf.org; Sun, 09 May 2004 03:21:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i497LU8A017255 for ips-archive@odin.ietf.org; Sun, 9 May 2004 03:21:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMibx-0004Ow-Re for ips-web-archive@optimus.ietf.org; Sun, 09 May 2004 03:20:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20964 for ; Sun, 9 May 2004 03:20:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMibv-0002My-Kp for ips-web-archive@ietf.org; Sun, 09 May 2004 03:20:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMias-0001yO-00 for ips-web-archive@ietf.org; Sun, 09 May 2004 03:19:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BMiZq-0001VE-00 for ips-web-archive@ietf.org; Sun, 09 May 2004 03:18:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMiVg-0003iS-0a; Sun, 09 May 2004 03:14:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMiU9-0003a6-Cl for ips@optimus.ietf.org; Sun, 09 May 2004 03:12:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20670 for ; Sun, 9 May 2004 03:12:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMiU7-0007Au-82 for ips@ietf.org; Sun, 09 May 2004 03:12:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMiT6-0006ny-00 for ips@ietf.org; Sun, 09 May 2004 03:11:25 -0400 Received: from [144.16.67.8] (helo=csa.iisc.ernet.in) by ietf-mx with esmtp (Exim 4.12) id 1BMiS3-000528-00 for ips@ietf.org; Sun, 09 May 2004 03:10:20 -0400 Received: from deimos.csa.iisc.ernet.in (deimos.csa.iisc.ernet.in [144.16.67.57]) by csa.iisc.ernet.in (Postfix) with ESMTP id BFC5D2BE97 for ; Sun, 9 May 2004 12:13:29 +0530 (IST) Received: by deimos.csa.iisc.ernet.in (Postfix, from userid 9355) id 9A6954DF86; Sun, 9 May 2004 12:37:04 +0530 (IST) Received: from localhost (localhost [127.0.0.1]) by deimos.csa.iisc.ernet.in (Postfix) with ESMTP id 987584A123 for ; Sun, 9 May 2004 12:37:04 +0530 (IST) Date: Sun, 9 May 2004 12:37:04 +0530 (IST) From: Motwani Girish Manoharlal To: ips@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Ips] testbed setup for validating iSCSI implementation Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi all, I am working on implementing the iSCSI protocol in ns-2. I have been able to implement a subset of the protocol ( from the drafts ) and integrate disksim with ns-2. Has there been any study on the performance of the protocol so that I can compare my results by setting up a tested identical to the testbed considered for this study. regards, -girish _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon May 10 13:09:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17454 for ; Mon, 10 May 2004 13:09:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNE6c-0005Jv-EE for ips-archive@odin.ietf.org; Mon, 10 May 2004 12:58:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4AGwIEH020452 for ips-archive@odin.ietf.org; Mon, 10 May 2004 12:58:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNDzo-0004Sh-8A for ips-web-archive@optimus.ietf.org; Mon, 10 May 2004 12:51:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16659 for ; Mon, 10 May 2004 12:51:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNDzm-0001p4-J7 for ips-web-archive@ietf.org; Mon, 10 May 2004 12:51:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNDyr-0001Tg-00 for ips-web-archive@ietf.org; Mon, 10 May 2004 12:50:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNDy5-00018F-00 for ips-web-archive@ietf.org; Mon, 10 May 2004 12:49:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNDl7-0001hH-Iv; Mon, 10 May 2004 12:36:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNDj6-0001Be-57 for ips@optimus.ietf.org; Mon, 10 May 2004 12:34:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15393 for ; Mon, 10 May 2004 12:33:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNDj4-0003U7-KQ for ips@ietf.org; Mon, 10 May 2004 12:33:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNDhz-00035e-00 for ips@ietf.org; Mon, 10 May 2004 12:32:52 -0400 Received: from email-out2.iomega.com ([147.178.1.83] helo=email.iomega.com) by ietf-mx with esmtp (Exim 4.12) id 1BNDh5-0002On-00 for ips@ietf.org; Mon, 10 May 2004 12:31:55 -0400 Received: from royntex01.iomegacorp.com (franklin [10.1.1.83]) by email.iomega.com (Postfix) with ESMTP id DF11C1C83; Mon, 10 May 2004 10:31:18 -0600 (MDT) Received: from [147.178.176.63] ([147.178.176.63]) by royntex01.iomegacorp.c om with Microsoft SMTPSVC(5.0.2195.5329);Mon, 10 May 2004 10:31:18 -0600 Subject: Re: [Ips] testbed setup for validating iSCSI implementation From: Pat LaVarre To: Motwani Girish Manoharlal Cc: ips@ietf.org In-Reply-To: References: Content-Type: text/plain Message-Id: <1084206652.2427.4.camel@patibmrh9> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 10 May 2004 10:30:53 -0600 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 May 2004 16:31:18.0356 (UTC) FILETIME=[38826140:01 C436AC] X-imss-version: 2.0 X-imss-result: Passed X-imss-scores: Clean:29.60580 C:20 M:1 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > implementing the iSCSI protocol in ns-2 > from the drafts ... disksim ... > any study on the performance ... I have no answer, sorry, I'm writing just to say I look forward to hearing here later what you actually find useful. Myself I have not yet made useful in design any benchmark of disk thruput other than the maximally and minimally complex extremes. By "maximally complex" I mean drag & drop of unusually well structured file sets, measure wall clock elapsed with a stopwatch. By "minimally complex" I mean the trivial raw rates of dd of=/dev/null and dd if=/dev/zero. Pat LaVarre _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon May 10 23:40:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28507 for ; Mon, 10 May 2004 23:40:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNO58-00083h-P8 for ips-archive@odin.ietf.org; Mon, 10 May 2004 23:37:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4B3bQB4030961 for ips-archive@odin.ietf.org; Mon, 10 May 2004 23:37:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNNyL-00072l-K5 for ips-web-archive@optimus.ietf.org; Mon, 10 May 2004 23:30:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27933 for ; Mon, 10 May 2004 23:30:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNNyJ-0007Bg-NI for ips-web-archive@ietf.org; Mon, 10 May 2004 23:30:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNNxN-0006pp-00 for ips-web-archive@ietf.org; Mon, 10 May 2004 23:29:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNNwQ-0006Tn-00 for ips-web-archive@ietf.org; Mon, 10 May 2004 23:28:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNNpF-0004NL-SF; Mon, 10 May 2004 23:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNNjo-0003oc-GB for ips@optimus.ietf.org; Mon, 10 May 2004 23:15:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27031 for ; Mon, 10 May 2004 23:15:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNNjm-0001se-Bk for ips@ietf.org; Mon, 10 May 2004 23:15:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNNip-0001Jw-00 for ips@ietf.org; Mon, 10 May 2004 23:14:24 -0400 Received: from mail.ict.ac.cn ([159.226.39.4]) by ietf-mx with smtp (Exim 4.12) id 1BNNgc-0000bn-00 for ips@ietf.org; Mon, 10 May 2004 23:12:06 -0400 Received: (qmail 13793 invoked from network); 11 May 2004 03:00:24 -0000 Received: from unknown (HELO sunzenxp) (159.226.39.251) by mail.ict.ac.cn with SMTP; 11 May 2004 03:00:24 -0000 Date: Tue, 11 May 2004 11:19:9 +0800 From: "sunzen.w" To: "Black_David@emc.com" CC: "ips@ietf.org" Subject: Re: [Ips] iSCSI RFCs published! X-Priority: 1 (Highest) X-mailer: Foxmail 4.1 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Message-Id: Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,DATE_IN_PAST_06_12, TO_ADDRESS_EQ_REAL,X_PRIORITY_HIGH autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi, At the beginning of abstract of RFC 3720, "This document describes a transport protocol for Internet Small Computer Systems Interface (iSCSI) that works on top of TCP. " a transport protocol for iSCSI? It seems unlogical. sunzen _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed May 12 13:04:16 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26689 for ; Wed, 12 May 2004 13:04:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNwrt-0005ez-PC for ips-archive@odin.ietf.org; Wed, 12 May 2004 12:46:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CGk5Ql021752 for ips-archive@odin.ietf.org; Wed, 12 May 2004 12:46:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNwku-00027e-MC for ips-web-archive@optimus.ietf.org; Wed, 12 May 2004 12:38:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24938 for ; Wed, 12 May 2004 12:38:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNwkt-0000kQ-4V for ips-web-archive@ietf.org; Wed, 12 May 2004 12:38:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNwiX-0007nm-00 for ips-web-archive@ietf.org; Wed, 12 May 2004 12:36:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNwfS-0006RJ-00 for ips-web-archive@ietf.org; Wed, 12 May 2004 12:33:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNwTt-0003GO-Tz; Wed, 12 May 2004 12:21:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNvzP-0004WU-1B for ips@optimus.ietf.org; Wed, 12 May 2004 11:49:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19565 for ; Wed, 12 May 2004 11:49:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNvzN-0001Cy-Sf for ips@ietf.org; Wed, 12 May 2004 11:49:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNvxp-0000Kd-00 for ips@ietf.org; Wed, 12 May 2004 11:48:09 -0400 Received: from [203.199.113.69] (helo=vmail.vsnl.com) by ietf-mx with esmtp (Exim 4.12) id 1BNvwN-0006uG-00 for Ips@ietf.org; Wed, 12 May 2004 11:46:39 -0400 Received: from Jyothis ([127.0.0.1]) by vmail.vsnl.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with SMTP id <0HXL00EV3YGLAW@vmail.vsnl.com> for Ips@ietf.org; Wed, 12 May 2004 21:15:57 +0530 (IST) Received: from ([203.197.168.145]) by vmail.vsnl.com (InterScan E-Mail VirusWall Unix); Wed, 12 May 2004 21:15:57 +0530 (IST) Date: Wed, 12 May 2004 21:18:37 +0530 From: Jyothis To: Ips@ietf.org Message-id: <002201c43838$97301010$3801080a@telxsi.com> Organization: Tel MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: multipart/alternative; boundary="Boundary_(ID_0YJsu4Lho9Fa6fl4RP18CA)" X-Priority: 3 X-MSMail-priority: Normal Subject: [Ips] How i know my session id in case of sytem testing Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. --Boundary_(ID_0YJsu4Lho9Fa6fl4RP18CA) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT hai all i am doing system test for iscsi initiator using windows CLI he has given LOGOUT as a system testr how i know this ? any suggestions to this given id plz jyothis@tataelxsi.co.in --Boundary_(ID_0YJsu4Lho9Fa6fl4RP18CA) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
hai all
i am doing system test for iscsi initiator using windows CLI
he has given LOGOUT <SESSION ID>
as a system testr how i know this <SESSION ID>?
any suggestions to this given id plz
jyothis@tataelxsi.co.in
--Boundary_(ID_0YJsu4Lho9Fa6fl4RP18CA)-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed May 12 15:52:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06917 for ; Wed, 12 May 2004 15:52:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNzdi-0005Ws-J5 for ips-archive@odin.ietf.org; Wed, 12 May 2004 15:43:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CJhcDp021255 for ips-archive@odin.ietf.org; Wed, 12 May 2004 15:43:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNzXz-0003g7-Uv for ips-web-archive@optimus.ietf.org; Wed, 12 May 2004 15:37:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06010 for ; Wed, 12 May 2004 15:37:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNzXy-0006Zk-D0 for ips-web-archive@ietf.org; Wed, 12 May 2004 15:37:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNzWx-00061z-00 for ips-web-archive@ietf.org; Wed, 12 May 2004 15:36:39 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNzVp-0005F8-00 for ips-web-archive@ietf.org; Wed, 12 May 2004 15:35:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNzI3-0006Yc-O5; Wed, 12 May 2004 15:21:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNzCJ-00037h-Ei for ips@optimus.ietf.org; Wed, 12 May 2004 15:15:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01512 for ; Wed, 12 May 2004 14:28:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNyTG-0002u0-Ew for ips@ietf.org; Wed, 12 May 2004 14:28:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNySJ-0002Pp-00 for ips@ietf.org; Wed, 12 May 2004 14:27:48 -0400 Received: from web60706.mail.yahoo.com ([216.109.117.229]) by ietf-mx with smtp (Exim 4.12) id 1BNyRo-0001v5-00 for Ips@ietf.org; Wed, 12 May 2004 14:27:16 -0400 Message-ID: <20040512181620.698.qmail@web60706.mail.yahoo.com> Received: from [12.18.164.157] by web60706.mail.yahoo.com via HTTP; Wed, 12 May 2004 11:16:20 PDT Date: Wed, 12 May 2004 11:16:20 -0700 (PDT) From: Joe Souza Subject: Re: [Ips] How i know my session id in case of sytem testing To: Jyothis , Ips@ietf.org In-Reply-To: <002201c43838$97301010$3801080a@telxsi.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-509415547-1084385780=:99931" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 --0-509415547-1084385780=:99931 Content-Type: text/plain; charset=us-ascii If you are using Microsoft's iSCSI initiator, there is an iscsicli.exe command that will list active sessions. Active sessions are also displayed via the UI applet, which can be found in the Control Panel and there is probably a shortcut to it also on your desktop. -Joe Jyothis wrote: hai all i am doing system test for iscsi initiator using windows CLI he has given LOGOUT as a system testr how i know this ? any suggestions to this given id plz jyothis@tataelxsi.co.in --0-509415547-1084385780=:99931 Content-Type: text/html; charset=us-ascii
If you are using Microsoft's iSCSI initiator, there is an iscsicli.exe command that will list active sessions.  Active sessions are also displayed via the UI applet, which can be found in the Control Panel and there is probably a shortcut to it also on your desktop.
 
-Joe


Jyothis <jyothis@tataelxsi.co.in> wrote:
hai all
i am doing system test for iscsi initiator using windows CLI
he has given LOGOUT <SESSION ID>
as a system testr how i know this <SESSION ID>?
any suggestions to this given id plz
jyothis@tataelxsi.co.in
--0-509415547-1084385780=:99931-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu May 13 17:39:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17980 for ; Thu, 13 May 2004 17:39:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BONm7-0004tz-C3 for ips-archive@odin.ietf.org; Thu, 13 May 2004 17:29:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4DLTtFV018843 for ips-archive@odin.ietf.org; Thu, 13 May 2004 17:29:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BONgs-0001nT-1j for ips-web-archive@optimus.ietf.org; Thu, 13 May 2004 17:24:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15950 for ; Thu, 13 May 2004 17:24:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BONgp-0001KP-Oe for ips-web-archive@ietf.org; Thu, 13 May 2004 17:24:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BONe0-000021-00 for ips-web-archive@ietf.org; Thu, 13 May 2004 17:21:32 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BONcR-00076P-01 for ips-web-archive@ietf.org; Thu, 13 May 2004 17:19:55 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BONST-0000qk-DA for ips-web-archive@ietf.org; Thu, 13 May 2004 17:09:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOMlN-0005C3-Gg; Thu, 13 May 2004 16:25:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOMHe-0006qJ-Uu for ips@optimus.ietf.org; Thu, 13 May 2004 15:54:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09683 for ; Thu, 13 May 2004 15:54:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOMHd-0005uv-D3 for ips@ietf.org; Thu, 13 May 2004 15:54:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOMGg-0005OC-00 for ips@ietf.org; Thu, 13 May 2004 15:53:22 -0400 Received: from email.crossroads.com ([65.68.235.6]) by ietf-mx with smtp (Exim 4.12) id 1BOMFh-0004KZ-00 for ips@ietf.org; Thu, 13 May 2004 15:52:21 -0400 Received: from mailnode1.COMMSTOR.Crossroads.com ([192.168.1.249]) by email.crossroads.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 13 May 2004 14:51:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 May 2004 14:51:49 -0500 Message-ID: <43F5E8AE07F17C47BC16F7A159E9E7006BAD@mailnode1.commstor.crossroads.com> Thread-Topic: [Ips] iSCSI: NOP-Out during discovery Thread-Index: AcQtheqES78fn0F4ROWbIsIcvdVfIQLkHxpQ From: "Buck Landry" To: X-OriginalArrivalTime: 13 May 2004 19:51:50.0026 (UTC) FILETIME=[BB2EC6A0:01C43923] Content-Transfer-Encoding: quoted-printable Subject: [Ips] iSCSI: question regarding ABORT TASK SET + ABORT TASK interaction Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable An example scenario: I->T Scsi Command (CmdSN=3D0x1, ITT=3D0x1, LUN=3D0, WRITE_10) T->I R2T (ITT=3D0x1, TTT=3D0x1, ExpCmdSN=3D0x2, MaxCmdSN=3D0x10) I->T Task Mgmt Request (ABORT TASK SET, CmdSN=3D0x2, LUN=3D0, I=3D0) /* .. target waits for TTT 0x1 to be satisfied as described in RFC 3720, = 10.6.2.. */ I->T Task Mgmt Request (ABORT TASK, CmdSN=3D0x3, LUN=3D0, I=3D1, = RefCmdSN=3D0x1, RefTaskTag=3D0x1) ------------- When the ABORT TASK arrives, is the WRITE_10 still considered a "valid = task" as mentioned in 10.6.1 ("a) If the Referenced Task Tag identifies = a valid task...") ? If so, I assume the WRITE_10 is aborted by the ABORT TASK, the ABORT = TASK rsp ("function complete") is issued, and the ABORT TASK SET rsp is = also issued. If not, I assume 10.6.1 "c) If the Referenced Task Tag does not = identify an existing task..." applies; an ABORT TASK rsp ("task does not = exist") is issued, and the ABORT TASK SET continues waiting for the = R2T's TTT to be responded to. .. As a 3rd possibility, perhaps an initiator is forbidden from sending = such a sequence of PDUs -- it certainly doesn't seem like a good idea. = But I'm not sure the RFC forbids it. 10.5.1 "For ABORT TASK SET and = CLEAR TASK SET, the issuing initiator MUST continue to respond to all = valid target transfer tags" comes close, but I don't see that as = excluding any other PDUs (such as an immediate ABORT TASK) the initiator = might also wish to send. I'm looking at this from the perspective of a target implementer who's = trying to "do the right thing". Any insights would be appreciated. = Thanks, --buck _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu May 13 19:15:09 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23491 for ; Thu, 13 May 2004 19:15:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOPOm-0007kV-JP for ips-archive@odin.ietf.org; Thu, 13 May 2004 19:13:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4DNDuDZ029783 for ips-archive@odin.ietf.org; Thu, 13 May 2004 19:13:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOPMQ-0007Ek-Jn for ips-web-archive@optimus.ietf.org; Thu, 13 May 2004 19:11:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23211 for ; Thu, 13 May 2004 19:11:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOPMN-0001mL-6d for ips-web-archive@ietf.org; Thu, 13 May 2004 19:11:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOPLT-0001FH-00 for ips-web-archive@ietf.org; Thu, 13 May 2004 19:10:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOPKV-0000iV-00 for ips-web-archive@ietf.org; Thu, 13 May 2004 19:09:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOPFD-00059H-H0; Thu, 13 May 2004 19:04:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOPBq-000468-F4 for ips@optimus.ietf.org; Thu, 13 May 2004 19:00:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22909 for ; Thu, 13 May 2004 19:00:29 -0400 (EDT) From: AClarke@attotech.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOPBn-0003ku-5X for ips@ietf.org; Thu, 13 May 2004 19:00:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOPAv-0003Ea-00 for ips@ietf.org; Thu, 13 May 2004 18:59:38 -0400 Received: from sw.attotech.com ([12.32.232.56] helo=noteserv1.attotech.com) by ietf-mx with esmtp (Exim 4.12) id 1BOPAG-0002hv-00 for ips@ietf.org; Thu, 13 May 2004 18:58:56 -0400 Subject: Re: [Ips] iSCSI: question regarding ABORT TASK SET + ABORT TASK interaction To: "Buck Landry" , ips@ietf.org Message-ID: Date: Thu, 13 May 2004 18:58:14 -0400 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 >I->T Scsi Command (CmdSN=0x1, ITT=0x1, LUN=0, WRITE_10) >T->I R2T (ITT=0x1, TTT=0x1, ExpCmdSN=0x2, MaxCmdSN=0x10) >I->T Task Mgmt Request (ABORT TASK SET, CmdSN=0x2, LUN=0, I=0) > >/* .. target waits for TTT 0x1 to be > satisfied as described in RFC 3720, 10.6.2.. */ Does this mean that all Data-Out's have been received, passed to the SCSI layer, and processed? If so it can send status and the task management response. Then the task would no longer exist. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu May 13 19:30:25 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24657 for ; Thu, 13 May 2004 19:30:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOPXl-00027h-Cg for ips-archive@odin.ietf.org; Thu, 13 May 2004 19:23:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4DNNDlu008157 for ips-archive@odin.ietf.org; Thu, 13 May 2004 19:23:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOPUM-0001Mk-Ja for ips-web-archive@optimus.ietf.org; Thu, 13 May 2004 19:19:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24197 for ; Thu, 13 May 2004 19:19:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOPUL-00064w-37 for ips-web-archive@ietf.org; Thu, 13 May 2004 19:19:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOPTL-0005VT-00 for ips-web-archive@ietf.org; Thu, 13 May 2004 19:18:40 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOPSE-0004sj-00 for ips-web-archive@ietf.org; Thu, 13 May 2004 19:17:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOPPp-0008EW-W9; Thu, 13 May 2004 19:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOPO1-0007T4-TN for ips@optimus.ietf.org; Thu, 13 May 2004 19:13:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23258 for ; Thu, 13 May 2004 19:13:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOPO0-0002Rh-DG for ips@ietf.org; Thu, 13 May 2004 19:13:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOPMQ-0001mz-00 for ips@ietf.org; Thu, 13 May 2004 19:11:31 -0400 Received: from email.crossroads.com ([65.68.235.6]) by ietf-mx with smtp (Exim 4.12) id 1BOPLc-0000js-00 for ips@ietf.org; Thu, 13 May 2004 19:10:40 -0400 Received: from mailnode1.COMMSTOR.Crossroads.com ([192.168.1.249]) by email.crossroads.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 13 May 2004 18:10:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] iSCSI: question regarding ABORT TASK SET + ABORT TASKinteraction Date: Thu, 13 May 2004 18:10:05 -0500 Message-ID: <43F5E8AE07F17C47BC16F7A159E9E7006BAF@mailnode1.commstor.crossroads.com> Thread-Topic: [Ips] iSCSI: question regarding ABORT TASK SET + ABORT TASKinteraction Thread-Index: AcQ5PeJPP0WVKjaXSTeGWa3nRiNemQAAEpzA From: "Buck Landry" To: , X-OriginalArrivalTime: 13 May 2004 23:10:05.0633 (UTC) FILETIME=[6D845B10:01C4393F] Content-Transfer-Encoding: quoted-printable Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Nope. In this scenario no Data-Out is sent; the ABORT TASK is the next = PDU sent after the ABORT TASK SET. I agree with your assessment of what would happen if a good Data-Out = *had* been sent. Thanks, --buck -----Original Message----- From: AClarke@attotech.com [mailto:AClarke@attotech.com] Sent: Thursday, May 13, 2004 5:58 PM To: Buck Landry; ips@ietf.org Subject: Re: [Ips] iSCSI: question regarding ABORT TASK SET + ABORT TASKinteraction >I->T Scsi Command (CmdSN=3D0x1, ITT=3D0x1, LUN=3D0, WRITE_10) >T->I R2T (ITT=3D0x1, TTT=3D0x1, ExpCmdSN=3D0x2, MaxCmdSN=3D0x10) >I->T Task Mgmt Request (ABORT TASK SET, CmdSN=3D0x2, LUN=3D0, I=3D0) > >/* .. target waits for TTT 0x1 to be > satisfied as described in RFC 3720, 10.6.2.. */ Does this mean that all Data-Out's have been received, passed to the SCSI layer, and processed? If so it can send status and the task management response. Then the task would no longer exist. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu May 13 23:25:09 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06681 for ; Thu, 13 May 2004 23:25:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOTHo-0003e0-LO for ips-archive@odin.ietf.org; Thu, 13 May 2004 23:23:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4E3N0Vk014009 for ips-archive@odin.ietf.org; Thu, 13 May 2004 23:23:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOTCu-0002Xr-1G for ips-web-archive@optimus.ietf.org; Thu, 13 May 2004 23:17:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06115 for ; Thu, 13 May 2004 23:17:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOTCs-00060h-48 for ips-web-archive@ietf.org; Thu, 13 May 2004 23:17:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOT7K-0004oq-00 for ips-web-archive@ietf.org; Thu, 13 May 2004 23:12:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOT4z-0003go-00 for ips-web-archive@ietf.org; Thu, 13 May 2004 23:09:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOT1P-0007qR-Bn; Thu, 13 May 2004 23:06:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOSpZ-0004zX-Eb for ips@optimus.ietf.org; Thu, 13 May 2004 22:53:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05234 for ; Thu, 13 May 2004 22:53:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOSpV-0004TK-Rl for ips@ietf.org; Thu, 13 May 2004 22:53:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOSoV-0003vy-00 for ips@ietf.org; Thu, 13 May 2004 22:52:44 -0400 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx with esmtp (Exim 4.12) id 1BOSnm-0003IV-00; Thu, 13 May 2004 22:51:58 -0400 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i4E2pIfV052822; Fri, 14 May 2004 02:51:18 GMT Received: from d12ml102.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i4E2pId2262416; Fri, 14 May 2004 04:51:18 +0200 In-Reply-To: <43F5E8AE07F17C47BC16F7A159E9E7006BAD@mailnode1.commstor.crossroads.com> To: "Buck Landry" Cc: ips@ietf.org, ips-admin@ietf.org MIME-Version: 1.0 Subject: Re: [Ips] iSCSI: question regarding ABORT TASK SET + ABORT TASK interaction X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 From: Julian Satran Message-ID: Date: Thu, 13 May 2004 19:51:16 -0700 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.0.2CF2|July 23, 2003) at 14/05/2004 05:51:17, Serialize complete at 14/05/2004 05:51:17 Content-Type: multipart/alternative; boundary="=_alternative 000F4B3188256E94_=" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 This is a multipart message in MIME format. --=_alternative 000F4B3188256E94_= Content-Type: text/plain; charset="US-ASCII" ips-admin@ietf.org wrote on 13/05/2004 12:51:49: > An example scenario: > > I->T Scsi Command (CmdSN=0x1, ITT=0x1, LUN=0, WRITE_10) > T->I R2T (ITT=0x1, TTT=0x1, ExpCmdSN=0x2, MaxCmdSN=0x10) > I->T Task Mgmt Request (ABORT TASK SET, CmdSN=0x2, LUN=0, I=0) > > /* .. target waits for TTT 0x1 to be satisfied as described in RFC > 3720, 10.6.2.. */ > > I->T Task Mgmt Request (ABORT TASK, CmdSN=0x3, LUN=0, I=1, > RefCmdSN=0x1, RefTaskTag=0x1) > > ------------- > > When the ABORT TASK arrives, is the WRITE_10 still considered a > "valid task" as mentioned in 10.6.1 ("a) If the Referenced Task Tag > identifies a valid task...") ? > The task is still valid (waiting for Data) > If so, I assume the WRITE_10 is aborted by the ABORT TASK, the ABORT > TASK rsp ("function complete") is issued, and the ABORT TASK SET rsp > is also issued. > Correct. > If not, I assume 10.6.1 "c) If the Referenced Task Tag does not > identify an existing task..." applies; an ABORT TASK rsp ("task does > not exist") is issued, and the ABORT TASK SET continues waiting for > the R2T's TTT to be responded to. > > .. As a 3rd possibility, perhaps an initiator is forbidden from > sending such a sequence of PDUs -- it certainly doesn't seem like a > good idea. But I'm not sure the RFC forbids it. 10.5.1 "For ABORT > TASK SET and CLEAR TASK SET, the issuing initiator MUST continue to > respond to all valid target transfer tags" comes close, but I don't > see that as excluding any other PDUs (such as an immediate ABORT > TASK) the initiator might also wish to send. > > I'm looking at this from the perspective of a target implementer > who's trying to "do the right thing". Any insights would be > appreciated. Thanks, > > --buck > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips --=_alternative 000F4B3188256E94_= Content-Type: text/html; charset="US-ASCII"

ips-admin@ietf.org wrote on 13/05/2004 12:51:49:

> An example scenario:
>
> I->T Scsi Command (CmdSN=0x1, ITT=0x1, LUN=0, WRITE_10)
> T->I R2T (ITT=0x1, TTT=0x1, ExpCmdSN=0x2, MaxCmdSN=0x10)
> I->T Task Mgmt Request (ABORT TASK SET, CmdSN=0x2, LUN=0, I=0)
>
> /* .. target waits for TTT 0x1 to be satisfied as described in RFC
> 3720, 10.6.2.. */
>
> I->T Task Mgmt Request (ABORT TASK, CmdSN=0x3, LUN=0, I=1,
> RefCmdSN=0x1, RefTaskTag=0x1)
>
> -------------
>
> When the ABORT TASK arrives, is the WRITE_10 still considered a
> "valid task" as mentioned in 10.6.1 ("a)  If the Referenced Task Tag
> identifies a valid task...") ?
>

The task is still valid (waiting for Data)
 
> If so, I assume the WRITE_10 is aborted by the ABORT TASK, the ABORT
> TASK rsp ("function complete") is issued, and the ABORT TASK SET rsp
> is also issued.
>

Correct.

> If not, I assume 10.6.1 "c)  If the Referenced Task Tag does not
> identify an existing task..." applies; an ABORT TASK rsp ("task does
> not exist") is issued, and the ABORT TASK SET continues waiting for
> the R2T's TTT to be responded to.
>
> .. As a 3rd possibility, perhaps an initiator is forbidden from
> sending such a sequence of PDUs -- it certainly doesn't seem like a
> good idea.  But I'm not sure the RFC forbids it.  10.5.1 "For ABORT
> TASK SET and CLEAR TASK SET, the issuing initiator MUST continue to
> respond to all valid target transfer tags" comes close, but I don't
> see that as excluding any other PDUs (such as an immediate ABORT
> TASK) the initiator might also wish to send.
>
> I'm looking at this from the perspective of a target implementer
> who's trying to "do the right thing".  Any insights would be
> appreciated.  Thanks,
>
> --buck
>
> _______________________________________________
> Ips mailing list
> Ips@ietf.org
> https://www1.ietf.org/mailman/listinfo/ips
 --=_alternative 000F4B3188256E94_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri May 14 13:31:25 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07296 for ; Fri, 14 May 2004 13:31:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOgV7-0000kc-6w for ips-archive@odin.ietf.org; Fri, 14 May 2004 13:29:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4EHTbCP002886 for ips-archive@odin.ietf.org; Fri, 14 May 2004 13:29:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOgT7-0000Lq-4H for ips-web-archive@optimus.ietf.org; Fri, 14 May 2004 13:27:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06971 for ; Fri, 14 May 2004 13:27:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOgT5-0004st-2N for ips-web-archive@ietf.org; Fri, 14 May 2004 13:27:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOgS4-0004NY-00 for ips-web-archive@ietf.org; Fri, 14 May 2004 13:26:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOgRO-0003sF-00 for ips-web-archive@ietf.org; Fri, 14 May 2004 13:25:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOgMo-0007KR-R5; Fri, 14 May 2004 13:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOgGE-0005gM-EA for ips@optimus.ietf.org; Fri, 14 May 2004 13:14:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05958 for ; Fri, 14 May 2004 13:14:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOgGC-0005vL-FX for ips@ietf.org; Fri, 14 May 2004 13:14:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOgF8-0005QN-00 for ips@ietf.org; Fri, 14 May 2004 13:13:07 -0400 Received: from [203.199.113.69] (helo=vmail.vsnl.com) by ietf-mx with esmtp (Exim 4.12) id 1BOgE6-0004SU-00 for Ips@ietf.org; Fri, 14 May 2004 13:12:02 -0400 Received: from Jyothis ([127.0.0.1]) by vmail.vsnl.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with SMTP id <0HXP00KHIRR0SX@vmail.vsnl.com> for Ips@ietf.org; Fri, 14 May 2004 22:41:25 +0530 (IST) Received: from ([203.197.168.145]) by vmail.vsnl.com (InterScan E-Mail VirusWall Unix); Fri, 14 May 2004 22:41:25 +0530 (IST) Date: Fri, 14 May 2004 22:44:02 +0530 From: Jyothis To: Ips@ietf.org Message-id: <001901c439d6$daf91cc0$3801080a@telxsi.com> Organization: Tel MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: multipart/alternative; boundary="Boundary_(ID_rJij19PlcjYRd6o8CbXt0w)" X-Priority: 3 X-MSMail-priority: Normal Subject: [Ips] (no subject) Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. --Boundary_(ID_rJij19PlcjYRd6o8CbXt0w) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hello Guys, Here i established a iSCSI connection by LOGGIN. with same target, if i try to do LOGGIN again what will be response? 1)if i am correet it will increse the present connection id =present connection id+1 (i use the same negotaition parameters what i use in the beggining) am i right???? plz reply thanks in advance --Boundary_(ID_rJij19PlcjYRd6o8CbXt0w) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
  Hello Guys,
 
Here i established a  iSCSI connection by LOGGIN.
with same target, if i try to do LOGGIN again what will be response?
1)if i am correet it will increse the  present connection id  =present connection id+1 (i use the same negotaition parameters what i use in the beggining)
am i right????
plz reply
thanks in advance
 
--Boundary_(ID_rJij19PlcjYRd6o8CbXt0w)-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri May 14 14:26:48 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10847 for ; Fri, 14 May 2004 14:26:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOhNI-00038J-M9 for ips-archive@odin.ietf.org; Fri, 14 May 2004 14:25:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4EIPaRQ012039 for ips-archive@odin.ietf.org; Fri, 14 May 2004 14:25:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOhLh-0002lR-4M for ips-web-archive@optimus.ietf.org; Fri, 14 May 2004 14:23:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10676 for ; Fri, 14 May 2004 14:23:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOhLe-0002ps-KW for ips-web-archive@ietf.org; Fri, 14 May 2004 14:23:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOhKb-0002F5-00 for ips-web-archive@ietf.org; Fri, 14 May 2004 14:22:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOhJN-0001fp-00 for ips-web-archive@ietf.org; Fri, 14 May 2004 14:21:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOhEz-0001PM-0n; Fri, 14 May 2004 14:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOhAg-0000lO-RS for ips@optimus.ietf.org; Fri, 14 May 2004 14:12:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09565 for ; Fri, 14 May 2004 14:12:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOhAe-0004in-9C for ips@ietf.org; Fri, 14 May 2004 14:12:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOh9h-0004BX-00 for ips@ietf.org; Fri, 14 May 2004 14:11:34 -0400 Received: from atlrel6.hp.com ([156.153.255.205]) by ietf-mx with esmtp (Exim 4.12) id 1BOh8d-0003EJ-00 for ips@ietf.org; Fri, 14 May 2004 14:10:27 -0400 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by atlrel6.hp.com (Postfix) with ESMTP id 186461A213; Fri, 14 May 2004 14:10:22 -0400 (EDT) Received: from rose.hp.com (dhcp-roseor-beb167.rose.hp.com [15.23.141.167]) by rosemail.rose.hp.com (Postfix) with ESMTP id 290F9841A; Fri, 14 May 2004 08:05:56 -0700 (PDT) Message-ID: <40A50B8D.7010705@rose.hp.com> Date: Fri, 14 May 2004 11:10:21 -0700 From: "Mallikarjun C." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "sunzen.w" Cc: "ips@ietf.org" Subject: Re: [Ips] iSCSI RFCs published! Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Yes, it is unfortunately incorrect. We have to fix it some other time. It should be a "transport protocol for SCSI". The reviewers missed this error introduced in the RFC process. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com sunzen.w wrote: > hi, > At the beginning of abstract of RFC 3720, > "This document describes a transport protocol for Internet Small > Computer Systems Interface (iSCSI) that works on top of TCP. " > > a transport protocol for iSCSI? It seems unlogical. > > sunzen > > > > > > > > > _______________________________________________ > 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 exim@www1.ietf.org Sat May 15 03:44:42 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09181 for ; Sat, 15 May 2004 03:44:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOtp9-0005Wb-Nx for ips-archive@odin.ietf.org; Sat, 15 May 2004 03:43:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4F7hBJF021237 for ips-archive@odin.ietf.org; Sat, 15 May 2004 03:43:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOtnu-0005Iw-UO for ips-web-archive@optimus.ietf.org; Sat, 15 May 2004 03:41:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09081 for ; Sat, 15 May 2004 03:41:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOtns-0004Lb-LJ for ips-web-archive@ietf.org; Sat, 15 May 2004 03:41:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOtmz-0003u9-00 for ips-web-archive@ietf.org; Sat, 15 May 2004 03:40:58 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOtmQ-0003Sd-00 for ips-web-archive@ietf.org; Sat, 15 May 2004 03:40:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOtjE-0004Hb-Fq; Sat, 15 May 2004 03:37:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOtZh-00039R-GM for ips@optimus.ietf.org; Sat, 15 May 2004 03:27:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08533 for ; Sat, 15 May 2004 03:27:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOtZf-0005E3-6d for ips@ietf.org; Sat, 15 May 2004 03:27:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOtYO-0004hp-00 for ips@ietf.org; Sat, 15 May 2004 03:25:52 -0400 Received: from [202.54.64.17] (helo=hclnpd.hcltech.com) by ietf-mx with esmtp (Exim 4.12) id 1BOtXZ-0003n6-00 for Ips@ietf.org; Sat, 15 May 2004 03:25:02 -0400 Received: from npd-mail.hclt-ntl.co.in ([192.168.19.35]) by hclnpd.hcltech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KK5R686X; Sat, 15 May 2004 12:53:46 +0530 Received: from npd.hcltech.com (SSENTHIL-PC [192.168.19.171]) by npd-mail.hclt-ntl.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 256AF560; Sat, 15 May 2004 12:52:40 +0530 Message-ID: <40A5C53E.3157F12@npd.hcltech.com> Date: Sat, 15 May 2004 12:52:38 +0530 From: sundara senthil X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jyothis CC: Ips@ietf.org Subject: Re: [Ips] (no subject) References: <001901c439d6$daf91cc0$3801080a@telxsi.com> Content-Type: multipart/alternative; boundary="------------4AC5619FA95232D1E243206F" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.4 required=5.0 tests=HTML_20_30,HTML_MESSAGE, ROUND_THE_WORLD_LOCAL autolearn=no version=2.60 --------------4AC5619FA95232D1E243206F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jyothis If you try to connect to the same session (ie) to the exisiting ISID then connection id will be incremented as you said. But If you added a new session (ie) new ISID then new session with connection id zero. Also you can refer to the table given in session 5.3 of iSCSI Draft 20 Thanks sundar Jyothis wrote: > Hello Guys, Here i established a iSCSI connection by LOGGIN.with > same target, if i try to do LOGGIN again what will be response?1)if i > am correet it will increse the present connection id =present > connection id+1 (i use the same negotaition parameters what i use in > the beggining)am i right????plz replythanks in advance -- ************************************************************** "Beginnings are scary Endings are usually sad, But its the middle that count's the most..." ************************************************************** --------------4AC5619FA95232D1E243206F Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Jyothis

   If you try to connect to the same session (ie) to the exisiting ISID then connection id will be incremented as you said. But If you added a new session (ie) new ISID then new session with connection id zero.

   Also you can refer to the table given in session 5.3 of iSCSI Draft 20

Thanks
sundar

Jyothis wrote:

  Hello Guys, Here i established a  iSCSI connection by LOGGIN.with same target, if i try to do LOGGIN again what will be response?1)if i am correet it will increse the  present connection id  =present connection id+1 (i use the same negotaition parameters what i use in the beggining)am i right????plz replythanks in advance 

--
**************************************************************
"Beginnings  are  scary
 Endings are usually sad,
 But its the middle that count's the most..."
**************************************************************
  --------------4AC5619FA95232D1E243206F-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Sun May 16 05:36:29 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23772 for ; Sun, 16 May 2004 05:36:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPI2x-0000rC-Dp for ips-archive@odin.ietf.org; Sun, 16 May 2004 05:35:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4G9Z33X003290 for ips-archive@odin.ietf.org; Sun, 16 May 2004 05:35:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPHu5-0008Vq-B3 for ips-web-archive@optimus.ietf.org; Sun, 16 May 2004 05:25:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23503 for ; Sun, 16 May 2004 05:25:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPHu1-00042s-VO for ips-web-archive@ietf.org; Sun, 16 May 2004 05:25:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPHt9-0003gn-00 for ips-web-archive@ietf.org; Sun, 16 May 2004 05:24:56 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPHsS-0003Kg-00 for ips-web-archive@ietf.org; Sun, 16 May 2004 05:24:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPHka-0007Aj-T1; Sun, 16 May 2004 05:16:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPHgY-0006go-AC for ips@optimus.ietf.org; Sun, 16 May 2004 05:11:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23061 for ; Sun, 16 May 2004 05:11:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPHgV-0006ld-3G for ips@ietf.org; Sun, 16 May 2004 05:11:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPHfP-0006OP-00 for ips@ietf.org; Sun, 16 May 2004 05:10:44 -0400 Received: from [80.74.102.50] (helo=SANSRV1.SAN-RAD.CO.IL) by ietf-mx with esmtp (Exim 4.12) id 1BPHeR-0005pm-00 for Ips@ietf.org; Sun, 16 May 2004 05:09:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 16 May 2004 12:09:22 +0300 Message-ID: <6CD55BEE318E0D45B89043D74720E22A0C557B@SANSRV1.SAN-RAD.CO.IL> Thread-Topic: Source Attribute of a Network Entity Thread-Index: AcQ7JXq9UaObVUXhTfeFV0999sNtUA== From: "Yaron Klein" To: , , Cc: Content-Transfer-Encoding: quoted-printable Subject: [Ips] Source Attribute of a Network Entity Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi folks, Section 5.6.1 in the iSNS draft specifies that the Source Attribute MUST = be either a Storage Node or a Control Node from the Network Entity.=20 In the case where the Network Entity is a switch, the Storage Nodes it = reflects may change through time (the user can add or remove Storage = Nodes). Thus, it can register using one node, and when this node goes = down, it must re-register under different node. This may cause = inconsistency in the Network Entity representation.=20 Thus, it may be better to allow the Source Attribute to be the Network = Entity name (in iSCSI name format). This will ensure consistency in the = Network Entity representation and provide better maintenance. Yaron Klein Sanrad _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Sun May 16 08:53:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29907 for ; Sun, 16 May 2004 08:53:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPL6t-0002DY-9s for ips-archive@odin.ietf.org; Sun, 16 May 2004 08:51:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4GCpJIn008516 for ips-archive@odin.ietf.org; Sun, 16 May 2004 08:51:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPKzm-0001LP-4e for ips-web-archive@optimus.ietf.org; Sun, 16 May 2004 08:43:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29690 for ; Sun, 16 May 2004 08:43:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPKzk-0004kJ-Ta for ips-web-archive@ietf.org; Sun, 16 May 2004 08:43:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPKyl-0004Nj-00 for ips-web-archive@ietf.org; Sun, 16 May 2004 08:42:55 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPKxl-00040X-00 for ips-web-archive@ietf.org; Sun, 16 May 2004 08:41:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPKoC-00088Q-Qv; Sun, 16 May 2004 08:32:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPKgU-0007IG-AY for ips@optimus.ietf.org; Sun, 16 May 2004 08:24:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29292 for ; Sun, 16 May 2004 08:24:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPKgT-0005h3-2Y for ips@ietf.org; Sun, 16 May 2004 08:24:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPKfW-0005LH-00 for ips@ietf.org; Sun, 16 May 2004 08:23:02 -0400 Received: from mail.ict.ac.cn ([159.226.39.4]) by ietf-mx with smtp (Exim 4.12) id 1BPKef-0004do-00 for ips@ietf.org; Sun, 16 May 2004 08:22:09 -0400 Received: (qmail 6923 invoked from network); 16 May 2004 12:09:15 -0000 Received: from unknown (HELO sunzenxp) (159.226.39.251) by mail.ict.ac.cn with SMTP; 16 May 2004 12:09:15 -0000 Date: Sun, 16 May 2004 20:29:7 +0800 From: "sunzen.w" To: "Mallikarjun C." CC: "ips@ietf.org" Subject: Re: Re: [Ips] iSCSI RFCs published! X-mailer: Foxmail 4.1 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Message-Id: Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,DATE_IN_PAST_12_24 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit God! The response arrives at last. >Yes, it is unfortunately incorrect. We have to fix it some other time. > It should be a "transport protocol for SCSI". The reviewers missed >this error introduced in the RFC process. >-- >Mallikarjun > >Mallikarjun Chadalapaka >Networked Storage Architecture >Network Storage Solutions >Hewlett-Packard MS 5668 >Roseville CA 95747 >cbm [at] rose.hp.com > sunzen _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Sun May 16 16:08:46 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19109 for ; Sun, 16 May 2004 16:08:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPRqw-0001BL-1f for ips-archive@odin.ietf.org; Sun, 16 May 2004 16:03:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4GK3Inu004544 for ips-archive@odin.ietf.org; Sun, 16 May 2004 16:03:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPRoz-0000vI-9B for ips-web-archive@optimus.ietf.org; Sun, 16 May 2004 16:01:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18892 for ; Sun, 16 May 2004 16:01:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPRox-0007j8-M3 for ips-web-archive@ietf.org; Sun, 16 May 2004 16:01:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPRny-0007QI-00 for ips-web-archive@ietf.org; Sun, 16 May 2004 16:00:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPRn2-000778-00 for ips-web-archive@ietf.org; Sun, 16 May 2004 15:59:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPRhw-0008Tt-Ty; Sun, 16 May 2004 15:54:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPReL-00089w-Qp for ips@optimus.ietf.org; Sun, 16 May 2004 15:50:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18423 for ; Sun, 16 May 2004 15:50:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPReK-0004GA-BB for ips@ietf.org; Sun, 16 May 2004 15:50:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPRdN-0003wH-00 for ips@ietf.org; Sun, 16 May 2004 15:49:18 -0400 Received: from web21326.mail.yahoo.com ([216.136.175.215]) by ietf-mx with smtp (Exim 4.12) id 1BPRcZ-0003cn-00 for Ips@ietf.org; Sun, 16 May 2004 15:48:27 -0400 Message-ID: <20040516194816.35880.qmail@web21326.mail.yahoo.com> Received: from [67.124.96.240] by web21326.mail.yahoo.com via HTTP; Sun, 16 May 2004 12:48:16 PDT Date: Sun, 16 May 2004 12:48:16 -0700 (PDT) From: Josh Tseng Subject: Re: [Ips] Source Attribute of a Network Entity To: Yaron Klein , jtseng@yahoo.com, kevin.gibbons@mcdata.com, dulaney@us.ibm.com Cc: Ips@ietf.org In-Reply-To: <6CD55BEE318E0D45B89043D74720E22A0C557B@SANSRV1.SAN-RAD.CO.IL> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Yaron, Note that the Network Entity is a container or collection of storage nodes, and identifying it with an iSCSI Name is probably not appropriate in most cases. Without knowing the specifics of your implementation, my suggestion is to have your switch create a control node with which to manage the registration and deregistration of the Storage Nodes that it is in control of. Josh --- Yaron Klein wrote: > Hi folks, > > Section 5.6.1 in the iSNS draft specifies that the > Source Attribute MUST be either a Storage Node or a > Control Node from the Network Entity. > > In the case where the Network Entity is a switch, > the Storage Nodes it reflects may change through > time (the user can add or remove Storage Nodes). > Thus, it can register using one node, and when this > node goes down, it must re-register under different > node. This may cause inconsistency in the Network > Entity representation. > > Thus, it may be better to allow the Source Attribute > to be the Network Entity name (in iSCSI name > format). This will ensure consistency in the Network > Entity representation and provide better > maintenance. > > Yaron Klein > Sanrad > > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips __________________________________ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/ _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Sun May 16 16:20:26 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19464 for ; Sun, 16 May 2004 16:20:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPS6s-0003Jn-6J for ips-archive@odin.ietf.org; Sun, 16 May 2004 16:19:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4GKJki9012747 for ips-archive@odin.ietf.org; Sun, 16 May 2004 16:19:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPS5d-000390-JC for ips-web-archive@optimus.ietf.org; Sun, 16 May 2004 16:18:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19405 for ; Sun, 16 May 2004 16:18:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPS5b-0004pv-Tm for ips-web-archive@ietf.org; Sun, 16 May 2004 16:18:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPS4g-0004WL-00 for ips-web-archive@ietf.org; Sun, 16 May 2004 16:17:31 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPS3v-0004Ct-00 for ips-web-archive@ietf.org; Sun, 16 May 2004 16:16:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPRxR-0001yD-Hg; Sun, 16 May 2004 16:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPRs3-0001LA-3I for ips@optimus.ietf.org; Sun, 16 May 2004 16:04:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19007 for ; Sun, 16 May 2004 16:04:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPRs1-0000sZ-GE for ips@ietf.org; Sun, 16 May 2004 16:04:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPRqx-0000YY-00 for ips@ietf.org; Sun, 16 May 2004 16:03:20 -0400 Received: from web60707.mail.yahoo.com ([216.109.117.230]) by ietf-mx with smtp (Exim 4.12) id 1BPRqQ-0000F1-00 for Ips@ietf.org; Sun, 16 May 2004 16:02:46 -0400 Message-ID: <20040516200217.78226.qmail@web60707.mail.yahoo.com> Received: from [24.19.1.171] by web60707.mail.yahoo.com via HTTP; Sun, 16 May 2004 13:02:16 PDT Date: Sun, 16 May 2004 13:02:16 -0700 (PDT) From: Joe Souza Subject: Re: [Ips] Source Attribute of a Network Entity To: Josh Tseng , Yaron Klein , jtseng@yahoo.com, kevin.gibbons@mcdata.com, dulaney@us.ibm.com Cc: Ips@ietf.org In-Reply-To: <20040516194816.35880.qmail@web21326.mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1215023584-1084737736=:77960" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=HTML_MESSAGE autolearn=no version=2.60 --0-1215023584-1084737736=:77960 Content-Type: text/plain; charset=us-ascii Note that the Microsoft iSNS server does not currently allow control node registrations from network clients. What I suggest in this case is to register a fictitious iSCSI node (type=initiator should be fine) for your entity and use that as the Source Attribute for your requests, if you don't currently have any target nodes registered for your entity. Note also that as long as you have at least one target registered in your entity, you can use that target name as the Source Attribute for your requests. -Joe Josh Tseng wrote: Yaron, Note that the Network Entity is a container or collection of storage nodes, and identifying it with an iSCSI Name is probably not appropriate in most cases. Without knowing the specifics of your implementation, my suggestion is to have your switch create a control node with which to manage the registration and deregistration of the Storage Nodes that it is in control of. Josh --- Yaron Klein wrote: > Hi folks, > > Section 5.6.1 in the iSNS draft specifies that the > Source Attribute MUST be either a Storage Node or a > Control Node from the Network Entity. > > In the case where the Network Entity is a switch, > the Storage Nodes it reflects may change through > time (the user can add or remove Storage Nodes). > Thus, it can register using one node, and when this > node goes down, it must re-register under different > node. This may cause inconsistency in the Network > Entity representation. > > Thus, it may be better to allow the Source Attribute > to be the Network Entity name (in iSCSI name > format). This will ensure consistency in the Network > Entity representation and provide better > maintenance. > > Yaron Klein > Sanrad > > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips __________________________________ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/ _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --0-1215023584-1084737736=:77960 Content-Type: text/html; charset=us-ascii

Note that the Microsoft iSNS server does not currently allow control node registrations from network clients.  What I suggest in this case is to register a fictitious iSCSI node (type=initiator should be fine) for your entity and use that as the Source Attribute for your requests, if you don't currently have any target nodes registered for your entity.  Note also that as long as you have at least one target registered in your entity, you can use that target name as the Source Attribute for your requests.
 
-Joe


Josh Tseng <joshtseng@yahoo.com> wrote:
Yaron,

Note that the Network Entity is a container or
collection of storage nodes, and identifying it with
an iSCSI Name is probably not appropriate in most
cases.

Without knowing the specifics of your implementation,
my suggestion is to have your switch create a control
node with which to manage the registration and
deregistration of the Storage Nodes that it is in
control of.

Josh


--- Yaron Klein wrote:
> Hi folks,
>
> Section 5.6.1 in the iSNS draft specifies that the
> Source Attribute MUST be either a Storage Node or a
> Control Node from the Network Entity.
>
> In the case where the Network Entity is a switch,
> the Storage Nodes it reflects may change through
> time (the user can add or remove Storage Nodes).
> Thus, it can register usin! g one node, and when this
> node goes down, it must re-register under different
> node. This may cause inconsistency in the Network
> Entity representation.
>
> Thus, it may be better to allow the Source Attribute
> to be the Network Entity name (in iSCSI name
> format). This will ensure consistency in the Network
> Entity representation and provide better
> maintenance.
>
> Yaron Klein
> Sanrad
>
>
>
> _______________________________________________
> Ips mailing list
> Ips@ietf.org
> https://www1.ietf.org/mailman/listinfo/ips





__________________________________
Do you Yahoo!?
SBC Yahoo! - Internet access at a great low price.
http://promo.yahoo.com/sbc/

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--0-1215023584-1084737736=:77960-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon May 17 12:27:19 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02973 for ; Mon, 17 May 2004 12:27:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPkhv-0001m6-TH for ips-archive@odin.ietf.org; Mon, 17 May 2004 12:11:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HGBFg6006817 for ips-archive@odin.ietf.org; Mon, 17 May 2004 12:11:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPkVJ-00082w-5e for ips-web-archive@optimus.ietf.org; Mon, 17 May 2004 11:58:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00584 for ; Mon, 17 May 2004 11:58:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPkVH-0002xK-QP for ips-web-archive@ietf.org; Mon, 17 May 2004 11:58:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPkTD-0002JT-00 for ips-web-archive@ietf.org; Mon, 17 May 2004 11:56:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPkSA-0001qy-00 for ips-web-archive@ietf.org; Mon, 17 May 2004 11:54:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPkEh-0005hN-6M; Mon, 17 May 2004 11:41:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPkCC-0005No-Pj for ips@optimus.ietf.org; Mon, 17 May 2004 11:38:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28900 for ; Mon, 17 May 2004 11:38:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPkCB-0003zl-Nh for ips@ietf.org; Mon, 17 May 2004 11:38:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPkBH-0003eR-00 for ips@ietf.org; Mon, 17 May 2004 11:37:31 -0400 Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx with esmtp (Exim 4.12) id 1BPkAY-0003H4-00 for ips@ietf.org; Mon, 17 May 2004 11:36:46 -0400 Received: from ivvt2dxrc11 (c-66-177-57-55.se.client2.attbi.com[66.177.57.55]) by comcast.net (sccrmhc11) with SMTP id <2004051715361201100sncife> (Authid: esquicksall); Mon, 17 May 2004 15:36:16 +0000 Message-ID: <000c01c43c24$b11948d0$0303a8c0@ivvt2dxrc11> From: "Eddy Quicksall" To: Date: Mon, 17 May 2004 11:36:11 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C43C03.27410EC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Subject: [Ips] iSCSI: number of PDU's Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_60_70,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C43C03.27410EC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable There was a protocol change in 20+errata that I just noticed. I am = wondering (and surprised) why it was done ... since we have all written = our drivers and thought the protocol was stable. Especially when other = less disruptive changes were asked for and turned down: =20 -- draft 20 =20 10.4.8 ExpDataSN =20 The number of Data-In (read) PDUs the target has sent for the command. =20 -- draft 20+erratta and RFC =20 10.4.8. ExpDataSN The number of R2T and Data-In (read) PDUs the target has sent for the command. Eddy ------=_NextPart_000_0009_01C43C03.27410EC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

There was=20 a protocol change in 20+errata that I just noticed. I am wondering = (and=20 surprised) why it was done ... since we have all written our drivers and = thought=20 the protocol was stable. Especially when other less disruptive changes = were=20 asked for and turned down:

 

-- draft=20 20

 

10.4.8  ExpDataSN

 

   The number of Data-In = (read) PDUs=20 the target has sent for the

   command.

 

-- draft 20+erratta and=20 RFC

 

10.4.8. =20 ExpDataSN

  =20 The number of R2T and Data-In (read) PDUs the target has sent for=20 the
   command.

 

Eddy

------=_NextPart_000_0009_01C43C03.27410EC0-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon May 17 13:36:15 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07441 for ; Mon, 17 May 2004 13:36:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPlyx-0007zl-5o for ips-archive@odin.ietf.org; Mon, 17 May 2004 13:32:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HHWt2f030734 for ips-archive@odin.ietf.org; Mon, 17 May 2004 13:32:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPlkd-0005dM-UH for ips-web-archive@optimus.ietf.org; Mon, 17 May 2004 13:18:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06211 for ; Mon, 17 May 2004 13:18:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPlkc-00006J-13 for ips-web-archive@ietf.org; Mon, 17 May 2004 13:18:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPlji-0007aV-00 for ips-web-archive@ietf.org; Mon, 17 May 2004 13:17:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPlj6-0007HK-00 for ips-web-archive@ietf.org; Mon, 17 May 2004 13:16:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPlZt-0003vt-Pc; Mon, 17 May 2004 13:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPlKV-0001oG-Tg for ips@optimus.ietf.org; Mon, 17 May 2004 12:51:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04563 for ; Mon, 17 May 2004 12:51:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPlKU-0006O3-5O for ips@ietf.org; Mon, 17 May 2004 12:51:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPlJZ-00063Z-00 for ips@ietf.org; Mon, 17 May 2004 12:50:11 -0400 Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx with esmtp (Exim 4.12) id 1BPlIY-0005PE-00 for ips@ietf.org; Mon, 17 May 2004 12:49:06 -0400 Received: from ivvt2dxrc11 (c-66-177-57-55.se.client2.attbi.com[66.177.57.55]) by comcast.net (sccrmhc11) with SMTP id <2004051716483001100smseie> (Authid: esquicksall); Mon, 17 May 2004 16:48:31 +0000 Message-ID: <002601c43c2e$c8f81440$0303a8c0@ivvt2dxrc11> From: "Eddy Quicksall" To: "Ken Sandars" , References: <002c01c43c2b$6371f710$650115ac@winminx> Subject: Re: [Ips] iSCSI: number of PDU's Date: Mon, 17 May 2004 12:48:30 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0023_01C43C0D.41862BD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_50_60, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0023_01C43C0D.41862BD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MessageSorry, I didn't pickup the "target sent no data-in PDU's". Forget = I said anything. Eddy ----- Original Message -----=20 From: Ken Sandars=20 To: 'Eddy Quicksall' ; ips@ietf.org=20 Sent: Monday, May 17, 2004 12:24 PM Subject: RE: [Ips] iSCSI: number of PDU's Hi Eddy, This was added for bi-directional command support. The next paragraph = in the spec is the important one to consider.=20 For a WRITE-ONLY command, no Data-In pdus are sent, so the field is = reserved (ie 0) - this is no change to draft 20 behaviour. For a = READ-ONLY command there are no R2T pdus issued, so the number to report = is the same as the number of Data-In pdus. However, for bidi commands, the ExpDataSN counter is the combined = counter for both R2T and Data-In pdus (ie the target uses the one = counter to track the pdus sent to the initiator for each command - = essential for SNACK support). There was some talk about renaming it = DataR2TSN (or something similar), but the authors chose to limit the = changes to defining the semantics. End result - no change except for bidi commands. HTH, Ken. Ken Sandars Adaptec UK -----Original Message----- From: ips-admin@ietf.org [mailto:ips-admin@ietf.org] On Behalf Of = Eddy Quicksall Sent: 17 May 2004 16:36 To: ips@ietf.org Subject: [Ips] iSCSI: number of PDU's There was a protocol change in 20+errata that I just noticed. I am = wondering (and surprised) why it was done ... since we have all written = our drivers and thought the protocol was stable. Especially when other = less disruptive changes were asked for and turned down: =20 -- draft 20 =20 10.4.8 ExpDataSN =20 The number of Data-In (read) PDUs the target has sent for the command. =20 -- draft 20+erratta and RFC =20 10.4.8. ExpDataSN The number of R2T and Data-In (read) PDUs the target has sent for = the command. Eddy ------=_NextPart_000_0023_01C43C0D.41862BD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Sorry, I didn't pickup the "target sent no data-in = PDU's".=20 Forget I said anything.
 
Eddy
----- Original Message -----
From:=20 Ken=20 Sandars
To: 'Eddy = Quicksall' ;=20 ips@ietf.org =
Sent: Monday, May 17, 2004 = 12:24 PM
Subject: RE: [Ips] iSCSI: = number of=20 PDU's

Hi=20 Eddy,
 
This=20 was added for bi-directional command support. The next paragraph in = the spec=20 is the important one to consider.
 
For=20 a WRITE-ONLY command, no Data-In pdus are sent, so the field is = reserved=20 (ie 0) - this is no change to draft 20 behaviour. For a READ-ONLY = command=20 there are no R2T pdus issued, so the number to report is the same as = the=20 number of Data-In pdus.
 
However, for bidi commands, the ExpDataSN counter is = the combined=20 counter for both R2T and Data-In pdus (ie the target uses the one = counter to=20 track the pdus sent to the initiator for each command - essential for = SNACK=20 support). There was some talk about renaming it DataR2TSN (or = something=20 similar), but the authors chose to limit the changes to defining the=20 semantics.
 
End=20 result - no change except for bidi commands.
 
 
HTH,
Ken.
 
Ken=20 Sandars
Adaptec UK
-----Original Message-----
From:=20 ips-admin@ietf.org [mailto:ips-admin@ietf.org] On Behalf Of = Eddy=20 Quicksall
Sent: 17 May 2004 16:36
To:=20 ips@ietf.org
Subject: [Ips] iSCSI: number of=20 PDU's

There was=20 a protocol change in 20+errata that I just noticed. I am = wondering (and=20 surprised) why it was done ... since we have all written our drivers = and=20 thought the protocol was stable. Especially when other less = disruptive=20 changes were asked for and turned down:

 

-- draft=20 20

 

10.4.8  ExpDataSN

 

   The number of = Data-In (read)=20 PDUs the target has sent for the

   command.

 

-- draft 20+erratta = and=20 RFC

 

10.4.8.  ExpDataSN

   The number of R2T and Data-In (read) = PDUs the=20 target has sent for the
   command.

 

Eddy

------=_NextPart_000_0023_01C43C0D.41862BD0-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon May 17 20:27:52 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16388 for ; Mon, 17 May 2004 20:27:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPsRC-0000lg-C1 for ips-archive@odin.ietf.org; Mon, 17 May 2004 20:26:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4I0QUkb002953 for ips-archive@odin.ietf.org; Mon, 17 May 2004 20:26:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPsPV-0008RZ-Mu for ips-web-archive@optimus.ietf.org; Mon, 17 May 2004 20:24:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16209 for ; Mon, 17 May 2004 20:24:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPsPT-0000k0-IK for ips-web-archive@ietf.org; Mon, 17 May 2004 20:24:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPsOZ-0000NX-00 for ips-web-archive@ietf.org; Mon, 17 May 2004 20:23:48 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPsNf-00001C-00 for ips-web-archive@ietf.org; Mon, 17 May 2004 20:22:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPsJ6-0005qL-MS; Mon, 17 May 2004 20:18:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPs37-00018d-54 for ips@optimus.ietf.org; Mon, 17 May 2004 20:01:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15253 for ; Mon, 17 May 2004 20:01:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPs35-0000Nx-6E for ips@ietf.org; Mon, 17 May 2004 20:01:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPs2F-0007nR-00 for ips@ietf.org; Mon, 17 May 2004 20:00:44 -0400 Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx with esmtp (Exim 4.12) id 1BPs1S-0007O1-00; Mon, 17 May 2004 19:59:54 -0400 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i4HNxMGP038280; Mon, 17 May 2004 23:59:22 GMT Received: from d12ml102.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i4HNxMtL289740; Tue, 18 May 2004 01:59:22 +0200 In-Reply-To: <000c01c43c24$b11948d0$0303a8c0@ivvt2dxrc11> To: "Eddy Quicksall" Cc: ips@ietf.org, ips-admin@ietf.org MIME-Version: 1.0 Subject: Re: [Ips] iSCSI: number of PDU's X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 From: Julian Satran Message-ID: Date: Tue, 18 May 2004 02:59:21 +0300 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.0.2CF2|July 23, 2003) at 18/05/2004 02:59:22, Serialize complete at 18/05/2004 02:59:22 Content-Type: multipart/alternative; boundary="=_alternative 005B6F9E85256E97_=" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 This is a multipart message in MIME format. --=_alternative 005B6F9E85256E97_= Content-Type: text/plain; charset="US-ASCII" Eddy, It is not a change - it is just a clarification. Somewhere else in text there is statement that R2T and Data-In share the numbering space. As others where confused the text was added to clarify the meaning for bi-directional commands (the only ones that have both Data-In and R2T). The issue was on the list and addressed and the solution was agreed. You have probably missed the discussion. Julo "Eddy Quicksall" Sent by: ips-admin@ietf.org 17/05/04 11:36 To cc Subject [Ips] iSCSI: number of PDU's There was a protocol change in 20+errata that I just noticed. I am wondering (and surprised) why it was done ... since we have all written our drivers and thought the protocol was stable. Especially when other less disruptive changes were asked for and turned down: -- draft 20 10.4.8 ExpDataSN The number of Data-In (read) PDUs the target has sent for the command. -- draft 20+erratta and RFC 10.4.8. ExpDataSN The number of R2T and Data-In (read) PDUs the target has sent for the command. Eddy --=_alternative 005B6F9E85256E97_= Content-Type: text/html; charset="US-ASCII"
Eddy,

It is not a change - it is just a clarification.
Somewhere else in text there is statement that R2T and Data-In share the numbering space.
As others where confused the text was added to clarify the meaning for bi-directional commands (the only ones that have both Data-In and R2T).
The issue was on the list and addressed and the solution was agreed.
You have probably missed the discussion.

Julo


"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>
Sent by: ips-admin@ietf.org

17/05/04 11:36

To
<ips@ietf.org>
cc
Subject
[Ips] iSCSI: number of PDU's





There was a protocol change in 20+errata that I just noticed. I am wondering (and surprised) why it was done ... since we have all written our drivers and thought the protocol was stable. Especially when other less disruptive changes were asked for and turned down:
 
-- draft 20
 
10.4.8  ExpDataSN
 
   The number of Data-In (read) PDUs the target has sent for the
   command.
 
-- draft 20+erratta and RFC
 
10.4.8.  ExpDataSN
   The number of R2T and Data-In (read) PDUs the target has sent for the
  command.
 
Eddy
--=_alternative 005B6F9E85256E97_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue May 18 09:37:41 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14348 for ; Tue, 18 May 2004 09:37:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ4kF-0004Gm-Eu for ips-archive@odin.ietf.org; Tue, 18 May 2004 09:34:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IDYxmn016411 for ips-archive@odin.ietf.org; Tue, 18 May 2004 09:34:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ4Vs-00087q-B4 for ips-web-archive@optimus.ietf.org; Tue, 18 May 2004 09:20:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13054 for ; Tue, 18 May 2004 09:20:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ4Vn-00007W-0h for ips-web-archive@ietf.org; Tue, 18 May 2004 09:20:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ4Up-0007XK-00 for ips-web-archive@ietf.org; Tue, 18 May 2004 09:19:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQ4Tg-0006wV-00 for ips-web-archive@ietf.org; Tue, 18 May 2004 09:17:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ4CR-0001GZ-4I; Tue, 18 May 2004 09:00:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPkwP-0005iM-4z for ips@optimus.ietf.org; Mon, 17 May 2004 12:26:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02898 for ; Mon, 17 May 2004 12:26:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPkwN-0005Rv-Lr for ips@ietf.org; Mon, 17 May 2004 12:26:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPkvb-00056V-00 for ips@ietf.org; Mon, 17 May 2004 12:25:24 -0400 Received: from mailgate.elipsan.com ([80.177.61.146] helo=hammer.elipsan.com) by ietf-mx with esmtp (Exim 4.12) id 1BPkuc-0004fi-00 for ips@ietf.org; Mon, 17 May 2004 12:24:23 -0400 Received: from [10.229.20.51] (helo=winminx) by hammer.elipsan.com with esmtp (Exim 4.12) id 1BPksw-00047g-00; Mon, 17 May 2004 17:22:38 +0100 From: "Ken Sandars" To: "'Eddy Quicksall'" , Subject: RE: [Ips] iSCSI: number of PDU's Date: Mon, 17 May 2004 17:24:06 +0100 Message-ID: <002c01c43c2b$6371f710$650115ac@winminx> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002D_01C43C33.C5365F10" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <000c01c43c24$b11948d0$0303a8c0@ivvt2dxrc11> Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_50_60, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_002D_01C43C33.C5365F10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Eddy, =20 This was added for bi-directional command support. The next paragraph in = the spec is the important one to consider.=20 =20 For a WRITE-ONLY command, no Data-In pdus are sent, so the field is = reserved (ie 0) - this is no change to draft 20 behaviour. For a READ-ONLY = command there are no R2T pdus issued, so the number to report is the same as the number of Data-In pdus. =20 However, for bidi commands, the ExpDataSN counter is the combined = counter for both R2T and Data-In pdus (ie the target uses the one counter to = track the pdus sent to the initiator for each command - essential for SNACK support). There was some talk about renaming it DataR2TSN (or something similar), but the authors chose to limit the changes to defining the semantics. =20 End result - no change except for bidi commands. =20 =20 HTH, Ken. =20 Ken Sandars Adaptec UK -----Original Message----- From: ips-admin@ietf.org [mailto:ips-admin@ietf.org] On Behalf Of Eddy Quicksall Sent: 17 May 2004 16:36 To: ips@ietf.org Subject: [Ips] iSCSI: number of PDU's There was a protocol change in 20+errata that I just noticed. I am = wondering (and surprised) why it was done ... since we have all written our = drivers and thought the protocol was stable. Especially when other less = disruptive changes were asked for and turned down: =20 -- draft 20 =20 10.4.8 ExpDataSN =20 The number of Data-In (read) PDUs the target has sent for the command. =20 -- draft 20+erratta and RFC =20 10.4.8. ExpDataSN The number of R2T and Data-In (read) PDUs the target has sent for the command. =20 Eddy ------=_NextPart_000_002D_01C43C33.C5365F10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Eddy,
 
This=20 was added for bi-directional command support. The next paragraph in the = spec is=20 the important one to consider.
 
For a=20 WRITE-ONLY command, no Data-In pdus are sent, so the field is = reserved (ie=20 0) - this is no change to draft 20 behaviour. For a READ-ONLY command = there are=20 no R2T pdus issued, so the number to report is the same as the number of = Data-In=20 pdus.
 
However, for bidi commands, the ExpDataSN counter is = the combined=20 counter for both R2T and Data-In pdus (ie the target uses the one = counter to=20 track the pdus sent to the initiator for each command - essential for = SNACK=20 support). There was some talk about renaming it DataR2TSN (or something=20 similar), but the authors chose to limit the changes to defining the=20 semantics.
 
End=20 result - no change except for bidi commands.
 
 
HTH,
Ken.
 
Ken=20 Sandars
Adaptec UK
-----Original Message-----
From:=20 ips-admin@ietf.org [mailto:ips-admin@ietf.org] On Behalf Of = Eddy=20 Quicksall
Sent: 17 May 2004 16:36
To:=20 ips@ietf.org
Subject: [Ips] iSCSI: number of=20 PDU's

There was=20 a protocol change in 20+errata that I just noticed. I am = wondering (and=20 surprised) why it was done ... since we have all written our drivers = and=20 thought the protocol was stable. Especially when other less disruptive = changes=20 were asked for and turned down:

 

-- draft=20 20

 

10.4.8  ExpDataSN

 

   The number of Data-In = (read)=20 PDUs the target has sent for the

   command.

 

-- draft 20+erratta and=20 RFC

 

10.4.8.  ExpDataSN

  =20 The number of R2T and Data-In (read) PDUs the target has sent for=20 the
   command.

 

Eddy

------=_NextPart_000_002D_01C43C33.C5365F10-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue May 18 14:46:37 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04986 for ; Tue, 18 May 2004 14:46:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ9VJ-0002jX-5K for ips-archive@odin.ietf.org; Tue, 18 May 2004 14:39:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IIdrXS010503 for ips-archive@odin.ietf.org; Tue, 18 May 2004 14:39:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ9Mm-0001Ln-S2 for ips-web-archive@optimus.ietf.org; Tue, 18 May 2004 14:31:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03925 for ; Tue, 18 May 2004 14:31:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ9Mk-0005Xk-9A for ips-web-archive@ietf.org; Tue, 18 May 2004 14:31:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ9Lo-0005Se-00 for ips-web-archive@ietf.org; Tue, 18 May 2004 14:30:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQ9Kw-0005Qj-00 for ips-web-archive@ietf.org; Tue, 18 May 2004 14:29:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ93X-0003zO-6S; Tue, 18 May 2004 14:11:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ8uu-0001rU-KY for ips@optimus.ietf.org; Tue, 18 May 2004 14:02:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01902 for ; Tue, 18 May 2004 14:02:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ8ur-0003Yx-Ul for ips@ietf.org; Tue, 18 May 2004 14:02:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ8tw-0003WI-00 for ips@ietf.org; Tue, 18 May 2004 14:01:17 -0400 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1BQ8tR-0003Rh-00 for ips@ietf.org; Tue, 18 May 2004 14:00:45 -0400 Received: from mail6.microsoft.com ([157.54.6.196]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 18 May 2004 11:00:11 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 18 May 2004 11:00:22 -0700 Received: from 157.54.8.155 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 18 May 2004 11:00:14 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 18 May 2004 11:00:19 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 18 May 2004 10:59:58 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 18 May 2004 10:59:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-fd912a29-3e96-485b-8611-8266331ba1a3" Date: Tue, 18 May 2004 11:01:18 -0700 Message-ID: Thread-Topic: [iSCSI] Implicit\Explicit logout on Connection failure thread-index: AcQ9Ah68kRcnr6JiQkq8/KmMg0y1uA== From: "Lakshmi Ramasubramanian" To: X-OriginalArrivalTime: 18 May 2004 17:59:39.0521 (UTC) FILETIME=[E38DF710:01C43D01] Subject: [Ips] [iSCSI] Implicit\Explicit logout on Connection failure Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_50_60, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,MIME_BOUND_NEXTPART autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPartTM-000-fd912a29-3e96-485b-8611-8266331ba1a3 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C43D01.EF41A162" ------_=_NextPart_001_01C43D01.EF41A162 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 6.1.4.3 Connection Recovery (Page 66 in iSCSI RFC 3720) says that in the event of TCP Connection failure, initiator MUST close the connection and MUST implicitly or explicitly logout of that connection. If the TCP connection had failed, how can the initiator send a logout command if there is only one connection? Is the initiator expected to open a new connection to send=20 the logout command? =20 If there are more than one connection, should the initiator send the logout command on a different connection to logout the connection that failed? =20 thanks, -lakshmi ------_=_NextPart_001_01C43D01.EF41A162 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
6.1.4.3 Connection = Recovery=20 (Page 66 in iSCSI RFC 3720) says that in the = event
of TCP Connection failure, initiator MUST close the connection = and=20 MUST
implicitly or explicitly logout of that connection. If the TCP=20 connection
had failed, how can the initiator send a logout command if = there is=20 only
one connection? Is the initiator expected=20 to open a new connection to send
the logout command?
 
If there are more than one connection, should the initiator = send the=20 logout
command on a different connection to logout the connection that = failed?
 
thanks,
 -lakshmi
------_=_NextPart_001_01C43D01.EF41A162-- ------=_NextPartTM-000-fd912a29-3e96-485b-8611-8266331ba1a3-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue May 18 15:17:56 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07903 for ; Tue, 18 May 2004 15:17:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ9xe-0005lw-Oa for ips-archive@odin.ietf.org; Tue, 18 May 2004 15:09:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IJ9Ah4022186 for ips-archive@odin.ietf.org; Tue, 18 May 2004 15:09:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ9st-0002Jb-6V for ips-web-archive@optimus.ietf.org; Tue, 18 May 2004 15:04:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06016 for ; Tue, 18 May 2004 15:04:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ9sq-0007Yn-At for ips-web-archive@ietf.org; Tue, 18 May 2004 15:04:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ9rw-0007WV-00 for ips-web-archive@ietf.org; Tue, 18 May 2004 15:03:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQ9rY-0007Tp-00 for ips-web-archive@ietf.org; Tue, 18 May 2004 15:02:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ9lw-0005Fg-32; Tue, 18 May 2004 14:57:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ9eF-0003v6-Mj for ips@optimus.ietf.org; Tue, 18 May 2004 14:49:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05125 for ; Tue, 18 May 2004 14:49:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ9eC-0006fa-U7 for ips@ietf.org; Tue, 18 May 2004 14:49:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ9dM-0006eA-00 for ips@ietf.org; Tue, 18 May 2004 14:48:13 -0400 Received: from atlrel7.hp.com ([156.153.255.213]) by ietf-mx with esmtp (Exim 4.12) id 1BQ9cp-0006cL-00 for ips@ietf.org; Tue, 18 May 2004 14:47:39 -0400 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by atlrel7.hp.com (Postfix) with ESMTP id 36F71E085; Tue, 18 May 2004 14:47:39 -0400 (EDT) Received: from rose.hp.com (dhcp-roseor-bdi140.rose.hp.com [15.23.138.140]) by rosemail.rose.hp.com (Postfix) with ESMTP id 93B5A8252; Tue, 18 May 2004 07:32:47 -0700 (PDT) Message-ID: <40AA5A4A.80608@rose.hp.com> Date: Tue, 18 May 2004 11:47:38 -0700 From: "Mallikarjun C." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lakshmi Ramasubramanian Cc: ips@ietf.org Subject: Re: [Ips] [iSCSI] Implicit\Explicit logout on Connection failure References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Note that the referenced text applies only if connection recovery is negotiated (i.e. operational ErrorRecoveryLevel=2). >Is the initiator expected to open a new connection to send > the logout command? The following text in 6.1.4.3 answers your questions: Note: The logout function is mandatory. However, a new connection establishment is only mandatory if the failed connection was the last or only connection in the session. Sending a Logout Request PDU for a CID different from the issuing connection is legal. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Lakshmi Ramasubramanian wrote: > > 6.1.4.3 Connection Recovery (Page 66 in iSCSI RFC 3720) says that in the > event > of TCP Connection failure, initiator MUST close the connection and MUST > implicitly or explicitly logout of that connection. If the TCP connection > had failed, how can the initiator send a logout command if there is only > one connection? Is the initiator expected to open a new connection to send > the logout command? > > If there are more than one connection, should the initiator send the logout > command on a different connection to logout the connection that failed? > > thanks, > -lakshmi _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue May 18 17:10:48 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18796 for ; Tue, 18 May 2004 17:10:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQBgx-0005bi-U4 for ips-archive@odin.ietf.org; Tue, 18 May 2004 17:00:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IL03rC021553 for ips-archive@odin.ietf.org; Tue, 18 May 2004 17:00:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQBQC-0008MB-O3 for ips-web-archive@optimus.ietf.org; Tue, 18 May 2004 16:42:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16111 for ; Tue, 18 May 2004 16:42:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQBQA-0001Wz-Sb for ips-web-archive@ietf.org; Tue, 18 May 2004 16:42:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQBPE-0001Nz-00 for ips-web-archive@ietf.org; Tue, 18 May 2004 16:41:45 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQBO1-0001DK-00 for ips-web-archive@ietf.org; Tue, 18 May 2004 16:40:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQAUb-0006qK-TG; Tue, 18 May 2004 15:43:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQAPg-0004op-CQ for ips@optimus.ietf.org; Tue, 18 May 2004 15:38:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09630 for ; Tue, 18 May 2004 15:38:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQAPe-0001mc-N4 for ips@ietf.org; Tue, 18 May 2004 15:38:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQAOn-0001kZ-00 for ips@ietf.org; Tue, 18 May 2004 15:37:14 -0400 Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx with esmtp (Exim 4.12) id 1BQAON-0001hn-00 for ips@ietf.org; Tue, 18 May 2004 15:36:47 -0400 Received: from ivvt2dxrc11 (c-66-177-57-55.se.client2.attbi.com[66.177.57.55]) by comcast.net (sccrmhc12) with SMTP id <2004051819361601200fpel1e> (Authid: esquicksall); Tue, 18 May 2004 19:36:17 +0000 Message-ID: <004a01c43d0f$633ef290$0303a8c0@ivvt2dxrc11> From: "Eddy Quicksall" To: "Julian Satran" Cc: References: Subject: Re: [Ips] iSCSI: number of PDU's Date: Tue, 18 May 2004 15:36:14 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0047_01C43CED.DA553730" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE, HTML_TAG_EXISTS_TBODY autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0047_01C43CED.DA553730 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks All ... When I saw that change I did not read on to the next paragraph where it = makes it clear that this is only for bi-directional. Eddy ----- Original Message -----=20 From: Julian Satran=20 To: Eddy Quicksall=20 Cc: ips@ietf.org ; ips-admin@ietf.org=20 Sent: Monday, May 17, 2004 7:59 PM Subject: Re: [Ips] iSCSI: number of PDU's Eddy,=20 It is not a change - it is just a clarification.=20 Somewhere else in text there is statement that R2T and Data-In share = the numbering space.=20 As others where confused the text was added to clarify the meaning for = bi-directional commands (the only ones that have both Data-In and R2T).=20 The issue was on the list and addressed and the solution was agreed.=20 You have probably missed the discussion.=20 Julo=20 "Eddy Quicksall" =20 Sent by: ips-admin@ietf.org=20 17/05/04 11:36=20 To =20 cc =20 Subject [Ips] iSCSI: number of PDU's=20 =20 =20 There was a protocol change in 20+errata that I just noticed. I am = wondering (and surprised) why it was done ... since we have all written = our drivers and thought the protocol was stable. Especially when other = less disruptive changes were asked for and turned down:=20 =20 -- draft 20=20 =20 10.4.8 ExpDataSN=20 =20 The number of Data-In (read) PDUs the target has sent for the=20 command.=20 =20 -- draft 20+erratta and RFC=20 =20 10.4.8. ExpDataSN=20 The number of R2T and Data-In (read) PDUs the target has sent for = the command.=20 =20 Eddy=20 ------=_NextPart_000_0047_01C43CED.DA553730 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thanks All ...
 
When I saw that change I did not read on to the next = paragraph=20 where it makes it clear that this is only for = bi-directional.
 
Eddy
----- Original Message -----
From:=20 Julian Satran
To: Eddy = Quicksall=20
Sent: Monday, May 17, 2004 7:59 = PM
Subject: Re: [Ips] iSCSI: = number of=20 PDU's


Eddy, =

It is not a change - it is just a = clarification.=20
Somewhere else in text there is = statement=20 that R2T and Data-In share the numbering space.
As others where confused the text was added = to clarify=20 the meaning for bi-directional commands (the only ones that have both = Data-In=20 and R2T).
The issue was on = the list=20 and addressed and the solution was agreed.
You have probably missed the discussion.

Julo


"Eddy = Quicksall" <eddy_quicksall_i= Vivity_iSCSI@comcast.net>=20
Sent by: ips-admin@ietf.org =

17/05/04 11:36

To
<ips@ietf.org>=20
cc
Subject
[Ips] = iSCSI: number of=20 PDU's

=




There was a protocol change in 20+errata that = I just=20 noticed. I am wondering (and surprised) why it was done ... since we = have all=20 written our drivers and thought the protocol was stable. Especially = when other=20 less disruptive changes were asked for and turned down: =
 
-- draft=20 20
 
10.4.8  ExpDataSN
 
  =  The number of=20 Data-In (read) PDUs the target has sent for the
   command.
 
-- draft = 20+erratta and=20 RFC
 
10.4.8.  ExpDataSN
 =20  The number of R2T and Data-In (read) PDUs the target has sent = for=20 the
  command.
  =
Eddy
------=_NextPart_000_0047_01C43CED.DA553730-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue May 18 17:17:39 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19588 for ; Tue, 18 May 2004 17:17:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQBqA-0001Lr-4I for ips-archive@odin.ietf.org; Tue, 18 May 2004 17:09:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IL9Ygf005190 for ips-archive@odin.ietf.org; Tue, 18 May 2004 17:09:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQBcQ-0005Br-Ug for ips-web-archive@optimus.ietf.org; Tue, 18 May 2004 16:55:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17763 for ; Tue, 18 May 2004 16:55:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQBcP-0003J4-0O for ips-web-archive@ietf.org; Tue, 18 May 2004 16:55:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQBbW-0003DA-00 for ips-web-archive@ietf.org; Tue, 18 May 2004 16:54:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQBac-00034Q-00 for ips-web-archive@ietf.org; Tue, 18 May 2004 16:53:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQBOf-0007hw-7N; Tue, 18 May 2004 16:41:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQAaP-0007EO-7C for ips@optimus.ietf.org; Tue, 18 May 2004 15:49:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10202 for ; Tue, 18 May 2004 15:49:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQAaN-0002Qp-JZ for ips@ietf.org; Tue, 18 May 2004 15:49:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQAZT-0002OH-00 for ips@ietf.org; Tue, 18 May 2004 15:48:16 -0400 Received: from dmz1.silverbacksystems.com ([65.172.158.82]) by ietf-mx with esmtp (Exim 4.12) id 1BQAYy-0002KO-00 for ips@ietf.org; Tue, 18 May 2004 15:47:44 -0400 Received: from ns.silverbacksystems.com (gate-camp-hme0.silverbacksystems.com [65.172.158.93]) by dmz1.silverbacksystems.com (Postfix on SuSE Linux 7.3 (i386)) with ESMTP id CBD6D11931; Tue, 18 May 2004 12:47:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ns.silverbacksystems.com (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 3874A45E8B; Tue, 18 May 2004 12:47:09 -0700 (PDT) Received: from ns.silverbacksystems.com (localhost [127.0.0.1]) by localhost (AvMailGate-2.0.1.6) id 26797-24BBA255; Tue, 18 May 2004 12:47:09 -0700 Received: from carlos.silverbacksystems.com (carlos.corp.silverbacksystems.com [10.0.16.197]) by ns.silverbacksystems.com (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id D40D445E8B; Tue, 18 May 2004 12:47:08 -0700 (PDT) Message-Id: <6.0.3.0.2.20040518124442.03775af8@pop.silverbacksystems.com> X-Sender: crimola@pop.silverbacksystems.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Tue, 18 May 2004 12:47:02 -0700 To: "Lakshmi Ramasubramanian" , From: Carlos Rimola Subject: Re: [Ips] [iSCSI] Implicit\Explicit logout on Connection failure In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" X-AntiVirus: checked by AntiVir MailGate (version: 2.0.1.6; AVE: 6.24.0.7; VDF: 6.24.0.88; host: ns.silverbacksystems.com) Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,MIME_HTML_ONLY autolearn=no version=2.60 Lakshmi,

I think this is where the implicit keyword applies.  In other words, it should go through the same process as if a Logout Req had been sent and a Logour Resp received - implicitly.

Carlos Rimola
Silverback Systems

At 11:01 AM 5/18/2004, Lakshmi Ramasubramanian wrote:
 
6.1.4.3 Connection Recovery (Page 66 in iSCSI RFC 3720) says that in the event
of TCP Connection failure, initiator MUST close the connection and MUST
implicitly or explicitly logout of that connection. If the TCP connection
had failed, how can the initiator send a logout command if there is only
one connection? Is the initiator expected to open a new connection to send
the logout command?
 
If there are more than one connection, should the initiator send the logout
command on a different connection to logout the connection that failed?
 
thanks,
 -lakshmi

_______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri May 21 02:18:09 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07550 for ; Fri, 21 May 2004 02:18:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR3KZ-0007Jy-6e for ips-archive@odin.ietf.org; Fri, 21 May 2004 02:16:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4L6GVx5028143 for ips-archive@odin.ietf.org; Fri, 21 May 2004 02:16:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR3HT-0005VG-0c for ips-web-archive@optimus.ietf.org; Fri, 21 May 2004 02:13:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07119 for ; Fri, 21 May 2004 02:13:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR3HP-0002XT-Hf for ips-web-archive@ietf.org; Fri, 21 May 2004 02:13:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR3GT-0002QC-00 for ips-web-archive@ietf.org; Fri, 21 May 2004 02:12:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BR3Fp-0002IV-00 for ips-web-archive@ietf.org; Fri, 21 May 2004 02:11:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR3AQ-0002Fg-Ht; Fri, 21 May 2004 02:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR38x-0001Na-Af for ips@optimus.ietf.org; Fri, 21 May 2004 02:04:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28483 for ; Fri, 21 May 2004 02:04:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR38t-0001Mh-I1 for ips@ietf.org; Fri, 21 May 2004 02:04:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR387-0001F4-00 for ips@ietf.org; Fri, 21 May 2004 02:03:39 -0400 Received: from web42001.mail.yahoo.com ([66.218.93.169]) by ietf-mx with smtp (Exim 4.12) id 1BR37J-00016C-00 for ips@ietf.org; Fri, 21 May 2004 02:02:49 -0400 Message-ID: <20040521060219.28446.qmail@web42001.mail.yahoo.com> Received: from [64.164.0.90] by web42001.mail.yahoo.com via HTTP; Thu, 20 May 2004 23:02:19 PDT Date: Thu, 20 May 2004 23:02:19 -0700 (PDT) From: Alberto Alesina To: ips@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1819395984-1085119339=:27101" Subject: [Ips] multiple iSCSI sessions Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 --0-1819395984-1085119339=:27101 Content-Type: text/plain; charset=us-ascii Hi all, - Can there be two different iSCSI sessions from different iSCSI initiator ports to the same iSCSI target port (i.e. same target node + portal group tag)? - Can two different iSCSI sessions from different iSCSI initiator ports carry commands for the *same* LUN within an iSCSI target node? - Can the same LUN be in two different iSCSI target nodes? Thanks a lot for any clarifications.. Alberto --------------------------------- Do you Yahoo!? Yahoo! Domains - Claim yours for only $14.70/year --0-1819395984-1085119339=:27101 Content-Type: text/html; charset=us-ascii
Hi all,
 
- Can there be two different iSCSI sessions from different iSCSI initiator ports to the same iSCSI target port (i.e. same target node + portal group tag)?
 
- Can two different iSCSI sessions from different iSCSI initiator ports carry commands for the *same*  LUN within an iSCSI target node?
 
- Can the same LUN be in two different iSCSI target nodes?
 
Thanks a lot for any clarifications..
 
Alberto  

Do you Yahoo!?
Yahoo! Domains - Claim yours for only $14.70/year --0-1819395984-1085119339=:27101-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri May 21 04:57:02 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16317 for ; Fri, 21 May 2004 04:57:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR5Z5-0001Pz-LE for ips-archive@odin.ietf.org; Fri, 21 May 2004 04:39:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4L8ddlt005443 for ips-archive@odin.ietf.org; Fri, 21 May 2004 04:39:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR5RB-0007mK-NU for ips-web-archive@optimus.ietf.org; Fri, 21 May 2004 04:31:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14826 for ; Fri, 21 May 2004 04:31:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR5R8-0005eR-S6 for ips-web-archive@ietf.org; Fri, 21 May 2004 04:31:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR5QG-0005VG-00 for ips-web-archive@ietf.org; Fri, 21 May 2004 04:30:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BR5PT-0005Mh-00 for ips-web-archive@ietf.org; Fri, 21 May 2004 04:29:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR5FC-0004s1-VS; Fri, 21 May 2004 04:19:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR57h-00038C-Bk for ips@optimus.ietf.org; Fri, 21 May 2004 04:11:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13781 for ; Fri, 21 May 2004 04:11:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR57e-0002oG-41 for ips@ietf.org; Fri, 21 May 2004 04:11:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR56j-0002hS-00 for ips@ietf.org; Fri, 21 May 2004 04:10:22 -0400 Received: from vmail.vsnl.com ([203.199.113.69]) by ietf-mx with esmtp (Exim 4.12) id 1BR56B-0002Wh-00 for ips@ietf.org; Fri, 21 May 2004 04:09:47 -0400 Received: from Manohar ([127.0.0.1]) by vmail.vsnl.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with SMTP id <0HY200DQK1BC9N@vmail.vsnl.com> for ips@ietf.org; Fri, 21 May 2004 13:39:13 +0530 (IST) Received: from ([203.197.168.145]) by vmail.vsnl.com (InterScan E-Mail VirusWall Unix); Fri, 21 May 2004 13:39:13 +0530 (IST) Date: Fri, 21 May 2004 13:42:55 +0530 From: Manohars To: ips@ietf.org Message-id: <017d01c43f0b$6c3ddc00$a301080a@Manohar> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [Ips] Regarding CRC Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi all, Here in the section 12.1, the table for header and data digests says 32 bit CRC. +---------------------------------------------+ | Name | Description | Generator | +---------------------------------------------+ | CRC32C | 32 bit CRC |0x11edc6f41| +---------------------------------------------+ | None | no digest | +---------------------------------------------+ But in the eg. Generator given it is 36 bits. Please can any one verify this. How many bits, the std. uses for CRC Generator. with regards, Manohar _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri May 21 05:33:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18547 for ; Fri, 21 May 2004 05:33:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR68C-0003Bk-D0 for ips-archive@odin.ietf.org; Fri, 21 May 2004 05:15:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4L9FtNB012248 for ips-archive@odin.ietf.org; Fri, 21 May 2004 05:15:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR64m-0002De-54 for ips-web-archive@optimus.ietf.org; Fri, 21 May 2004 05:12:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17445 for ; Fri, 21 May 2004 05:12:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR64i-0004KB-UZ for ips-web-archive@ietf.org; Fri, 21 May 2004 05:12:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR63n-0004C4-00 for ips-web-archive@ietf.org; Fri, 21 May 2004 05:11:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BR630-000445-00 for ips-web-archive@ietf.org; Fri, 21 May 2004 05:10:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR5r1-0006bu-Ts; Fri, 21 May 2004 04:58:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR5eE-00033j-FX for ips@optimus.ietf.org; Fri, 21 May 2004 04:44:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15693 for ; Fri, 21 May 2004 04:44:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR5eB-0007kz-E8 for ips@ietf.org; Fri, 21 May 2004 04:44:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR5dK-0007Yj-00 for ips@ietf.org; Fri, 21 May 2004 04:44:02 -0400 Received: from vmail.vsnl.com ([203.199.113.69]) by ietf-mx with esmtp (Exim 4.12) id 1BR5cR-0007KK-00 for ips@ietf.org; Fri, 21 May 2004 04:43:07 -0400 Received: from pubbhaskar ([127.0.0.1]) by vmail.vsnl.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with SMTP id <0HY200DD02V1VK@vmail.vsnl.com> for ips@ietf.org; Fri, 21 May 2004 14:12:37 +0530 (IST) Received: from ([203.197.168.145]) by vmail.vsnl.com (InterScan E-Mail VirusWall Unix); Fri, 21 May 2004 14:12:37 +0530 (IST) Date: Fri, 21 May 2004 14:15:09 +0530 From: Bhaskar To: ips@ietf.org Message-id: <001a01c43f0f$ed263520$4601080a@telxsi.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [Ips] reg., bidirectional command Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi, Can any one give an example where bidirectional commands can be used. regards Bhaskar _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri May 21 09:29:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00458 for ; Fri, 21 May 2004 09:29:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRA3j-0006Sx-JL for ips-archive@odin.ietf.org; Fri, 21 May 2004 09:27:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LDRZJ0024811 for ips-archive@odin.ietf.org; Fri, 21 May 2004 09:27:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR9sA-0004LA-63 for ips-web-archive@optimus.ietf.org; Fri, 21 May 2004 09:15:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29756 for ; Fri, 21 May 2004 09:15:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR9s8-0001GH-FR for ips-web-archive@ietf.org; Fri, 21 May 2004 09:15:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR9rA-00013R-00 for ips-web-archive@ietf.org; Fri, 21 May 2004 09:14:37 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BR9qC-0000rR-00 for ips-web-archive@ietf.org; Fri, 21 May 2004 09:13:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR9kw-0001xK-Fg; Fri, 21 May 2004 09:08:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR9W1-0006UN-AC for ips@optimus.ietf.org; Fri, 21 May 2004 08:52:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28512 for ; Fri, 21 May 2004 08:52:42 -0400 (EDT) From: Black_David@emc.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR9Vz-0004Tn-OP for ips@ietf.org; Fri, 21 May 2004 08:52:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR9VB-0004HT-00 for ips@ietf.org; Fri, 21 May 2004 08:51:53 -0400 Received: from mxic2.corp.emc.com ([128.221.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1BR9US-00040K-00 for ips@ietf.org; Fri, 21 May 2004 08:51:08 -0400 Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 May 2004 08:50:37 -0400 Message-ID: To: aalesina@yahoo.com, ips@ietf.org Subject: RE: [Ips] multiple iSCSI sessions Date: Fri, 21 May 2004 08:50:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 > Hi all, > > - Can there be two different iSCSI sessions from different iSCSI initiator ports > to the same iSCSI target port (i.e. same target node + portal group tag)? Yes. > - Can two different iSCSI sessions from different iSCSI initiator ports carry > commands for the *same* LUN within an iSCSI target node? Yes. > - Can the same LUN be in two different iSCSI target nodes? Yes, although the SCSI-correct way to describe this is that the same LU can be accessed via LUNs at two different targets. 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 exim@www1.ietf.org Fri May 21 10:02:52 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02215 for ; Fri, 21 May 2004 10:02:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRAYJ-0005iD-Hn for ips-archive@odin.ietf.org; Fri, 21 May 2004 09:59:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LDxB0a021958 for ips-archive@odin.ietf.org; Fri, 21 May 2004 09:59:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRAKH-0002UN-Kv for ips-web-archive@optimus.ietf.org; Fri, 21 May 2004 09:44:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01255 for ; Fri, 21 May 2004 09:44:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRAKF-0007Cv-Qm for ips-web-archive@ietf.org; Fri, 21 May 2004 09:44:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRAJP-00071R-00 for ips-web-archive@ietf.org; Fri, 21 May 2004 09:43:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRAJ2-0006pE-00 for ips-web-archive@ietf.org; Fri, 21 May 2004 09:43:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRAEo-0001Xo-Lm; Fri, 21 May 2004 09:39:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRA7d-0007du-Dl for ips@optimus.ietf.org; Fri, 21 May 2004 09:31:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00514 for ; Fri, 21 May 2004 09:31:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRA7b-0004Pp-M1 for ips@ietf.org; Fri, 21 May 2004 09:31:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRA6c-0004DW-00 for ips@ietf.org; Fri, 21 May 2004 09:30:34 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BRA5n-0003r6-00 for ips@ietf.org; Fri, 21 May 2004 09:29:43 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 21 May 2004 06:29:39 -0700 X-BrightmailFiltered: true Received: from cisco.com (mbakke-lnx2.cisco.com [64.101.211.59]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i4LDT930029478; Fri, 21 May 2004 09:29:10 -0400 (EDT) Message-ID: <40AE0425.7010107@cisco.com> Date: Fri, 21 May 2004 08:29:09 -0500 From: Mark Bakke User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Manohars CC: ips@ietf.org Subject: Re: [Ips] Regarding CRC References: <017d01c43f0b$6c3ddc00$a301080a@Manohar> In-Reply-To: <017d01c43f0b$6c3ddc00$a301080a@Manohar> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Manohar- It's still a 32-bit polynomial; the generator is always one bit more (33 bits in this case), with the high bit always "1". For more info on how these work, Ross Williams wrote an excellent guide to how CRCs work a while back; it's called "A Painless Gude to CRC Error Detection Algorithms". It's available at: http://www.ross.net/crc/crcpaper.html -- Mark Bakke Manohars wrote: >Hi all, > Here in the section 12.1, the table for header and data digests says 32 bit >CRC. > >+---------------------------------------------+ >| Name | Description | Generator | >+---------------------------------------------+ >| CRC32C | 32 bit CRC |0x11edc6f41| >+---------------------------------------------+ >| None | no digest | >+---------------------------------------------+ > >But in the eg. Generator given it is 36 bits. Please can any one verify >this. How many bits, the std. uses for CRC Generator. > > > >with regards, >Manohar > > >_______________________________________________ >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 exim@www1.ietf.org Fri May 21 10:45:19 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06405 for ; Fri, 21 May 2004 10:45:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRBD7-0007EO-P2 for ips-archive@odin.ietf.org; Fri, 21 May 2004 10:41:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LEfLGV027755 for ips-archive@odin.ietf.org; Fri, 21 May 2004 10:41:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRAwD-0000ZD-19 for ips-web-archive@optimus.ietf.org; Fri, 21 May 2004 10:23:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03998 for ; Fri, 21 May 2004 10:23:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRAwA-00006i-C4 for ips-web-archive@ietf.org; Fri, 21 May 2004 10:23:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRAuy-0007cW-00 for ips-web-archive@ietf.org; Fri, 21 May 2004 10:22:37 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRAtv-0007NA-00 for ips-web-archive@ietf.org; Fri, 21 May 2004 10:21:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRAc5-0008Sn-Dy; Fri, 21 May 2004 10:03:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRAYn-0005xu-7R for ips@optimus.ietf.org; Fri, 21 May 2004 09:59:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01940 for ; Fri, 21 May 2004 09:59:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRAYl-0002ad-3K for ips@ietf.org; Fri, 21 May 2004 09:59:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRAXn-0002OL-00 for ips@ietf.org; Fri, 21 May 2004 09:58:40 -0400 Received: from ztxmail03.ztx.compaq.com ([161.114.1.207]) by ietf-mx with esmtp (Exim 4.12) id 1BRAX2-000200-00 for ips@ietf.org; Fri, 21 May 2004 09:57:52 -0400 Received: from cceexg11.americas.cpqcorp.net (cceexg11.americas.cpqcorp.net [16.81.1.28]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id 926C6AAD0 for ; Fri, 21 May 2004 08:57:21 -0500 (CDT) Received: from cceexc17.americas.cpqcorp.net ([16.81.1.15]) by cceexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 21 May 2004 08:57:21 -0500 X-MIMEOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] reg., bidirectional command Date: Fri, 21 May 2004 08:57:13 -0500 Message-ID: <78AF3C342AEAEF4BA33B35A8A15668C606E396AA@cceexc17.americas.cpqcorp.net> Thread-Topic: [Ips] reg., bidirectional command Thread-Index: AcQ/E4sSEignP03eTBOGlonmV0/0awAJ7gEA From: "Elliott, Robert (Server Storage)" To: X-OriginalArrivalTime: 21 May 2004 13:57:21.0420 (UTC) FILETIME=[89690CC0:01C43F3B] Content-Transfer-Encoding: quoted-printable Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable So far: 1. The XDWRITEREAD command in SBC-2 (block commands) 2. All commands in OSD (object based storage device commands) See http://www.t10.org/drafts.htm for the latest T10 committee working drafts of those standards. -- Rob Elliott, elliott@hp.com Hewlett-Packard Industry Standard Server Storage Advanced Technology https://ecardfile.com/id/RobElliott > -----Original Message----- > From: ips-admin@ietf.org [mailto:ips-admin@ietf.org] On=20 > Behalf Of Bhaskar > Sent: Friday, May 21, 2004 3:45 AM > To: ips@ietf.org > Subject: [Ips] reg., bidirectional command >=20 >=20 > Hi, >=20 > Can any one give an example where bidirectional commands can be used. >=20 > regards > Bhaskar >=20 > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips >=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri May 21 12:04:10 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10856 for ; Fri, 21 May 2004 12:04:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRCF2-0007KB-FM for ips-archive@odin.ietf.org; Fri, 21 May 2004 11:47:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LFlOrg028156 for ips-archive@odin.ietf.org; Fri, 21 May 2004 11:47:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRCBW-00065N-CF for ips-web-archive@optimus.ietf.org; Fri, 21 May 2004 11:43:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09799 for ; Fri, 21 May 2004 11:43:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRCBV-0006uX-B5 for ips-web-archive@ietf.org; Fri, 21 May 2004 11:43:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRCAV-0006rM-00 for ips-web-archive@ietf.org; Fri, 21 May 2004 11:42:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRC9e-0006oh-00 for ips-web-archive@ietf.org; Fri, 21 May 2004 11:41:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRBuO-0001BT-14; Fri, 21 May 2004 11:26:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRBnB-00084r-4Z for ips@optimus.ietf.org; Fri, 21 May 2004 11:18:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08301 for ; Fri, 21 May 2004 11:18:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRBnA-000520-8c for ips@ietf.org; Fri, 21 May 2004 11:18:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRBmA-0004m5-00 for ips@ietf.org; Fri, 21 May 2004 11:17:35 -0400 Received: from email-out1.iomega.com ([147.178.1.82] helo=email.iomega.com) by ietf-mx with esmtp (Exim 4.12) id 1BRBl9-0004Jm-00 for ips@ietf.org; Fri, 21 May 2004 11:16:31 -0400 Received: from royntex01.iomegacorp.com (edison [10.1.1.82]) by email.iomega.com (Postfix) with ESMTP id 29B321BD3 for ; Fri, 21 May 2004 09:15:47 -0600 (MDT) Received: from [147.178.176.63] ([147.178.176.63]) by royntex01.iomegacorp.c om with Microsoft SMTPSVC(5.0.2195.5329);Fri, 21 May 2004 09:15:46 -0600 Subject: RE: [Ips] reg., bidirectional command From: Pat LaVarre To: ips@ietf.org In-Reply-To: <78AF3C342AEAEF4BA33B35A8A15668C606E396AA@cceexc17.americas.cpq c orp.net> References: <78AF3C342AEAEF4BA33B35A8A15668C606E396AA@cceexc17.americas.cpqc orp.net> Content-Type: text/plain Message-Id: <1085152538.6103.7.camel@patibmrh9> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 21 May 2004 09:15:38 -0600 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 May 2004 15:15:46.0629 (UTC) FILETIME=[7DEEF750:01 C43F46] X-imss-version: 2.0 X-imss-result: Passed X-imss-scores: Clean:24.04638 C:20 M:1 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > Can any one give an > > example where bidirectional commands can be used. > > So far: > > 1. The XDWRITEREAD command in SBC-2 (block commands) > 2. All commands in OSD (object based storage device commands) Bidirectional is not sharply limited in Out bytes, yes? Popular Command Out byte length limits for various kinds of SCSI include x 0C 10 FF 104 107 3E8 (equal to decimal 12 16 255 300 303 1000). Pat LaVarre _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri May 21 18:58:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11172 for ; Fri, 21 May 2004 18:58:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRItV-0005b9-3h for ips-archive@odin.ietf.org; Fri, 21 May 2004 18:53:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LMrbvw021516 for ips-archive@odin.ietf.org; Fri, 21 May 2004 18:53:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRIf8-0003Bq-O4 for ips-web-archive@optimus.ietf.org; Fri, 21 May 2004 18:38:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10152 for ; Fri, 21 May 2004 18:38:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRIf5-0005Rx-My for ips-web-archive@ietf.org; Fri, 21 May 2004 18:38:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRIe8-0005KO-00 for ips-web-archive@ietf.org; Fri, 21 May 2004 18:37:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRIdB-0005Ej-00 for ips-web-archive@ietf.org; Fri, 21 May 2004 18:36:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRIVh-0000tM-VL; Fri, 21 May 2004 18:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRITU-00007h-Ib for ips@optimus.ietf.org; Fri, 21 May 2004 18:26:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09158 for ; Fri, 21 May 2004 18:26:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRITR-0004Km-Jw for ips@ietf.org; Fri, 21 May 2004 18:26:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRIST-0004FX-00 for ips@ietf.org; Fri, 21 May 2004 18:25:41 -0400 Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx with esmtp (Exim 4.12) id 1BRIRY-00047j-00; Fri, 21 May 2004 18:24:44 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i4LMODAN111272; Fri, 21 May 2004 22:24:13 GMT Received: from d12ml102.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i4LMOCmo152842; Sat, 22 May 2004 00:24:13 +0200 In-Reply-To: <20040521060219.28446.qmail@web42001.mail.yahoo.com> To: Alberto Alesina Cc: ips@ietf.org, ips-admin@ietf.org MIME-Version: 1.0 Subject: Re: [Ips] multiple iSCSI sessions X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 From: Julian Satran Message-ID: Date: Fri, 21 May 2004 18:24:10 -0400 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.0.2CF2|July 23, 2003) at 22/05/2004 01:24:12, Serialize complete at 22/05/2004 01:24:12 Content-Type: multipart/alternative; boundary="=_alternative 007A2A0785256E9B_=" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 This is a multipart message in MIME format. --=_alternative 007A2A0785256E9B_= Content-Type: text/plain; charset="US-ASCII" in text - julo ips-admin@ietf.org wrote on 21/05/2004 02:02:19: > Hi all, > > - Can there be two different iSCSI sessions from different iSCSI > initiator ports to the same iSCSI target port (i.e. same target node > + portal group tag)? > yes > - Can two different iSCSI sessions from different iSCSI initiator > ports carry commands for the *same* LUN within an iSCSI target node? > I assume you mean "same LU" as LUN is the "LU number" and the same LU may have different LUNs in different I_T nexi (different sessions in iSCSI) The response is yes. > > - Can the same LUN be in two different iSCSI target nodes? > See clarification above - yes if LU is what you meant > Thanks a lot for any clarifications.. > > Alberto > Do you Yahoo!? > Yahoo! Domains - Claim yours for only $14.70/year --=_alternative 007A2A0785256E9B_= Content-Type: text/html; charset="US-ASCII"
in text - julo

ips-admin@ietf.org wrote on 21/05/2004 02:02:19:

> Hi all,
>  
> - Can there be two different iSCSI sessions from different iSCSI
> initiator ports to the same iSCSI target port (i.e. same target node
> + portal group tag)?
>

yes
 
> - Can two different iSCSI sessions from different iSCSI initiator
> ports carry commands for the *same*  LUN within an iSCSI target node?
>

I assume you mean "same LU"  as LUN is the "LU number" and the same LU may have different LUNs in different I_T nexi (different sessions in iSCSI)
The response is yes.

>
> - Can the same LUN be in two different iSCSI target nodes?
>  

See clarification above - yes if LU is what you meant

> Thanks a lot for any clarifications..
>  
> Alberto  
> Do you Yahoo!?
> Yahoo! Domains - Claim yours for only $14.70/year --=_alternative 007A2A0785256E9B_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri May 21 19:31:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12539 for ; Fri, 21 May 2004 19:31:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRJQb-0004Ns-4j for ips-archive@odin.ietf.org; Fri, 21 May 2004 19:27:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4LNRnAL016853 for ips-archive@odin.ietf.org; Fri, 21 May 2004 19:27:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRJJq-0003SF-2G for ips-web-archive@optimus.ietf.org; Fri, 21 May 2004 19:20:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12190 for ; Fri, 21 May 2004 19:20:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRJJo-0001Vq-1e for ips-web-archive@ietf.org; Fri, 21 May 2004 19:20:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRJIu-0001RD-00 for ips-web-archive@ietf.org; Fri, 21 May 2004 19:19:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRJIB-0001MU-00 for ips-web-archive@ietf.org; Fri, 21 May 2004 19:19:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRJDF-00020o-9C; Fri, 21 May 2004 19:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRJ7B-0000M1-TP for ips@optimus.ietf.org; Fri, 21 May 2004 19:07:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11633 for ; Fri, 21 May 2004 19:07:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRJ78-0000I3-Ih for ips@ietf.org; Fri, 21 May 2004 19:07:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRJ6A-0000Bh-00 for ips@ietf.org; Fri, 21 May 2004 19:06:42 -0400 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx with esmtp (Exim 4.12) id 1BRJ5F-000032-00; Fri, 21 May 2004 19:05:45 -0400 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i4LN5FfV047514; Fri, 21 May 2004 23:05:15 GMT Received: from d12ml102.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i4LN59V6265300; Sat, 22 May 2004 01:05:15 +0200 In-Reply-To: <001a01c43f0f$ed263520$4601080a@telxsi.com> To: Bhaskar Cc: ips@ietf.org, ips-admin@ietf.org MIME-Version: 1.0 Subject: Re: [Ips] reg., bidirectional command X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 From: Julian Satran Message-ID: Date: Fri, 21 May 2004 19:05:07 -0400 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.0.2CF2|July 23, 2003) at 22/05/2004 02:05:15, Serialize complete at 22/05/2004 02:05:15 Content-Type: multipart/alternative; boundary="=_alternative 007BA1FF85256E9B_=" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE autolearn=no version=2.60 This is a multipart message in MIME format. --=_alternative 007BA1FF85256E9B_= Content-Type: text/plain; charset="US-ASCII" Look at the OSD (Object Storage Device) project in T10. Julo Bhaskar Sent by: ips-admin@ietf.org 21/05/04 04:45 To ips@ietf.org cc Subject [Ips] reg., bidirectional command Hi, Can any one give an example where bidirectional commands can be used. regards Bhaskar _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 007BA1FF85256E9B_= Content-Type: text/html; charset="US-ASCII"
Look at the OSD (Object Storage Device) project in T10.

Julo


Bhaskar <pubbhaskar@tataelxsi.co.in>
Sent by: ips-admin@ietf.org

21/05/04 04:45

To
ips@ietf.org
cc
Subject
[Ips] reg., bidirectional command





Hi,

Can any one give an example where bidirectional commands can be used.

regards
Bhaskar

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 007BA1FF85256E9B_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Sat May 22 09:04:30 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05193 for ; Sat, 22 May 2004 09:04:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRW1C-0000lM-4X for ips-archive@odin.ietf.org; Sat, 22 May 2004 08:54:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4MCsQbn002932 for ips-archive@odin.ietf.org; Sat, 22 May 2004 08:54:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRVpV-000720-F7 for ips-web-archive@optimus.ietf.org; Sat, 22 May 2004 08:42:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04551 for ; Sat, 22 May 2004 08:42:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRVpT-00066E-P0 for ips-web-archive@ietf.org; Sat, 22 May 2004 08:42:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRVoU-0005wU-00 for ips-web-archive@ietf.org; Sat, 22 May 2004 08:41:19 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BRVnk-0005nc-00 for ips-web-archive@ietf.org; Sat, 22 May 2004 08:40:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRVgV-0004XY-Sb; Sat, 22 May 2004 08:33:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRVZJ-0003AP-Or for ips@optimus.ietf.org; Sat, 22 May 2004 08:25:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03779 for ; Sat, 22 May 2004 08:25:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRVZI-000362-NW for ips@ietf.org; Sat, 22 May 2004 08:25:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRVYN-0002vr-00 for ips@ietf.org; Sat, 22 May 2004 08:24:40 -0400 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx with esmtp (Exim 4.12) id 1BRVXs-0002ih-00 for ips@ietf.org; Sat, 22 May 2004 08:24:08 -0400 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i4MCNafV098222; Sat, 22 May 2004 12:23:36 GMT Received: from d12ml102.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i4MCNacZ164176; Sat, 22 May 2004 14:23:36 +0200 In-Reply-To: <20040521224919.95419.qmail@web42004.mail.yahoo.com> To: Alberto Alesina Cc: ips@ietf.org MIME-Version: 1.0 Subject: Re: [Ips] multiple iSCSI sessions X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 From: Julian Satran Message-ID: Date: Sat, 22 May 2004 08:23:34 -0400 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.0.2CF2|July 23, 2003) at 22/05/2004 15:23:36, Serialize complete at 22/05/2004 15:23:36 Content-Type: multipart/alternative; boundary="=_alternative 00426B7A85256E9C_=" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 This is a multipart message in MIME format. --=_alternative 00426B7A85256E9C_= Content-Type: text/plain; charset="US-ASCII" Alberto Alesina wrote on 21/05/2004 18:49:19: > Julian..thanks for the reply. Please see inline > > >> - Can two different iSCSI sessions from different iSCSI initiator > >> ports carry commands for the *same* LUN within an iSCSI target node? > >> > > > I assume you mean "same LU" as LUN is the "LU number" and the > same LU may have different LUNs in > > different I_T nexi (different sessions in iSCSI) > > The response is yes. > Can the LU have the same LUN in different I_T nexi? > Yes > >> - Can the same LUN be in two different iSCSI target nodes? > >> > > > See clarification above - yes if LU is what you meant > Similarly, can an LU belonging to two different target nodes have > the same LUN? Yes > Also, can the same block numbers in an LU be written to from > different I_T nexi? Does iSCSI target have to care about maintaining > ordering consistency when two different iSCSI sessions are writing > to the same blocks in the same LU? > That is the domain of the SCSI Block Devices commands sets (not iSCSI). The general answer is that SCSI does not care about consistency not even about isolation although isolation can be "enforced" with a (seldom implemented) feature. > Thanks a lot for your time. > > - Alberto > > Do you Yahoo!? > Yahoo! Domains - Claim yours for only $14.70/year --=_alternative 00426B7A85256E9C_= Content-Type: text/html; charset="US-ASCII"

Alberto Alesina <aalesina@yahoo.com> wrote on 21/05/2004 18:49:19:

>  Julian..thanks for the reply. Please see inline  
>    
> >> - Can two different iSCSI sessions from different iSCSI initiator
> >> ports carry commands for the *same*  LUN within an iSCSI target node?
> >>
>
> > I assume you mean "same LU"  as LUN is the "LU number" and the
> same LU may have different LUNs in
> > different I_T nexi (different sessions in iSCSI)
> > The response is yes.
> Can the LU have the same LUN in different I_T nexi?
>
Yes

> >> - Can the same LUN be in two different iSCSI target nodes?
> >>  
>  
> > See clarification above - yes if LU is what you meant
> Similarly, can an LU belonging to two different target nodes have
> the same LUN?

Yes

> Also, can the same block numbers in an LU be written to from
> different I_T nexi? Does iSCSI target have to care about maintaining
> ordering consistency when two different iSCSI sessions are writing
> to the same blocks in the same LU?
>  

That is the domain of the SCSI Block Devices commands sets (not iSCSI).
The general answer is that SCSI does not care about consistency not even about isolation
although isolation can be "enforced" with a (seldom implemented) feature.

> Thanks a lot for your time.
>  
> - Alberto
>  
> Do you Yahoo!?
> Yahoo! Domains - Claim yours for only $14.70/year --=_alternative 00426B7A85256E9C_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips