Re: [OSPF] MIB Dr. Review of draft-ietf-ospf-ospfv3-mib-12.txt

["Daniel Joyal" <djoyal at nortel.com>]

Hi,

 Please see my comments below.

Thanks.
-Dan 

> -----Original Message-----
> From: Joan Cucchiara [mailto:jcucchiara at mindspring.com] 
> Sent: Tuesday, March 11, 2008 11:32 AM
> To: Joan Cucchiara; Romascanu, Dan (Dan); Acee Lindem; 
> ospf at ietf.org; 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" <jcucchiara at mindspring.com>
> To: "Joan Cucchiara" <jcucchiara at mindspring.com>; "Romascanu, 
> Dan (Dan)" 
> <dromasca at avaya.com>; "Acee Lindem" <acee at redback.com>; 
> <ospf at ietf.org>; "MIB Doctors (E-mail)" <mib-doctors at ietf.org>
> Cc: "Ronald Bonica" <rbonica at juniper.net>; "Abhay Roy" 
> <akr at cisco.com>; "Ross Callon" <rcallon at juniper.net>; 
> "Vishwas Manral" 
> <vishwas at ipinfusion.com>; "Dan Joyal" <djoyal at nortel.com>; 
> "Bert Wijnen" 
> <bertietf at bwijnen.net>; "David Ward" <dward at cisco.com>
> 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" <jcucchiara at mindspring.com>
> > To: "Romascanu, Dan (Dan)" <dromasca at avaya.com>; "Acee Lindem" 
> > <acee at redback.com>; <ospf at ietf.org>; "MIB Doctors (E-mail)" 
> > <mib-doctors at ietf.org>
> > Cc: "Ronald Bonica" <rbonica at juniper.net>; "Abhay Roy" 
> > <akr at cisco.com>; "Ross Callon" <rcallon at juniper.net>; 
> "Vishwas Manral"
> > <vishwas at ipinfusion.com>; "Dan Joyal" <djoyal at nortel.com>; 
> "Bert Wijnen" 
> > <bertietf at bwijnen.net>; "David Ward" <dward at cisco.com>
> > 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
OSPF at ietf.org
https://www.ietf.org/mailman/listinfo/ospf