[imss] FC-SP MIB - consensus check

[[e-mail]]

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
[phone]             FAX: [phone]
[e-mail]        Mobile: [phone]
----------------------------------------------------


_______________________________________________
imss mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/imss