[imss] RE: FC-SP MIB - consensus check

Black_David@emc.com Fri, 18 January 2008 01:04 UTC

Return-path: <imss-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFffG-0004TQ-Nu; Thu, 17 Jan 2008 20:04:58 -0500
Received: from imss by megatron.ietf.org with local (Exim 4.43) id 1JFffF-0004RO-G9 for imss-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 20:04:57 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFffF-0004MU-43 for imss@ietf.org; Thu, 17 Jan 2008 20:04:57 -0500
Received: from mexforward.lss.emc.com ([128.222.32.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFffE-0002YU-DH for imss@ietf.org; Thu, 17 Jan 2008 20:04:56 -0500
Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m0I14tuD017587 for <imss@ietf.org>; Thu, 17 Jan 2008 20:04:55 -0500 (EST)
Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13]) by hop04-l1d11-si02.isus.emc.com (Tablus Interceptor) for <imss@ietf.org>; Thu, 17 Jan 2008 20:04:55 -0500
Received: from corpussmtp4.corp.emc.com (corpussmtp4.corp.emc.com [10.254.64.54]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m0I14XFH021099 for <imss@ietf.org>; Thu, 17 Jan 2008 20:04:53 -0500 (EST)
From: Black_David@emc.com
Received: from CORPUSMX20A.corp.emc.com ([128.221.62.11]) by corpussmtp4.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Jan 2008 20:04:34 -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: Thu, 17 Jan 2008 20:04:34 -0500
Message-ID: <8CC6CEAB44F131478D3A7B429ECACD91085F73@CORPUSMX20A.corp.emc.com>
In-Reply-To: <8CC6CEAB44F131478D3A7B429ECACD91085E7E@CORPUSMX20A.corp.emc.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: FC-SP MIB - consensus check
Thread-Index: AchRSPWe1ji+CuHbTyiyhQe5WwUwYAIJIkJQ
References: <8CC6CEAB44F131478D3A7B429ECACD91085E7E@CORPUSMX20A.corp.emc.com>
To: <imss@ietf.org>
X-OriginalArrivalTime: 18 Jan 2008 01:04:34.0324 (UTC) FILETIME=[16C36D40:01C8596E]
X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, 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: 0.0 (/)
X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5
Subject: [imss] RE: 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

Having seen no comment on this message in the week and a
half since it was posted, I believe that the approaches it
describes represent the rough consensus of the imss WG.

Hence, Keith should prepare and upload a revision of the
FC-SP MIB draft that is in accordance with these approaches
and contains the other changes identified from Bert's MIB
Doctor reviews.  That revision should be suitable to be sent
to our ADs with a request to publish as an RFC.

Thanks,
--David (imss WG chair)
----------------------------------------------------
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
----------------------------------------------------

> -----Original Message-----
> From: Black, David 
> Sent: Monday, January 07, 2008 11:19 AM
> To: imss@ietf.org
> Cc: Black, David
> Subject: FC-SP MIB - consensus check
> 
> 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:
> 
> http://www.ietf.org/internet-drafts/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
be
> > proposed for multiple SA's even when the SA's are on different
Fabrics,
> > 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
SA
> > proposals, introduces an (always present) complication which I think
> > outweighs the potential (and at most occasional) benefit. That is, I
no
> > longer believe the omission is worthwhile.  If the WG agrees, I
propose
> > to change the rows in t11FcSpSaTSelPropTable and t11FcSpSaTransTable
to
> > 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
to
> > 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
modified
> > 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
t11FcSpPoNaSummaryTable.
> > 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
> approaches.
> 
> Thanks,
> --David
> ----------------------------------------------------
> 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
imss@ietf.org
https://www1.ietf.org/mailman/listinfo/imss