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?
Mmm... I think that is what you seem to be reading. But I think that Glenn
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.
means more what is written inf diffserv MIB. Glenn?
I did not say it is MANDATORY or NEEDED. I said it would be "best".
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 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.
I see what you mean, I read your comment differently in 'best' was for the inclusion in the MODULE-COMPLIANCE itself.