Definition of Managed Objects for the Optimized Link State Routing Protocol Version 2
draft-ietf-manet-olsrv2-mib-12

[Ballot comment]
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

[Ballot comment]

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

[Ballot comment]
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?

[Ballot discuss]
Revised (I think this might just be a ctrl-x/ctrl-v issue but was asked to provide a little more rationale on my discuss)

The 2nd to last paragraph in this document:

  It is RECOMMENDED that implementers consider the security
  features as provided by the SNMPv3 framework (see [RFC3410],
  Section 8, including full support for the SNMPv3
  cryptographic mechanisms (for authentication and privacy).

differs somewhat from what I thought was last agreed with the MIB doctors (and what's in RFC 6779):

  Implementations SHOULD provide the security features
  described by the SNMPv3 framework (see [RFC3410]),
  and implementations claiming compliance to the SNMPv3
  standard MUST include full support for authentication
  and privacy via the User-based Security Model (USM)
  [RFC3414] with the AES cipher algorithm [RFC3826].
  Implementations MAY also provide support for the
  Transport Security Model (TSM) [RFC5591] in combination
  with a secure transport such as SSH [RFC5592] or TLS/DTLS
  [RFC6353].

My primary issue here is that a requirement to "consider" is not the same an MTI (mandatory to implement).  Further, the RFC 3414 mechanisms referred to in RFC 3410 for authentication are HMAC-based and for privacy are CBC-DES-based. Don't really have a problem with the authentication protocols (see RFC 6151 and 6194) but I do have a really big problem with the CBC-DES-based privacy mechanism.  The reworded boiler plate takes in to account the AES-based privacy mechanism RFC 3414 refers to as a draft.  I can not believe you'd really use a DES-based mechanism instead of the AES-based mechanism and if you are I'd like to see some text about that.

The bit about the TSM is a nod to reality about how the data will be gathered.  I'm guessing here but I suspect that SSH is used with the router so you could just say SSH is required as opposed to the current wishy washy one or the approach in the new boiler plate.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-manet-olsrv2-mib-06.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

In the SMI Network Management MGMT Codes Internet-standard MIB (iso.org.dod.internet.mgmt.mib-2) sub-registry of the Network Management Parameters registry located at:

http://www.iana.org/assignments/smi-numbers

a new MIB will be registered as follows:

Decimal: [ TBD by IANA at time of registration ]
Name: OLSRv2-MIB
Description: Optimized Link State Routing Protocol version 2
References: [ RFC-to-be ]

IANA understands this to be the only action required of IANA upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Definition of Managed Objects for the Optimized Link State Routing Protocol version 2) to Proposed Standard


The IESG has received a request from the Mobile Ad-hoc Networks WG
(manet) to consider the following document:
- 'Definition of Managed Objects for the    Optimized Link State Routing
  Protocol version 2'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-04-23. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

  This document defines the Management Information Base (MIB) module
  for configuring and managing the Optimized Link State Routing
  protocol version 2 (OLSRv2).  The OLSRv2-MIB module is structured
  into state information, performance metrics, and notifications.  This
  additional state and performance information is useful to
  troubleshoot problems and performance issues of the routing protocol.
  Different levels of compliance allow implementers to use smaller
  subsets of all defined objects, allowing for this MIB module to be
  deployed on more constrained routers.


The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-mib/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-mib/ballot/


No IPR declarations have been submitted directly on this I-D.

Further AD review comment
====

Ooops,

I just ran idnits. Looks like the references are in a bit of a mess as well.

  [OLSRv2]      Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
                "The Optimized Link State Routing Protocol version 2",
                draft-ietf-manet-olsr-17 (work in progress),
                October 2012.
*** should read draft-ietf-manet-olsrv2

Do you really need a normative reference to RFC 3781? This is a Downref (which we can handle if necessary), but I don't see why it is referenced.

Because these both show as Downrefs, and because Downrefs get called out in IETF last call, I need an answer to these points before I can go forward. If answering them involves respinning the document, then it would be good to pick up the other points as well.

Thanks,
Adrian

AD Review
====

Thanks for your work on this document, and sorry for the long time it
has taken me to review it. it looks like you have done a really
thorough job - I can normally pick a few holes in a MIB

I think the only big question we are going to get (again) is about the
level of write (and create) access. Do you think that it would be
helpful to add an Informational reference to
draft-nguyen-manet-management-00 and some discussion in the document
about why you have some level of write access? Maybe this is just a
little more text in Section 9.

I think you should think about this while I run the IETF last call.
That will attract an OPS Dir review that may dwell on the point further.

---

My other comments are quite small and can all be taken as IETF last call
comments to be fixed later...



The RFC Editor might become confused by the different uses of "XXXX"
in the document. It would be worth sorting them out just to make life
easier.

---

Tiny point...

In olsrv2AHoldTime you have...
              a value = 3 x olsrv2TcInterval is
              recommended.
But in draft-ietf-manet-olsrv2-15 you have
      a value >= 3 x
      TC_INTERVAL is RECOMMENDED.

---

I think olsrv2LinkMetricType needs to be mentioned in Section 8 because,
according to Section 5.5 of draft-ietf-manet-olsrv2-19, the consequences
of a change are quite significant.

---

Possibly just me being puzzled:

Are you sure that olsrv2TibRoutableAddressTopologySetIndex can really be
limited to Integer32 (0..65535)?  I agree that larger would be a great
validation of OLSRv2, but I wondered how quickly we might reach that
threshold.

Ditto olsrv2TibRouterTopologySetIndex

Changes are expected over time. This version is dated January 9, 2013.
(1.a) Stan Ratliff (sratliff@cisco.com) is the document shepherd for this document. The shepherd has personally reviewed the document, and believes it is ready for forwarding to the IESG for publication.
(1.b) The document has had adequate review from both key working group members and from key non-WG members. The shepherd does not have any concerns about the depth or breadth of the reviews that have been performed.
(1.c) The shepherd does not have any concerns about the document needing additional review.
(1.d) The shepherd does not have any concerns or issues with the document that the responsible Area Director or the IESG need to be aware of. IPR disclosures were not necessary, therefore, none have been filed.
(1.e) Working group consensus behind this document is solid. The document represents strong concurrence of the working group as a whole, the the WG understands and agrees with the document.
(1.f) No one has threatened appeal or has indicated discontent with the document.
(1.g) The document shepherd has run the "idnits" tool against the document. The document has met all required formal review criteria.
(1.h) The document has split its references into normative and informative. There is a normative reference to draft-ietf-manet-olsrv2-17, which is currently in IESG evaluation, with  one DISCUSS but enough votes to pass, once the DISCUSS is resolved. The shepard is confident that OLSRv2 will be published soon. Other than that, to the shepherd's knowledge, there are no normative references to documents that are not ready for advancement or are in an unclear state. There are no downward references.
(1.i) The shepherd has verified that document IANA consideration section exists, and is consistent with the body of the document. No protocol extensions are requested. The necessary IANA registries are clearly defined. No new registries are requested. No expert review has been requested.
(1.j) The document has been run through the "smilint" checker. Warnings exist due to references to "FLOAT-TC-MIB", however, those references appear to be due to a deficiency of the tool (e.g., RFC6340 is 'too new' to be in view by the tool).
(1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:
  Technical Summary This document defines a portion of the Management Information Base (MIB) for use with the Optimized Link State Routing Protocol version 2 developed in the MANET working group.
  Working Group Summary The process for reaching working group consensus on this was smooth; no controversy existed. Working group consensus behind the document is solid.
  Document Quality This document shepherd is not aware of existing implementations of this MIB. Review by MIB doctor was discussed within the working group, however, the WG consensus was that this review was unnecessary, as the WG contains sufficient expertise to determine applicability of all objects, and correctness of the MIB.