[imss] Re: AD review of: draft-ietf-imss-fc-fspf-mib-01.txt

Keith McCloghrie <kzm@cisco.com> Tue, 07 March 2006 15:43 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGeLH-00015C-9B; Tue, 07 Mar 2006 10:43:19 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGeLF-00011R-TI for imss@ietf.org; Tue, 07 Mar 2006 10:43:17 -0500
Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGeLF-00078y-Kb for imss@ietf.org; Tue, 07 Mar 2006 10:43:17 -0500
Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 07 Mar 2006 07:43:17 -0800
X-IronPort-AV: i="4.02,172,1139212800"; d="scan'208"; a="1782629364:sNHT35006012"
Received: from cisco.com (cypher.cisco.com [171.69.11.142]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k27FhGYg017750; Tue, 7 Mar 2006 07:43:16 -0800 (PST)
Received: (from kzm@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id HAA21489; Tue, 7 Mar 2006 07:43:15 -0800 (PST)
From: Keith McCloghrie <kzm@cisco.com>
Message-Id: <200603071543.HAA21489@cisco.com>
To: kzm@cisco.com
Date: Tue, 07 Mar 2006 07:43:15 -0800
In-Reply-To: <no.id> from "Keith McCloghrie" at Mar 07, 2006 07:23:40 AM
X-Mailer: ELM [version 2.5 PL5]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Cc: silvano@ip6.com, cds@cisco.com, imss@ietf.org, kzm@cisco.com, dromasca@avaya.com, bwijnen@lucent.com, Black_David@emc.com, vgaonkar@cisco.com
Subject: [imss] Re: AD review of: draft-ietf-imss-fc-fspf-mib-01.txt
X-BeenThere: imss@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet and Management Support for Storage Working Group <imss.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/imss>, <mailto:imss-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:imss@ietf.org>
List-Help: <mailto:imss-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/imss>, <mailto:imss-request@ietf.org?subject=subscribe>
Errors-To: imss-bounces@ietf.org

> > looks good. I would be OK with doing IETF Last Call and consider these
> > comments as initial IETF Last Call comments. At the other hand, IETF
> > LC right before/during an IETF will not get many people to pay
> > attention to this. Maybe you rather do a new rev first?
>  
> I'll do a new rev first, but it won't now get posted until after the IETF.

In starting to do the edits, I have found one other thing which it
might be appropriate to change at this time.

The present MIB, draft-ietf-imss-fc-fspf-mib-01.txt, defines the
object:

  t11FspfARegionNum OBJECT-TYPE
      SYNTAX      T11FspfARegionNum
      MAX-ACCESS  read-write
      STATUS      current
      DESCRIPTION
             "The AR number of this switch in this Fabric."
      REFERENCE  "Fibre Channel - Switch Fabric - 4 (FC-SW-4), Rev 7.5,
                 May 2005, section D.3.1."
      DEFVAL     {0}
      ::= { t11FspfEntry 2 }

I was starting to update the REFERENCE clauses to refer to the latest
rev of FC-SW-4, but in doing so I find that Annex/section D.3.1 is
missing.  In fact, the whole of what was Annex D has been removed from
the latest revision (rev 7.7 of December 2005).  I knew that T11 was
deprecating the concept of an "FSPF-Backbone" which was defined as:

    The FSPF-Backbone Fabric consists of multiple Autonomous Regions
    (AR) that are interconnected by a backbone network.

What I didn't realise was that it would disappear from the FC-SW-4
specification so soon.

Without that Annex, the definition of t11FspfARegionNum no longer
makes any sense.

So, the question is:

- should the T11-FC-FSPF-MIB retain the definition of t11FspfARegionNum,
  and do so by referring to an out-of-date T11 specification, or,

- should the definition of t11FspfARegionNum be removed from the
  T11-FC-FSPF-MIB at this time ??

(Note that the edits that would be needed to remove it are obvious and
straight-forward, e.g., the T11FspfARegionNum TC which is only used by
t11FspfARegionNum would be deleted; t11FspfARegionNum would deleted
from both the MODULE-COMPLIANCE clause and from the t11FspfGeneralGroup
group.)

Keith.

_______________________________________________
imss mailing list
imss@ietf.org
https://www1.ietf.org/mailman/listinfo/imss