Hi Joan, Thanks much for the thorough and prompt review. There are some basic semantic differences between OSPFv2 and OSPFv3. Hence, I'm not sure if it is feasible to combine the MIBs. Also, over the long term our intent is to incorporate new function into OSPFv3 that will not be contained in OSPFv2. Finally, we've been working on this MIB for so long that I don't think it is in the best interest of the OSPF WG to even attempt consolidation. Thanks, Acee On Mar 7, 2008, at 12:37 PM, Joan Cucchiara wrote:
> > Hello, > > I do also have one other question. There seems to be > quite a bit of overlap between RFC4750 (OSPFv2 MIB) > and this draft. While I understand that there are obvious > differences between IPv4 and IPv6 addresses, and also > some differences in OSPFv2 vs. OSPFv3, I still see many > of the same MIB objects in the 2 MIB Modules, did the > authors consider using OSPFv2 MIB and doing AUGMENTS > for OSPFv3? > > Please give me some background/history on why a completely > separate MIB Module was done for OSPFv3. > > Thank you, > Joan > > > ----- Original Message ----- From: "Joan Cucchiara" > <[EMAIL PROTECTED]> > To: "Romascanu, Dan (Dan)" <[EMAIL PROTECTED]>; "Acee Lindem" > <[EMAIL PROTECTED]>; <[email protected]>; "MIB Doctors (E-mail)" <mib- > [EMAIL PROTECTED]> > Cc: "Ronald Bonica" <[EMAIL PROTECTED]>; "Abhay Roy" > <[EMAIL PROTECTED]>; "Ross Callon" <[EMAIL PROTECTED]>; "Vishwas > Manral" <[EMAIL PROTECTED]>; "Dan Joyal" <[EMAIL PROTECTED]>; > "Bert Wijnen" <[EMAIL PROTECTED]>; "David Ward" <[EMAIL PROTECTED]> > Sent: Friday, March 07, 2008 2:37 AM > 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
