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

"Cole, Robert G CIV USARMY CERDEC (US)" <robert.g.cole.civ@mail.mil> Mon, 20 April 2015 13:31 UTC

Return-Path: <robert.g.cole.civ@mail.mil>
X-Original-To: disman@ietfa.amsl.com
Delivered-To: disman@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46C81B2B72; Mon, 20 Apr 2015 06:31:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbs1YSm4E29P; Mon, 20 Apr 2015 06:31:48 -0700 (PDT)
Received: from upbd19pa13.eemsg.mail.mil (upbd19pa13.eemsg.mail.mil [214.24.27.88]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB4E1B2B6E; Mon, 20 Apr 2015 06:31:47 -0700 (PDT)
Received: from edge-eurd01.mail.mil ([214.24.180.6]) by upbd19pa13.eemsg.mail.mil with ESMTP; 20 Apr 2015 13:31:39 +0000
Received: from UPDCHU27.easf.csd.disa.mil (214.24.180.159) by edge-eurd01.mail.mil (214.24.180.6) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 20 Apr 2015 13:31:46 +0000
Received: from UCOLHPM7.easf.csd.disa.mil (131.64.104.32) by UPDCHU27.easf.csd.disa.mil (214.24.180.159) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 20 Apr 2015 13:31:40 +0000
Received: from UCOLHPKT.easf.csd.disa.mil ([169.254.2.143]) by UCOLHPM7.easf.csd.disa.mil ([131.64.104.32]) with mapi id 14.03.0224.002; Mon, 20 Apr 2015 13:29:07 +0000
From: "Cole, Robert G CIV USARMY CERDEC (US)" <robert.g.cole.civ@mail.mil>
To: Randy Presuhn <randy_presuhn@mindspring.com>, "manet@ietf.org" <manet@ietf.org>
Thread-Topic: comments on draft-ietf-manet-report-mib-04
Thread-Index: AQHQei9Fiv92wK/hwkWBi6jwuYs6iJ1V4VdA
Date: Mon, 20 Apr 2015 13:29:07 +0000
Message-ID: <B9468E58D6A0A84AAD66FE4E694BEABB8504BEC9@ucolhpkt.easf.csd.disa.mil>
References: <18699062.1429399645552.JavaMail.root@mswamui-valley.atl.sa.earthlink.net>
In-Reply-To: <18699062.1429399645552.JavaMail.root@mswamui-valley.atl.sa.earthlink.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [131.64.22.15]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/disman/ObN7M5fAVWAR06i_kLeAZRGcQB0>
X-Mailman-Approved-At: Mon, 20 Apr 2015 10:49:31 -0700
Cc: "mib-doctors@ietf.org" <mib-doctors@ietf.org>, "disman@ietf.org" <disman@ietf.org>
Subject: Re: [Disman] comments on draft-ietf-manet-report-mib-04
X-BeenThere: disman@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Management <disman.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/disman>, <mailto:disman-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/disman/>
List-Post: <mailto:disman@ietf.org>
List-Help: <mailto:disman-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/disman>, <mailto:disman-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Apr 2015 13:31:51 -0000

Randy,

I appreciate your detailed review.   I can start working through modifications to the module based upon your list of issues, but I am most concerned with your very last comment/paragraph.    If OK with you, I would first like to address your question on the utility of the module.  If that question cannot be answered in the positive, the rest of my efforts on fixing the module would be moot.

I'll write up a justification for the module, to be placed in the introductory text.  Only when it passes (on not) your approval and that of the WG, then I'll proceed with the rest of the comments and modifications.  Does this seem reasonable?

Thanks, Bob


> -----Original Message-----
> From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]
> Sent: Saturday, April 18, 2015 7:27 PM
> To: manet@ietf.org
> Cc: Cole, Robert G CIV USARMY CERDEC (US); disman@ietf.org; mib-doctors@ietf.org
> Subject: comments on draft-ietf-manet-report-mib-04
> 
> 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 report
>     generation on any device that supports MIBs containing objects that
>     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 problems.
>         - 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 Counter32,
>                       Gauge32, or TimeTicks, as defined in RFC 3416.
>                       The SMI type *Unsigned32* does cover the same ranges.
> 	- 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 reportSampledCurrentMeasurementValue
>   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, reportSampledCurrentMeasurementIndex }
>         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 following
>   as a starting point for discussion:
> 
>      Security for local access effectively requires recording appropriate
>      security credentials of the creator of a reportSampledControlEntry
>      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 reasonable
>   given the intended applicability.  I do think, however, there should
>   be a clear explanation of the rationale behind limiting its functionality
>   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 work
>   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