Re: [MIB-DOCTORS] comments on draft-ietf-manet-report-mib-04

Hi Benoit,

This review of the report MIB was not intended to be the MIB Doctor's revie=
w.  The module has not reached WG last call.

Instead, I wanted someone with DISMAN knowledge to review the structure of =
the MIB to ensure its design leverages (correctly) the
Capabilities from the DISMAN MIB Modules and provides the desired functiona=
lity.   Further, the WG has not put a lot of eyes on the module development=
 and we have gone through a lot of major revisions to get to this point whe=
re we are using existing DISMAN capabilities.

I will clean up the MIB (based upon Randy's detailed comments) and ensure i=
t passes a MIB compiler in the next revision.

Thanks, Bob

US Army CERDEC
QUEST Program, S&TCD
APG, MD

(c) 443.910.4420
(o) 443.395.8744
[email protected]

> -----Original Message-----
> From: MIB-DOCTORS [mailto:[email protected]] On Behalf Of Beno=
it Claise
> Sent: Tuesday, April 21, 2015 4:08 AM
> To: Randy Presuhn; [email protected]
> Cc: [email protected]; [email protected]
> Subject: Re: [MIB-DOCTORS] comments on draft-ietf-manet-report-mib-04
>=20
> Thanks Randy for your time.
>=20
> draft-ietf-manet-report-mib authors,
> What really concerns me is Randy's comment: "It's pretty obvious that thi=
s module has not seen a MIB compiler recently."
> This is inappropriate to ask for a MIB doctor review for a MIB module tha=
t doesn't even compile.
>=20
> Regards, Benoit
> > Hi -
> >
> > I was asked to take a look at draft-ietf-manet-report-mib-04.
> > This is *not* a full MIB doctor review; in my opinion some fundamental
> > issues need to be resolved before a detailed review (either from a MIB
> > doctor or disman perspective) would be worthwhile.
> >
> > These are mostly just top-level issues that absolutely need to be
> > resolved.  I fear that even though the questions aren't terribly
> > difficult, the fixes may result in significant document churn.  There
> > are also some odds and ends that jumped out that should be fixed
> > before bothering with a serious review. I didn't go into a lot of
> > detail because the sheer number of problems would make any such
> > attempt seem like a DoS attack.  The categories here are:
> >    (1) data type difficulties
> >    (2) time stamping
> >    (3) access control
> >    (4) odds and ends
> >    (5) questions of power
> >
> > Data Type Difficulties
> >
> >    Location: Abstract and elswhere
> >
> >    Example of Current text:
> >      In particular, it describes objects for configuring autonomous rep=
ort
> >      generation on any device that supports MIBs containing objects tha=
t
> >      resolve to type Integer32 (i.e., Integer32, Counter, Gauge, or
> >      TimeTicks). to be used for performance monitoring.
> >
> >    Problems:
> > 	- typographical nit: misplaced "." after ")"
> >          - technical: "Counter" is not an SMIv2 type.  I assume
> >                       "Counter32" is intended.  If inclusion of
> >                       Counter64 is also intended, there are other probl=
ems.
> >          - technical: "Gauge" is not an SMIv2 type.  I assume
> >                       "Gauge32" is intended.
> > 	- technical:  the range of type Integer32 (defined in RFC 2578)
> >                        does not cover the entire ranges of type Counter=
32,
> >                        Gauge32, or TimeTicks, as defined in RFC 3416.
> >                        The SMI type *Unsigned32* does cover the same ra=
nges.
> > 	- technical: the use of "resolve" is questionable, since all
> >                       of the data types mentioned have distinct ASN.1
> >                       tags.  (RFC 3416 section 3)
> >
> >    It gets worse.  The definitions for reportSampledCurrentMeasurementV=
alue
> >    and reportSampledHistoricalReportsValue limit their ranges to
> >    1 to 2,147,483,647.  This means that samples of Counter32, Gauge32,
> >    and TimeTicks with values of 0 or anything in the range from
> >    2,147,483,647 to 4,294,967,295 cannot be represented.
> >
> >    The reportSampledCurrentMeasurementStatus and the
> >    reportSampledHistoricalMeasurementStatus OBJECT-TYPEs appear
> >    to be an attempt to address this problem, and would *almost*
> >    work if the MeasurementValue were of type Unsigned32, and
> >    if its range were not constrained.  However, if the module
> >    functioned as though sampled data, regardless of type, were
> >    "cast" to Unsigned32, then the valuePositive(2) and valueNegative(3)
> >    aren't really needed, since the signedness of the sampled values
> >    can be recovered from reportSampledStudyOid.
> >
> >
> > Time Stamping
> >    There are a bunch of concerns related to time stamping.
> >
> >    - several OBJECT-TYPE definitions have impossible syntaxes.
> >      "sysUptime" is not a syntax.  It should not be IMPORTed.
> >      For reportSampledCurrentMeasurementTime and for
> >      reportSampledHistoricalMeasurementTime you intend to
> >      use a syntax of "TimeStamp"
> >
> >    - HOWEVER, there is a health warning attached to the
> >      TimeStamp textual convention in RFC 2579, and it applies
> >      here.  Firstly, it applies because the set of values
> >      permitted for reportSampledStudySamplingInterval means
> >      it is possible to construct a single report in which
> >      the sample times are ambiguous.  More significantly,
> >      for historical reports, especially for "archival" purposes,
> >      the sample times are almost certainly ambiguous.  Consequently,
> >      I think there needs to be a re-think of whether this is
> >      the correct data type for the intended use.
> >
> >    - Many counter objects have "discontinuity indicators" other
> >      than sysUpTime. This module does not provide a straightforward
> >      way to cope with these.  See RFC 2981 (search for "discontinuity")
> >      to see one approach.
> >
> >    - reportSampledStudySamplingInterval may be modified during a
> >      report.  This means that conventional algorithms for detecting
> >      sysUpTime discontinuities within a report may not work.
> >
> > Access Control
> >    There are a couple of ways in which access control considerations
> >    might affect the design of this module.  The presence of
> >    reportSampledStudyOwner suggests that someone was thinking about
> >    this, but some changes are needed to make things work.
> >
> >      (1) reportSampledControlEntry should have an INDEX of
> >          { reportSampledStudyOwner, reportSampledStudyIndex }
> >          This is necessary if you want to be able to limit access
> >          to specific studies to specific users in a reasonable way,
> >          and to prevent collisions between users during the creation
> >          of studies.
> >
> >      (2) Likewise, reportSampledCurrentReportsStatusEntry should
> >          also have an INDEX of
> >          { reportSampledStudyOwner, reportSampledStudyIndex },
> >          reportSampledCurrentReportsEntry should have
> >          { reportSampledStudyIndex, reportSampledCurrentMeasurementInde=
x }
> >          reportSampledHistoricalReportsEntry should have
> >          { reportSampledStudyOwner, reportSampledStudyIndex,
> >            reportSampledHistoricalReportIndex,
> >            reportSampledHistoricalMeasurementIndex }
> >
> >      (3) A consequence is that (for example) reportSampledStudyIndex
> >          only needs to be unique for a given owner, and not among
> >          all studies.
> >
> >    Note that reportSampledDataCollectionFailure suffers from the
> >    "who's buried in Grant's Tomb" problem, and can be simplified.
> >
> >    A second way in which access control matters here is that the
> >    sampling process should not circumvent access control.  I strongly
> >    urge putting in explicit language about this.  I'd suggest the follo=
wing
> >    as a starting point for discussion:
> >
> >       Security for local access effectively requires recording appropri=
ate
> >       security credentials of the creator of a reportSampledControlEntr=
y
> >       and using those to access the local objects.  These security
> >       credentials are parameters necessary as inputs to isAccessAllowed
> >       from the Architecture for Describing SNMP Management Frameworks.
> >       The system MUST (conceptually) use isAccessAllowed at the time of
> >       each access (not just creation of the reportSampledControlEntry)
> >       to ensure that it does not permit unauthorized access.
> >
> >       When using VACM, the security administrator SHOULD ensure that
> >       access permitted to the collected data and notifications (that is=
,
> >       access to reportSampledCurrentReportsStatusTable.*.<user>,
> >       reportSampledCurrentReportsTable.*.<user>, and
> >       reportSampledHistoricalReportsTable.*.<user>) is
> >       limited to the <user>'s appropriate VACM group.
> >
> > Odds and ends:
> >    It's pretty obvious that this module has not seen a MIB compiler
> >    recently.  In addition to the syntactic problem, there are some
> >    glaring stylistic issues that, if fixed now, will make an eventual
> >    MIB doctor review go a lot smoother.
> >
> >     (1) Use of data types.  Every single use of Integer32 in this
> >         module is arguably incorrect.  Unsigned32 would be a better
> >         choice, since these are all sub-typed to exclude negative
> >         values.
> >
> >    (2) Use of data types.  reportSampledStudySamplingInterval
> >        seems like it should make use of RFC 2579 TimeInterval, perhaps
> >        constrained to be at least 10.
> >
> >    (3) Use of UNITS.  Though it's a little unusual (but not unheard-of)
> >        to use UNITS with non-counter types, a value of "count" in,
> >        for example, reportSampledStudyMaximumNumberOfHistoricalReports,
> >        is really not helpful.  In that particular case, "reports"
> >        would make more sense.
> >
> >    (4) Attention to error cases: there are a bunch of error situations
> >        that should be given a little attention.  What happens when
> >        there's no longer enough memory to keep accumulating studies?
> >        What happens when the object instance referred to by
> >        reportSampledStudyOid is the wrong data type?
> >
> >    (5) The use of non-volatile storage doesn't seem to have been
> >        completely thought through.  It doesn't make sense to me, for
> >        example, to have the control entries in backing storage, but
> >        not the "archival" historical data.  Likewise, if a control
> >        entry is restored from non-volatile upon reboot, does that
> >        cause a new report to be started or does it pick up where
> >        it left off on a existing report?
> >
> >    (6) Notification throttling.
> >
> > Questions of Power
> >    I think the decision to limit the module to local access is reasonab=
le
> >    given the intended applicability.  I do think, however, there should
> >    be a clear explanation of the rationale behind limiting its function=
ality
> >    to the current SNMP context, unlike RFC 1981.
> >
> >    I think it would be helpful to at least suggest how it is envisioned
> >    that future "statistical" functions alluded to in the text would wor=
k
> >    with this MIB module -   are they expected to be extensions of this
> >    module or completely new ones?
> >
> >    I honestly have some difficulty seeing what good this module would
> >    do; perhaps the WG has discussed concrete use cases, but don't be
> >    surpised if a future reviewer raises questions on this point.
> >
> > Randy
> >
> > _______________________________________________
> > MIB-DOCTORS mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/mib-doctors
> > .
> >
>=20
> _______________________________________________
> MIB-DOCTORS mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/mib-doctors