[Ips] MIB Doctor review: draft-ietf-ips-fcip-mib-08.txt (fwd)

[Keith McCloghrie <[e-mail]>]

Bert,

You mention several nits which can be fixed by minor edits.  You also
point out this issue:

> > - Table fcipLinkErrorsTable contains a lot of Counter32 columns.
> >   Each of the DESCRIPTION clauses is supposed to describe if there
> >   can be discontinuity situations, and if so, which timer is to
> >   be used to detect that.
>
> I know Keith has some disagreement with me, but I prefer that
> it is made clear to the readers/implementors as to do/expect.
> At least I'd like to see in the Table or Entry DESCRIPTION clause
> that all counters have "xxx as discontinuity indicator"

In reviewing the issue for this particular MIB, I do agree with you
because the Counter32's are in a table INDEX-ed by fcipLinkIndex, and
the values of fcipLinkIndex are controlled by fcipLinkStatus which has
a syntax of RowStatus.  Thus, there is a potential for the re-use of a
previously-used value of fcipLinkIndex to apply to a different link.
So, these counters definitely need a discontinuity timestamp. 
I suggest a xxxCreateTime object needs be added in the fcipLinkTable,
e.g.,:

    fcipLinkCreateTime OBJECT-TYPE
        SYNTAX      TimeStamp
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
               "The value of sysUpTime when this entry was last created."
        ::= { fcipLinkEntry 12 }

so that each of the DESCRIPTIONs for the Counter32's in the
fcipLinkErrorsTable can include this sentence:

           The last discontinuity of this counter is indicated by
           fcipLinkCreateTime.

(and TimeStamp will need to be IMPORTed from SNMPv2-TC.)

My apologies to Anil & Ravi that I didn't catch this earlier.
Also, while the document is being updated, can I suggest that the Authors'
Addresses section be checked to ensure it has correct email addresses.

Keith.
-------------
Forwarded message:
> From: "Wijnen, Bert (Bert)" <[e-mail]>
> Date: Mon, 17 Oct 2005 04:01:38 +0200
> To: "'[e-mail]'" <[e-mail]>
> Cc: "'Ipswg \(E-mail\)'" <[e-mail]>
> Subject: [Ips] MIB Doctor review: draft-ietf-ips-fcip-mib-08.txt
> Message-ID: <[e-mail]>
> 
> OK, I have re-checked the new revision (08) of this document.
> 
> Here are my findings:
> 
> When you revise a MIB module, then both the LAST-UPDATED
> and REVISION clauses must be kept in sync.
> 
>   C:\bwijnen\smicng\work>smicng fcip.inc
>   W: f(fcip.mi2), (39,21) The first revision should match the
>      last update for MODULE-IDENTITY fcipMIB
> 
> 
> There still seem to be citation/reference issues:
> 
>   !! Missing citation for Normative reference:
>   P029 L052: [FC-SW-3]   Fibre Channel Switch Fabric -3 (FC-SW-3), T11/03-018v4,
> 
> I see it is used in a REFERENCE clause in the MIB
> See below at problem with RFC2571
> 
>   !! Missing citation for Normative reference:
>   P030 L030: [RFC2474]   Nichols, K., Blake, S., Baker, F., and D. Black, "Definition
> 
>   !! Missing citation for Normative reference:
>   P030 L018: [RFC2571]   Harrington, D., Presuhn, R., and B. Wijnen, "An
> 
> RFC2571 has been obsoleted by the way by RFC3411.
> I think you IMPORT from RFC3411
> Further your IMPORT from RFC4001, which causes a normative reference
> that I am missing.
> 
> Normally you add some text just before the MIB module starts aka
> 
>   The following MIB modules has IMPORTS from [RFC3411] and [RFC4001]
>   and refers  to [FC-SW-3] in REFERENCE clauses.
> 
> 
> Below is my revision 7 review, and I am commenting on the ones that
> have (as far as I can tell) not been addressed yet:
> 
> Following has not been addressed.
> > - Table fcipLinkErrorsTable contains a lot of Counter32 columns. 
> >   Each of the DESCRIPTION clauses is supposed to describe if there
> >   can be discontinuity situations, and if so, which timer is to
> >   be used to detect that.
> > 
> I know Keith has some disagreement with me, but I prefer that
> it is made clear to the readers/implementors as to do/expect.
> At least I'd like to see in the Table or Entry DESCRIPTION clause
> that all counters have "xxx as discontinuity indicator"
> 
> > - I think the Security COnsiderations section is weak.
> >   It lists sensitive objects, but it does not describe much about
> >   why they are sensitive and what kind of damage can happen if 
> >   improperly changed.
> >   The security guidelines on www.ops.ietf.org  explains how it
> >   should be done in an acceptable manenr
> > 
> 
> I don't think I see any change to the security considerations.
> Oh well... we'll see what security ADs will have to day about it.
> 
> Bert
> 
> _______________________________________________
> Ips mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ips
> 

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