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

From: Keith McCloghrie <[email-masked]>
Date: Mon, 17 Oct 2005 08:30:18 -0700 (PDT)

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)" <[email-masked]>
> Date: Mon, 17 Oct 2005 04:01:38 +0200
> To: "[email-masked]'" <[email-masked]>
> Cc: "'Ipswg \(E-mail\)'" <[email-masked]>
> Subject: [Ips] MIB Doctor review: draft-ietf-ips-fcip-mib-08.txt
> Message-ID: <[email-masked]>
> 
> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ips
> 

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

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 18 Oct 2005 15:42:52 +0200

OK, so it sounds Allison can mark this doc as "REvised ID needed"

I think I now used the correct email address for ravi

Bert

> -----Original Message-----
> From: Keith McCloghrie [mailto:[email-masked]]
> Sent: Monday, October 17, 2005 11:30
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: [Ips] MIB Doctor review: draft-ietf-ips-fcip-mib-08.txt (fwd)
> 
> 
> Bert,
> 
> > Message-ID: 
> <[email-masked]
> cent.com>
> >