Re: [MIB-DOCTORS] MIB Doctor review of draft-ietf-sidr-rpki-rtr-protocol-mib-04

[Benoit Claise <[e-mail]>]

Thanks.
I just cleared my DISCUSS.

Regards, Benoit
> Hi Benoit,
>
> A updated 06 version of the draft was just submitted.  I have inline
> comments below.
>
>>>>>> On Mon, 11 Feb 2013 17:09:42 +0100, Benoit Claise <[e-mail]> said:
>      BC> Hi Michael, Thanks for addressing the MIB doctor points.
>
>      >>
>      DH> The Errors table contains counters that represent "the number of
>      DH> XXX errors received." This description seems to indicate that
>      DH> counters start at zero (and implicitly reset to zero on a
>      DH> discontinuity). An NMS developer certainly might interpret this
>      DH> text as indicating zero-based counters. I think if there is an
>      DH> assumption these are zero-based, there are TC-s that could be
>      DH> used to show that assumption. OTOH, counters typically are not
>      DH> zero-based because if errors occur during system startup, the
>      DH> counter might be initialized partway through the startup and not
>      DH> reflect all the errors that occurred during the startup phase. I
>      DH> think this table would benefit from a discussion of the expected
>      DH> initial values (zero or unpredictable/implementation-dependent)
>      DH> and the nature of expected discontinuities, so NMS developers
>      DH> can be sure to understand the relevant assumptions.  (is the
>      DH> only discontinuity a restart of the management system?  What
>      DH> about rollovers? Are all these error counters not preserved
>      DH> across system restarts? Or can an implementation choose to
>      DH> preserve them across resets to enhance debugging history?) Some
>      DH> of this discussion would seem to apply to all the error
>      DH> counters; if that is true of all current counters and should be
>      DH> true for an potentially new counters added to this table, this
>      DH> type of discussion could be captured in the Table or TableEntry
>      DH> description.  (including the discussion of
>      DH> rpkiRtrDiscontinuityTimer, which seems to apply to the whole
>      DH> table).
>      >>
>      >> I meant to add clarifying text to the discontinuity time (e.g. a
>      >> manager can only compare values pulled since the discontinuity
>      >> time...). But double checking now, I didn't get this change into
>      >> the current draft.
>      BC> The document would really benefit from this clarification.
>      BC> Please post a new version with this improvement, and I'll clear
>      BC> my DISCUSS.
>
> I added text to the rpkiRtrDiscontinuityTimer object:
>
>      For objects that use rpkiRtrDiscontinuityTimer to indicate
>      discontinuity, only values received since the time indicated by
>      rpkiRtrDiscontinuityTimer are comparable to each other. A manager
>      should take the possibility of rollover into account when
>      calculating difference values.
>
>      DH> rpkiRtrCacheServerId would benefit from a reference.
>      >> meant to, but not added
>      BC> It would nice to add it, along with above improvement.
>
> I did add a reference clause to this object (as well as fixing a
> spelling nit mentioned by Brian Carpenter).
>
> Thanks,
> Mike
>
>