From owner-ipfc@standards.gadzoox.com Mon Apr 2 12:19:47 2001 Received: from standards.gadzoox.com ([216.52.31.24]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18155 for ; Mon, 2 Apr 2001 12:19:46 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id IAA07842 for ipfc-list; Mon, 2 Apr 2001 08:47:36 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from smtp1.cluster.oleane.net (smtp1.cluster.oleane.net [195.25.12.16]) by standards.gadzoox.com (8.8.7/8.8.7) with SMTP id IAA07839 for ; Mon, 2 Apr 2001 08:47:30 -0700 Received: from oleane (dyn-1-1-150.Vin.dialup.oleane.fr [195.25.4.150]) by smtp1.cluster.oleane.net with SMTP id f32G0VO21004 for ; Mon, 2 Apr 2001 18:00:31 +0200 (CEST) Message-ID: <008801c0bb8e$33ee9dc0$8001a8c0@oleane.com> From: "Peter Lewis" To: Subject: IPoW ' 01 (IP over DWDM) Date: Mon, 2 Apr 2001 18:01:39 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0085_01C0BB9E.F7451320" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0085_01C0BB9E.F7451320 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable =20 Which granularity for all optical networks?=20 Synchronous or asynchronous optical networks?=20 Which model for the optical network: overlay or peer-to-peer?=20 How to integrate DWDM systems into MPL(ambda)S ?=20 IPoW ' 01 (IP over DWDM), will take place in Paris, France, from October = 9 to 12, 2001.=20 The call for proposals dead line has been extended to April 23rd. http://www.upperside.fr/ipow01/ipow2001intro.htm ------=_NextPart_000_0085_01C0BB9E.F7451320 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Which granularity for all optical networks? =
Synchronous or=20 asynchronous optical networks?
Which model for the optical network: = overlay=20 or peer-to-peer?
How to integrate DWDM systems into MPL(ambda)S ? =
IPoW ' 01 (IP over DWDM), will take place = in Paris,=20 France, from October 9 to 12, 2001.=20

The call for proposals dead line has been extended = to=20 April 23rd.

http://www.uppe= rside.fr/ipow01/ipow2001intro.htm

------=_NextPart_000_0085_01C0BB9E.F7451320-- From owner-ipfc@standards.gadzoox.com Mon Apr 2 12:19:54 2001 Received: from standards.gadzoox.com ([216.52.31.24]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18165 for ; Mon, 2 Apr 2001 12:19:53 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id IAA07837 for ipfc-list; Mon, 2 Apr 2001 08:45:59 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from smtp1.cluster.oleane.net (smtp1.cluster.oleane.net [195.25.12.16]) by standards.gadzoox.com (8.8.7/8.8.7) with SMTP id IAA07834 for ; Mon, 2 Apr 2001 08:45:52 -0700 Received: from oleane (dyn-1-1-150.Vin.dialup.oleane.fr [195.25.4.150]) by smtp1.cluster.oleane.net with SMTP id f32FwqO19923 for ; Mon, 2 Apr 2001 17:58:52 +0200 (CEST) Message-ID: <007001c0bb8d$f8ef7780$8001a8c0@oleane.com> From: "Peter Lewis" To: Subject: IPoW ' 01 (IP over DWDM) Date: Mon, 2 Apr 2001 17:59:57 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006D_01C0BB9E.BA578A60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_006D_01C0BB9E.BA578A60 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Which granularity for all optical networks?=20 Synchronous or asynchronous optical networks?=20 Which model for the optical network: overlay or peer-to-peer?=20 How to integrate DWDM systems into MPL(ambda)S ?=20 IPoW ' 01 (IP over DWDM), will take place in Paris, France, from October = 9 to 12, 2001.=20 The call for proposals dead line has been extended to April 23rd. http://www.upperside.fr/ipow01/ipow2001intro.htm ------=_NextPart_000_006D_01C0BB9E.BA578A60 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

The call for proposals dead line has been extended = to=20 April 23rd.

http://www.uppe= rside.fr/ipow01/ipow2001intro.htm

------=_NextPart_000_006D_01C0BB9E.BA578A60-- From owner-ipfc@standards.gadzoox.com Thu Apr 5 13:39:26 2001 Received: from standards.gadzoox.com ([216.52.31.24]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09172 for ; Thu, 5 Apr 2001 13:39:25 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id JAA09762 for ipfc-list; Thu, 5 Apr 2001 09:55:53 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from gordan.pl.gadzoox.com (gordan.pl.gadzoox.com [209.95.220.16]) by standards.gadzoox.com (8.8.7/8.8.7) with ESMTP id JAA09759 for ; Thu, 5 Apr 2001 09:55:47 -0700 Received: by gordan.pl.gadzoox.com with Internet Mail Service (5.5.2653.19) id <2HYZM4X6>; Thu, 5 Apr 2001 10:07:18 -0700 Message-ID: From: Sonny Sasspal To: "'ipfc@standards.gadzoox.com'" Subject: ipfc test Date: Thu, 5 Apr 2001 10:07:17 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk Test message Do not respond From owner-ipfc@standards.gadzoox.com Fri Apr 6 22:56:34 2001 Received: from standards.gadzoox.com ([216.52.31.24]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA26780 for ; Fri, 6 Apr 2001 22:56:34 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id TAA10715 for ipfc-list; Fri, 6 Apr 2001 19:12:11 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from mercury.lss.emc.com (mercury.eng.emc.com [168.159.40.77]) by standards.gadzoox.com (8.8.7/8.8.7) with SMTP id TAA10712 for ; Fri, 6 Apr 2001 19:12:03 -0700 Received: by mercury.eng.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Apr 2001 22:24:12 -0400 Message-ID: <2CE33F05597DD411AAE800D0B769587C026EE38D@sryoung.lss.emc.com> From: "blumenau, steven" To: "'Les Lovett'" Cc: "'ldarrow@vixel.com'" , "'ipfc@standards.gadzoox.com'" Subject: RE: Comments on fcmgmt 06 Date: Fri, 6 Apr 2001 22:25:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk how would you propose unsupported counters be identified. > -----Original Message----- > From: Les Lovett [mailto:les_lovett@cnt.com] > Sent: Friday, April 06, 2001 11:53 AM > To: blumenau, steven > Cc: 'ldarrow@vixel.com'; 'ipfc@standards.gadzoox.com' > Subject: Comments on fcmgmt 06 > > > Regarding most recently published fcmgmt MIB, > draft-ietf-ipfc-fcmgmt-int-mib-06.txt > Specifically - Port Statistics table > All of the counters are defined as Counter64. > The table's comment header says to set the most significant > bit to 1 if > the counter is not supported. > > My opinion is - do not use bit 1 {high order bit} to indicate > supported/not-supported. Instead use all 64 bits as a counter. > > LesLovett > From owner-ipfc@standards.gadzoox.com Fri Apr 6 23:35:28 2001 Received: from standards.gadzoox.com ([216.52.31.24]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA27348 for ; Fri, 6 Apr 2001 23:35:27 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id TAA10733 for ipfc-list; Fri, 6 Apr 2001 19:56:13 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from emulex.emulex.com (emulex.emulex.com [138.239.112.1]) by standards.gadzoox.com (8.8.7/8.8.7) with SMTP id TAA10730 for ; Fri, 6 Apr 2001 19:56:06 -0700 Received: from emulex.com (jinfantepc.emulex.com [138.239.96.81]) by emulex.emulex.com (8.9.1a/8.9.1) with ESMTP id UAA00797; Fri, 6 Apr 2001 20:08:35 -0700 (PDT) Message-ID: <3ACE84B7.E1980532@emulex.com> Date: Fri, 06 Apr 2001 20:08:40 -0700 From: "Infante, Jon" Organization: Emulex Corporation X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "blumenau, steven" CC: "'Les Lovett'" , "'ldarrow@vixel.com'" , "'ipfc@standards.gadzoox.com'" Subject: Re: Comments on fcmgmt 06 References: <2CE33F05597DD411AAE800D0B769587C026EE38D@sryoung.lss.emc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk Content-Transfer-Encoding: 7bit FYI In other FC documents, like FC-MI the HBAAPI annex, unsupported counters are identified by setting all bits in the counter (-1). Jon Infante Emulex "blumenau, steven" wrote: > how would you propose unsupported counters be identified. > > > -----Original Message----- > > From: Les Lovett [mailto:les_lovett@cnt.com] > > Sent: Friday, April 06, 2001 11:53 AM > > To: blumenau, steven > > Cc: 'ldarrow@vixel.com'; 'ipfc@standards.gadzoox.com' > > Subject: Comments on fcmgmt 06 > > > > > > Regarding most recently published fcmgmt MIB, > > draft-ietf-ipfc-fcmgmt-int-mib-06.txt > > Specifically - Port Statistics table > > All of the counters are defined as Counter64. > > The table's comment header says to set the most significant > > bit to 1 if > > the counter is not supported. > > > > My opinion is - do not use bit 1 {high order bit} to indicate > > supported/not-supported. Instead use all 64 bits as a counter. > > > > LesLovett > > From owner-ipfc@standards.gadzoox.com Sat Apr 7 00:24:55 2001 Received: from standards.gadzoox.com ([216.52.31.24]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA27733 for ; Sat, 7 Apr 2001 00:24:54 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id UAA10833 for ipfc-list; Fri, 6 Apr 2001 20:46:54 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from mercury.lss.emc.com (mercury.eng.emc.com [168.159.40.77]) by standards.gadzoox.com (8.8.7/8.8.7) with SMTP id UAA10828 for ; Fri, 6 Apr 2001 20:46:48 -0700 Received: by mercury.eng.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Apr 2001 23:58:59 -0400 Message-ID: <2CE33F05597DD411AAE800D0B769587C026EE38E@sryoung.lss.emc.com> From: "blumenau, steven" To: "'Infante, Jon'" Cc: "'Les Lovett'" , "'ldarrow@vixel.com'" , "'ipfc@standards.gadzoox.com'" Subject: RE: Comments on fcmgmt 06 Date: Fri, 6 Apr 2001 23:59:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk The original definition has these counters as unsigned so -1 would not work. Any other comments ? > -----Original Message----- > From: Infante, Jon [mailto:Jon.Infante@emulex.com] > Sent: Friday, April 06, 2001 11:09 PM > To: blumenau, steven > Cc: 'Les Lovett'; 'ldarrow@vixel.com'; 'ipfc@standards.gadzoox.com' > Subject: Re: Comments on fcmgmt 06 > > > FYI > In other FC documents, like FC-MI the HBAAPI annex, > unsupported counters > > are identified by setting all bits in the counter (-1). > > Jon Infante > Emulex > > > "blumenau, steven" wrote: > > > how would you propose unsupported counters be identified. > > > > > -----Original Message----- > > > From: Les Lovett [mailto:les_lovett@cnt.com] > > > Sent: Friday, April 06, 2001 11:53 AM > > > To: blumenau, steven > > > Cc: 'ldarrow@vixel.com'; 'ipfc@standards.gadzoox.com' > > > Subject: Comments on fcmgmt 06 > > > > > > > > > Regarding most recently published fcmgmt MIB, > > > draft-ietf-ipfc-fcmgmt-int-mib-06.txt > > > Specifically - Port Statistics table > > > All of the counters are defined as Counter64. > > > The table's comment header says to set the most significant > > > bit to 1 if > > > the counter is not supported. > > > > > > My opinion is - do not use bit 1 {high order bit} to indicate > > > supported/not-supported. Instead use all 64 bits as a counter. > > > > > > LesLovett > > > > From owner-ipfc@standards.gadzoox.com Mon Apr 9 06:07:17 2001 Received: from standards.gadzoox.com (standards.gadzoox.com [216.52.31.24]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA02308 for ; Mon, 9 Apr 2001 06:07:17 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id CAA12489 for ipfc-list; Mon, 9 Apr 2001 02:20:42 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from mumm.ibr.cs.tu-bs.de (mumm.ibr.cs.tu-bs.de [134.169.34.190]) by standards.gadzoox.com (8.8.7/8.8.7) with SMTP id CAA12485 for ; Mon, 9 Apr 2001 02:19:04 -0700 Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id LAA14195; Mon, 9 Apr 2001 11:10:05 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id LAA10994; Mon, 9 Apr 2001 11:10:04 +0200 Date: Mon, 9 Apr 2001 11:10:04 +0200 Message-Id: <200104090910.LAA10994@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: blumenau_steven@emc.com CC: les_lovett@cnt.com, ldarrow@vixel.com, ipfc@standards.gadzoox.com In-reply-to: <2CE33F05597DD411AAE800D0B769587C026EE38D@sryoung.lss.emc.com> (blumenau_steven@emc.com) Subject: Re: Comments on fcmgmt 06 References: <2CE33F05597DD411AAE800D0B769587C026EE38D@sryoung.lss.emc.com> Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk >>>>> blumenau, steven writes: Steven> how would you propose unsupported counters be identified. There is a general MIB rule: Objects that an implementation does not support do not exist. You need a very good reason to invent something new. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-ipfc@standards.gadzoox.com Mon Apr 9 18:10:50 2001 Received: from standards.gadzoox.com (standards.gadzoox.com [216.52.31.24]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17946 for ; Mon, 9 Apr 2001 18:10:49 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id OAA12827 for ipfc-list; Mon, 9 Apr 2001 14:28:09 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from falcon.vixel.com (mail.vixel.com [207.115.190.210]) by standards.gadzoox.com (8.8.7/8.8.7) with SMTP id OAA12824 for ; Mon, 9 Apr 2001 14:28:05 -0700 Received: from vixel.com ([38.244.18.141]) by falcon.vixel.com (Netscape Messaging Server 4.15) with ESMTP id GBJO8H00.65R for ; Mon, 9 Apr 2001 14:41:05 -0700 Message-ID: <3AD22C66.3238F97E@vixel.com> Date: Mon, 09 Apr 2001 14:40:54 -0700 From: "Lee Darrow" X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ipfc@standards.gadzoox.com Subject: Comments on fcmgmt 06 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk Content-Transfer-Encoding: 7bit Ok, here's a retry of the message I tried several times to send to this list last week. Lee -------- Original Message -------- Subject: Comments on fcmgmt 06 Date: Wed, 04 Apr 2001 15:52:24 -0700 From: Lee Darrow To: ipfc@standards.gadzoox.com I've got several comments, questions and issues regarding the most recently published fcmgmt MIB, draft-ietf-ipfc-fcmgmt-int-mib-06.txt. The order is basically as they appear in the MIB. I'm really sorry about the length. 1) The description of fcConnUnitModuleId is confusing to me. I take it that all the members of the connunit would set their fcConnUnitModuleId to the value of the fcConnUnitId of the module connunit. The description in the MIB doesn't exactly say this, but it's the only way I could see it working. 2) fcConnUnitFabricID. If unknown, the description says to set it to an empty string, but fcConnUnitFabricID is OCTET STRING (SIZE(16)), which must be 16 bytes long. It would probably be better to say fcConnUnitFabricID is all 0's or 1's in the event it is unknown. 3) FcGlobalId. The description is as follows: "Represents the Worldwide Name (WWN; IEEE 124-bit variety) associated with a Fibre Channel (FC) entity." While it is true that the IEEE registered extended (124-bit, NAA=6) format may be used, my semi-educated guess is that it will be the exception rather than the rule. Normally, I would expect this to be the Node_Name or the Port_Name of the element in question, and at least on the FC wire, they are all the 8 byte variety. The way the description above reads, it sounds like it must be the NAA=6 format. 4) FcNameId Vs. FcGlobalId. I'm confused as to why we have both. They both must be in one of the FC-PH/PH3 formats. The only difference is that FcGlobalId allows NAA=6 and FcNameId doesn't. Their usage is also inconsistent. fcConnUnitPortWwn is a FcGlobalId, but fcConnUnitSnsPortName is a FcNameId, and even worse fcConnUnitLinkPortWwnX is an OCTET STRING (SIZE(16)). I have not thought this through, but my initial thought would be to change all references to what should be a WWN to FcGlobaldId. 5) fcConnUnitLinkTable header comment. There is what I assume to be a search-and-replace-o. The second to last paragraph begins "This table is MAX-ACCESSed either". 6) fcConnUnitLinkTable header comment. The last paragraph is as follows: "For an entry to be considered to be valid, both the X (local) and the Y (remote) need to have one valid value." I would just remove this paragraph. It contradicts the last sentence in the third paragraph stating "the information MUST include either a nonzero connUnitNodeId- or a nonzero connUnitPortWwn- for each end of the link." Personally, I prefer the less restrictive one, but it's not worth the discussion. 7) The link table again. I can't remember the reason why we named what FC calls the Node_Name for the X side fcConnUnitLinkNodeIdX instead of fcConnUnitLinkNodeWWNX or fcConnUnitLinkNodeNameX. I think it was done this way because we wanted to reference this field back to a connunitid. My preference would be to force this to be a WWN, and not make it a connunitid. A management app can't tell from looking at a connunitid whether it's a WWN or not, so it must go back to the connunit table and read the fcConnUnitGlobalId. It would be nice if a single link table row was "self describing" about that like, and not require information from other parts of the MIB. 8) fcConnUnitLinkNodeIdX/Y again. The MIB says it's OCTET STRING (SIZE(64)). There's that 64 bytes again. It won't go away. Someone really wants this sucker to be 64 bytes long. Per my previous comment 4) and 8), I think it should be a FcGlobalId which must be an 8 or 16 byte WWN. 9) fcConnUnitLinkAgentAddressTypeY. It would be nice to explicitly specify what to put in here if fcConnUnitLinkAgentAddressY is unknown. >From a MIB implemeneters point of view, it was hard to figure out what to put here when there was no agent address. Not that it really makes any difference. I bring this up because the obvious unknown value is 0, but that's listed as "Reserved" as an IANA address family number. If we changed this to an integer, we could use -1. 10) fcConnUnitLinkAgentMask. I don't understand what this is. Please help. 11) fcConnUnitLinkAgentPortY. Same issue as fcConnUnitLinkAgentAddressTypeY. What do you put in here when fcConnUnitLinkAgentAddressY is unknown? 12) Port Statistics table. All of the counters are Counter64, yet in the table comment header it says to set the most significant bit to 1 if the counter is not supported. I do not know this for sure, but I don't think that is a valid use of Counter64. Does anyone know? If not, we might want to put it back to an 8-byte octet string. 13) SNS Table. I'm confused as to why fcConnUnitSnsMaxRows is down under fcMgmtConfig, but fcConnUnitSnsTable is up a level under fcMgmtObjects. 14) fcConnUnitSnsPortIdentifier. What is it used for and how is it different than fcConnUnitSnsPortName? 15) fcConnUnitSnsNodeIPAddress and fcConnUnitSnsPortIPAddress. What are these the IP address of? Is it for management of that node or port, or is for operational use? 16) fcConnUnitSnsPortType. It's currently shows as a single byte octet. I'm not sure that it's big enough, and the description doesn't say how it's encoded. 17) fcConnUnitSnsHardAddress. It's defined as an FcGlobalId, but the description says that it's a hard ALPA. I'm not sure what that means. 18) The top of the MIB tree is currently mib-2.8888. Is that where it's really going to go? 19) I noticed that there was no version information in the MIB. Why was that removed? Again, sorry for the length. If anyone would rather discuss any of these items with me vocally rather than e-mail, please feel free to call. Lee Darrow Vixel Corporation 425-806-4516