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 > . >
- [Disman] comments on draft-ietf-manet-report-mib-… Randy Presuhn
- Re: [Disman] comments on draft-ietf-manet-report-… Cole, Robert G CIV USARMY CERDEC (US)
- Re: [Disman] [MIB-DOCTORS] comments on draft-ietf… Randy Presuhn
- Re: [Disman] [MIB-DOCTORS] comments on draft-ietf… Benoit Claise
- Re: [Disman] [MIB-DOCTORS] comments on draft-ietf… Cole, Robert G CIV USARMY CERDEC (US)
- Re: [Disman] [MIB-DOCTORS] comments on draft-ietf… Randy Presuhn