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.

-- 
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: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.com | 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: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Randy Presuhn
Sent: 13 June 2013 06:53
To: mib-doctors@ietf.org; draft-ietf-manet-olsrv2-mib.all@tools.ietf.org; manet@ietf.org
Subject: [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 reponse to my earlier comments, the editors of the OLSRv2
MIB module issued an updated I-D, which I understand has been
sent to the manet WG for a sanity check.  In order speed things
along, I did a quick skim of the document this evening.

These comments are in my opinion very minor, with the exception
of RMP-313, but I would appreciate comments from other MIB doctors
on the two "***" items below.  (As well as anything else if you
think I've missed the boat.)

RMP-301
top of page 4: "OLSRV2" should be "OLSRv2"

RMP-302
top of page 4: "intervals etc." -> "intervals, etc."

RMP-303
6.3: needs to mention IANAolsrv2LinkMetricType-MIB in
the list.

RMP-304
Olsrv2MetricValueCompressedFormTC: I'm surprised that
the display-hint is "x" rather than "d".  I hope the
WG discussed this - I'm ok with whatever, as long as
it's a conscious decision and not an oversight.

RMP-305
Olsrv2MetricValueCompressedFormTC: I'm also a little
surprised that the DESCRIPTION talks about set processing,
since it looks to me as though all uses of this TC are
for read-only objects.

RMP-306
Olsrv2MetricValueCompressedFormTC: has the WG discussed
what a management system should do if an implementation
reponds to a get/getnext/getbulk request for an object
of this type with a syntactically legal but mathematically
impossible value, such as 16776959?

RMP-307
olsrv2InterfaceTable: "This object is set either by
network management, or by other means, e.g., CLI."
Is the EXCLUSIVE-OR intentional?  If not, should
delete the "either".

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? 

*** RMP-309
olsrv2LinkMetricType: the DEFVAL should probably say
	{ unknown(0) } - I don't know whether all
	MIB compilers out there nowadays are smart
	enough to figure out { unknown } by itself.
	They *should* be able to, but this might be
	a case where conservatism is warranted.

RMP-310
olsrv2TibAdRemoteRouterSetMaxSeqNo and
olsrv2TibAttNetworksSetSeqNo: I seem to recall from
another document that the notion of "greatest" for this
bit of information isn't the same as in math.  If that
is so, it should be spelled out here, as has already been done
in the description for olsrv2TibAdRemoteRouterSetMaxSeqNo.

*** RMP-311
All items with SYNTAX TimeStamp - some might argue whether
UNITS clauses are appropriate for these.  I'm equivocal on
the point.

RMP-312
You might consider whether you'd like to put DEFVAL clauses
on the read-write items in olsrv2NotificationsControl.
DEFVALs are merely advisory - implementations are NOT obligated
to follow them (RFC 2578 clause 7.9).

RMP-313
Section 10: needs to add instructions for the registration
and spin-off of the MIB module with the metric textual convention.
(Those instructions currently are in the first paragraph
of Appendix A.  It's ok by me if thery're repeated there, but
I think it's crucial that IANA's instructions in section 10 are
complete.)

Randy
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

********************************************************************
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.
********************************************************************