The two (V2 and V3) are incompatible. -DWard
On Mar 7, 2008, at 11:37 AM, 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
