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

[[e-mail]]

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

> -----Original Message-----
> From: Black, David 
> Sent: Monday, January 07, 2008 11:19 AM
> To: [e-mail]
> 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
> [phone]             FAX: [phone]
> [e-mail]        Mobile: [phone]
> ----------------------------------------------------
> 


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