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

I have done a MIB-Doctor review of this draft.

Below are my comments. Some are serious, some are
mor nits/admin-related. But it would be good to address
them and to spin a new rev. Pls do so quickly.
Since my last review (rev 5, early Nov 2004) 5 months 
have gone by.

Pls consider the MIB Review Guidelines as per (now approved as BCP)

  http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-04.txt

See also guidelines for security considerations at

  http://www.ops.ietf.org/mib-security.html

The revision 7 does compile clean. But...
some of it is just minor admin things, but quite a few are serious.

- Top of page 4
     Each FCIP Entity managed by this MIB is referred to as a FCIP
     Instance. The MIB is broken up as follows:
  I would change both "MIB" occurences into "MIB module".

- Section 4 should probably have a statement that it be removed
  by the RFC-Editor before publication as RFC.

- This statement
        ::= { mib-2 8889 } -- TO BE ASSIGNED by IANA
  is NOT ALLOWED. One must do a 
        ::= { mib-2 nnn } -- nnnn TO BE ASSIGNED by IANA

- The MODULE DESCRIPTION clause states:
    DESCRIPTION "The module defines management information specific to
                 FCIP devices."
  So it is missing the mandatory COPYRIGHT statement. It should read:
    DESCRIPTION "The module defines management information specific to
                 FCIP devices.

                 Copyright (C) The Internet Society (2005).  This
                 version of this MIB module is part of RFC xxxx; see
                 the RFC itself for  full legal notices."

- The REVISION description says:
    DESCRIPTION
            "Initial version of the FCIP MIB module."
   It would be much better to say:
    DESCRIPTION
            "Initial version of the FCIP MIB module, published
             as RFC xxxx."

- The two Textual Conventions are named: FcDomainId and FcEntityMode.
  I would prefer them to be named fcipDomainId and FcipEntityMode
  so that we have a more consistent naming convention within the
  MIB module itself and less risk for future name clashes in other
  MIB modules.  I can see it is kind of consistent with the FcXxx
  TCs they import from FC-MGMT-MIB, but that fact also explains
  why there is a potential risk for future name clashes. Oh well,
  I guess this is what they have chosen. So...

- In the FcDomainId TC they talk about FC entity while they talk 
  about FCIP entity in FcEntityMode TC. Is that intentional
  or just inconsistent?

- I see (in
   FcDomainIdOrZero ::= TEXTUAL-CONVENTION
    STATUS current
    DESCRIPTION
            "The Domain Id (of a FC swit
            has been assigned."
    SYNTAX  Integer32 (0..239)

  While the FcDomainId in this MIB document is:
    SYNTAX    OCTET STRING (SIZE(1))
  That is pretty inconsistent between the two MIB modules.
  This sort of proves my previous point about inconsistencies
  and/or name clashes right away.

- In the DESCRIPTION clause of the read-write object fcipDynIpConfType
  I would like to see a statement about expected persistency behaviour. 
  In other words, what happens on a restart?

- On page 10 I see:
    REFERENCE
      "IETF IPS Working Group - draft-ietf-ips-fcovertcpip-12.txt"
  That makes that internet-draft normative (I think). Just so you know.

- I see:
  fcipEntityId   OBJECT-TYPE
    SYNTAX OCTET STRING (SIZE(8))
    MAX-ACCESS not-accessible
    STATUS current
    DESCRIPTION
      "The FCIP entity identifier."
    REFERENCE
      "IETF IPS Working Group - draft-ietf-ips-fcovertcpip-12.txt"
    ::= { fcipEntityInstanceEntry 1 }
  I think it would be good to add a few words to the description clause
  to explain what the format of such an FCIP entity identifier look like.
  In fact, maybe it should be a Textual Convention too.

- fcipEntityAddress
  The decription clasue should state that the format of this object is determined
  by the value of fcipEntityAddressType, as explained in the RFC4001 in the TC
  DESCRIPTION for the InetAddress TC.

  Same for fcipLinkLocalFcipEntityAddress and fcipLinkRemFcipEntityAddress
  maybe others?

- Description clause of fcipEntityStatus MUST describe which columns can
  or cannor be changed if the row in in active state.

  Same for fcipLinkStatus... maybe others

- I am finding various DESCRIPTION clauses pretty meager, for example
  fcipLinkCost. fcipLinkLocalFcipEntityMode 

- I find it strange that fcipEntityId is of  SYNTAX OCTET STRING (SIZE(8))
  while fcipLinkRemFcipEntityId as a SYNTAX Unsigned32

- I cannot find any details of the persistency behaviour for fcipLinkTable !!??

  same for fcipStaticRouteTable... and may be others?

  same for read-write column in fcipDiscoveryDomainTable

- 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 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 do not see a IANA COnsiderations section, which is mandatory,
  and specifically so because a MIB OID needs to be assigned.

- $ idnits draft-ietf-ips-fcip-mib-07.txt
  idnits 1.58

  draft-ietf-ips-fcip-mib-07.txt:

  Checking nits according to http://www.ietf.org/ID-Checklist.html :

  * The document seems to lack an IANA Considerations section.

- !! Bad reference -- !MISSING.]
  P031 L019: [RFC2012}   McCloghrie, K., "SNMPv2 MIB for the Transmission Control

  !! Missing Reference for citation: [RFC2012]
  P005 L019:    Objects relevant to TCP must be obtained from this group [RFC2012].

  That is cause by a accolade instead of a square bracket in the reference sect.

  Also... RFC2012 has now been obsolted by RFC4022. That is what happens if there
  are long periods between my comments and a ready for re-review.

- !! Missing Reference for citation: [FC-MGMT-MIB]
  P005 L036:    be a regular FC interface.  As stated in [FC-MGMT-MIB], a regular

  That reference is indeed missing. Or maybe it intends to point to this:

     [FCMGMT]    McCloghrie, K., "Fibre Channel Management MIB", 
                <draft-ietf-ips-fcmgmt-mib-04.txt>, February 2003.

  Then the citation should be changed to 'FCMGMT]
  And the cirrent revivion of the fcmgmt-mib is revision 6 as in the RFC-Ed queue.

- A NORMATIVE reference is needed for every document from which an IMPORT is done.
  So that means we are missing normative references (and citations somehwere in
  the text) to:

    INET-ADDRESS-MIB ... RFC4022

Oh well....

Bert

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips