Joan, Thanks for the prompt and very thorough review. We will get to work addressing the comments.
Regards, -Dan > -----Original Message----- > From: Joan Cucchiara [mailto:[EMAIL PROTECTED] > Sent: Friday, March 07, 2008 2:38 AM > To: Romascanu, Dan (Dan); Acee Lindem; [email protected]; MIB > Doctors (E-mail) > Cc: Ronald Bonica; Abhay Roy; Ross Callon; Vishwas Manral; > Joyal, Daniel (BL60:SF23); Bert Wijnen; David Ward > Subject: MIB Dr. Review of draft-ietf-ospf-ospfv3-mib-12.txt > > > Hi Folks, > > First is the output from the MIB tools. > Followed by some General Comments, and then followed by > fairly specific comments/questions on the MIB. > > Thanks, > Joan > > > SMICNG results: > ---------------- > > E: f(OSPFV3-MIB.txt), (2523,21) Item "ospfv3AreaAggregateRouteTag" > in sequence "Ospfv3AreaAggregateEntry" has conflicting syntax > specified > > E: f(OSPFV3-MIB.txt), (756,31) Index item "ospfv3AsLsdbLsid" > must be defined with syntax that includes a range > > E: f(OSPFV3-MIB.txt), (904,31) Index item "ospfv3AreaLsdbLsid" > must be defined with syntax that includes a range > > E: f(OSPFV3-MIB.txt), (1066,31) Index item "ospfv3LinkLsdbLsid" > must be defined with syntax that includes a range > > E: f(OSPFV3-MIB.txt), (2647,31) Index item "ospfv3VirtLinkLsdbLsid" > must be defined with syntax that includes a range > > > smilint > ------------ > severity level requested 6 > > line severity problem > -------------------------- > > 2844 5 warning: `InetAddress' object should have an > accompanied preceding `InetAdressType' object > (Please see comments below wrt Notifications) > > > > ID NITS (== 1 warning) > -------- > > == The copyright year in the IETF Trust Copyright Line does > not match the > current year > > > > > General Comments > ----------------- > > 1) Need to have a read-only conformance. > > 2) I would like to understand the use of the single > DiscontinuityTime object for all the counters in the MIB. My > thoughts are that having a few more discontinuity objects > (specifically in tables) would be more beneficial, so please > give me some feedback on this, so I can understand why only > one Discontinuity object is used. > > 3) Throttling of notifications and Polling Event Counters. > I think more details of this need to be in the MIB itself. > Please expand some of these DESCRIPTIONS. > > 4) Please note that many of my comments apply to the entire > MIB, although I only commented on the first few objects. > Please be sure to check the entire MIB for an issue. For > example, please rename any RowStatus object with > xxxRowStatus, please spell out Interval, etc. > > 5) The MIB did not extract using mstrip (MIB tool). > If possible, could this be fixed? > > > Comments in Order of the document > ---------------------------------- > > 1) (NIT) Header should say: > Proposed Status: Standards Track > > > 2) (NIT) Expiration date has incorrect year. > > > *) (NIT) please be consistent with using RFCXXX vs. MIB tree > assignment, so for example > > DESCRIPTION > "The MIB module for OSPF version 3. > > Copyright (C) The IETF Trust (2007). > This version of this MIB module is part of > RFC XXXX; see the RFC itself for full legal > notices." > > REVISION "200709171200Z" > DESCRIPTION -- RFC Editor assigns RFC XXXX > "Initial version, published as RFC XXXX" > > ::= { mib-2 YYY } -- to be assigned by IANA > > > > > *)Ospfv3UpToRefreshIntervalTc > > *) Please change to use TC (in caps) so, Ospfv3UpToRefreshIntervalTC > > *) Could DISPLAY-HINT "d" be used instead? > > *) Should be Unsigned32 (see rfc4181.txt section 4.6.1.1.) > > *) Please add a reference > > *) Ospfv3DeadIntRangeTc > *) Please spell out Interval and change Tc to TC, > i.e. Ospfv3DeadIntervalRangeTC > > *) Could DISPLAY-HINT "d" be used instead? > > *) Should be Unsigned32 (see rfc4181.txt section 4.6.1.1.) > > *) Please add a reference > > *) Ospfv3RouterIdTC > > *) Please use TC, Ospfv3RouterIdTC > > *) Could DISPLAY-HINT "d" be used instead? > > *) Please add a reference > > *) Ospfv3AreaIdTc > > *) Please use TC, Ospfv3AreaIdTC > > *) Could DISPLAY-HINT "d" be used instead? > > > *) Please add a reference > > > *) Ospfv3IfInstIdTc > > *) Please Tc to TC, i.e. Ospfv3IfInstIdTC > > *) Could DISPLAY-HINT "d" be used instead? > > *) Should be Unsigned32 (see rfc4181.txt section 4.6.1.1.) > > *) Please add a reference > > > *) ospfv3RouterId > > Isn't this a 32-bit unsigned integer? > Please add REFERENCE clause. > > > *) ospfv3AreaBdrRtrStatus > > Please indicate the value of the flag > when the router is an area border router. > (i.e. when the value of this object is true(1)...) > > *) ospfv3AsScopeLsaCksumSum > > *) should be Unsigned32 > > > *) ospfv3DemandExtensions > > Same comment as with the previous object that has SYNTAX of > TruthValue, please specify, when this object has the value of > true(1), then the router supports demand circuits... > > *) ospfv3ReferenceBandwidth > > -Please add UNITS > -Please add DEFVAL > - Please add REFERENCE > > > *) ospfv3RestartSupport > > -Is there a value which could be considered a DEFVAL for this object? > (In general, please review all the read-write objects and add > DEFVALs if appropriate). > > *) ospfv3RestartInterval > -Is there a value which could be considered a DEFVAL for this object? > > > *) ospfv3RestartStrictLsaChecking > > Please indicate what true(1) means in the DESCRIPTION (Please > do this for all objects which contain a > TruthValue) > > *) ospfv3RestartExitRc > > What does the Rc stand for, could this be spelled out? > > Are any additional objects needed to tell when the value of > this object changed? > > *) ospfv3NotificationEnable > > Why is this object needed? Or,in other words, why can't > RFC3413 be used. > > *) ospfv3StubRouterAdvertisement > > Need to add DEFVAL > Please add a REFERENCE > > *) ospfv3AreaTable > > - This table has a combination of both objects to configure > areas and statistics for areas. Could this be devided into > 2 tables one for configuring and one for status/statics? > > Additionally, if is not clear to me what happens when an > attached area is established and then the configuration > changes? Can the configurable objects be changed? > > Also, the counters in this table refer to > ospfv3DiscontinuityTime but if the OSPFv3 routing process > starts-up, then my understanding is that these counters might > be affected (specifically, ospfv3AreaNssTranslatorEvents), so > I think another discontinuityTime object is needed...please comment. > > > *) ospfv3AreaId > > Isn't this unsigned? > > > *) ospfv3AreaBdrRtrCount and other Gauge32 objects in this > table may have a DEFVAL clause of zero (this is mentioned in > the DESCRIPTION clauses). > > *) ospfv3AreaScopeLsaCksumSum > > Should this be Unsigned32? > > > *) ospfv3AreaStatus > > Please rename to ospfv3AreaRowStatus > > *) ospfv3AreaStubMetric > > Is there a DEFVAL for this object? > > > *) ospfv3AreaNssaTranslatorStabInt > > Please use entire word Interval > > > > *) ospfv3AsLsdbSequence > > Should this have a range? > > *) ospfv3AreaLsdbSequence > > (same question, is there a range for this?) > > *) ospfv3AreaLsdbAge > > Unsigned32 and a range? > > What is the value if the DoNotAge Bit is set? > > *) ospfv3AreaLsdbChecksum > > Should this be unsigned32? > > > *) ospfv3AreaLsdbTypeKnown > > Please indicate what true(1) means in the > DESCRIPTION > > *) ospfv3LinkLsdbSequence > > Same comment as with the other Sequence numbers, > should this have a range? Additionally, should these > sequence numbers have a common TC? > > *)ospfv3LinkLsdbAge > > same comments and questions > as with the "Age" object in the prior table? > > *) ospfv3LinkLsdbChecksum > > Unsigned32? > > > *) ospfv3HostTable > > Need to have a storageType object added to this table. > > > > > > *) ospfv3HostStatus > > Please rename to ospfv3HostRowStatus > Usually, this is the last in the list of objects. > > *)ospfv3IfTable > > Don't understand the REFERENCE here, please explain. > > > Same comment as with the other table, there is mix of > configuration and status/statistics in this one table. > Could this be made into 2 tables? > > Also, the Counters in this table > likely need their own discontinuityTime object.... > > Can configurable objects change once the interface > is established (for example, if the interface is pointToPoint?) > > > > > *) ospfv3IfTransitDelay > > Don't understand the DESCRIPTION here. Could you > please expand. > > Is there a REFERENCE that could be added? > > *) ospfv3IfStatus > > Please rename to ospfv3IfRowStatus > > *) ospfv3IfAdminStat > > Would an OperStatus object be beneficial in this > table? > > *) ospfv3IfDemandNbrProbeRetxLimit > > Retx is used for Retransmission, elsewhere Retrans > was used. Please be consistant. > > *) ospfv3VirtIfTable > > Don't understand the reference here. If this is > an IPv6/V3 specific table then why are you > Refering to OSPFv2? Is this correct? Additionally, > could a OSPFv3 REFERENCE be added also? > > Same comments as with the other tables that have > a mix of config and status/statistics objects. > > Please change RowStatus objects to have RowStatus > at the end of their name. > > *) ospfv3NbrTable > > Same question as to how the Counters in this table > can successfully use ospfv3DiscontinuityTime. In other > words, if this table is specific to neighbors, then > the counters are also, so there might be (at least it > seems to me) a case where an entry in this table is > affected and neighbor counters suffer a discontinuity > but the ospfv3DiscontinuityTime may not. Please comment. > > > *) ospfv3NbrTable and ospfv3CfgNbrTable > > What is the relationship between these 2 tables? > The indexing is different between the 2 tables and so > I'm wondering what the relationship is between them. > > > > *) ospfv3AreaAggregateRouteTag > > Is this Unsigned32? > > > Notifications > ------------ > > In general the accessible-for-notify objects should probably be > changed into read-only objects. Additionally, a timestamp should > be associated with some of these. There is an assumption made that > it is better to send out notifications rather than poll, but I'd > rather give the operator the choice on that. > > > > > > > > Compliance Statements > ------------------------- > > * Need a Read-only compliance statement. > It is missing. > > --- > > > > > > > _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
