From exim@www1.ietf.org Sun May 2 14:23:38 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24929 for ; Sun, 2 May 2004 14:23:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKLaK-0008ST-G4 for imss-archive@odin.ietf.org; Sun, 02 May 2004 14:21:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i42IL4eR032513 for imss-archive@odin.ietf.org; Sun, 2 May 2004 14:21:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKLQg-00060i-NX for imss-web-archive@optimus.ietf.org; Sun, 02 May 2004 14:11: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 OAA24492 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 1BKLQe-0001wH-AC for imss-web-archive@ietf.org; Sun, 02 May 2004 14:11:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKLPf-0001gb-00 for imss-web-archive@ietf.org; Sun, 02 May 2004 14:10:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKLOd-0001FI-00 for imss-web-archive@ietf.org; Sun, 02 May 2004 14:08:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKLGv-0003t5-T6; 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 1BKLF7-0003I7-H7 for imss@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 NAA24030 for ; Sun, 2 May 2004 13:59:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKLF5-0006jD-7Z for imss@ietf.org; Sun, 02 May 2004 13:59:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKLE8-0006U2-00 for imss@ietf.org; Sun, 02 May 2004 13:58:09 -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> 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 Subject: [imss] Re: [Ips] Proposal to remove "dynamic" port type for FcPortType Sender: imss-admin@ietf.org Errors-To: imss-admin@ietf.org X-BeenThere: imss@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet and Management Support for Storage Working Group 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 > > > > > _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From exim@www1.ietf.org Sun May 2 14:42: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 OAA25721 for ; Sun, 2 May 2004 14:42: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 1BKLmW-0004qs-2f for imss-archive@odin.ietf.org; Sun, 02 May 2004 14:33:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i42IXeWC018645 for imss-archive@odin.ietf.org; Sun, 2 May 2004 14:33:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKLgH-0003Hj-Mg for imss-web-archive@optimus.ietf.org; Sun, 02 May 2004 14:27: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 OAA25074 for ; Sun, 2 May 2004 14:27: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 1BKLgF-0005rX-54 for imss-web-archive@ietf.org; Sun, 02 May 2004 14:27:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKLfO-0005dI-00 for imss-web-archive@ietf.org; Sun, 02 May 2004 14:26:19 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKLex-0005OM-00 for imss-web-archive@ietf.org; Sun, 02 May 2004 14:25:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKLbF-00009S-Dz; 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 1BKLQi-00060m-61 for imss@optimus.ietf.org; Sun, 02 May 2004 14:11: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 OAA24498 for ; Sun, 2 May 2004 14:11:05 -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-0001wR-Mf for imss@ietf.org; Sun, 02 May 2004 14:11:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKLPg-0001gr-00 for imss@ietf.org; Sun, 02 May 2004 14:10:05 -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> 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 Subject: [imss] Re: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for FcPortType Sender: imss-admin@ietf.org Errors-To: imss-admin@ietf.org X-BeenThere: imss@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet and Management Support for Storage Working Group 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. _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From exim@www1.ietf.org Mon May 3 13:43:27 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16041 for ; Mon, 3 May 2004 13:43:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKhMI-0005hy-Rd for imss-archive@odin.ietf.org; Mon, 03 May 2004 13:36:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43Ha2gV021939 for imss-archive@odin.ietf.org; Mon, 3 May 2004 13:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKhHD-0004DN-Rb for imss-web-archive@optimus.ietf.org; Mon, 03 May 2004 13:30: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 NAA15236 for ; Mon, 3 May 2004 13:30: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 1BKhHB-0004DY-Qi for imss-web-archive@ietf.org; Mon, 03 May 2004 13:30:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKhGL-00049B-00 for imss-web-archive@ietf.org; Mon, 03 May 2004 13:29:54 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKhG2-00044B-00 for imss-web-archive@ietf.org; Mon, 03 May 2004 13:29:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKh1z-00013l-7U; 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-0006vx-0m for imss@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 NAA14218 for ; Mon, 3 May 2004 13:06: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 1BKgu6-00022v-3y for imss@ietf.org; Mon, 03 May 2004 13:06:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKgtL-0001tq-00 for imss@ietf.org; Mon, 03 May 2004 13:06:08 -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 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 Subject: [imss] RE: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for FcPortType Sender: imss-admin@ietf.org Errors-To: imss-admin@ietf.org X-BeenThere: imss@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet and Management Support for Storage Working Group 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 _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From exim@www1.ietf.org Mon May 3 14:54: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 OAA20259 for ; Mon, 3 May 2004 14:54: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 1BKiLY-0004Xz-7g for imss-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 i43IdKJB017475 for imss-archive@odin.ietf.org; Mon, 3 May 2004 14:39:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKiHB-0002tA-Dq for imss-web-archive@optimus.ietf.org; Mon, 03 May 2004 14: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 OAA19006 for ; Mon, 3 May 2004 14:34: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 1BKiH8-0003ap-Mr for imss-web-archive@ietf.org; Mon, 03 May 2004 14:34:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKiGF-0003Uy-00 for imss-web-archive@ietf.org; Mon, 03 May 2004 14:33:52 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKiFT-0003Oo-00 for imss-web-archive@ietf.org; Mon, 03 May 2004 14:33:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKhzx-0006gP-OD; 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 1BKhs6-0004yj-08 for imss@optimus.ietf.org; Mon, 03 May 2004 14:08: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 OAA17313 for ; Mon, 3 May 2004 14:08: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 1BKhs3-0000SR-IH for imss@ietf.org; Mon, 03 May 2004 14:08:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKhrE-0000Mk-00 for imss@ietf.org; Mon, 03 May 2004 14:08:01 -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: imss-admin@ietf.org Errors-To: imss-admin@ietf.org X-BeenThere: imss@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet and Management Support for Storage Working Group 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 > _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From exim@www1.ietf.org Mon May 3 15:19:53 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23379 for ; Mon, 3 May 2004 15:19: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 1BKin4-00015A-Ld for imss-archive@odin.ietf.org; Mon, 03 May 2004 15:07:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43J7kSs004154 for imss-archive@odin.ietf.org; Mon, 3 May 2004 15:07:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKijE-0006I4-CP for imss-web-archive@optimus.ietf.org; Mon, 03 May 2004 15:03: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 PAA20797 for ; Mon, 3 May 2004 15:03: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 1BKijB-00072V-Em for imss-web-archive@ietf.org; Mon, 03 May 2004 15:03:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKiiC-0006u5-00 for imss-web-archive@ietf.org; Mon, 03 May 2004 15:02:45 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKihD-0006ix-00 for imss-web-archive@ietf.org; Mon, 03 May 2004 15:01:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKiMM-0004g4-68; Mon, 03 May 2004 14:40:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKiFF-0002M5-A3 for imss@optimus.ietf.org; Mon, 03 May 2004 14:32: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 OAA18772 for ; Mon, 3 May 2004 14:32: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 1BKiFC-0003Mk-Mj for imss@ietf.org; Mon, 03 May 2004 14:32:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKiEF-0003D5-00 for imss@ietf.org; Mon, 03 May 2004 14:31:48 -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> 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 Subject: [imss] Re: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for FcPortType Sender: imss-admin@ietf.org Errors-To: imss-admin@ietf.org X-BeenThere: imss@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet and Management Support for Storage Working Group 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 > > _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From exim@www1.ietf.org Mon May 3 16:04:21 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26105 for ; Mon, 3 May 2004 16:04:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKjZB-0005hB-BW for imss-archive@odin.ietf.org; Mon, 03 May 2004 15:57:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43JvTLo021893 for imss-archive@odin.ietf.org; Mon, 3 May 2004 15:57:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKjQp-00042I-0I for imss-web-archive@optimus.ietf.org; Mon, 03 May 2004 15:48: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 PAA25244 for ; Mon, 3 May 2004 15:48: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 1BKjQn-0004hz-Ev for imss-web-archive@ietf.org; Mon, 03 May 2004 15:48:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKjPn-0004Zk-00 for imss-web-archive@ietf.org; Mon, 03 May 2004 15:47:48 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKjOq-0004Rz-00 for imss-web-archive@ietf.org; Mon, 03 May 2004 15:46:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKjDR-0006pJ-R0; Mon, 03 May 2004 15:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKhzj-0006eg-Fe for imss@optimus.ietf.org; Mon, 03 May 2004 14:16: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 OAA17886 for ; Mon, 3 May 2004 14:16: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 1BKhzg-0001RA-U5 for imss@ietf.org; Mon, 03 May 2004 14:16:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKhyo-0001JV-00 for imss@ietf.org; Mon, 03 May 2004 14:15:51 -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 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 Subject: [imss] RE: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for FcPortType Sender: imss-admin@ietf.org Errors-To: imss-admin@ietf.org X-BeenThere: imss@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet and Management Support for Storage Working Group 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 _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From exim@www1.ietf.org Mon May 3 16:04: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 QAA26122 for ; Mon, 3 May 2004 16:04: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 1BKjZB-0005hX-Jy for imss-archive@odin.ietf.org; Mon, 03 May 2004 15:57:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i43JvTEd021910 for imss-archive@odin.ietf.org; Mon, 3 May 2004 15:57:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKjRN-000488-VS for imss-web-archive@optimus.ietf.org; Mon, 03 May 2004 15:49: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 PAA25318 for ; Mon, 3 May 2004 15:49:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKjRM-0004nb-Js for imss-web-archive@ietf.org; Mon, 03 May 2004 15:49:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKjQ2-0004by-00 for imss-web-archive@ietf.org; Mon, 03 May 2004 15:48:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKjPO-0004Uv-00 for imss-web-archive@ietf.org; Mon, 03 May 2004 15:47:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKjDS-0006pU-58; Mon, 03 May 2004 15:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKiUr-0006bf-09 for imss@optimus.ietf.org; Mon, 03 May 2004 14:48: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 OAA20002 for ; Mon, 3 May 2004 14:48: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 1BKiUo-0005IP-60 for imss@ietf.org; Mon, 03 May 2004 14:48:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKiTy-0005C4-00 for imss@ietf.org; Mon, 03 May 2004 14:48:03 -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 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 Subject: [imss] RE: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for FcPortType Sender: imss-admin@ietf.org Errors-To: imss-admin@ietf.org X-BeenThere: imss@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet and Management Support for Storage Working Group 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) _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From exim@www1.ietf.org Mon May 3 20:43:43 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 UAA14008 for ; Mon, 3 May 2004 20:43: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 1BKo1N-0005ws-U7 for imss-archive@odin.ietf.org; Mon, 03 May 2004 20:42:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i440grTj022866 for imss-archive@odin.ietf.org; Mon, 3 May 2004 20:42:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKnyg-0005Qh-92 for imss-web-archive@optimus.ietf.org; Mon, 03 May 2004 20:40: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 UAA13874 for ; Mon, 3 May 2004 20:40: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 1BKnyd-00075T-W6 for imss-web-archive@ietf.org; Mon, 03 May 2004 20:40:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKnxm-0006xq-00 for imss-web-archive@ietf.org; Mon, 03 May 2004 20:39:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKnwp-0006qK-00 for imss-web-archive@ietf.org; Mon, 03 May 2004 20:38:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKntk-0003lW-RR; Mon, 03 May 2004 20:35:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKncL-0000Wg-W5 for imss@optimus.ietf.org; Mon, 03 May 2004 20:17: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 UAA13000 for ; Mon, 3 May 2004 20:16: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 1BKncJ-00049o-RZ for imss@ietf.org; Mon, 03 May 2004 20:16:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKnbP-00042f-00 for imss@ietf.org; Mon, 03 May 2004 20:16:04 -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 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 Subject: [imss] RE: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for FcPortType Sender: imss-admin@ietf.org Errors-To: imss-admin@ietf.org X-BeenThere: imss@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet and Management Support for Storage Working Group 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) _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From exim@www1.ietf.org Mon May 3 23:13: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 XAA18891 for ; Mon, 3 May 2004 23:13: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 1BKqLG-0007Qg-Bd for imss-archive@odin.ietf.org; Mon, 03 May 2004 23:11:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i443BYTZ028553 for imss-archive@odin.ietf.org; Mon, 3 May 2004 23:11:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKqJl-00074J-T2 for imss-web-archive@optimus.ietf.org; Mon, 03 May 2004 23:10: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 XAA18678 for ; Mon, 3 May 2004 23: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 1BKqJi-0002z9-7A for imss-web-archive@ietf.org; Mon, 03 May 2004 23:09:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKqHI-0002eo-00 for imss-web-archive@ietf.org; Mon, 03 May 2004 23:07:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BKqED-0002Jq-00 for imss-web-archive@ietf.org; Mon, 03 May 2004 23:04:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKqCz-0005Wz-NS; Mon, 03 May 2004 23:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKqBG-0005CD-EM for imss@optimus.ietf.org; Mon, 03 May 2004 23:01: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 XAA18306 for ; Mon, 3 May 2004 23:01:09 -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 1BKqBC-0001zZ-Os for imss@ietf.org; Mon, 03 May 2004 23:01:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKqAK-0001r0-00 for imss@ietf.org; Mon, 03 May 2004 23:00:17 -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: imss-admin@ietf.org Errors-To: imss-admin@ietf.org X-BeenThere: imss@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet and Management Support for Storage Working Group 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.6 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 _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From exim@www1.ietf.org Tue May 4 09:45:56 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 JAA01203 for ; Tue, 4 May 2004 09:45: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 1BL07j-0001xk-FZ for imss-archive@odin.ietf.org; Tue, 04 May 2004 09:38:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44DcFO1007539 for imss-archive@odin.ietf.org; Tue, 4 May 2004 09:38:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL04G-0000Hm-HA for imss-web-archive@optimus.ietf.org; Tue, 04 May 2004 09:34: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 JAA00553 for ; Tue, 4 May 2004 09:34: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 1BL04E-0002Gd-Oj for imss-web-archive@ietf.org; Tue, 04 May 2004 09:34:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL03I-0002Dh-00 for imss-web-archive@ietf.org; Tue, 04 May 2004 09:33:41 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL02g-0002Ax-00 for imss-web-archive@ietf.org; Tue, 04 May 2004 09:33:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKzuz-0006Vx-8G; Tue, 04 May 2004 09: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 1BKztb-0006C7-8p for imss@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 JAA00017 for ; Tue, 4 May 2004 09:23: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 1BKztZ-0001bt-GZ for imss@ietf.org; Tue, 04 May 2004 09:23:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKzsl-0001YF-00 for imss@ietf.org; Tue, 04 May 2004 09:22:49 -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> 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 Subject: [imss] Re: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for FcPortType6 Sender: imss-admin@ietf.org Errors-To: imss-admin@ietf.org X-BeenThere: imss@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet and Management Support for Storage Working Group 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) > _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From exim@www1.ietf.org Tue May 4 10:06:56 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 KAA02619 for ; Tue, 4 May 2004 10:06: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 1BL0Uz-0001DN-5O for imss-archive@odin.ietf.org; Tue, 04 May 2004 10:02:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44E2HZS004666 for imss-archive@odin.ietf.org; Tue, 4 May 2004 10:02:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL0Qd-0006pO-TC for imss-web-archive@optimus.ietf.org; Tue, 04 May 2004 09:57: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 JAA01916 for ; Tue, 4 May 2004 09:57: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 1BL0Qb-0003tK-Sl for imss-web-archive@ietf.org; Tue, 04 May 2004 09:57:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL0Po-0003pS-00 for imss-web-archive@ietf.org; Tue, 04 May 2004 09:56:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL0PB-0003jz-00 for imss-web-archive@ietf.org; Tue, 04 May 2004 09:56:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL0FI-000456-78; Tue, 04 May 2004 09:46:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL0Cx-0003Lq-Kh for imss@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 JAA01000 for ; Tue, 4 May 2004 09:43: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 1BL0Cv-0002qe-Nn for imss@ietf.org; Tue, 04 May 2004 09:43:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL0C6-0002nE-00 for imss@ietf.org; Tue, 04 May 2004 09:42: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 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: imss-admin@ietf.org Errors-To: imss-admin@ietf.org X-BeenThere: imss@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet and Management Support for Storage Working Group 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 > _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From exim@www1.ietf.org Tue May 4 13:10:35 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 NAA13284 for ; Tue, 4 May 2004 13:10: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 1BL3LG-0005TA-2e for imss-archive@odin.ietf.org; Tue, 04 May 2004 13:04:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44H4QsA021019 for imss-archive@odin.ietf.org; Tue, 4 May 2004 13:04:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL3Bo-0002vG-U6 for imss-web-archive@optimus.ietf.org; Tue, 04 May 2004 12:54: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 MAA12315 for ; Tue, 4 May 2004 12:54: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 1BL3Bn-0002Z8-8u for imss-web-archive@ietf.org; Tue, 04 May 2004 12:54:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL3Aq-0002RE-00 for imss-web-archive@ietf.org; Tue, 04 May 2004 12:53:41 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL39r-0002Lk-00 for imss-web-archive@ietf.org; Tue, 04 May 2004 12:52:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL2wl-00071f-4j; Tue, 04 May 2004 12:39:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL2sa-0005Cg-JR for imss@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 MAA11696 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-0000vt-UR for imss@ietf.org; Tue, 04 May 2004 12:34:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL2rh-0000qj-00 for imss@ietf.org; Tue, 04 May 2004 12:33:54 -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: imss-admin@ietf.org Errors-To: imss-admin@ietf.org X-BeenThere: imss@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet and Management Support for Storage Working Group 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 ...] _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From exim@www1.ietf.org Tue May 4 13:20:22 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 NAA13998 for ; Tue, 4 May 2004 13:20:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL3Z6-0001eu-Ki for imss-archive@odin.ietf.org; Tue, 04 May 2004 13:18:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44HIitd006376 for imss-archive@odin.ietf.org; Tue, 4 May 2004 13:18:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL3XD-0000lv-5u for imss-web-archive@optimus.ietf.org; Tue, 04 May 2004 13:16: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 NAA13731 for ; Tue, 4 May 2004 13: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 1BL3XB-0004vC-8d for imss-web-archive@ietf.org; Tue, 04 May 2004 13:16:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL3WN-0004pM-00 for imss-web-archive@ietf.org; Tue, 04 May 2004 13:15:56 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL3VK-0004jl-00 for imss-web-archive@ietf.org; Tue, 04 May 2004 13:14:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL3Ls-0005iO-3x; Tue, 04 May 2004 13:05:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL3C2-0002vm-Kz for imss@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 MAA12406 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-0002aq-Rm for imss@ietf.org; Tue, 04 May 2004 12:54:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL3B5-0002TW-00 for imss@ietf.org; Tue, 04 May 2004 12:53:56 -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> 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 Subject: [imss] Re: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for FcPortType Sender: imss-admin@ietf.org Errors-To: imss-admin@ietf.org X-BeenThere: imss@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet and Management Support for Storage Working Group 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) > _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From exim@www1.ietf.org Tue May 4 13:38:17 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 NAA14890 for ; Tue, 4 May 2004 13:38: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 1BL3kx-0005OI-EV for imss-archive@odin.ietf.org; Tue, 04 May 2004 13:30:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44HUxaG020717 for imss-archive@odin.ietf.org; Tue, 4 May 2004 13:30:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL3e2-0002yT-2C for imss-web-archive@optimus.ietf.org; Tue, 04 May 2004 13:23: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 NAA14202 for ; Tue, 4 May 2004 13:23: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 1BL3e0-0005fX-3W for imss-web-archive@ietf.org; Tue, 04 May 2004 13:23:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL3d2-0005aR-00 for imss-web-archive@ietf.org; Tue, 04 May 2004 13:22:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL3cS-0005VZ-00 for imss-web-archive@ietf.org; Tue, 04 May 2004 13:22:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL3ZR-0001mK-4K; 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 1BL3SS-0008Kr-1v for imss@optimus.ietf.org; Tue, 04 May 2004 13:11: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 NAA13452 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 1BL3SQ-0004Pz-7k for imss@ietf.org; Tue, 04 May 2004 13:11:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL3Rc-0004IX-00 for imss@ietf.org; Tue, 04 May 2004 13:11:01 -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: imss-admin@ietf.org Errors-To: imss-admin@ietf.org X-BeenThere: imss@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet and Management Support for Storage Working Group 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 ...] > _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From exim@www1.ietf.org Tue May 4 14:25:49 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 OAA17885 for ; Tue, 4 May 2004 14:25: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 1BL4Qs-0003gs-1O for imss-archive@odin.ietf.org; Tue, 04 May 2004 14:14:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44IEIUp014182 for imss-archive@odin.ietf.org; Tue, 4 May 2004 14:14:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL4Na-0002SC-Tb for imss-web-archive@optimus.ietf.org; Tue, 04 May 2004 14:10: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 OAA16827 for ; Tue, 4 May 2004 14:10: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 1BL4NY-0002iC-Eq for imss-web-archive@ietf.org; Tue, 04 May 2004 14:10:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL4Me-0002cb-00 for imss-web-archive@ietf.org; Tue, 04 May 2004 14:09:58 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL4M1-0002WZ-00 for imss-web-archive@ietf.org; Tue, 04 May 2004 14:09:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL4BE-0006fq-8u; 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 1BL45A-0002cP-FG for imss@optimus.ietf.org; Tue, 04 May 2004 13:51: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 NAA15671 for ; Tue, 4 May 2004 13:51: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 1BL458-0000e3-2M for imss@ietf.org; Tue, 04 May 2004 13:51:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL447-0000Xm-00 for imss@ietf.org; Tue, 04 May 2004 13:50:48 -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: imss-admin@ietf.org Errors-To: imss-admin@ietf.org X-BeenThere: imss@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet and Management Support for Storage Working Group 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 _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From exim@www1.ietf.org Tue May 4 17:32:17 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 RAA00576 for ; Tue, 4 May 2004 17:32: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 1BL7L5-0002AN-Vu for imss-archive@odin.ietf.org; Tue, 04 May 2004 17:20:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44LKVDH008323 for imss-archive@odin.ietf.org; Tue, 4 May 2004 17:20:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL7Gi-0000lO-7g for imss-web-archive@optimus.ietf.org; Tue, 04 May 2004 17:16: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 RAA00007 for ; Tue, 4 May 2004 17: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 1BL7Gf-0001Xl-W0 for imss-web-archive@ietf.org; Tue, 04 May 2004 17:15:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL7Fn-0001RD-00 for imss-web-archive@ietf.org; Tue, 04 May 2004 17:15:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL7Ez-0001KG-00 for imss-web-archive@ietf.org; Tue, 04 May 2004 17:14:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL776-0006Pf-VH; Tue, 04 May 2004 17:06:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL677-0006bu-ST for imss@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 QAA25958 for ; Tue, 4 May 2004 16:01: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 1BL676-0000Ea-9X for imss@ietf.org; Tue, 04 May 2004 16:02:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL66B-00007b-00 for imss@ietf.org; Tue, 04 May 2004 16:01:05 -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: imss-admin@ietf.org Errors-To: imss-admin@ietf.org X-BeenThere: imss@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet and Management Support for Storage Working Group 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) _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From exim@www1.ietf.org Thu May 6 14:36: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 OAA09972 for ; Thu, 6 May 2004 14:36: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 1BLnbA-0002xv-BC for imss-archive@odin.ietf.org; Thu, 06 May 2004 14:27:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46IRuVl011391 for imss-archive@odin.ietf.org; Thu, 6 May 2004 14:27:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLnS3-0007Xa-RD for imss-web-archive@optimus.ietf.org; Thu, 06 May 2004 14:18: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 OAA08791 for ; Thu, 6 May 2004 14:18:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLnS1-0005lJ-Fp for imss-web-archive@ietf.org; Thu, 06 May 2004 14:18:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLnQo-0005L1-00 for imss-web-archive@ietf.org; Thu, 06 May 2004 14:17:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLnQ9-0004v0-00 for imss-web-archive@ietf.org; Thu, 06 May 2004 14:16:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLnE1-0000ma-P2; 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 1BLn1f-0003b7-2U for imss@optimus.ietf.org; Thu, 06 May 2004 13:51: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 NAA07060 for ; Thu, 6 May 2004 13:51:12 -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 1BLn1c-0001nq-N3 for imss@ietf.org; Thu, 06 May 2004 13:51:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLn0g-0001MH-00 for imss@ietf.org; Thu, 06 May 2004 13:50:15 -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: [imss] FC Mgmt MIB: "dynamic" FC port type resolution Sender: imss-admin@ietf.org Errors-To: imss-admin@ietf.org X-BeenThere: imss@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet and Management Support for Storage Working Group 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 ---------------------------------------------------- _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss