[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Personal invitation to comment on the RPR MIB - Ballot P802. 17/D 3.2 2nd Recirculation


On Monday, April 19, 2004, at 09:47 AM, Wijnen, Bert (Bert) wrote:

Harrie, thanks for your review and comments.
I agree with quite a few of them... but have not checked all your
concerns yet. Of course some are subjective and do not MANDATE
change, but in many cases a change might be wise.

Here is one that bothers me somewhat.

Harrie notes/comments: 
rprIfChanges OBJECT-TYPE
    SYNTAX        Counter32
    MAX-ACCESS    read-only
    STATUS        current
    DESCRIPTION
        "Indicates number of times rprIfLastChange changed.

         The discontinued counter value is indicated
         by the ifCounterDiscontinuityTime value."


Can you add this functionality to some other object?
It would change the semantics, since the description
of the "ifCounterDiscontinuityTime" in the IF-MIB says:

"... The relevant counters are the specific
      instances associated with this interface of any Counter32 or
      Counter64 object contained in the ifTable or ifXTable."

Unfortenately, it limits the tables.

Interesting.... cause we have allowed other counters to use the
ifCounterDiscontinuityTime for this purpose. For example
diffServCountActOctets in RFC3289. And you did review that MIB
too.


Yep, I know. I get triggered for this one by the fact that the
RPR-MIB has a lot of times items written in the DESCRIPTION
that are possible to do formally. I know this is a subjective.
I also beleive that the approach is 'reverse' as described below.


It says:

  diffServCountActOctets OBJECT-TYPE
    SYNTAX       Counter64
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION
       "The number of octets at the Action data path element.

       Discontinuities in the value of this counter can occur at re-
       initialization of the management system and at other times as
       indicated by the value of ifCounterDiscontinuityTime on the
       relevant interface."

So it is a bit more specific as to which instance fo that timer object.
But this RPR MIB use of it is intended in the same way I think.
I think what the DESCRIPTION clause says (or intends to say) is that
discontinuities will not occur unless there are also discontinuties
in the regualr counter associated with that specific interface.

Now I do see you have a point here... but before we make Glenn
change this, we better think again if we cannot allow this.
I want to try and be consistent.


I agree for the consistency and I believe taht the difference between
both usages is:

DIFFSERV-MIB: a discontinuity of this count may happen if the system is
re-initialize or when indicated in the 'ifCounterDiscontinuityTime'.
Meaning the 'ifCounterDiscontinuityTime' drives the discontinuity of
the 'diffServCountActOctets'.

RPR-MIB: I read it as a change of the 'rprIfChanges' changes also the
'ifCounterDiscontinuityTime'. Meaning the one who triggers the other is
here in reverse.


I will also note that if this ifCounterDiscontinuityTime is used,
then the MODULE-COMPLIANCE better state so too. The RFC3289 does
it as follows:

  diffServMIBFullCompliance MODULE-COMPLIANCE
    STATUS current
    DESCRIPTION
       "When this MIB is implemented with support for read-create, then
       such an implementation can claim full compliance. Such devices
       can then be both monitored and configured with this MIB."

    MODULE IF-MIB -- The interfaces MIB, RFC2863
    MANDATORY-GROUPS {
       ifCounterDiscontinuityGroup
    }

    MODULE -- This Module
    MANDATORY-GROUPS {
        diffServMIBDataPathGroup, diffServMIBClfrGroup,
        diffServMIBClfrElementGroup, diffServMIBMultiFieldClfrGroup,
    ... and so on

It is then also best to IMPORT ifCounterDiscontinuityGroup (which RFC3289
does not do unfortunately). 

The import is not needed there, since the 'MODULE IF-MIB' of the
module compliance already does that. See section 5.4.3 of RFC 2580.

5.4.3. Mapping of the OBJECT clause

   The OBJECT clause, which need not be present, is repeatedly used to
   specify each MIB object for which compliance has a refined
   requirement with respect to the MIB module definition.  The MIB
   object must be present in one of the conformance groups named in the
   correspondent MANDATORY-GROUPS clause or GROUP clauses.

   By definition, each object specified in an OBJECT clause follows a
   MODULE clause which names the information module in which that object
   is defined.  Therefore, the use of an IMPORTS statement, to specify
   from where such objects are imported, is redundant and is not
   required in an information module.

regards,

Harrie