> ----- Original Message ----- > From: "Daniel Joyal" <[EMAIL PROTECTED]> > To: "Joan Cucchiara" <[EMAIL PROTECTED]>; "Romascanu, Dan (Dan)" > <[EMAIL PROTECTED]>; "Acee Lindem" <[EMAIL PROTECTED]>; <[email protected]>; > "MIB Doctors (E-mail)" <[EMAIL PROTECTED]> > Cc: "Ronald Bonica" <[EMAIL PROTECTED]>; "Abhay Roy" <[EMAIL PROTECTED]>; > "Ross Callon" <[EMAIL PROTECTED]>; "Vishwas Manral" > <[EMAIL PROTECTED]>; "Bert Wijnen" <[EMAIL PROTECTED]>; "David > Ward" > <[EMAIL PROTECTED]> > Sent: Thursday, March 13, 2008 4:51 PM > Subject: RE: MIB Dr. Review of draft-ietf-ospf-ospfv3-mib-12.txt > > > Hi, > > Please see my comments below. > > Thanks. > -Dan > >> -----Original Message----- >> From: Joan Cucchiara [mailto:[EMAIL PROTECTED] >> Sent: Tuesday, March 11, 2008 11:32 AM >> To: Joan Cucchiara; 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: Re: MIB Dr. Review of draft-ietf-ospf-ospfv3-mib-12.txt >> >> Hi Folks, >> >> I have a couple of clarifications inline below. >> >> Thanks, >> Joan >> >> >> ----- Original Message ----- >> From: "Joan Cucchiara" <[EMAIL PROTECTED]> >> To: "Joan Cucchiara" <[EMAIL PROTECTED]>; "Romascanu, >> Dan (Dan)" >> <[EMAIL PROTECTED]>; "Acee Lindem" <[EMAIL PROTECTED]>; >> <[email protected]>; "MIB Doctors (E-mail)" <[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 12:37 PM >> Subject: Re: MIB Dr. Review of draft-ietf-ospf-ospfv3-mib-12.txt >> >> >> > >> > 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)" >> > <[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 >> > >> > > [snip] >> >> >> >> General Comments >> >> ----------------- >> >> >> >> 1) Need to have a read-only conformance. >> >> >> >> It has been explained to me that the read-only conformance >> is not a requirement. >> However, the working group need to be aware of what it means >> to NOT have a read-only conformance. >> >> Here is the relevant text from RFC 4181: >> >> - If there are any objects with a MAX-ACCESS value of read-write or >> read-create for which there is no OBJECT clause that specifies a >> MIN-ACCESS of read-only, then implementations must support write >> access to those objects in order to be compliant with >> that MODULE- >> COMPLIANCE statement. This fact sometimes catches MIB module >> authors by surprise. When confronted with such cases, reviewers >> SHOULD verify that this is indeed what the authors >> intended, since >> it often is not. >> >> - On the other side of the coin, MIB module authors need >> to be aware >> that while a read-only compliance statement is sufficient to >> support interoperable monitoring applications, it is not >> sufficient >> to support interoperable configuration applications. A technique >> commonly used in MIB modules that are intended to support both >> monitoring and configuration is to provide both a read-only >> compliance statement and a full compliance statement. A good >> example is provided by the DIFFSERV-MIB [RFC3289]. >> Authors SHOULD >> consider using this technique when it is applicable. >> >> I would ask that the authors and working group comment on the >> read-only conformance, either for or against, and why. In my personal >> experience not all operators want to use SNMP to configure, so having >> a read-only conformance allows MIB implementations to be compliant >> to the MIB standard. In other words, read-only conformance guides >> MIB implementors on the interoperability with read-only conformance, >> just as the full (read and write) conformance does. >> Certainly, I would >> encourage this to be added to the MIB, but it is not mandatory. >> > > Since it's not mandatory, do many MIB authors opt to add a > read-only conformance? In other words, is it common practice? >
Yes, it is common practice. > >> >> 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. >> >> >> >> Having discussed this with other MIB Drs. has lead me to >> rephrase the above, please comment on 2 issues: >> >> a) situations where counters could suffer a discontinuity >> (e.g. a single OSPFv3 area's counters could have a discontinuity) >> The reason is that the document specifies only one OSPFv3 related >> reason for counters to suffer a discontinuity (i.e., the >> restart of the >> OSPFv3 >> routing process) and this is in the text of the document, not the MIB >> portion >> of the document. Describing more specific OSPFv3 situations >> in the MIB >> document itself >> would help implementors. > > The thinking was that an OSPFv3 instance would never clear its SNMP > counters after it is started, so only the coarse discontinuity > timer is necessary. I will add the text into the MIB module in > the discontinuity timer object description. Thank you. > >> >> b) some of the indexes use InterfaceIndex from the IF-MIB. >> The counters >> in these tables "might" be related to the ifCounterDiscontinuityTime >> object. >> More discussion on these tables would be helpful to determine if this >> is so. > > The ifCounterDiscontinuityTime does not apply to the counters associated > with OSPFv3 interfaces. > Okay. I do have a couple more questions, is there a one-to-one mapping between an OSPFv3 Interface and an IPv6 interface? If so, then do the DiscontinuityTimeObjects in RFC4293 apply to OSPFv3 interfaces as well? More generally, does the IP-MIB in RFC4293 need to be populated prior to this MIB? -Joan >> >> In essence, more Discontinuity objects may NOT be beneficial, and so >> would like to discuss a) and b) above before making that >> determination. >> >> Thanks, >> -Joan >> > [snip to end] > _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
