Return-Path: <owner-ips-outgoing@ece.cmu.edu>
X-Sieve: cmu-sieve 2.0
Return-Path: <owner-ips-outgoing@ece.cmu.edu>
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 h5Q2CO425450
	for <ipsml@ece.cmu.edu>; Wed, 25 Jun 2003 22:12:24 -0400 (EDT)
Received: by osgood.ece.cmu.edu (Postfix, from userid 953)
	id E825FD5; Wed, 25 Jun 2003 22:12:21 -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 64BA1C5; Wed, 25 Jun 2003 22:11:49 -0400 (EDT)
Received: by sos.ece.cmu.edu (Postfix)
	id EE8568A0D; Wed, 25 Jun 2003 22:11:34 -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 DEAB08A06
	for <ips-outgoing@sos.ece.cmu.edu>; Wed, 25 Jun 2003 22:11:34 -0400 (EDT)
Received: by hazard.ece.cmu.edu (Postfix)
	id B410D91; Wed, 25 Jun 2003 22:11:34 -0400 (EDT)
Received: by hazard.ece.cmu.edu (Postfix, from userid 953)
	id 912AD8F; Wed, 25 Jun 2003 22:11:34 -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 125A393
	for <ips-outgoing@ece.cmu.edu>; Wed, 25 Jun 2003 22:11:27 -0400 (EDT)
Received: by sos.ece.cmu.edu (Postfix, from userid 363)
	id DCF6E8A0E; Wed, 25 Jun 2003 22:11:26 -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 35EC38A06
	for <ips@sos.ece.cmu.edu>; Wed, 25 Jun 2003 22:11:25 -0400 (EDT)
Received: by hazard.ece.cmu.edu (Postfix)
	id ABD338F; Wed, 25 Jun 2003 22:11:24 -0400 (EDT)
Delivered-To: ips@ece.cmu.edu
Received: by hazard.ece.cmu.edu (Postfix, from userid 953)
	id 7D4B993; Wed, 25 Jun 2003 22:11:24 -0400 (EDT)
Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72])
	by hazard.ece.cmu.edu (Postfix) with ESMTP id E9D968F
	for <ips@ece.cmu.edu>; Wed, 25 Jun 2003 22:11:16 -0400 (EDT)
Received: from cisco.com (171.71.177.238)
  by sj-iport-3.cisco.com with ESMTP; 25 Jun 2003 19:14:32 -0800
Received: from cisco.com (cypher.cisco.com [171.69.11.143])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h5Q2BEOs016282;
	Wed, 25 Jun 2003 19:11:14 -0700 (PDT)
Received: (from kzm@localhost)
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id TAA23023;
	Wed, 25 Jun 2003 19:11:14 -0700 (PDT)
From: Keith McCloghrie <kzm@cisco.com>
Message-Id: <200306260211.TAA23023@cisco.com>
Subject: Re: Additional FC MIBs proposed
To: roger.cummings@veritas.com (Roger Cummings)
Date: Wed, 25 Jun 2003 19:11:14 -0700 (PDT)
Cc: kzm@cisco.com ('Keith McCloghrie'), Black_David@emc.com, ips@ece.cmu.edu,
   pat_thaler@agilent.com, sgai@cisco.com ("'Silvano Gai (E-mail)'"),
   cds@andiamo.com ('cds@andiamo.com')
In-Reply-To: <41CB8E1D9E23D511B7610008C786059E05663BD7@lmoxch06.enterprise.veritas.com> from "Roger Cummings" at Jun 25, 2003 05:50:46 PM
X-Mailer: ELM [version 2.5 PL1]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
X-Spam-Status: No, hits=-13.0 required=5.0
	tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT
	version=2.50
X-Spam-Level: 
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)

Hi Roger,

Thanks for correcting the errors in my message.  I'm glad that the
Letter Ballot comment was effective.  I tried to check the status
before sending my message but was unable to access the PDF file at:

  ftp://ftp.t11.org/t11/member/fc/fa/02-134v4.pdf 

and that's why I worded my message with caveats like "the last time I
looked", and "T11 seem to have", etc.

I was especially pleased to read your last sentence (about not repeating
past mistakes).

Thanks,
Keith.
 
> Keith,
> 
> T11 has certainly traditionally not had a great amount of MIB expertise,
> although with the formation of T11.5 containing some organizations with
> expertise in this area, and the participation of some of us in efforts like
> the SCSI MIB along with some notable experts that's changing, albeit slowly.
> :-)) However that is OK because T11 has also never generated a MIB for Fibre
> Channel, as far as I'm aware. The draft-ietf-ipfc-fcmgmt-int-mib was neither
> submitted to the IETF by T11 (it was created in an independent industry
> group called the Fibre Alliance), nor was it developed in T11.
> 
> I'm frankly not sure what your reference to "publishing
> draft-ietf-ips-fcmgmt-mib
> as if it were the definitive standard for a Fibre Channel MIB" relates to.
> If this relates to the MIB-FA Technical Report that was recently published
> as INCITS TR-33:2003 then:
> 
> a) This is a Technical Report, NOT a standard, definitive or otherwise.
> 
> b) The TR contains three different revisions of the MIB, because all three
> are used and different.
> 
> c) The Scope section of this document states:
> 
> The MIBs specified in this technical report are widely implemented even
> though they do not meet IETF requirements. To address this issue a revised
> Fibre Channel Management MIB has been developed in the IETF. For new
> implementations, vendors should implement the revised IETF Fibre Channel
> Management MIB.
> 
> This wording was introduced in response to a comment submitted against the
> T11 Letter Ballot by Cisco. I'm both the T11.5 Chair and the T11 webmaster,
> and I'm certainly not aware of any  requests for wording in relation to this
> subject that weren't honored.
> 
> The T11 web site does not list any reference to draft-ietf-ips-fcmgmt-mib as
> a published standard. Quite to the contrary, the front page for Task Group
> T11.5 (http://www.t11.org/t11/stat.nsf/tg5) links to a page containing SNMP
> information on which the only MIBs referenced are the IETF Entity MIB, and
> the FC Management MIB I-D via the link on the IETF IP Storage WG page.
> 
> Keith, I completely agree that the current situation regarding the FA MIB is
> NOT good, and I'd like to see the new MIB adopted with all possible speed.
> Part of the reason that I agreed to come back into T11 and get involved in
> T11.5 was a realization that the many of the FC companies had not been
> closely integrated enough with the development of management interfaces and
> information definitions. That having been said, I'm under pressure from some
> quarters to focus T11.5's attention on newer and supposedly "more
> extensible" management schemes. I think that would be narrow-minded in the
> extreme, but discussions like this aren't exactly helping my cause!
> 
> I've already indicated to the IPS WG Co-Chairs that I'm neutral as to where
> further MIB work for FC gets done, and I'll personally participate wherever
> this happens. If the decision is that there is insufficient support in the
> IETF I'll solicit support for one or more new projects getting created in
> T11.5 to do this work, and I'll issue a call for people with expertise to
> participate as always. I still have the slides from your "Tips on MIB
> design" presentation that you gave to the IP Working Group on August 27,
> 2001 and I'd certainly solicit your making the same type of presentation in
> T11.5 and your active participation in the work there if at all possible.
> Regardless of where the work gets done, I think you'll find a number of
> people with very firm desires NOT to repeat what happened with the earlier
> Fibre Channel MIBs.
> 
> Regards,
> 
> 
> Roger Cummings
> 
> roger.cummings@veritas.com
> 
> 
> 
> 
> -----Original Message-----
> From: Keith McCloghrie [mailto:kzm@cisco.com]
> Sent: Wednesday, June 25, 2003 1:15 PM
> 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.
> > 
> 
