[MIB-DOCTORS] MIB Doctor review: SYNTAX checks: draft-ietf-ipsp-ikeaction-mib-02.txt

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

SMICng (tools) tell me:

  $ smicmfm IPSEC-IKEACTION-MIB.mi2
  E: f(IPSEC-IKEACTION-MIB.mi2), (41,21) Date/time is wrong length
  ** 1 error and 0 warnings in parsing

This is cause by:
   ipiaMIB MODULE-IDENTITY
       LAST-UPDATED "20060905'"    -- 05 September 2006

which should be something like:
   ipiaMIB MODULE-IDENTITY
       LAST-UPDATED "200609050000Z"    -- 05 September 2006

Once I fix that, I get

  $ smicng IPSEC-IKEACTION-MIB.inc
  W: f(IPSEC-IKEACTION-MIB.mi2), (82,21) REVISION value "20060905'"
     is not a valid extended UTC time
sane problem as LAST-UPDATED
  W: f(IPSEC-IKEACTION-MIB.mi2), (1331,22) Row "ipiaIkeProposalEntry"
     does not have a consistent indexing scheme - index item
     ipiaIkeActPropName from base row ipiaIkeActionProposalsEntry
     is not defined as an index item
  W: f(IPSEC-IKEACTION-MIB.mi2), (1787,38) Row "ipiaIkeIdentityEntry"
     does not have a consistent indexing scheme - index item
     ipiaIkeActIdentityType from base row ipiaIkeActionEntry is not
     defined as an index item
  W: f(IPSEC-IKEACTION-MIB.mi2), (2299,18) Row
"ipiaRevokedCertificateEntry"
     does not have a consistent indexing scheme - index items must
     be in same order as used in INDEX clause for "base row"
ipiaCredMngCRLEntry

I suggest that the authors/editors review the last 3 warnings and 
make sure that this is their intended INDEXing scheme, regardless of
the errors. And pls explain why you index this way. It does look
weird to me too.

SMILINT tells me:

  C:\smi\mibs\work>smilint -l6 -s -m ./IPSEC-IKEACTION-MIB
  ./IPSEC-IKEACTION-MIB:41: [2] {date-length} date specification
    `20060905'' has an illegal length
  ./IPSEC-IKEACTION-MIB:82: [2] {date-length} date specification
    `20060905'' has an illegal length
  ./IPSEC-IKEACTION-MIB:40: [4] {module-identity-registration} 
    warning: uncontrolled MODULE-IDENTITY registration


The first two are the same as what SMICng reported on the date spec for
LAST-UPDATED and REVISION clauses.

The last one warns that you are registering the MIB under a branch 
that is not well controlled. You are doing:

       ::= { spdActions 2 }

I see in IPSEC-SPD-MIB that you have defined
   spdActions                OBJECT IDENTIFIER
        ::= { spdMIB 4 }

And that in its IANA considerations (rev 7 ID) you state:
   8.  IANA Considerations

   Only two IANA considerations exist for this document.  The first is
   just the node number allocation of the IPSEC-SPD-MIB itself.

   The IPSEC-SPD-MIB also allows for extension action MIB's.  Although
   additional actions are not required to use it, the node spdActions is
   allocated as a subtree under which IANA can define any additional
   actions.  IANA would be responsible for allocating any values under
   this node.  The only restriction is that additional nodes appended to
   spdACtions should be in reference to IPSEC-SPD-MIB actions.

So you don't even seem to ask that a spec is published for allocation?
I am somewhat surprised by this (and probably should have seen this 
earlier). The spdActions ultimately are under mib-2 which is standards 
track space. Oh well.

In any event, you do state that IANA assigns new values. So in your 
IPSEC-IKEACTION-MIB I would have expected:

       ::= { spdActions nnn } -- to be assigned by IANA. We suggest to
                              -- assign the value 2.

More review comments later.
Bert

_______________________________________________
MIB-DOCTORS mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mib-doctors