Re: [MIB-DOCTORS] [manet] MIB doctor "skim" of draft-ietf-manet-olsrv2-mib-11.txt

[Randy Presuhn <[e-mail]>]

Hi -

In response to this comment:
RMP-308
Something I overlooked on previous passes:
olsrv2RxHoldTime, olsrv2PHoldTime, olsrv2FHoldTime,
olsrv2TpMaxJitter, olsrv2TtMaxJitter, olsrv2FMaxJitter:
are the maximum values for these *really* more than
49 days? 

There was this:
>From: "Dearlove, Christopher (UK)" 
>Sent: Jun 14, 2013 1:47 AM
>To: Randy Presuhn , "[e-mail]" , "[e-mail]" , "[e-mail]" 
>Subject: RE: [manet] MIB doctor "skim" of draft-ietf-manet-olsrv2-mib-11.txt
>
>With regard to the maximum long period for timing information,
> something abou the figure you indicate is the maximum value
> representable using the RFC 5497 format.
>
>Is it realistic? I can see a use for a large figure,
>if running a MANET in part over reliable fixed links.
>But essentially the original format had a 4/4 split of bits,
>and its maximum was deemed too short. 5/3 gave a long figure,
>even setting granularity to a binary millisecond.
...

Using the RFC 5497 section 5 formulas, the maximum value
representable (a = 7, b = 31, c = 1/1,024 {or is it .001?})
comes to 3,932,160 seconds, or about 45 days right?
That's less than the upper bound of the Unsigned32 data
type, so if the architecture truly supports the whole range
of the RFC 5497 representation for these values, then the
SMI data type should be restricted to an upper bound of
3,932,160,000 rather than the 4,294,967,295 that comes
with the Unsigned32 data type. (Of course, someone should
check my math.)

Rationale: it's generally a bad idea to permit a management
interface to configure architecturally impossible settings.

Perhaps this perfectly reasonable given the operational
characteristics of this protocol (I'm ignorant on the topic)
but permitting configuration of (for example) a jitter term
to have a value of more than 6 weeks, particularly given
the recommendations of RFC 5148, doesn't seem to make a
great deal of sense.

Rationale: we have a tradition of giving operators plenty
of rope with which to hang themselves, but this seems
excessive. :-)

Randy