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? > >> 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. > > 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. > > 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
