Definition of Managed Objects for the Optimized Link State Routing Protocol Version 2
draft-ietf-manet-olsrv2-mib-12
Yes
(Adrian Farrel)
No Objection
(Barry Leiba)
(Brian Haberman)
(Gonzalo Camarillo)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Pete Resnick)
(Richard Barnes)
(Stewart Bryant)
Note: This ballot was opened for revision 07 and is now closed.
Adrian Farrel Former IESG member
Yes
Yes
(for -07)
Unknown
Benoît Claise Former IESG member
(was No Objection)
Yes
Yes
(2013-05-29 for -09)
Unknown
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. 1. 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: 2. 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. * 3. 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. 4. 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. 5. 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. 6. 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?
Barry Leiba Former IESG member
No Objection
No Objection
(for -08)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(for -07)
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -09)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -09)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -07)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -07)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(for -09)
Unknown
Richard Barnes Former IESG member
No Objection
No Objection
(for -09)
Unknown
Sean Turner Former IESG member
(was Discuss)
No Objection
No Objection
(2013-05-09 for -08)
Unknown
Thanks for being so quick to resolve my discuss.
Spencer Dawkins Former IESG member
No Objection
No Objection
(2013-05-30 for -09)
Unknown
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
Stephen Farrell Former IESG member
No Objection
No Objection
(2013-05-30 for -09)
Unknown
- 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 MANET? - 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 check.)
Stewart Bryant Former IESG member
No Objection
No Objection
(for -07)
Unknown