Re: [MIB-DOCTORS] initial responses to: MIB doctor review of draft-ietf-manet-olsrv2-mib-08.txt (UNCLASSIFIED)

[Randy Presuhn <[e-mail]>]

Hi -

>From: "Cole, Robert G CIV USARMY CERDEC (US)" <[e-mail]>
>Sent: Jun 10, 2013 6:20 AM
>To: Randy Presuhn <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
>Cc: Ulrich Herberg <[e-mail]>, Thomas Heide Clausen <[e-mail]>
>Subject: RE: [MIB-DOCTORS] initial responses to: MIB doctor review of draft-ietf-manet-olsrv2-mib-08.txt (UNCLASSIFIED)

Thanks for the quick response.  I've elided the stuff where we're
in agreement, and just commented on the items needing further
conversation.

...
>On page 12 "This is done in Section 24.5 in OLSRv2" - Opinions vary about citations in DESCRIPTION clauses. I'm in the camp that thinks they're ok, *but*, mindful of the fact that modules are frequently extracted from their context, would like to see a reference that can be traced (e.g., RFC number) when this text is extracted.
>
>RGC>  I believe that these Object descriptions always have an associated REFERENCE clause.  But I suspect you are looking for text in the DESCRIPTION that reads something like "This is done in Section 24.5 in OLSRv2 (RFC XXXX)".  Is this true?

This particular case (the TC that will be handed off to IANA)
doesn't have a REFERENCE clause.  Adding one would address the
issue for me, keeping in mind that because it will be deleted
from the published RFC, it's especially important that the
TC has all the pointers it needs.

>The DESCRIPTION of Olsrv2MetricValueCompressedFormTC seems to cover the issues I raised in my comments, but a (minor!) new question I'd ask is whether it would be helpful to say anything about the "holes"
>in this representation, and what (if any) special course of action a management action should take if one of those "impossible"
>values shows up in reponse to a query. (Developers sometimes use "impossible" values for proprietary hack^Wkludge^Wfeatures.)
>
>RGC> The algorithm in RFC 5497 converts time (t) to (a,b), the parameters of the exponent-mantissa format.  The (a,b) are derived such that t<T(a,b) where T(a,b) is the time value derived from these (a,b) parameter choices and T is the smallest time representation greater than t.   So I suggest the following:
>
>If a net mgmt sets the time value t thru the MIB module, then the OLSRv2 code can derive t' = T(a,b) according to the algorithm in RFC 5497 and t' is the value represented in the OLSRv2 messages. But the value t is persistently stored by the MIB-module. If the MIB-module is pulling this time parameter from some other source, i.e., the protocol instance, then this value is stored as is.
...

That's a useful clarification of the *time*-related stuff,
and I think it would be good to include it.

But...

We're talking about different things here.  I was happy with the
revised time-related material.  My question is regarding the
*metric* values.  These are read-only, so handling a set request
isn't an issue.  My question is just whether you want to say
anything about what, if anything, a management system should
do if it gets, for example, a syntactically legal but mathematically
impossible (given the domain and range of the conversion function)
value of 16776959 in a response.

Randy