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

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

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. 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 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).
 
Bert