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

["Joan Cucchiara" <jcucchiara at mindspring.com>]

> ----- Original Message ----- 
> From: "Daniel Joyal" <djoyal at nortel.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>; "Bert Wijnen" <bertietf at bwijnen.net>; "David 
> Ward"
> <dward at cisco.com>
> 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: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?
>

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
OSPF at ietf.org
https://www.ietf.org/mailman/listinfo/ospf