Subject: [MIB-DOCTORS] MIB doctor review of draft-ietf-manet-olsrv2-mib-08.txt

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 17 May 2013 22:58:04 -0700

Hi -

I was asked to review draft-ietf-manet-olsrv2-mib-08.txt
as a MIB doctor.  There are several issues that clearly
need to be addressed before this document is ready for
publication.  There are numerous places where I think
the clarity could be improved, particularly with potential
implementors in mind.  I also have several questions about
the intent of the design the document left unanswered.
The answers to these might simply put my mind at rest or
raise other issues regarding how this design would function.

To simplify discussion of my comments, I'm organizing them
by issue type rather than location in the document, since
most issues show up in several places.

I draw the Mib Doctors' attention to the following issues,
where my opinion might be potentially controversial:
    RMP-002, RMP-006, RMP-012, RMP-035

Major Issues:

Issue RMP-001
Location: multiple objects referring to
UNKNOWN_METRIC in their DESCRIPTION clauses
Issue: UNKNOWN_METRIC isn't defined in this document, and 
draft-ietf-manet-olsrv2-19 section 6.1 explcitly
avoids defining a specific external representation.
That obviously won't do here, and a unique value
that can be accommodated by the objects' syntax
needs to be selected and documented.

Issue RMP-002
Location: All "Metric" Objects, all Float32 usages
Issue: All possible values that can be encoded using
the metric representation defined in section 6.2
of the OLSRv2 I-D, section 6.2 can be represented
as exactly using Unsigned32 in SMI.  (The
possible values are all integers in range 1..65280)
Using Float32 is simply not necessary here.
Suggestion: Define a textual convention for metrics, with
and underlying syntax of Unsigned32, carving
out a reserved value for "UNKNOWN_METRIC" (see
issue RMP-001) and use that rather than Float32.
Remove the IMPORTS and references rendered superfluous.

Issue RMP-003
Location: 5.5.  Tables and Indexing
Issue: The structure described in the text here does not
match the actual structure defined in the MIB module.
Suggestion: replace the discussion of "olsrv2LibOrigSetIpAddrType
and olsrv2LibOrigSetIpAddr", which are *not* indexes,
with discussion of olsrv2LibOrigSetIndex.
Suggestion: replace the discussion of "olsrv2LibLocAttNetSetIpAddrType,
olsrv2LibLocAttNetSetIpAddr and
olsrv2LibLocAttNetSetIpAddrPrefixLen", which are *not*
indexes, with discussion of olsrv2LibLocAttNetSetIndex.
Suggestion:  replace the discussion of 
"olsrv2TibRouterTopologySetFromOrigIpAddrType and
      olsrv2TibRouterTopologySetFromOrigIpAddr", which are
*not* indexes, with discussion of 
olsrv2TibRouterTopologySetIndex.
Suggestion: replace discussion of "olsrv2TibAttNetworksSetNetIpAddrType,
olsrv2TibAttNetworksSetNetIpAddr and
      olsrv2TibAttNetworksSetNetIpAddrPrefixLen", which are *not*
indexes, with one about olsrv2TibAttNetworksSetIndex.

Minor Issues:

Issue RMP-004
Location: Section 5
Issue: The text refers to several labels that don't exist
in the MIB module.
Suggestion: replace "olsrv2Objects" with  "olsrv2MIBObjects"
Suggestion: replace "olsrv2Notifications" with "olsrv2MIBNotifications"
Suggestion: replace "olsrv2Conformance" with "olsrv2MIBConformance"

Issue RMP-005
Location: 5.5.  Tables and Indexing
Issue: A label in the text doesn't match the (apparently) intended
OBJECT-TYPE in the MIB module.  However, the label in the
text follows the pattern of other labels in the module,
while the label in the module deviates from the pattern
of other labels.
Suggestion: change the label "olsrv2TibRoutingSetDestIpAddrPrefLen"
in the MIB module to match the 
"olsrv2TibRoutingSetDestIpAddrPrefixLen" label used
in the text.

Issue RMP-006
Location: all object types with SYNTAX InetAddressType
Issue: All of these have DESCRIPTION text constraining the
set of possible values.  If these constraints are
indeed architectural constraints, and it is impossible
for OLSRv2 to work with any other address types, this
should be reflected in the syntax.  If it is envisioned
that some future version of this module might support
other types, then the place for the constraint is
neither in the SYNTAX nor the DESCRIPTION, but in the
conformance material.
Suggestion: replace "SYNTAX InetAddressType" with
"SYNTAX  InetAddressType { ipv4(1) , ipv6(2) }" in
all cases.

Issue RMP-007
Location: all object types with SYNTAX TimeStamp
Issue: All of these have UNITS clauses specifying "milliseconds".
This cannot be, since TimeStamp is defined in terms
of *centi*seconds.
Suggestion: either remove the UNITS, or correct them

Issue RMP-008
Location: olsrv2RoutingSetRecalculationCountChange and
olsrv2MPRSetRecalculationCountChange NOTIFICATION-TYPEs
Issue: neither of these describes any mechanism for limiting
the rate at which these notifications are generated
Suggestion: add text to each to the effect that that notification
can be generated at most once per window.

Issue RMP-009
Location: 8.  Security Considerations
Issue: This MIB module AUGMENTS tables from another MIB module.
Care must be taken in configuring access control to make
sure that the permissions granted for the AUGMENT-ing tables
are no more generous than those for the tabled being AUGMENT-ed.
Otherwise, for example, not-accessible index information leaks.
Suggestion: Identify these tables and recommend that access control
policies be provisioned accordingly.

Issue RMP-010
Location: 8.  Security Considerations
Text: "olsrv2TibRouterTopologySetFromOrigIpAddr is the index into the"
Issue: No, that's *not* the index into that table.
Suggestion: refer to olsrv2TibRouterTopologySetIndex instead, or,
better still, delete the last two sentences of the paragraph
since they don't really add anything.

Issue RMP-011
Location: olsrv2PreviousOrigIpAddrType  OBJECT-TYPE
Issue: The address type needs to effectively be just
as persistent as olsrv2PreviousOrigIpAddr.
Suggest: add words to the effect:
"This object MUST have the same persistance
characteristics as olsrv2PreviousOrigIpAddr."

Issue RMP-012
Location olsrv2THoldTime  OBJECT-TYPE
olsrv2AHoldTime  OBJECT-TYPE
Issue: Since this is required to be fit the constraints of the
exponent-mantissa notation in RFC 5497, the syntax should
at least constrain the range.  With "C" nailed down as
1/1024 second, rather than the 1/1000 second interval
the object type is defined in terms of, the permitted
values for this object are: 125, 250, 375, 500, 625, 750, 875,
1000, 1125, 1250, 1375, 1500, 1625, 1750, 1875, 2000, 2250,
2500, 2750, 3000, 3250, 3500, 3750, 4000, 4500, 5000, 5500,
6000, 6500, 7000, 7500, 8000, 9000, 10000, 11000, 12000, 13000,
14000, 15000, 16000, 18000, 20000, 22000, 24000, 26000, 28000,
30000, 32000, 36000, 40000, 44000, 48000, 52000, 56000, 60000,
        and so on up to 3,932,160 (I think).  My concern is whether
the operator of a management system will be able to guess/calculate
these values on the fly, and whether they might be astonished
to discover that this object can be set to 28, 30, 32, and 36
seconds, but not 34.
Suggestion: this seems to be a candidate for a textual convention,
possibly punting on the upper reaches, but being explicit at least
up to 60 seconds or so.

Editorial Issues:

Issue RMP-013
Location: all object types with SYNTAX InetAddressPrefixLength
Suggestion: add 'UNITS "bits"' to each of these.

Issue RMP-014
Issue: many object type definitions would benefit from UNITS clauses
Location: olsrv2IfTcMessageXmits  OBJECT-TYPE
  olsrv2IfTcMessageRecvd  OBJECT-TYPE
Suggest: UNITS "messages"
Location: olsrv2IfTcMessageXmitAccumulatedSize  OBJECT-TYPE
  olsrv2IfTcMessageRecvdAccumulatedSize  OBJECT-TYPE
Suggest: UNITS "octets"
Location: olsrv2IfTcMessageXmitAccumulatedMPRSelectorCount OBJECT-TYPE
Suggest: UNITS "advertised selectors"
Location: olsrv2RoutingSetRecalculationCount  OBJECT-TYPE
          olsrv2MPRSetRecalculationCount  OBJECT-TYPE
          olsrv2RoutingSetRecalculationCountThreshold OBJECT-TYPE
          olsrv2MPRSetRecalculationCountThreshold OBJECT-TYPE
Suggestion: UNITS "recalculations"
Location: olsrv2IfTcMessageForwardedXmits  OBJECT-TYPE,
      olsrv2IfTcMessagePeriodicXmits  OBJECT-TYPE, and
      olsrv2IfTcMessageTriggeredXmits  OBJECT-TYPE
Suggestion: UNITS "messages" (if that's what these count...)

Issue RMP-015
Location: 8.  Security Considerations
Text: "This information can be use to expedite attacks"
Issue: grammar
Suggestion: replace "can be use to" with "can be used to"

Issue RMP-016
Location: 9.  Applicability Statement
Text: "Some level of configuration, i.e., read-write
objects, are desirable"
Issue: verb/subject agreement
Suggestion: replace "are" with "is"

Issue RMP-017
Location: 9.  Applicability Statement
Text: "this MIB allows for"
Issue: terminology
Suggest: replace "MIB" with "MIB Module"

Issue: RMP-018
Location: multiple
Issue: in most cases, it appears that "RECOMMENDED" is
intended where "recommended" is used, and "SHOULD"
where "should" appears in the text.
Suggestion: Use "RECOMMENDED" and "SHOULD" where that is
indeed intended.

Issue: RMP-019
Location: Abstract & Introduction - similar wording
Text: "The OLSRv2-MIB module is structured into state information,
   performance information, and notifications."
Issue: Neglects configuration information and is not consistent
   with section 5 and the MIB module itself.
Suggestion: include "confiuration information" in the list.

Issue: RMP-020
Location: Abstract & Introduction - similar wording
Text: "Different levels of compliance allow implementers to use
   smaller subsets of all defined objects..."
Issue: Only two levels are defined.
Suggestion: Replace the sentence beginning with "Different" with:
   "Two levels of compliance allow this MIB module to be
   deployed on constrained routers." or something to that effect.

Issue: RMP-021
Location: 5.4.  The Notifications Group
Text: "The Notifications Group contains Control, Objects and States, where
   the Control contains definitions of objects to control the frequency
   of notifications being sent.  The Objects define the supported
   notifications and the State is used to define additional information
   to be carried within the notifications."
Issue: (a) This paragraph really belongs at the beginning, rather than
   at the end, of 5.4.
   (b) within the MIB modules these divisions are referred to as
       olsrv2NotificationsObjects, olsrv2NotificationsControl,
       and olsrv2NotificationsStates
Suggestion:
   (a) move this paragraph to the beginnin of 5.4
   (b) Revise the first sentence to read something like:
       "The Nofications Group contains Control (olsrv2NotificationsControl),
       Objects (olsrv2NotificationsObjects), and States
       (olsrv2NotificationsStates), where ...."

Issue RMP-022
Location: 5.4.  The Notifications Group
Text: "The Notifications sub-tree..."
Issue: That's not quite where the information is in the MIB module.
Suggestion: Replace with "The olsrv2NotificationsObjects sub-tree..."

Issue: RMP-023
Location: 5.5.  Tables and Indexing, similar wording appears
several times within the MIB module's DESCRIPTION clauses
Text: "a recently used originator address by this router" 
Issue: awkward English syntax
Suggestion: replace with "an originator address this
router has recently employed"
Issue: it's not clear what is meant by "recently"...

Issue RMP-024
Location: 5.5.  Tables and Indexing
Text: "is indexed via the set" (several times)
Issue: the word "set" is unnecessary and is arguably incorrect,
since the order of indices does matter
Suggestion: delete "the set"

Issue RMP-025
Location: 5.5.  Tables and Indexing
Text: INDEX { }, AUGMENTS { } (several times)
Issue: no value added by quoting MIB Module syntax
Suggestion: replace with "in indexed by ..." or "augments ..." or
   similar English text, rather than using MIB Module syntax.

Issue RMP-026
Location: 5.5.  Tables and Indexing
Text: "olsrv2InterfacePerfTable - records performance counters for each
      active OLSRv2 interface on this device. selected path to each
      destination for which any such path is known."
Issue:  It looks like there's something missing here - in any case
      the text beginning with "selected" is currently grammatically
      a fragment rather than a complete sentence.
Suggestion: fix it to make logical and grammatical sense - I don't
know what was intended here.

Issue RMP-027
Location: 5.5.  Tables and Indexing
Text: "each Remote Router's IfAddr"
Issue: "IfAddr" isn't defined.
Suggestion: Unsure - it's not clear to me what's really intended
  here.

Issue RMP-028
Location: 6.2.  Relationship to the NHDP-MIB
Text: "In order access"
Issue: missing word
Suggestion: replace with "In order to access"

Issue RMP-029
Location: all NOTIFICATION-TYPE descriptions
Issue: It's not quite correct to say "sent" - other MIBs control
whether a notification ever shows up on the wire
(e.g., SNMP-NOTIFICATION-MIB (RFC 3413)), and
in some environments notifications may be locally logged
Suggestion: say "generated" rather than "sent"

Issue RMP-030
Location: conformance material
Issue: The language in these descriptions will potentially break
if this module is ever updated to include additional
objects or notifications.  The suggestions here are just
examples of ways to say it while remaining future-proof.
Location: olsrv2ConfigObjectsGroup OBJECT-GROUP
Suggestion: "Objects to permit configuration of OLSRv2.
          All of these SHOULD be backed by non-volatile storage."
Location: olsrv2StateObjectsGroup OBJECT-GROUP
Suggest: "Objects to permit monitoring of OLSRv2 state."
Location: olsrv2PerfObjectsGroup  OBJECT-GROUP
Suggest: "Objects to support monitoring of OLSRv2 performance ."
Location: olsrv2NotificationsObjectsGroup OBJECT-GROUP
Suggest: "Objects to support the notification types in the
olsrv2NotificationsGroup.  Some of these appear in
        notification payloads, others serve to control
notification generation." or something more helpful.
Location: olsrv2NotificationsGroup NOTIFICATION-GROUP
Suggestion: "Notification types to support management of OLSRv2."
or something more helpful.

RMP-031
Location: olsrv2RouterStatusChange NOTIFICATION-TYPE
  olsrv2OrigIpAddrChange NOTIFICATION-TYPE
  olsrv2RoutingSetRecalculationCountChange NOTIFICATION-TYPE
  olsrv2MPRSetRecalculationCountChange NOTIFICATION-TYPE
Issue: the term "originator" is used in the document in a special
sense.  That's fine.  Where I get a little heartburn is
where it is used in the phrase "originator of the
notification".  That's uncomfortably close the the SNMP
term "notification originator", which means something
quite different.
Suggestion: reword the passages that say things like "originator
of the notification" to improve clarity and avoid confusion.

Issue RMP-032
Location: multiple
Issue: choice of base data types - this is a stylistic preference,
especially for indexes.
Suggestion: change Integer32 to Unsigned32

Issue RMP-033
Location: throughout the MIB module
Issue: labels from the OLSRv2 specification are widely used
in DESCRIPTIONS, without a key identifying the
OBJECT-TYPEs to which they correspond.  Not sure
what they refer to, I haven't investigated whether
they are correct.
Specific examples:
Location: olsrv2IibLinkSetEntry  OBJECT-TYPE
Text: (L_in_metric, L_out_metric, L_mpr_selector)"
Location: olsrv2IibLinkSetInMetric  OBJECT-TYPE
Text: L_neighbor_iface_addr_list
Location: olsrv2IibLinkSetOutMetric  OBJECT-TYPE
Text: L_neighbor_iface_addr_list
Location: olsrv2Iib2HopSetEntry  OBJECT-TYPE
Text: (N2_in_metric, N2_out_metric)"
Location: olsrv2Iib2HopSetInMetric  OBJECT-TYPE
Text: N2_2hop_iface_addr, N2_neighbor_iface_addr_list.
Location: olsrv2Iib2HopSetOutMetric  OBJECT-TYPE
Text: N2_2hop_iface_addr, N2_neighbor_iface_addr_list.
Location: olsrv2LibOrigSetEntry  OBJECT-TYPE
Text: (O_orig_addr, O_time)"
Location: olsrv2LibLocAttNetSetEntry  OBJECT-TYPE
Text: (AL_net_addr, AL_dist, AL_metric)
Location: olsrv2LibLocAttNetSetMetric  OBJECT-TYPE
Text: AL_net_addr 
Location: olsrv2NibNeighborSetEntry  OBJECT-TYPE
Text: N_orig_addr N_in_metric N_out_metric N_will_flooding N_will_routing
N_flooding_mpr N_routing_mpr N_mpr_selector N_advertised
Location: olsrv2NibNeighborSetNAdvertised  OBJECT-TYPE
Text: N_mpr_selector
Location: olsrv2TibAdRemoteRouterSetEntry  OBJECT-TYPE
Text: (AR_orig_addr, AR_seq_number, AR_time)
Location: olsrv2TibRouterTopologySetEntry  OBJECT-TYPE
Text: " (TR_from_orig_addr, TR_to_orig_addr,
    TR_seq_number, TR_metric, TR_time)"
Location: olsrv2TibRouterTopologySetFromOrigIpAddr  OBJECT-TYPE
Text: TR_to_orig_addr
Location: olsrv2TibRouterTopologySetToOrigIpAddr  OBJECT-TYPE
Text: TR_to_orig_addr 
Location: olsrv2TibRouterTopologySetSeqNo  OBJECT-TYPE
Text: TR_from_orig_addr
Location: olsrv2TibRouterTopologySetMetric  OBJECT-TYPE
Text: TR_from_orig_addr TR_to_orig_addr."
Location: olsrv2TibRoutableAddressTopologySetEntry  OBJECT-TYPE
Text: (TA_from_orig_addr, TA_dest_addr,
    TA_seq_number, TA_metric, TA_time)"
Location: olsrv2TibRoutableAddressTopologySetFromOrigIpAddr  OBJECT-TYPE
Text: TA_dest_addr
Location: olsrv2TibRoutableAddressTopologySetDestIpAddr  OBJECT-TYPE
Text: TA_from_orig_addr 
Location: olsrv2TibRoutableAddressTopologySetSeqNo  OBJECT-TYPE
Text: TA_from_orig_addr
Location: olsrv2TibRoutableAddressTopologySetMetric  OBJECT-TYPE
Text: TA_from_orig_addr 
Location: olsrv2TibAttNetworksSetEntry  OBJECT-TYPE
Text: (AN_orig_addr, AN_net_addr, AN_seq_number,
    AN_dist, AN_metric, AN_time)"
Location: olsrv2TibAttNetworksSetOrigIpAddr  OBJECT-TYPE
Text: AN_net_addr."
Location: olsrv2TibAttNetworksSetNetIpAddr  OBJECT-TYPE
Text: AN_orig_addr."
Location: olsrv2TibAttNetworksSetSeqNo  OBJECT-TYPE
Text: AN_orig_addr"
Location: olsrv2TibAttNetworksSetDist  OBJECT-TYPE
Text: AN_net_addr AN_orig_addr."
Location: olsrv2TibAttNetworksSetMetric  OBJECT-TYPE
Text: AN_orig_addr AN_net_addr."
Suggestion: assuming these are useful links into the OLSRv2
specification, I suggest accompanying each one with
the label of the corresponding object-type from
the mib module.

Issue RMP-034
Issue: obvious typographical errors in DESCRIPTIONs
Location: olsrv2MPRSetRecalculationCountThreshold OBJECT-TYPE
Suggestion: replace "olsrv2MPRSetReculculationCountWindow"
    with    "olsrv2MPRSetRecalculationCountWindow"
Location: olsrv2Iib2HopSetOutMetric  OBJECT-TYPE
Suggestion replace "olsrv2Iib2HopSetN2Time" with
   "olsrv2Iib2HopSetOutMetric"
Location: olsrv2IibLinkSetOutMetric  OBJECT-TYPE
Suggestion: replace "olsrv2IibLinkSetInMetric"
    with    "olsrv2IibLinkSetOutMetric"
Location: olsrv2TibRoutingSetNextIfIpAddrType  OBJECT-TYPE
Text:     "The type of the olsrv2TibRoutingSetNextIfIpAddr
                  and olsrv2TibRoutingSetNextIfIpAddr,"
Suggestion: delete "and olsrv2TibRoutingSetNextIfIpAddr,"

Issue RMP-035
Location: olsrv2NibNeighborSetNWillFlooding  OBJECT-TYPE
Location: olsrv2NibNeighborSetNWillRouting  OBJECT-TYPE
Location: olsrv2WillFlooding     OBJECT-TYPE
Location: olsrv2WillRouting  OBJECT-TYPE
Issue: these all have the same syntax, and seem a good
candidate for a textual convention, particularly
if there's a desire to have willNever, willAlways,
or willDefault available to tools.
Suggestion: create a textual convention with the appropriate
values and semantics

Issue RMP-036
Location: olsrv2LinkMetricType  OBJECT-TYPE
Issue: With the allocation of metric types under IANA control,
it may make sense to define a textual convention (spun
off into an IANA-maintained MIB module) to support
metric type selection.

Issue RMP-037
Location: 7.  Definitions
Text:
    -- This MIB module defines objects for the management of
    -- RFC XXXX - The Optimized Link State Routing Protocol
    -- version 2, Clausen, T., Dearlove, C., Jacquet, P.
    -- and U. Herberg, March 2013.
Issue: this information is redundant with what is already in
   the MODULE-IDENTITY's DESCRIPTION clause
Suggestion: delete these comments
Location: page 65
Text: -- olsrv2NotificationStates
Issue: this comment isn't helpful at all.
Suggestion: delete it

Issue RMP-038
Location: Olsrv2Status ::= TEXTUAL-CONVENTION
Issue: the description of this textual convention says
   it's an "indication of the operability", but the
   actual use is to configure / control.
Suggestion: reword the description to make the administrative
control aspect explicit, e.g.:
       "Controls the operation of the OLSRv2
        protocol on the device or a specific interface.
        For example, for an interface: 'enabled' indicates
        that OLSRv2 is permitted to operate,
        and 'disabled' indicates that it is not."

Issue RMP-039
Location: olsrv2InterfaceTable  OBJECT-TYPE
Text: "are explicitly defined by network manager servers"
Issue: terminology
Suggestion: replace "manager servers" with "managers" or
"management"

Issue RMP-040
Location: olsrv2InterfaceTable  OBJECT-TYPE
Text: "contains a single boolean object, the"
Issue: the object is not a boolean.  If it were, the correct type
would be TruthValue (RFC 4181 clause 4.6.1.9)
Suggestion: delete "boolean"

Issue RMP-041
Location: olsrv2InterfaceAdminStatus OBJECT-TYPE
Text: "is running the OLSRv2 routing process.
       The value 'disabled' denotes that the interface is
       external to the OLSRv2 routing process."
Issue: "running" "external" and "process" strongly
   suggest a particular implementation strategy
Suggest: "is permitted to participate in the OLSRv2 protocol.
       The value 'disabled' denotes that the interface is
       not permitted to participate in the OLSRv2 protocol."

Issue RMP-042
Location: olsrv2NibNeighborSetNOrigIpAddr  OBJECT-TYPE
Text: "This is the originator IP address of that neighbor."
Issue: What neighbor?
Sugestion: clarify

Issue RMP-043
Location: olsrv2IibLinkSetMprSelector  OBJECT-TYPE
Location: olsrv2NibNeighborSetNFloodingMpr  OBJECT-TYPE
Location: olsrv2NibNeighborSetNRoutingMpr  OBJECT-TYPE
Location: olsrv2NibNeighborSetNMprSelector  OBJECT-TYPE
Text: "describing if this neighbor"
Issue: stylistic preference
Suggestion: replace "describing if" with "recording whether"

Issue RMP-044
Location: olsrv2TibAdRemoteRouterSetMaxSeqNo  OBJECT-TYPE
Location: olsrv2TibRouterTopologySetSeqNo  OBJECT-TYPE
Location: olsrv2TibRoutableAddressTopologySetSeqNo  OBJECT-TYPE
Text: "the greatest ANSN in any TC message"
Suggest: explain what "greatest" means under wrap conditions,
or otherwise re-word for correctness

Issue RMP-045
Location: olsrv2TibAdRemoteRouterSetRouterId  OBJECT-TYPE
text: "This object is an additional index for each
   Remote Router's IfAddr associated with the
   olsrv2TibAdRemoteRouterSetIpAddr."
Issue: "additional" makes no sense, as this is the sole index
Suggestion: delete "additional"

Issue RMP-046
Location: olsrv2TibAttNetworksSetOrigIpAddr  OBJECT-TYPE
Text: network with address AN_net_addr."
Location: olsrv2TibAttNetworksSetNetIpAddr  OBJECT-TYPE
Text: the router with originator address AN_orig_addr."
Issue: addresses need a type, too.

Issue RMP-047
Location: olsrv2TibRoutingSetDestIpAddrType  OBJECT-TYPE
Text: "The type of the olsrv2TibRoutingSetDestIpAddr
   and olsrv2TibRoutingSetNextIfIpAddr,"
Issue: Another object defines the type for the latter.
Suggestion: delete "and olsrv2TibRoutingSetNextIfIpAddr"

Issue RMP-048
Location: olsrv2RoutingSetRecalculationCountChange NOTIFICATION-TYPE
Suggest: Delete "The new count of the routing set recalculations"
since the explanation is just confusing.
Issue: the description could be more precise
Suggest: Replace with something like:
          "The olsrv2RoutingSetRecalculationCountChange 
           notification is generated when a significant number of
           routing set recalculations have occurred in a short time.
           The network administrator should select
           appropriate values for 'significant number of
           routing set recalculations' and 'short time' through the settings
           of the olsrv2RoutingSetRecalculationCountThreshold
           and olsrv2RoutingSetRecalculationCountWindow
           objects."

Location: olsrv2MPRSetRecalculationCountChange NOTIFICATION-TYPE
Suggest: Delete "The new MPR set recalculation count", since
the explanation is just confusing.
Issue: the description could be more precise
Suggest: Replace with:
          "The olsrv2MPRSetRecalculationCountChange 
           notification is generated when a significant
   number of MPR set recalculations occur in
   a short period of time.
           The network administrator should select
           appropriate values for 'significant number of
           MPR set recalculations' and 'short period of
   time' through the settings
           of the olsrv2MPRSetRecalculationCountThreshold
           and olsrv2MPRSetRecalculationCountWindow
           objects."

Location:    olsrv2RoutingSetRecalculationCountWindow OBJECT-TYPE
Issue: clarity
Suggestion: I *think* this is what is intended in the first
part of the DESCRIPTION:
"This object is used to determine whether to generate
an olsrv2RoutingSetRecalculationCountChange notification.

This object represents an interval from the present moment,
extending into the past, expressed in hundredths of
a second.  If the change in the value of the
        olsrv2RoutingSetRecalculationCount object during
this interval has exceeded the value of 
        olsrv2RoutingSetRecalculationCountThreshold, then the
an olsrv2RoutingSetRecalculationCountChange notification
is generated."

Location: olsrv2MPRSetRecalculationCountWindow OBJECT-TYPE
Text: "A time window for the
           olsrv2MPRSetRecalculationCount object.
           If the number of occurrences exceeds the
           olsrv2MPRSetRecalculationCountThreshold
           within the previous
           olsrv2MPRSetRecalculationCountWindow,
           then the
           olsrv2MPRSetRecalculationCountChange
           notification is to be sent.
           This object represents the timei interval in hundredths
           of a second."
Issue: clarity
Suggestion: I *think* this is what is intended in that part of the
DESCRIPTION:
"This object is used to determine whether to generate
an olsrv2MPRSetRecalculationCountChange notification.

This object represents an interval from the present moment,
extending into the past, expressed in hundredths of
a second.  If the change in the value of the
        olsrv2MPRSetRecalculationCount object during
that interval has exceeded the value of 
        olsrv2MPRSetRecalculationCountThreshold, then the
an olsrv2MPRSetRecalculationCountChange notification
is generated."

Questions / Clarifications:

Issue RMP-049
Location: 4.  Overview
Text: This document provides management and control capabilities of an
   OLSRv2 instance..."
Issue: The design of this module permits only a *single* OLSRv2 instance
   to be managed in a given SNMP context. (But doesn't preclude using
   SNMP contexts to provide access to different instances running
   on a given system.  This would be needed, for example, if a single
   box provided services to two or more non-connected (by adminstrative
   policy, for example) ad hoc networks.)
Suggestion:  I'm not advocating any particular direction here,
   just alerting you to the fact that this design effectively
   makes a decision here, and hope this was a *conscious* decision.

Issue RMP-050
Location: 6.2.  Relationship to the NHDP-MIB
Text: "locally significant but should be locally common"
Issue: Is normative "should" intended here, or is this merely
   implementation advice?  I think the normative requirement is
   merely that the set of values and the semantics of each
   individual value be identical for the two MIB modules
   within a given SNMP context.  Anything beyond that is
   implementation detail, and would properly be out of scope.
Suggestion: remove the ambiguity.

Issue RMP-051
Location: olsrv2InterfaceTable  OBJECT-TYPE
Text:      A conceptual row in this table exists if and only
           if either a manager has explicitly created the row
           in the nhdpInterfaceTable
           or there is an interface on the managed device
           that supports and runs NHDP.
Issue: Is the intent here to preclude provisioning by NETCONF,
   CLI, or other means?  If not, the language needs softening.

Issue RMP-052
Location: DESCRIPTION and SYNTAX of integer index objects, e.g.:
  olsrv2LibOrigSetIndex  OBJECT-TYPE
  olsrv2LibLocAttNetSetIndex  OBJECT-TYPE
  olsrv2TibAdRemoteRouterSetRouterId  OBJECT-TYPE
  olsrv2TibRouterTopologySetIndex  OBJECT-TYPE
  olsrv2TibRoutableAddressTopologySetIndex  OBJECT-TYPE
  olsrv2TibAttNetworksSetIndex  OBJECT-TYPE
Issue: these index definitions raise more questions than they answer
Suggestion: (a) Provide motivation for constraints on index ranges
       (b) describe how index values for new entrys are allocated
       (c) describe conditions for re-use of previously-used values

Issue RMP-053
Location: DESCRIPTION of various entry object types, e.g.:
olsrv2LibLocAttNetSetEntry  OBJECT-TYPE
olsrv2NibNeighborSetEntry  OBJECT-TYPE
olsrv2TibAdRemoteRouterSetEntry  OBJECT-TYPE
olsrv2TibRouterTopologySetEntry  OBJECT-TYPE
olsrv2TibRoutableAddressTopologySetEntry  OBJECT-TYPE
Issue: it is helpful to the implementor of both instrumentation
and management applications to know the expected lifecycle
of table entries - when they are created, when they can
disappear, and the conditions for index re-use.  It would
also be helpful to have a little more explanation of
what does and doesn't happen as a consequence of
interface enable/disable.
Suggestion: outline the lifecycle of table entries for each
non-AUGMENTS table in the MIB module

Issue RMP-054
Location: olsrv2AdminStatus  OBJECT-TYPE
Text: "Hence, this
       object cannot have a status of 'enabled'
       unless at least one interface an the device
       is a MANET interface with NHDP enabled on that
       interface.  If all device interfaces running
       NHDP become disabled or removed, then the
       olsrv2AdminStatus MUST be set to 'disabled'.

       If the network manager sets this object to
       'disabled', then the associated interface specific
       objects, i.e., the olsrv2InterfaceAdminStatus
       objects must all be set to 'disabled'."
Issues: (1) Is the intent that a request to set this to 'enabled'
would (in the absence of NHDP) fail with 
inconsistentValue? (if not...?)
(2) what entity does the set referred to in the
        "MUST be set to 'disabled'? (if it's not the managed device...)
(3) is the intent that olsrv2InterfaceAdminStatus objects
        take on a value of 'disabled' as an automatic side-effect
of olsrv2AdminStatus becoming 'disabled', or does this
side-effect only happen olsrv2AdminStatus has been set to
'disabled' by an SNMP setRequest, or does the "must" mean
that the manager is required to explicitly issue setRequests
for all those olsrv2InterfaceAdminStatus Objects?
(4) The DESCRIPTION of olsrv2InterfaceAdminStatus gives
additional meaning to 'disabled'.  When, after having been
disabled, olsrv2AdminStatus is subsequently set to 'enabled',
is explicit management action required to re-enable the
various instances of olsrv2InterfaceAdminStatus?

Issue RMP-055
Location: olsrv2IfTcMessageRecvd  OBJECT-TYPE
Issue: does this include messages that are ignored
   due to OSLRv2 protocol procedures?
Location: olsrv2IfTcMessageRecvdAccumulatedSize  OBJECT-TYPE
Issue: Should specify whether this includes payloads excluded
due to syntax errors or ignored due the protocols
other procedures.

Issue RMP-056
Issue: In some cases the indexing structure does not appear to provide
any support for intelligent retrieval of table contents.
Did the working group go through the use cases they
intended these tables to support to determine whether
the indexing structure made sense?

Randy

---

From: Benoit Claise <[email-masked]>
Date: Tue, 28 May 2013 18:14:33 +0200

Hi Randy, Bob

One clarification please
> Suggestion: remove the ambiguity.
Since we deal with an AUGMENT in this case, isn't it obvious that the 
objects are identical?
The new text reads like this:

    OLSRv2 depends on the neighborhood information that is discovered by
    [RFC6130  <https://tools.ietf.org/html/rfc6130>].  In order to access the Objects relating to discovered
    neighbors, the State Group tables of the NHDP-MIB [RFC6779  <https://tools.ietf.org/html/rfc6779>] module
    are aligned with this MIB module.  This is accomplished through the
    use of the AUGMENTS capability of SMIv2 and the definition of
    TEXTUAL-CONVENTIONS in the NHDP-MIB module: specifically the
    NeighborRouterIndex.  These object types are used to develop indexes
    into common NHDP-MIB module and routing protocol State Group tables.
    The values of these objects and the semantics of each individual
    value SHOULD be identical for the two MIB modules within a given SNMP
    context.This will allow for improved cross referencing of
    information across the two MIB modules within a given SNMP context.

Maybe I don't understand the meaning of "The values of these objects and 
the semantics of each individual value"

Regards, Benoit

---

From: "Cole, Robert G CIV USARMY CERDEC (US)" <[email-masked]>
Date: Tue, 28 May 2013 19:44:26 +0000

Classification: UNCLASSIFIED
Caveats: NONE

Benoit,

Not all the tables in the olsrv2-mib are augments to the nhdp-mib.  There
are some new tables in the olsrv2-mib as well.  Specifically, the
olsrv2TibAdRemoteRouterSetTable uses an index of syntax '
NeighborRouterIndex'.  I interpreted Randy's concerns as related to the use
of the NeighborRouterIndex in this table and in the nhdp-mib to ensure
consistency of indices.  It sounds as if my text changes need some further
clarifications.

Thanks,
Bob

Robert G. Cole
Comm:  443.395.8744
Email: [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Benoit Claise
Sent: Tuesday, May 28, 2013 12:15 PM
To: Randy Presuhn; Robert G. Cole
Cc: [email-masked]; [email-masked]
Subject: Re: [MIB-DOCTORS] MIB doctor review of
draft-ietf-manet-olsrv2-mib-08.txt

Hi Randy, Bob

One clarification please

	Issue RMP-050

   OLSRv2 depends on the neighborhood information that is discovered by
   [RFC6130 <https://tools.ietf.org/html/rfc6130> ].  In order to access the
Objects relating to discovered
   neighbors, the State Group tables of the NHDP-MIB [RFC6779
<https://tools.ietf.org/html/rfc6779> ] module
   are aligned with this MIB module.  This is accomplished through the
   use of the AUGMENTS capability of SMIv2 and the definition of
   TEXTUAL-CONVENTIONS in the NHDP-MIB module: specifically the
   NeighborRouterIndex.  These object types are used to develop indexes
   into common NHDP-MIB module and routing protocol State Group tables.
   The values of these objects and the semantics of each individual
   value SHOULD be identical for the two MIB modules within a given SNMP
   context.  This will allow for improved cross referencing of
   information across the two MIB modules within a given SNMP context.
Maybe I don't understand the meaning of "The values of these objects and the
semantics of each individual value"

Regards, Benoit   

Classification: UNCLASSIFIED
Caveats: NONE