Definition of Managed Objects for the Optimized Link State Routing Protocol Version 2

Note: This ballot was opened for revision 07 and is now closed.

(Benoît Claise) (was No Objection) Yes

Comment (2013-05-29 for -09)
No email
send info
The list of comments is the ongoing discussion points between the MIB doctor, the authors, and myself. For documentation purposes only before the IESG telechat, while the good discussion continues via email.


6.2. Relationship to the NHDP-MIB

   OLSRv2 depends on the neighborhood information that is discovered by
   [RFC6130].  In order to access the Objects relating to discovered
   neighbors, the State Group tables of the NHDP-MIB [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.

Clarify what the "The values of these objects" is:

Checking nits according to :

  ** There is 1 instance of lines with control characters in the document.

- Most probably, the RFC editors will pick that up, but since I spotted it.
In the following, replace

 * 1) The reference to RFCYYYY within the DESCRIPTION clauses  *
   * of the MIB module point to this draft and are to be         *
   * assigned by the RFC Editor.                                 *
   *                                                             *
   * 2) The reference to RFCXXXX throughout this document point  *
   * to the current draft-ietf-manet-olsrv2-xx.txt.  This        *
   * needs to be replaced with the XXXX RFC number for the       *
   * OLSRv2 publication.                                         *

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.

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-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-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?

(Adrian Farrel) Yes

(Jari Arkko) No Objection

(Richard Barnes) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Spencer Dawkins) No Objection

Comment (2013-05-30 for -09)
No email
send info
I'm a No Objection, but I am somewhat confused about the Security Considerations section, which if I'm reading it correctly can be summarized as 

- this protocol is often used in tactical applications where, if you screw up security, people can die
- older versions of SNMP had security problems

Am I misreading the text? Is it obvious to users of the protocol (and the related MIB) what the tradeoffs are? 

I'm assuming this isn't intended to be "SNMPv3 is RECOMMENDED unless you already have a working SNMPv2c implementation and you'd rather spend engineering resources on something else" :D

(Stephen Farrell) No Objection

Comment (2013-05-30 for -09)
No email
send info
- intro: I think section 9 is important here and could
be either moved up or else maybe add a sentence to the
intro saying that section 9 tells you when this might
be useful/reasonable.

- WillingnessTC - Nice. Should you add "happy to throw
car-keys into the bowl" as well?  Even nicer, you then
say: "The williness ranges..." Please make no change
so as to amuse future RFC readers who're as easily
amused by adolescent word-play as me:-)

(BTW, I also doubt that this'll be very useful since
its too fine-grained but will be happy and interested
to hear if your experience shows me to be wrong.)

- p12, s/HNDP/NHDP/ ?

- p21, repeated text in the definition of
olsrv2FHoldTime and how is someone writing this value
supposed to know the time require to traverse the

- p46 (and elsewhere): 16777215 is a LOT. Makes me
wonder if there's a DoS vector there somewhere.

- p77 s/privacy/confidentiality/ but does SNMP
security even do that? (Sorry, didn't have time to

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

(Barry Leiba) No Objection

(Pete Resnick) No Objection

(Martin Stiemerling) No Objection

(Sean Turner) (was Discuss) No Objection

Comment (2013-05-09 for -08)
No email
send info
Thanks for being so quick to resolve my discuss.