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

["Dearlove, Christopher (UK)" <[e-mail]>]

OK, if you are discussing the difference between 45 and 49 days, and whether all variables need that range, I'll leave that to the document authors.

-- 
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: [phone] |  Fax: [phone]
[e-mail] | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687


-----Original Message-----
From: Randy Presuhn [mailto:[e-mail]] 
Sent: 14 June 2013 19:18
To: Dearlove, Christopher (UK); [e-mail]; [e-mail]; [e-mail]
Subject: RE: [manet] MIB doctor "skim" of draft-ietf-manet-olsrv2-mib-11.txt

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

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
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************