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

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

inline

> > 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.
> 
So you are saying that they should use simialr text as in diffserv MIb
(if that is indeed what they mean, which I think it is, but Glenn can
explain that to us I hope). So if they reaplce:

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

with:

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

at everyplace where they have such text, then you would be happy?

> 
> >  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.
> 
Mmm... I think that is what you seem to be reading. But I think that Glenn
means more what is written inf diffserv MIB. Glenn?

> >
> > 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.
> 
I did not say it is MANDATORY or NEEDED. I said it would be "best".
I base this on section 4.4 of draft-ietf-ops-mib-review-guidelines-02.txt
I think it makes interdependecy clearer. But I would not block on it.

Bert