OSPF Version 2 Management Information Base
RFC 4750

Note: This ballot was opened for revision 11 and is now closed.

(Bill Fenner) Yes

(Jari Arkko) No Objection

(Ross Callon) No Objection

(Brian Carpenter) No Objection

(Lisa Dusseault) No Objection

(Lars Eggert) No Objection

Comment (2006-04-12 for -)
The "Original Authors" section on the first page is unusual and should probably go; the "Acknowledgements" section is the right place for this and credits the original authors already.

(Ted Hardie) No Objection

(Sam Hartman) No Objection

(Russ Housley) (was Discuss) No Objection

(Cullen Jennings) No Objection

(Jon Peterson) No Objection

(Dan Romascanu) (was Discuss) No Objection

Comment (2006-04-10)
COMMENT

Forwarding comment from Bert Wijnen.

I reviewed this one back in November as MIB Doctor.
My comments have been addressed and/or answered.

So basically I am basically happy with this one.

But I see:
   E: f(ospftrap.mi2), (518,22) Group "ospfTrapControlGroup" is 
   both a MANDATORY and conditional group for module "OSPF-TRAP-MIB"
I think it is OK, because of the 2 module compliance statements.

A few nits remain (RFC-Editor can fix):

!! Missing Reference for citation: [24]
  P086 L046:     explained in RFC 1224 [24]. The basic premise of the throttling

!! Missing citation for Informative reference:
  P101 L011:      [RFC1765] Moy, J., "OSPF Database Overflow", RFC 1765, March 1995.

!! Missing citation for Informative reference:
  P101 L013:      [RFC1793] Moy, J., "Extending OSPF to Support Demand Circuits",

!! Missing citation for Informative reference:
  P101 L019:      [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998.

!! Missing citation for Informative reference:
  P101 L021:      [RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370,

!! Missing citation for Normative reference:
  P100 L055:      [RFC2863] McCloghrie, K., Kastenholtz, F.,

!! Missing citation for Informative reference:
  P101 L024:      [RFC3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option",

Also (those are mine)

- idnits complains:
 - The document seems to use RFC 2119 keywords, but does not seem to
    contain the recommended RFC 2119 boilerplate

smilint complains of the following:

This is an automatically generated mail message in response to a mail message you (or someone else who used your address) sent to <smilint@ibr.cs.tu-bs.de>.
If you want to learn more about this mail service, send a mail message with the "Subject: help" to <smilint@ibr.cs.tu-bs.de>.

The program smilint 0.4.3, as of Fri Apr 07 09:10:01 2006 has been used to process your request as follows:

smilint -m -s -e -l 6 OSPF-MIB OSPF-TRAP-MIB

OSPF-MIB:667: [5] {index-element-accessible} warning: index element `ospfAreaId' of row `ospfAreaEntry' should be not-accessible in SMIv2 MIB
OSPF-MIB:921: [5] {index-element-accessible} warning: index element `ospfStubAreaId' of row `ospfStubAreaEntry' should be not-accessible in
SMIv2 MIB
OSPF-MIB:921: [5] {index-element-accessible} warning: index element `ospfStubTOS' of row `ospfStubAreaEntry' should be not-accessible in
SMIv2 MIB
OSPF-MIB:1026: [5] {index-element-accessible} warning: index element `ospfLsdbAreaId' of row `ospfLsdbEntry' should be not-accessible in
SMIv2 MIB
OSPF-MIB:1026: [5] {index-element-accessible} warning: index element `ospfLsdbType' of row `ospfLsdbEntry' should be not-accessible in SMIv2 MIB
OSPF-MIB:1026: [5] {index-element-accessible} warning: index element `ospfLsdbLsid' of row `ospfLsdbEntry' should be not-accessible in SMIv2 MIB
OSPF-MIB:1026: [5] {index-element-accessible} warning: index element `ospfLsdbRouterId' of row `ospfLsdbEntry' should be not-accessible in
SMIv2 MIB
OSPF-MIB:1200: [5] {index-element-accessible} warning: index element `ospfAreaRangeAreaId' of row `ospfAreaRangeEntry' should be not-accessible in SMIv2 MIB
OSPF-MIB:1200: [5] {index-element-accessible} warning: index element `ospfAreaRangeNet' of row `ospfAreaRangeEntry' should be not-accessible in SMIv2 MIB
OSPF-MIB:1308: [5] {index-element-accessible} warning: index element `ospfHostIpAddress' of row `ospfHostEntry' should be not-accessible in
SMIv2 MIB
OSPF-MIB:1308: [5] {index-element-accessible} warning: index element `ospfHostTOS' of row `ospfHostEntry' should be not-accessible in SMIv2 MIB
OSPF-MIB:1418: [5] {index-element-accessible} warning: index element `ospfIfIpAddress' of row `ospfIfEntry' should be not-accessible in SMIv2 MIB
OSPF-MIB:1418: [5] {index-element-accessible} warning: index element `ospfAddressLessIf' of row `ospfIfEntry' should be not-accessible in
SMIv2 MIB
OSPF-MIB:1852: [5] {index-element-accessible} warning: index element `ospfIfMetricIpAddress' of row `ospfIfMetricEntry' should be not-accessible in SMIv2 MIB
OSPF-MIB:1852: [5] {index-element-accessible} warning: index element `ospfIfMetricAddressLessIf' of row `ospfIfMetricEntry' should be not-accessible in SMIv2 MIB
OSPF-MIB:1852: [5] {index-element-accessible} warning: index element `ospfIfMetricTOS' of row `ospfIfMetricEntry' should be not-accessible in
SMIv2 MIB
OSPF-MIB:1956: [5] {index-element-accessible} warning: index element `ospfVirtIfAreaId' of row `ospfVirtIfEntry' should be not-accessible in
SMIv2 MIB
OSPF-MIB:1956: [5] {index-element-accessible} warning: index element `ospfVirtIfNeighbor' of row `ospfVirtIfEntry' should be not-accessible in SMIv2 MIB
OSPF-MIB:2197: [5] {index-element-accessible} warning: index element `ospfNbrIpAddr' of row `ospfNbrEntry' should be not-accessible in SMIv2 MIB
OSPF-MIB:2197: [5] {index-element-accessible} warning: index element `ospfNbrAddressLessIndex' of row `ospfNbrEntry' should be not-accessible in SMIv2 MIB
OSPF-MIB:2455: [5] {index-element-accessible} warning: index element `ospfVirtNbrArea' of row `ospfVirtNbrEntry' should be not-accessible in
SMIv2 MIB
OSPF-MIB:2455: [5] {index-element-accessible} warning: index element `ospfVirtNbrRtrId' of row `ospfVirtNbrEntry' should be not-accessible in
SMIv2 MIB
OSPF-MIB:2647: [5] {index-element-accessible} warning: index element `ospfExtLsdbType' of row `ospfExtLsdbEntry' should be not-accessible in
SMIv2 MIB
OSPF-MIB:2647: [5] {index-element-accessible} warning: index element `ospfExtLsdbLsid' of row `ospfExtLsdbEntry' should be not-accessible in
SMIv2 MIB
OSPF-MIB:2647: [5] {index-element-accessible} warning: index element `ospfExtLsdbRouterId' of row `ospfExtLsdbEntry' should be not-accessible in SMIv2 MIB
OSPF-MIB:2850: [5] {index-element-accessible} warning: index element `ospfAreaAggregateAreaID' of row `ospfAreaAggregateEntry' should be not-accessible in SMIv2 MIB
OSPF-MIB:2850: [5] {index-element-accessible} warning: index element `ospfAreaAggregateLsdbType' of row `ospfAreaAggregateEntry' should be not-accessible in SMIv2 MIB
OSPF-MIB:2850: [5] {index-element-accessible} warning: index element `ospfAreaAggregateNet' of row `ospfAreaAggregateEntry' should be not-accessible in SMIv2 MIB
OSPF-MIB:2850: [5] {index-element-accessible} warning: index element `ospfAreaAggregateMask' of row `ospfAreaAggregateEntry' should be not-accessible in SMIv2 MIB

I believe those are all because this is basically an update to the old RFC1850 MIB module, that was itself an update to RFC 1253 (which did not contain an SMIv2 MIB module.

Adding some ASN.1 comments or text in the DESCRIPTION clauses of the tables along the lines of those in (e.g.) RFC 3895 would be a Good Thing for the readable index objects.

In RFC 3895 the following commented text was added for each such index:

-- read-only since originally an
-- SMIv1 index




OSPF-TRAP-MIB:161: [5] {notification-not-reversible} warning:
notification `ospfVirtIfStateChange' is not reverse mappable
OSPF-TRAP-MIB:178: [5] {notification-not-reversible} warning:
notification `ospfNbrStateChange' is not reverse mappable
OSPF-TRAP-MIB:201: [5] {notification-not-reversible} warning:
notification `ospfVirtNbrStateChange' is not reverse mappable
OSPF-TRAP-MIB:217: [5] {notification-not-reversible} warning:
notification `ospfIfConfigError' is not reverse mappable
OSPF-TRAP-MIB:236: [5] {notification-not-reversible} warning:
notification `ospfVirtIfConfigError' is not reverse mappable
OSPF-TRAP-MIB:254: [5] {notification-not-reversible} warning:
notification `ospfIfAuthFailure' is not reverse mappable
OSPF-TRAP-MIB:273: [5] {notification-not-reversible} warning:
notification `ospfVirtIfAuthFailure' is not reverse mappable
OSPF-TRAP-MIB:290: [5] {notification-not-reversible} warning:
notification `ospfIfRxBadPacket' is not reverse mappable
OSPF-TRAP-MIB:304: [5] {notification-not-reversible} warning:
notification `ospfVirtIfRxBadPacket' is not reverse mappable
OSPF-TRAP-MIB:317: [5] {notification-not-reversible} warning:
notification `ospfTxRetransmit' is not reverse mappable
OSPF-TRAP-MIB:337: [5] {notification-not-reversible} warning:
notification `ospfVirtIfTxRetransmit' is not reverse mappable
OSPF-TRAP-MIB:356: [5] {notification-not-reversible} warning:
notification `ospfOriginateLsa' is not reverse mappable
OSPF-TRAP-MIB:376: [5] {notification-not-reversible} warning:
notification `ospfMaxAgeLsa' is not reverse mappable
OSPF-TRAP-MIB:390: [5] {notification-not-reversible} warning:
notification `ospfLsdbOverflow' is not reverse mappable
OSPF-TRAP-MIB:401: [5] {notification-not-reversible} warning:
notification `ospfLsdbApproachingOverflow' is not reverse mappable
OSPF-TRAP-MIB:413: [5] {notification-not-reversible} warning:
notification `ospfIfStateChange' is not reverse mappable
OSPF-TRAP-MIB:430: [5] {notification-not-reversible} warning:
notification `ospfNssaTranslatorStatusChange' is not reverse mappable
OSPF-TRAP-MIB:445: [5] {notification-not-reversible} warning:
notification `ospfRestartStatusChange' is not reverse mappable
OSPF-TRAP-MIB:460: [5] {notification-not-reversible} warning:
notification `ospfNbrRestartHelperStatusChange' is not reverse mappable
OSPF-TRAP-MIB:478: [5] {notification-not-reversible} warning:
notification `ospfVirtNbrRestartHelperStatusChange' is not reverse mappable

One of the MIB Doctors commented the following wrt. those warning:

For the non-reverse-mappable notifications there is already Section 4.7, "Translating Notification Parameters".  While its contents are technically correct, I'm not entirely satisfied with it, because it fails to clearly state the consequences, namely that a trap originated from a V1 agent won't be converted into the same thing that a native V2 or V3 agent would emit.  A short paragraph at the end of the section spelling this out would be helpful IMHO.

There was a similar problem with the recent update to the BGP MIB but that case was different since the traps were originally defined in the SMIv1 version of the MIB module and were incorrectly translated into the initial SMIv2 version.  This was corrected in RFC 4273.  I don't think that would be appropriate here;  I think the choices would be to obsolete all the existing notification definitions and make new ones that comply with the translation rules, or else to leave the definitions alone and clearly note the limitations (which is what I suggested above).


Additional descriptions of some error/warning messages:

OSPF-TRAP-MIB:21: [4] {module-identity-registration} warning:
uncontrolled MODULE-IDENTITY registration


Warning:     module-identity-registration (level 4)
Message:     uncontrolled MODULE-IDENTITY registration
Description: The identities of IETF MIB modules should be registered below
             mib-2, transmission, or snmpModules so that the registration
             space can be controlled by IANA.

Is this a result of the backwards compatibility with the original version of the MIB. That's fine, but a note should be included acknowledging this, so that people who compile in the future understand what is the problem, and do not start asking questions. 

Same, I would include a note about the very 'traps-centric' language used in OSPF-TRAP-MIB which I guess also has some kind of historic context. 

Something on the lines: 'The original MIB modules that this document updates were written in SMIv1 for SNMPv1, and only traps were used. Since this version of the MIB module is written in SMIv2, it should be understood that all types of notifications (Trap and Inform PDUs) may be used by native SNMPv2 or SNMPv3 agents, although the original language and names that mentioned only traps were preserved for backwards compatibility reasons.'

(Mark Townsley) No Objection

(Magnus Westerlund) No Objection