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

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
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips