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

["Wijnen, Bert (Bert)" <[e-mail]>]

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:[e-mail]]
> Sent: Monday, October 17, 2005 11:30
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: [Ips] MIB Doctor review: draft-ietf-ips-fcip-mib-08.txt (fwd)
> 
> 
> 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]
> cent.com>
> > 
> > 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