[manet] Fwd: initial responses to: MIB doctor review of draft-ietf-manet-olsrv2-mib-08.txt

[Ulrich Herberg <[e-mail]>]

FYI: We submitted a new revision of the OLSRv2-MIB document,
addressing most comments from the Mib doctor review. We would like to
thank Randy Presuhn, who provided an extremely valuable and detailed
review.

Ulrich


---------- Forwarded message ----------
From: Cole <[e-mail]>
Date: Sat, May 25, 2013 at 3:49 PM
Subject: initial responses to: MIB doctor review of
draft-ietf-manet-olsrv2-mib-08.txt
To: Randy Presuhn <[e-mail]>, [e-mail],
Benoit Claise <[e-mail]>
Cc: Ulrich Herberg <[e-mail]>, Thomas Clausen
<[e-mail]>


Randy, Adrian, Benoit,

We have taken an initial pass at Randy's extensive review of the
draft-ietf-manet-olsrv2-mib-08 and have posted for your review a new
version draft-ietf-manet-olsrv2-mib-09.  That said we have a few todos
and questions for Randy.  Specifically,

We have addressed 52 of the 56 comments/questions.  We detail our
responses below.  But we have a few questions regarding the remaining:

+ RMP-012 -- we are in discussion on whether the 'olsrv2THoldTime'
object is indeed required to fit the constraints of the
exponent-mantissa notation in RFC 5497.  We will resolve this question
early this coming week.

+ RMP-033 -- regarding labels from the OLSRv2 specification referenced
in the MIB.  This list is extensive.  I'll take care of this by early
next week.  But I did not want this to hold us up in getting back to
you on the other issues.

+ RMP-036 -- regarding a TC for the OLSRv2 metric definitions.  I am
not sure exactly how to craft such a TC?  Any guidance would be
greatly appreciated.

+ RMP-056 -- regarding intelligent indexing.  Short answer is that the
WG did not go thru use cases.  We, the authors, did go back and forth
on several of the tables on the way to best index them, i.e., we had
several of the tables indexed via the (ipAddrType, ipAddr) index,
which I suspect gets to your question.  What specific Tables come to
mind that you would want us to reconsider the indexing?

Thanks,
Bob, Ulrich and Thomas.

--------------------------------------------------------
On Fri, May 17, 2013 at 10:58 PM, Randy Presuhn
<[e-mail]> wrote:
>
> 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.


See RMP-002


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


We have changed these to Unsigned32 and have assigned value=0 to UNKNOWN_METRIC.


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



Fixed the indexing


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


Fixed


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


Good catch. Fixed.


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


Fixed.


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


Changed this for not only for TimeStamps
but - for consistency reasons - for the message intervals as well.


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


Yes, good point. We added text to these DESCRIPTIONS.



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


yes. We added a discussion of Table AUGMENTs.


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


We deleted the two sentences.

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


We added the suggested sentence.

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


 TODO - pending further investigation.

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


We agree. Fixed

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


Okay, changed.


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


Thanks, fixed!

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


Thanks, fixed.

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


Fixed.

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


For some of the cases, it is lower case (for the imported constraints
from OLSRv2, which itself sets to constraints, not the MIB document).
But there were several cases where indeed it should have been RFC2119.
We changed that.

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


Correct. Fixed.

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


Agreed, fixed.

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


We made these changes to the DESCRIPTIONs.


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


Fixed.

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


We worked on the rewording, but not sure we caught all of your concerns?

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


Fixed.

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


Fixed.

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


That was a copy&paste error. Fixed now.


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


Fixed.

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


Fixed.


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

Fixed.

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


Fixed.

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


We made these changes.

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


Changed for indexes

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


TODO - working this one.

>
> 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,"


Fixed.

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


Agreed. Added a WillingnessTC.  Please check this out?

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


Agreed.  Looking for some help/suggested wording for such a TC?

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


Okay, done.

> Location: page 65
> Text: -- olsrv2NotificationStates
> Issue: this comment isn't helpful at all.
> Suggestion: delete it


deleted

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


Fixed.

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


Fixed.

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


Fixed.


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


Agreed.  We updated (hopefully improved) the DESCRIPTIONs on both the
olsrv2InterfaceAdminStatus and the olsrv2Admin Status to address these issues.

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


Changed to "This is the originator IP address of the neighbor
          represented by this table entry."

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


Fixed.

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


Added text to clarify.  Pulled description from olsrv2 draft.

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


Fixed

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


Fixed (we think).  Added text to the effect of 'router with
AN_orig_addr of type ....'.


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


Fixed.

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


Fixed.


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


Fixed.

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


Fixed.

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


Fixed.


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


After some discussion between the authors of the MIB and the protocol,
we are content with leaving this description as is.


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


Fixed.

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


Fixed.  We modified the text here (and elsewhere in the MIB).  The
intent is not to preclude other management interfaces such as CLI
(now) or NETCONF (down the road).

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


Fixed this by added text to the DESCRIPTION addressing your concerns.
However, these may change depending upon the resolution to RMP-056.

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


We added to the DESCRIPTION regarding this.  But primarily we point
the developers to
specific Sections within the olsrv2 draft which holds extensive
discussions of the management of these tables.

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


Clarified the appropriate behavior in the descriptions of the
AdminStatus object and the InterfaceAdminStatusTable.


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


Clarified the descriptions.  Excluding messages discarded due to
errors or protocol procedures for both of these.


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


Pending your response?