Note: This ballot was opened for revision 07 and is now closed.
Summary: Has enough positions to pass.
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 http://www.ietf.org/id-info/checklist :
** 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
RFCYYYY -> RFC YYYY
RFCXXXX -> RFC XXXX
* 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. *
Location olsrv2THoldTime 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.
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.
Location: olsrv2IibLinkSetEntry OBJECT-TYPE
Text: (L_in_metric, L_out_metric, L_mpr_selector)"
Location: olsrv2IibLinkSetInMetric OBJECT-TYPE
Location: olsrv2IibLinkSetOutMetric OBJECT-TYPE
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
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
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
Location: olsrv2TibRouterTopologySetToOrigIpAddr OBJECT-TYPE
Location: olsrv2TibRouterTopologySetSeqNo OBJECT-TYPE
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
Location: olsrv2TibRoutableAddressTopologySetDestIpAddr OBJECT-TYPE
Location: olsrv2TibRoutableAddressTopologySetSeqNo OBJECT-TYPE
Location: olsrv2TibRoutableAddressTopologySetMetric OBJECT-TYPE
Location: olsrv2TibAttNetworksSetEntry OBJECT-TYPE
Text: (AN_orig_addr, AN_net_addr, AN_seq_number,
AN_dist, AN_metric, AN_time)"
Location: olsrv2TibAttNetworksSetOrigIpAddr OBJECT-TYPE
Location: olsrv2TibAttNetworksSetNetIpAddr OBJECT-TYPE
Location: olsrv2TibAttNetworksSetSeqNo OBJECT-TYPE
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.
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: 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?
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 -
SNMPv3 is RECOMMENDED, but not REQUIRED
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
- 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
- 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