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

Benoit Claise <bclaise@cisco.com> Tue, 21 April 2015 08:07 UTC

Return-Path: <bclaise@cisco.com>
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 0E4791B3730; Tue, 21 Apr 2015 01:07:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 RcXiqAn7Lsfy; Tue, 21 Apr 2015 01:07:02 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6B541B372A; Tue, 21 Apr 2015 01:07:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10443; q=dns/txt; s=iport; t=1429603622; x=1430813222; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=XhBKRFVrqoMUHs9/LeDFACGANzNQTK+NpiMCg2S7XmE=; b=E53UElAZuHxUDN40HQME/vJGjr+whZ5oFeWVO+5uLrKod9g2/1k4SuQD AJ+OSMBv1n/VeSqYl72Q5KEUG3YeDPRikP9UOZG27JfeRuDcHXINwR4Ju h6pYu4bKuBu1+fKH4lrXXOnRsk+li9MGuglCBwPkOhURX/5iLj/jz9YJz s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BxFQCDBDZV/xbLJq1VBoNeXMYdgUUKC4V5AoF5EgEBAQEBAQF9QQODXQEBBAEBATU2CgEQCxIPFg8JAwIBAgEVIg4GAQwBBQIBAYgnDcoKAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLN4EjgwgBCQYGQweELQEEhGWKLYpDggKBIIYJijGDTiKBZBwegVc8MYECAR+BIgEBAQ
X-IronPort-AV: E=Sophos;i="5.11,614,1422921600"; d="scan'208";a="441632913"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 21 Apr 2015 08:06:59 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t3L86xHL019237; Tue, 21 Apr 2015 08:06:59 GMT
Message-ID: <55360555.4020403@cisco.com>
Date: Tue, 21 Apr 2015 10:07:49 +0200
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Randy Presuhn <randy_presuhn@mindspring.com>, manet@ietf.org
References: <18699062.1429399645552.JavaMail.root@mswamui-valley.atl.sa.earthlink.net>
In-Reply-To: <18699062.1429399645552.JavaMail.root@mswamui-valley.atl.sa.earthlink.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/disman/xoHKBZ6l_v2s47uTbmTsLxGAfQs>
Cc: mib-doctors@ietf.org, disman@ietf.org
Subject: Re: [Disman] [MIB-DOCTORS] 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: Tue, 21 Apr 2015 08:07:06 -0000

Thanks Randy for your time.

draft-ietf-manet-report-mib authors,
What really concerns me is Randy's comment: "It's pretty obvious that 
this module has not seen a MIB compiler recently."
This is inappropriate to ask for a MIB doctor review for a MIB module 
that doesn't even compile.

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 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
>
> _______________________________________________
> MIB-DOCTORS mailing list
> MIB-DOCTORS@ietf.org
> https://www.ietf.org/mailman/listinfo/mib-doctors
> .
>