[imss] AD review of: draft-ietf-imss-fc-fspf-mib-01.txt

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

Summary:

looks good. I would be OK with doing IETF Last Call and consider these
comments as initial IETF Last Call comments. At the other hand, IETF
LC right before/during an IETF will not get many people to pay
attention to this. Maybe you rather do a new rev first?

more serious questions/issues:

SMICng tells me:
  E: f(t11fcfspf.mi2), (915,54) Index item "t11FspfLinkIndex" must be
     defined with syntax that includes a range
  W: f(t11fcfspf.mi2), (1007,19) Variable "ifIndex" in notification
     "t11FspfNbrStateChangNotify" is an index for a table

The warning is OK/acceptable as far as I am concerned.
The Error would probably be best fixed.

SMILINT tells me:

C:\smi\mibs\work>smilint -m -s -l 6 ./T11-FC-FSPF-MIB
./T11-FC-FSPF-MIB:212: [5] {identifier-case-match} warning: identifier `t11FspfA
RegionNum' differs from `T11FspfARegionNum' only in case
./T11-FC-FSPF-MIB:61: [6] {previous-definition} info: previous definition of `T1
1FspfARegionNum'
./T11-FC-FSPF-MIB:824: [5] {identifier-case-match} warning: identifier `t11FspfL
srType' differs from `T11FspfLsrType' only in case
./T11-FC-FSPF-MIB:71: [6] {previous-definition} info: previous definition of `T1
1FspfLsrType'
./T11-FC-FSPF-MIB:964: [5] {identifier-case-match} warning: identifier `t11FspfL
inkType' differs from `T11FspfLinkType' only in case
./T11-FC-FSPF-MIB:89: [6] {previous-definition} info: previous definition of `T1
1FspfLinkType'
./T11-FC-FSPF-MIB:61: [5] {type-without-format} warning: type `T11FspfARegionNum
' has no format specification
./T11-FC-FSPF-MIB:71: [5] {type-without-format} warning: type `T11FspfLsrType' h
as no format specification
./T11-FC-FSPF-MIB:89: [5] {type-without-format} warning: type `T11FspfLinkType'
has no format specification
./T11-FC-FSPF-MIB:129: [5] {type-without-format} warning: type `T11FspfLastCreat
ionTime' has no format specification

The identifier-case-match are acceptable. They may confuse people though.

The type-without-format warnings are for your TCs.
You may want to add a SIPLAY-HINT


- sect 5 states:
   protocol.  (Note that there are no definitions in this MIB module of
   "managed actions" which can be invoked via SNMP.)
  So what does that mean for t11FspfSetToDefault, which to me seems to
  be an action that can be invoked via SNMP??
  Same for t11FspfIfSetToDefault

- redundant objects??
  I do not see what the difference is between the follow two
  (well, except SYNTAX). Is there any? If so, can that be made
  clear in the DESCRIPTION clauses? If not, can one be removed?

  t11FspfLsrs OBJECT-TYPE
    SYNTAX      Gauge32
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
           "The current number of entries for this Fabric in the
           t11FspfLsrTable."
    ::= { t11FspfEntry 19 }

  t11FspfLsrNumber  OBJECT-TYPE
    SYNTAX      Unsigned32 (0..2147483647)
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
           "The current number of rows for this fabric in the
           t11FspfLsrTable."
    ::= { t11FspfEntry 23 }

- t11FspfStorageType
  Which writeable objects must be writable for a 'permanent' row?

- Mmm. I find the way you delete a row in t11FspfIfRowStatus
  a bit strange/weird. But I guess I can live with it.
  Can you explain why you do it this way?

- t11FspfLinkIndex probably better specifies a range that excludes zero ??
  see also smicng error above.

admin/nits and just questions for clarity/explanation

- I see:
    t11FspfIfNbrPortIndex OBJECT-TYPE
        SYNTAX      Unsigned32 (1..4294967295)

    t11FspfLinkPortIndex OBJECT-TYPE
        SYNTAX      Unsigned32 (0..16777215)

    t11FspfLinkNbrPortIndex OBJECT-TYPE
        SYNTAX      Unsigned32 (0..16777215)

  Is it just me who wonders about the different ranges??
  Maybe I am missing something or misunderstanding.
    
- I wonder what a value of zero means for T11FspfLinkType
  If it can never exist, would it be better to make the range
  (1..255) ??

- I wonder if T11FspfLsrType and T11FspfLinkType would be better
  defined with a base type of INTEGER? In other words Enumerations?

- I wonder how new non-Vendor-Specific values for T11FspfLsrType 
  and T11FspfLinkType will be assigned/allocated?
  Probably by T11? Would not hurt to say something about that.

- I suspect that the RFCyyyy in t11FspfAdminStatus REFERENCE clause
  is (or should be) a different yyyy than the one in the
  MODULE-IDENTITY macro?

- In a number of places I would prefer to see "MIB module" instead
  of just "MIB". But I cam live with if if this is the doc does not
  need changing for anything else.

- Section 7 is redundant and contains same material as the back matter.

Bert

_______________________________________________
imss mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/imss