[imss] FC-SP MIB - consensus check

Black_David@emc.com Mon, 07 January 2008 16:18 UTC

Return-path: <imss-bounces@ietf.org>
Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBugU-0007SV-IK; Mon, 07 Jan 2008 11:18:42 -0500
Received: from imss by megatron.ietf.org with local (Exim 4.43) id 1JBugT-0007Kb-Sf for imss-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 11:18:41 -0500
Received: from [] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBugT-0007FD-Ck for imss@ietf.org; Mon, 07 Jan 2008 11:18:41 -0500
Received: from mexforward.lss.emc.com ([]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBugS-0000PV-Tc for imss@ietf.org; Mon, 07 Jan 2008 11:18:41 -0500
Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com []) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m07GIeoR001010 for <imss@ietf.org>; Mon, 7 Jan 2008 11:18:40 -0500 (EST)
Received: from mailhub.lss.emc.com (uraeus.lss.emc.com []) by hop04-l1d11-si01.isus.emc.com (Tablus Interceptor) for <imss@ietf.org>; Mon, 7 Jan 2008 11:18:40 -0500
Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com []) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m07GIRGV027810 for <imss@ietf.org>; Mon, 7 Jan 2008 11:18:39 -0500 (EST)
From: Black_David@emc.com
Received: from CORPUSMX20A.corp.emc.com ([]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jan 2008 11:18:38 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 7 Jan 2008 11:18:38 -0500
Message-ID: <8CC6CEAB44F131478D3A7B429ECACD91085E7E@CORPUSMX20A.corp.emc.com>
Thread-Topic: FC-SP MIB - consensus check
thread-index: AchRSPWe1ji+CuHbTyiyhQe5WwUwYA==
To: <imss@ietf.org>
X-OriginalArrivalTime: 07 Jan 2008 16:18:38.0739 (UTC) FILETIME=[F609C630:01C85148]
X-PMX-Version:, Antispam-Engine:, Antispam-Data: 2007.8.30.51425
X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0'
X-Tablus-Inspected: yes
X-Tablus-Classifications: public
X-Tablus-Action: allow
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
Cc: Black_David@emc.com
Subject: [imss] FC-SP MIB - consensus check
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

The MIB Doctor review (many thanks to Bert for his usual
detailed level of review) has turned up a few issues that
need to be rechecked with the imss WG.

The current draft is draft-ietf-imss-fc-fcsp-mib-00.txt:


In addition to the decision we've already made to delete
the CERTS-MIB module, here are the three issues on which
comments are requested:

1) In the SA-MIB:

> the intent of omitting the FabricIndex from
> the INDEX clause of t11FcSpSaTSelPropTable (and t11FcSpSaTransTable)
> was so that the same list of Traffic Selectors (or transforms) could
> proposed for multiple SA's even when the SA's are on different
> which seemed like it would be useful in some situations.  However, the
> need to have a StorageType which is common for the lists and for the
> proposals, introduces an (always present) complication which I think
> outweighs the potential (and at most occasional) benefit.  That is, I
> longer believe the omission is worthwhile.  If the WG agrees, I
> to change the rows in t11FcSpSaTSelPropTable and t11FcSpSaTransTable
> be per-Fabric, i.e., to add t11FcSpSaIfFabricIndex into the INDEX
> clause of the t11FcSpSaTSelPropTable and of the t11FcSpSaTransTable.
> (Indeed, the DESCRIPTION of t11FcSpSaIfStorageType is already worded
> assume this change will be made.)

2) In the POLICY-MIB:

> The second is that t11FcSpPoAdminFabricNameis read-only, as indeed it
> must be because it's part of the Active Policy which cannot be
> once it's active.  So, how is the Fabric name specified when Policy is
> in use ??  I believe the answer is that t11FcSpPoNaSummaryFabricName
> needs to be added as a read-create object in the
> If the WG agrees, then I will add this new object.

3) Counter behavior:

I want to recheck this:

> sysUpTime gets reset to zero in any MIB view which
> includes this MIB whenever this Counter32 has a discontinuity.

The MIBs have always been specified with this behavior - if
something happens that causes the implementation to lose track
of the counter values (think hard reset of some form), sysUpTime
is reset to zero.  Note that Counter32 is essentially a counter
modulo 2^32, hence the rollover from 2^32-1 to 0 is not a
discontinuity, and SNMP managers are already expecting to sample
counter variables often enough to not get confused by this
sort of rollover.

If anyone has objections to these approaches, please post them
to the list by next Monday, January 14th.  Absence of objection
will be taken as an indication of WG agreement with these

David L. Black, Distinguished Engineer
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