Return-Path: X-Sieve: cmu-sieve 2.0 Return-Path: Received: from osgood.ece.cmu.edu (OSGOOD.ECE.CMU.EDU [128.2.129.25]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id h5Q5du403352 for ; Thu, 26 Jun 2003 01:39:56 -0400 (EDT) Received: by osgood.ece.cmu.edu (Postfix, from userid 953) id E43E59C; Thu, 26 Jun 2003 01:39:53 -0400 (EDT) Received: from sos.ece.cmu.edu (SOS.ECE.CMU.EDU [128.2.129.27]) by osgood.ece.cmu.edu (Postfix) with ESMTP id E743C6F; Thu, 26 Jun 2003 01:38:43 -0400 (EDT) Received: by sos.ece.cmu.edu (Postfix) id 5AB1F8A10; Thu, 26 Jun 2003 01:38:29 -0400 (EDT) Received: from hazard.ece.cmu.edu (HAZARD.ECE.CMU.EDU [128.2.129.24]) by sos.ece.cmu.edu (Postfix) with ESMTP id 46A6789F7 for ; Thu, 26 Jun 2003 01:38:29 -0400 (EDT) Received: by hazard.ece.cmu.edu (Postfix) id 4BF6099; Thu, 26 Jun 2003 01:38:28 -0400 (EDT) Received: by hazard.ece.cmu.edu (Postfix, from userid 953) id 78D1CC1; Thu, 26 Jun 2003 01:38:27 -0400 (EDT) Received: from sos.ece.cmu.edu (SOS.ECE.CMU.EDU [128.2.129.27]) by hazard.ece.cmu.edu (Postfix) with ESMTP id B476699 for ; Thu, 26 Jun 2003 01:35:23 -0400 (EDT) Received: by sos.ece.cmu.edu (Postfix, from userid 363) id D16788A10; Thu, 26 Jun 2003 01:35:01 -0400 (EDT) X-Original-To: ips@sos.ece.cmu.edu Received: from hazard.ece.cmu.edu (HAZARD.ECE.CMU.EDU [128.2.129.24]) by sos.ece.cmu.edu (Postfix) with ESMTP id A25EE89F7 for ; Thu, 26 Jun 2003 01:34:59 -0400 (EDT) Received: by hazard.ece.cmu.edu (Postfix) id E146970; Thu, 26 Jun 2003 01:34:58 -0400 (EDT) Delivered-To: ips@ece.cmu.edu Received: by hazard.ece.cmu.edu (Postfix, from userid 953) id B61BC91; Thu, 26 Jun 2003 01:34:58 -0400 (EDT) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by hazard.ece.cmu.edu (Postfix) with ESMTP id DF73D70 for ; Thu, 26 Jun 2003 01:34:39 -0400 (EDT) Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate-2.de.ibm.com (8.12.9/8.12.8) with ESMTP id h5Q5YcPO065734; Thu, 26 Jun 2003 07:34:38 +0200 Received: from d10ml001.telaviv.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h5Q5YaZh276136; Thu, 26 Jun 2003 07:34:37 +0200 In-Reply-To: <95C56F83F771C041B4EC26C4DAEEC94205148C@MC4EXCH03.mcdata.com> To: "Mike O'Donnell" Cc: "Bill Strahm" , ips@ece.cmu.edu Subject: RE: Additional FC MIBs proposed MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 From: "Julian Satran" Message-ID: Date: Thu, 26 Jun 2003 08:34:34 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 26/06/2003 08:34:36, Serialize complete at 26/06/2003 08:34:36 Content-Type: multipart/alternative; boundary="=_alternative 001E1633C2256D51_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk X-Spam-Status: No, hits=-25.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,HTML_10_20,IN_REP_TO, QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) This is a multipart message in MIME format. --=_alternative 001E1633C2256D51_= Content-Type: text/plain; charset="US-ASCII" It looks more and more like interesting parties want us (IETF) to rubber-stamp their flavor of FC management. I do not think that this particular WG is qualified to handle FC related MIBs. As I said several time we are the IP storage WG. And FC belongs to T11. Julo "Mike O'Donnell" 26/06/03 01:39 To "Bill Strahm" , Julian Satran/Haifa/IBM@IBMIL cc Subject RE: Additional FC MIBs proposed All, I have reviewed the proposal for the 9 MIB's suggested by the authors. I have no opinion on where the MIB definition should reside (IETF vs. T11) - which is the debate below. However, in both cases, my assumptions are that the underlying FC protocols needed to support the management MIB would have already been accepted (or be close to it) by the FC Switch vendor community at a minimum. That activity is chartered under T11 (for which I can assume there is no debate). My feedback follows: 1. The authors suggest standardizing a MIB as it relates to VSAN awareness. The author's are correct in stating that the "concept" has been introduced to 'T11'. However, there is considerable work and needed agreement by T11 membership that VSAN-like technology is a requirement for Fibre Channel (and hence any resulting interoperable ANSI Fibre Channel protocols). To date the only information that has been presented to T11 has been a power-point presentation. This is far from what is needed to insure an agreed upon interoperable solution for FC SAN's. As such, and until the underlying ANSI Standard FC protocols are defined and accepted for inclusion into an ANSI standard, I would recommend any such MIB definition would be very premature. 2. Ditto the proposed 'Fibre Element' which introduces TE_ports which are not defined in current ANSI standards. 3. Virtual Fabrics (see #1 above). 4. Domain Manager. To the extent it abides by definitions and protocols defined in FC-SW-3, I have no comments 5. FSPF. I am unclear what a 'region id' is as it relates to FSPF. Autonomous regions are defined in FC-SW-3 but widely acknowleged as woefully inadequate for practicial implementation. I would need to understand the authors' intent with respect to 'configuring' an FSPF attribute that is not defined in FC today before I could comment futher on this MIB. 6. Routing Information. To the extent it abides by definitions and protocols defined in FC-SW-2, I have no comments 7. Name Server. To the extent it abides by definitions and protocols defined in FC-SW-2, I have no comments 8. Registered State Change Notification. To the extent it abides by definitions and protocols defined in FC-SW-2, I have no comments 9. Zone Server. There is still considerable consternation in T11 with respect to alignment of zoning operations. Per the suggested MIB, the authors describes several items that are NOT defined in current approved FC-SW-2 or FC-GS-3 nor are they in any proposed standard.("operative status, administrative status...". I would need to understand the authors intent of the new status and how it aligns with current approved ansi standards before I could further comment. Regards, 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: Bill Strahm [mailto:bill@strahm.net] Sent: Wednesday, June 25, 2003 3:37 PM To: Julian Satran Cc: ips@ece.cmu.edu Subject: Re: Additional FC MIBs proposed Ok, I remember these coming into the IPS working group about two years ago. Unfortunately I am about 2 laptop from there, and have not archived mail for that period of time. I remember the history about like Keith does, looking at the MIBs and going these are a piece of junk, how did they get standardized... (then being told to implement them anyway, because they were "correct") Lets not fight over where they belong. Frankly most of the storage people in the IETF hang out here, so here is as good a place as any to get these corrected Bill On Wed, Jun 25, 2003 at 09:26:46PM +0300, Julian Satran wrote: > Keith, > > I do not recall the IPS working group having a FC MIB in it's charter, nor > having being asked to extend the charter to include it by a popular vote > or the IESG. > > I do not know how the MIB draft got to have the name draft-ietf-ips... > that implies a working group work item and I follow this group work from > its inception. > > David asked a question to which the answer was silence or NO. IPFC - or > the designated trustees of it's documents are the place to take this. > > Julo > > > > > > > > > Keith McCloghrie > Sent by: owner-ips@ece.cmu.edu > 25/06/03 20:14 > > To > pat_thaler@agilent.com > cc > Black_David@emc.com, ips@ece.cmu.edu > Subject > Re: Additional FC MIBs proposed > > > > > > > The issue with doing the MIBs in T11 is that T11 has, in the past, not > had the appropriate amount of MIB expertise. My understanding is that > T11 themselves acknowledged this by the submission of the "Fibre > Alliance MIB" as draft-ietf-ipfc-fcmgmt-int-mib. However, as and when > the IPFC WG had completed all other items in its charter, it had been > unable to reach consensus on that MIB. So, to allow the IPFC WG to > conclude, the unfinished work item was moved to the IP Storage WG. > After abortive attempts to get changes in draft-ietf-ipfc-fcmgmt-int-mib, > I created draft-ietf-ips-fcmgmt-mib as a MIB which: a) meets IETF's > standards, b) replaces both draft-ietf-ips-fcmgmt-mib and the overlapping > RFC 2837, and c) details the problems with those previous MIBs. > > Meanwhile, T11 has published on its website a copy of one version (I'm > not sure if it's the latest version) of draft-ietf-ips-fcmgmt-mib. > Since that MIB is widely implemented in the industry, I agreed that > such publication would be appropriate *if* T11's publication indicated > that the MIB is already being deprecated by the IETF's definition of > draft-ietf-ips-fcmgmt-mib. The last time I looked, T11 had failed to > do that; rather, T11 seem to have published draft-ietf-ips-fcmgmt-mib > as if it were the definitive standard for a Fibre Channel MIB. > (However, the MIB was still in its Internet-Draft format, and perhaps > T11 intended that as an indication that the MIB was just a draft, as > ephemeral as all Internet-Drafts are, by definition). These recent > actions of T11 suggest to me that they still do not have the > appropriate amount of MIB expertise. > > The bottom line is that a bad MIB was widely implemented in the industry, > and I believe that network management of Fibre Channel devices suffered > because of that. A better MIB for Fibre Channel has been defined in the > IP Storage WG, who have already discussed the definition of further FC > MIBs > (see http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09473.html), but > deferred them as future work. > > Keith. > > > > It doesn't appear that any of these MIBs are in scope for us. They > > don't deal with IP storage. They are all very specific to Fibre Channel > > and deal mostly with fabric issues. T11 would be more appropriate. > > > > Pat > > > > -----Original Message----- > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > Sent: Monday, June 23, 2003 6:55 AM > > To: ips@ece.cmu.edu > > Subject: Additional FC MIBs proposed > > > > > > Everyone, > > > > This Internet-Draft describes a number of MIBs that the authors > > would like the IPS WG to take up. The WG chairs are seeking > > input on the level interest in standardization and use of these > > MIBs, the appropriateness of working on them here (vs. T11) and > > prioritization (which ones to take up first, as all 9 in parallel > > is not likely). > > > > Send comments/opinions/etc. to the list or directly to Elizabeth > > (ElizabethRodriguez@ieee.org) and myself (black_david@emc.com). > > > > 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: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: Friday, June 20, 2003 2:28 PM > > Subject: I-D ACTION:draft-gai-fc-mibs-00.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : MIBs Standardization > for Fibre Channel > > Author(s) : S. Gai et al. > > Filename : draft-gai-fc-mibs-00.txt > > Pages : 9 > > Date : 2003-6-20 > > > > Fibre Channel (FC) is a high speed serial interface technology that > > supports several Upper Layer Protocols including Small Computer > > System Interface (SCSI) and IP. Fibre Channel is standardized by the > > INCITS T11 Technical Committee. Fibre Channel Standards include > > Framing and Signaling protocols [FC-FS], Generic Services protocols > > [FC-GS-3], Switch Fabric protocols [FC-SW-2], etc. > > The management of a Fibre Channel network requires to monitor and set > > many parameters related to these protocols and this may be > > accomplished defining a proper set of MIBs. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-gai-fc-mibs-00.txt > > > > To remove yourself from the IETF Announcement list, send a message to > > ietf-announce-request with the word unsubscribe in the body of the > message. > > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > > "anonymous" and a password of your e-mail address. After logging in, > type > > "cd internet-drafts" and then > > "get draft-gai-fc-mibs-00.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-gai-fc-mibs-00.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use > this > > feature, insert the command "ENCODING mime" before the > "FILE" > > command. To decode the response(s), you will need > "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant > mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been > split > > up into multiple messages), so check your local > documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > 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(s). You may not distribute or copy the confidential and privileged portion of this communication to another. 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) --=_alternative 001E1633C2256D51_= Content-Type: text/html; charset="US-ASCII"
It looks more and more like interesting parties want us (IETF) to rubber-stamp their flavor of FC management.
I do not think that this particular WG is qualified to handle FC related MIBs.
As I said several time we are the IP storage WG. And FC belongs to T11.

Julo


"Mike O'Donnell" <mike.o'donnell@mcdata.com>

26/06/03 01:39

To
"Bill Strahm" <bill@strahm.net>, Julian Satran/Haifa/IBM@IBMIL
cc
<ips@ece.cmu.edu>
Subject
RE: Additional FC MIBs proposed






All,

I have reviewed the proposal for the 9 MIB's suggested by the authors.   I have no opinion on where the MIB definition should reside (IETF vs. T11) - which is the debate below.

However, in both cases, my assumptions are that the underlying FC protocols needed to support the management MIB would have already been accepted (or be close to it) by the FC Switch vendor community at a minimum.  That activity is chartered under T11 (for which I can assume there is no debate).

My feedback follows:

1.  The authors suggest standardizing a MIB as it relates to VSAN awareness. The author's are correct in stating that the "concept" has been introduced to 'T11'.  However, there is considerable work and needed agreement by T11 membership that VSAN-like technology is a requirement for Fibre Channel (and hence any resulting interoperable ANSI Fibre Channel protocols).  To date the only information that has been presented to T11 has been a power-point presentation.  This is far from what is needed to insure an agreed upon interoperable solution for FC SAN's.  As such, and until the underlying ANSI Standard FC protocols are defined and accepted for inclusion into an ANSI standard, I would recommend any such MIB definition would be very premature.

2. Ditto the proposed 'Fibre Element' which introduces TE_ports which are not defined in current ANSI standards.

3. Virtual Fabrics  (see #1 above).

4. Domain Manager.  To the extent it abides by definitions and protocols defined in FC-SW-3, I have no comments

5. FSPF.  I am unclear what a 'region id' is as it relates to FSPF. Autonomous regions are defined in FC-SW-3 but widely acknowleged as woefully inadequate for practicial implementation.  I would need to understand the authors' intent with respect to 'configuring' an FSPF attribute that is not defined in FC today before I could comment futher on this MIB.

6. Routing Information. To the extent it abides by definitions and protocols defined in FC-SW-2, I have no comments

7. Name Server. To the extent it abides by definitions and protocols defined in FC-SW-2, I have no comments

8. Registered State Change Notification. To the extent it abides by definitions and protocols defined in FC-SW-2, I have no comments

9. Zone Server.  There is still considerable consternation in T11 with respect to alignment of zoning operations.  Per the suggested MIB, the authors describes several items that are NOT defined in current approved FC-SW-2 or FC-GS-3 nor are they in any proposed standard.("operative status, administrative status...".  I would need to understand the authors intent of the new status and how it aligns with current approved ansi standards before I could further comment.

Regards,

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: Bill Strahm [mailto:bill@strahm.net]
Sent: Wednesday, June 25, 2003 3:37 PM
To: Julian Satran
Cc: ips@ece.cmu.edu
Subject: Re: Additional FC MIBs proposed


Ok, I remember these coming into the IPS working group about two years ago.  
Unfortunately I am about 2 laptop from there, and have not archived mail for
that period of time.

I remember the history about like Keith does, looking at the MIBs and going
these are a piece of junk, how did they get standardized... (then being told
to implement them anyway, because they were "correct")

Lets not fight over where they belong.  Frankly most of the storage people
in the IETF hang out here, so here is as good a place as any to get these
corrected

Bill
On Wed, Jun 25, 2003 at 09:26:46PM +0300, Julian Satran wrote:
> Keith,
>
> I do not recall the IPS working group having a FC MIB in it's charter, nor
> having being asked to extend the charter to include it by a popular vote
> or the IESG.
>
> I do not know how the MIB draft got to have the name draft-ietf-ips...
> that implies a working group work item and I follow this group work from
> its inception.
>
> David asked a question to which the answer was silence or NO.  IPFC - or
> the designated trustees of it's documents are the place to take this.
>
> Julo
>
>
>
>
>
>
>
>
> Keith McCloghrie <kzm@cisco.com>
> Sent by: owner-ips@ece.cmu.edu
> 25/06/03 20:14
>
> To
> pat_thaler@agilent.com
> cc
> Black_David@emc.com, ips@ece.cmu.edu
> Subject
> Re: Additional FC MIBs proposed
>
>
>
>
>
>
> The issue with doing the MIBs in T11 is that T11 has, in the past, not
> had the appropriate amount of MIB expertise.  My understanding is that
> T11 themselves acknowledged this by the submission of the "Fibre
> Alliance MIB" as draft-ietf-ipfc-fcmgmt-int-mib.  However, as and when
> the IPFC WG had completed all other items in its charter, it had been
> unable to reach consensus on that MIB.  So, to allow the IPFC WG to
> conclude, the unfinished work item was moved to the IP Storage WG.
> After abortive attempts to get changes in draft-ietf-ipfc-fcmgmt-int-mib,
> I created draft-ietf-ips-fcmgmt-mib as a MIB which: a) meets IETF's
> standards, b) replaces both draft-ietf-ips-fcmgmt-mib and the overlapping
> RFC 2837, and c) details the problems with those previous MIBs.
>
> Meanwhile, T11 has published on its website a copy of one version (I'm
> not sure if it's the latest version) of draft-ietf-ips-fcmgmt-mib.
> Since that MIB is widely implemented in the industry, I agreed that
> such publication would be appropriate *if* T11's publication indicated
> that the MIB is already being deprecated by the IETF's definition of
> draft-ietf-ips-fcmgmt-mib.  The last time I looked, T11 had failed to
> do that; rather, T11 seem to have published draft-ietf-ips-fcmgmt-mib
> as if it were the definitive standard for a Fibre Channel MIB.
> (However, the MIB was still in its Internet-Draft format, and perhaps
> T11 intended that as an indication that the MIB was just a draft, as
> ephemeral as all Internet-Drafts are, by definition).  These recent
> actions of T11 suggest to me that they still do not have the
> appropriate amount of MIB expertise.
>
> The bottom line is that a bad MIB was widely implemented in the industry,
> and I believe that network management of Fibre Channel devices suffered
> because of that.  A better MIB for Fibre Channel has been defined in the
> IP Storage WG, who have already discussed the definition of further FC
> MIBs
> (see http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09473.html), but
> deferred them as future work.
>
> Keith.
>
>
> > It doesn't appear that any of these MIBs are in scope for us. They
> > don't deal with IP storage. They are all very specific to Fibre Channel
> > and deal mostly with fabric issues. T11 would be more appropriate.
> >
> > Pat
> >
> > -----Original Message-----
> > From: Black_David@emc.com [mailto:Black_David@emc.com]
> > Sent: Monday, June 23, 2003 6:55 AM
> > To: ips@ece.cmu.edu
> > Subject: Additional FC MIBs proposed
> >
> >
> > Everyone,
> >
> > This Internet-Draft describes a number of MIBs that the authors
> > would like the IPS WG to take up.  The WG chairs are seeking
> > input on the level interest in standardization and use of these
> > MIBs, the appropriateness of working on them here (vs. T11) and
> > prioritization (which ones to take up first, as all 9 in parallel
> > is not likely).
> >
> > Send comments/opinions/etc. to the list or directly to Elizabeth
> > (ElizabethRodriguez@ieee.org) and myself (black_david@emc.com).
> >
> > 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: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> > Sent: Friday, June 20, 2003 2:28 PM
> > Subject: I-D ACTION:draft-gai-fc-mibs-00.txt
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> >
> >
> >                Title                           : MIBs Standardization
> for Fibre Channel
> >                Author(s)               : S. Gai et al.
> >                Filename                : draft-gai-fc-mibs-00.txt
> >                Pages                           : 9
> >                Date                            : 2003-6-20
> >
> > Fibre Channel (FC) is a high speed serial interface technology that
> > supports several Upper Layer Protocols including Small Computer
> > System Interface (SCSI) and IP. Fibre Channel is standardized by the
> > INCITS T11 Technical Committee. Fibre Channel Standards include
> > Framing and Signaling protocols [FC-FS], Generic Services protocols
> > [FC-GS-3], Switch Fabric protocols [FC-SW-2], etc.
> > The management of a Fibre Channel network requires to monitor and set
> > many parameters related to these protocols and this may be
> > accomplished defining a proper set of MIBs.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-gai-fc-mibs-00.txt
> >
> > To remove yourself from the IETF Announcement list, send a message to
> > ietf-announce-request with the word unsubscribe in the body of the
> message.
> >
> > Internet-Drafts are also available by anonymous FTP. Login with the
> username
> > "anonymous" and a password of your e-mail address. After logging in,
> type
> > "cd internet-drafts" and then
> >                "get draft-gai-fc-mibs-00.txt".
> >
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> >
> > Internet-Drafts can also be obtained by e-mail.
> >
> > Send a message to:
> >                mailserv@ietf.org.
> > In the body type:
> >                "FILE /internet-drafts/draft-gai-fc-mibs-00.txt".
> >
> > NOTE:          The mail server at ietf.org can return the document in
> >                MIME-encoded form by using the "mpack" utility.  To use
> this
> >                feature, insert the command "ENCODING mime" before the
> "FILE"
> >                command.  To decode the response(s), you will need
> "munpack" or
> >                a MIME-compliant mail reader.  Different MIME-compliant
> mail readers
> >                exhibit different behavior, especially when dealing with
> >                "multipart" MIME messages (i.e. documents which have been
> split
> >                up into multiple messages), so check your local
> documentation on
> >                how to manipulate these messages.
> >
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> >
>

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(s).

You may not distribute or copy the confidential and privileged portion of this communication to another. 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)
--=_alternative 001E1633C2256D51_=--