From nobody Sat Apr 18 16:32:05 2015 Return-Path: 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 5DA811AC3C1; Sat, 18 Apr 2015 16:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 gqjgxMhc4o7I; Sat, 18 Apr 2015 16:27:27 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id F0DF71AC3BB; Sat, 18 Apr 2015 16:27:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=nvKq1/R6DzrBB1K0kTeBR7R8A51sCHIL6PtohBM7RDKDwUeabifUT37ebs+31NzV; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.52] (helo=mswamui-valley.atl.sa.earthlink.net) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Yjc8z-00037y-Kv; Sat, 18 Apr 2015 19:27:25 -0400 Received: from 76.254.50.248 by webmail.earthlink.net with HTTP; Sat, 18 Apr 2015 19:27:25 -0400 Message-ID: <18699062.1429399645552.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> Date: Sat, 18 Apr 2015 16:27:25 -0700 (GMT-07:00) From: Randy Presuhn To: manet@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b65b6112f8911537d81312d8c217761dde4d378d2d5f2c5a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.52 Archived-At: X-Mailman-Approved-At: Sat, 18 Apr 2015 16:32:03 -0700 Cc: "Cole, Robert G CIV USARMY CERDEC \(US\)" , disman@ietf.org, mib-doctors@ietf.org Subject: [Disman] comments on draft-ietf-manet-report-mib-04 X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2015 23:27:29 -0000 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.*., reportSampledCurrentReportsTable.*., and reportSampledHistoricalReportsTable.*.) is limited to the '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 From nobody Mon Apr 20 10:49:33 2015 Return-Path: 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)" To: Randy Presuhn , "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: 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: X-Mailman-Approved-At: Mon, 20 Apr 2015 10:49:31 -0700 Cc: "mib-doctors@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 13:31:51 -0000 UmFuZHksDQoNCkkgYXBwcmVjaWF0ZSB5b3VyIGRldGFpbGVkIHJldmlldy4gICBJIGNhbiBzdGFy dCB3b3JraW5nIHRocm91Z2ggbW9kaWZpY2F0aW9ucyB0byB0aGUgbW9kdWxlIGJhc2VkIHVwb24g eW91ciBsaXN0IG9mIGlzc3VlcywgYnV0IEkgYW0gbW9zdCBjb25jZXJuZWQgd2l0aCB5b3VyIHZl cnkgbGFzdCBjb21tZW50L3BhcmFncmFwaC4gICAgSWYgT0sgd2l0aCB5b3UsIEkgd291bGQgZmly c3QgbGlrZSB0byBhZGRyZXNzIHlvdXIgcXVlc3Rpb24gb24gdGhlIHV0aWxpdHkgb2YgdGhlIG1v ZHVsZS4gIElmIHRoYXQgcXVlc3Rpb24gY2Fubm90IGJlIGFuc3dlcmVkIGluIHRoZSBwb3NpdGl2 ZSwgdGhlIHJlc3Qgb2YgbXkgZWZmb3J0cyBvbiBmaXhpbmcgdGhlIG1vZHVsZSB3b3VsZCBiZSBt b290Lg0KDQpJJ2xsIHdyaXRlIHVwIGEganVzdGlmaWNhdGlvbiBmb3IgdGhlIG1vZHVsZSwgdG8g YmUgcGxhY2VkIGluIHRoZSBpbnRyb2R1Y3RvcnkgdGV4dC4gIE9ubHkgd2hlbiBpdCBwYXNzZXMg KG9uIG5vdCkgeW91ciBhcHByb3ZhbCBhbmQgdGhhdCBvZiB0aGUgV0csIHRoZW4gSSdsbCBwcm9j ZWVkIHdpdGggdGhlIHJlc3Qgb2YgdGhlIGNvbW1lbnRzIGFuZCBtb2RpZmljYXRpb25zLiAgRG9l cyB0aGlzIHNlZW0gcmVhc29uYWJsZT8NCg0KVGhhbmtzLCBCb2INCg0KDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFJhbmR5IFByZXN1aG4gW21haWx0bzpyYW5keV9wcmVz dWhuQG1pbmRzcHJpbmcuY29tXQ0KPiBTZW50OiBTYXR1cmRheSwgQXByaWwgMTgsIDIwMTUgNzoy NyBQTQ0KPiBUbzogbWFuZXRAaWV0Zi5vcmcNCj4gQ2M6IENvbGUsIFJvYmVydCBHIENJViBVU0FS TVkgQ0VSREVDIChVUyk7IGRpc21hbkBpZXRmLm9yZzsgbWliLWRvY3RvcnNAaWV0Zi5vcmcNCj4g U3ViamVjdDogY29tbWVudHMgb24gZHJhZnQtaWV0Zi1tYW5ldC1yZXBvcnQtbWliLTA0DQo+IA0K PiBIaSAtDQo+IA0KPiBJIHdhcyBhc2tlZCB0byB0YWtlIGEgbG9vayBhdCBkcmFmdC1pZXRmLW1h bmV0LXJlcG9ydC1taWItMDQuDQo+IFRoaXMgaXMgKm5vdCogYSBmdWxsIE1JQiBkb2N0b3IgcmV2 aWV3OyBpbiBteSBvcGluaW9uIHNvbWUgZnVuZGFtZW50YWwgaXNzdWVzIG5lZWQgdG8gYmUgcmVz b2x2ZWQgYmVmb3JlIGEgZGV0YWlsZWQgcmV2aWV3IChlaXRoZXINCj4gZnJvbSBhIE1JQiBkb2N0 b3Igb3IgZGlzbWFuIHBlcnNwZWN0aXZlKSB3b3VsZCBiZSB3b3J0aHdoaWxlLg0KPiANCj4gVGhl c2UgYXJlIG1vc3RseSBqdXN0IHRvcC1sZXZlbCBpc3N1ZXMgdGhhdCBhYnNvbHV0ZWx5IG5lZWQg dG8gYmUgcmVzb2x2ZWQuICBJIGZlYXIgdGhhdCBldmVuIHRob3VnaCB0aGUgcXVlc3Rpb25zIGFy ZW4ndCB0ZXJyaWJseQ0KPiBkaWZmaWN1bHQsIHRoZSBmaXhlcyBtYXkgcmVzdWx0IGluIHNpZ25p ZmljYW50IGRvY3VtZW50IGNodXJuLiAgVGhlcmUgYXJlIGFsc28gc29tZSBvZGRzIGFuZCBlbmRz IHRoYXQganVtcGVkIG91dCB0aGF0IHNob3VsZCBiZSBmaXhlZA0KPiBiZWZvcmUgYm90aGVyaW5n IHdpdGggYSBzZXJpb3VzIHJldmlldy4gSSBkaWRuJ3QgZ28gaW50byBhIGxvdCBvZiBkZXRhaWwg YmVjYXVzZSB0aGUgc2hlZXIgbnVtYmVyIG9mIHByb2JsZW1zIHdvdWxkIG1ha2UgYW55IHN1Y2gN Cj4gYXR0ZW1wdCBzZWVtIGxpa2UgYSBEb1MgYXR0YWNrLiAgVGhlIGNhdGVnb3JpZXMgaGVyZSBh cmU6DQo+ICAgKDEpIGRhdGEgdHlwZSBkaWZmaWN1bHRpZXMNCj4gICAoMikgdGltZSBzdGFtcGlu Zw0KPiAgICgzKSBhY2Nlc3MgY29udHJvbA0KPiAgICg0KSBvZGRzIGFuZCBlbmRzDQo+ICAgKDUp IHF1ZXN0aW9ucyBvZiBwb3dlcg0KPiANCj4gRGF0YSBUeXBlIERpZmZpY3VsdGllcw0KPiANCj4g ICBMb2NhdGlvbjogQWJzdHJhY3QgYW5kIGVsc3doZXJlDQo+IA0KPiAgIEV4YW1wbGUgb2YgQ3Vy cmVudCB0ZXh0Og0KPiAgICAgSW4gcGFydGljdWxhciwgaXQgZGVzY3JpYmVzIG9iamVjdHMgZm9y IGNvbmZpZ3VyaW5nIGF1dG9ub21vdXMgcmVwb3J0DQo+ICAgICBnZW5lcmF0aW9uIG9uIGFueSBk ZXZpY2UgdGhhdCBzdXBwb3J0cyBNSUJzIGNvbnRhaW5pbmcgb2JqZWN0cyB0aGF0DQo+ICAgICBy ZXNvbHZlIHRvIHR5cGUgSW50ZWdlcjMyIChpLmUuLCBJbnRlZ2VyMzIsIENvdW50ZXIsIEdhdWdl LCBvcg0KPiAgICAgVGltZVRpY2tzKS4gdG8gYmUgdXNlZCBmb3IgcGVyZm9ybWFuY2UgbW9uaXRv cmluZy4NCj4gDQo+ICAgUHJvYmxlbXM6DQo+IAktIHR5cG9ncmFwaGljYWwgbml0OiBtaXNwbGFj ZWQgIi4iIGFmdGVyICIpIg0KPiAgICAgICAgIC0gdGVjaG5pY2FsOiAiQ291bnRlciIgaXMgbm90 IGFuIFNNSXYyIHR5cGUuICBJIGFzc3VtZQ0KPiAgICAgICAgICAgICAgICAgICAgICAiQ291bnRl cjMyIiBpcyBpbnRlbmRlZC4gIElmIGluY2x1c2lvbiBvZg0KPiAgICAgICAgICAgICAgICAgICAg ICBDb3VudGVyNjQgaXMgYWxzbyBpbnRlbmRlZCwgdGhlcmUgYXJlIG90aGVyIHByb2JsZW1zLg0K PiAgICAgICAgIC0gdGVjaG5pY2FsOiAiR2F1Z2UiIGlzIG5vdCBhbiBTTUl2MiB0eXBlLiAgSSBh c3N1bWUNCj4gICAgICAgICAgICAgICAgICAgICAgIkdhdWdlMzIiIGlzIGludGVuZGVkLg0KPiAJ LSB0ZWNobmljYWw6ICB0aGUgcmFuZ2Ugb2YgdHlwZSBJbnRlZ2VyMzIgKGRlZmluZWQgaW4gUkZD IDI1NzgpDQo+ICAgICAgICAgICAgICAgICAgICAgICBkb2VzIG5vdCBjb3ZlciB0aGUgZW50aXJl IHJhbmdlcyBvZiB0eXBlIENvdW50ZXIzMiwNCj4gICAgICAgICAgICAgICAgICAgICAgIEdhdWdl MzIsIG9yIFRpbWVUaWNrcywgYXMgZGVmaW5lZCBpbiBSRkMgMzQxNi4NCj4gICAgICAgICAgICAg ICAgICAgICAgIFRoZSBTTUkgdHlwZSAqVW5zaWduZWQzMiogZG9lcyBjb3ZlciB0aGUgc2FtZSBy YW5nZXMuDQo+IAktIHRlY2huaWNhbDogdGhlIHVzZSBvZiAicmVzb2x2ZSIgaXMgcXVlc3Rpb25h YmxlLCBzaW5jZSBhbGwNCj4gICAgICAgICAgICAgICAgICAgICAgb2YgdGhlIGRhdGEgdHlwZXMg bWVudGlvbmVkIGhhdmUgZGlzdGluY3QgQVNOLjENCj4gICAgICAgICAgICAgICAgICAgICAgdGFn cy4gIChSRkMgMzQxNiBzZWN0aW9uIDMpDQo+IA0KPiAgIEl0IGdldHMgd29yc2UuICBUaGUgZGVm aW5pdGlvbnMgZm9yIHJlcG9ydFNhbXBsZWRDdXJyZW50TWVhc3VyZW1lbnRWYWx1ZQ0KPiAgIGFu ZCByZXBvcnRTYW1wbGVkSGlzdG9yaWNhbFJlcG9ydHNWYWx1ZSBsaW1pdCB0aGVpciByYW5nZXMg dG8NCj4gICAxIHRvIDIsMTQ3LDQ4Myw2NDcuICBUaGlzIG1lYW5zIHRoYXQgc2FtcGxlcyBvZiBD b3VudGVyMzIsIEdhdWdlMzIsDQo+ICAgYW5kIFRpbWVUaWNrcyB3aXRoIHZhbHVlcyBvZiAwIG9y IGFueXRoaW5nIGluIHRoZSByYW5nZSBmcm9tDQo+ICAgMiwxNDcsNDgzLDY0NyB0byA0LDI5NCw5 NjcsMjk1IGNhbm5vdCBiZSByZXByZXNlbnRlZC4NCj4gDQo+ICAgVGhlIHJlcG9ydFNhbXBsZWRD dXJyZW50TWVhc3VyZW1lbnRTdGF0dXMgYW5kIHRoZQ0KPiAgIHJlcG9ydFNhbXBsZWRIaXN0b3Jp Y2FsTWVhc3VyZW1lbnRTdGF0dXMgT0JKRUNULVRZUEVzIGFwcGVhcg0KPiAgIHRvIGJlIGFuIGF0 dGVtcHQgdG8gYWRkcmVzcyB0aGlzIHByb2JsZW0sIGFuZCB3b3VsZCAqYWxtb3N0Kg0KPiAgIHdv cmsgaWYgdGhlIE1lYXN1cmVtZW50VmFsdWUgd2VyZSBvZiB0eXBlIFVuc2lnbmVkMzIsIGFuZA0K PiAgIGlmIGl0cyByYW5nZSB3ZXJlIG5vdCBjb25zdHJhaW5lZC4gIEhvd2V2ZXIsIGlmIHRoZSBt b2R1bGUNCj4gICBmdW5jdGlvbmVkIGFzIHRob3VnaCBzYW1wbGVkIGRhdGEsIHJlZ2FyZGxlc3Mg b2YgdHlwZSwgd2VyZQ0KPiAgICJjYXN0IiB0byBVbnNpZ25lZDMyLCB0aGVuIHRoZSB2YWx1ZVBv c2l0aXZlKDIpIGFuZCB2YWx1ZU5lZ2F0aXZlKDMpDQo+ICAgYXJlbid0IHJlYWxseSBuZWVkZWQs IHNpbmNlIHRoZSBzaWduZWRuZXNzIG9mIHRoZSBzYW1wbGVkIHZhbHVlcw0KPiAgIGNhbiBiZSBy ZWNvdmVyZWQgZnJvbSByZXBvcnRTYW1wbGVkU3R1ZHlPaWQuDQo+IA0KPiANCj4gVGltZSBTdGFt cGluZw0KPiAgIFRoZXJlIGFyZSBhIGJ1bmNoIG9mIGNvbmNlcm5zIHJlbGF0ZWQgdG8gdGltZSBz dGFtcGluZy4NCj4gDQo+ICAgLSBzZXZlcmFsIE9CSkVDVC1UWVBFIGRlZmluaXRpb25zIGhhdmUg aW1wb3NzaWJsZSBzeW50YXhlcy4NCj4gICAgICJzeXNVcHRpbWUiIGlzIG5vdCBhIHN5bnRheC4g IEl0IHNob3VsZCBub3QgYmUgSU1QT1JUZWQuDQo+ICAgICBGb3IgcmVwb3J0U2FtcGxlZEN1cnJl bnRNZWFzdXJlbWVudFRpbWUgYW5kIGZvcg0KPiAgICAgcmVwb3J0U2FtcGxlZEhpc3RvcmljYWxN ZWFzdXJlbWVudFRpbWUgeW91IGludGVuZCB0bw0KPiAgICAgdXNlIGEgc3ludGF4IG9mICJUaW1l U3RhbXAiDQo+IA0KPiAgIC0gSE9XRVZFUiwgdGhlcmUgaXMgYSBoZWFsdGggd2FybmluZyBhdHRh Y2hlZCB0byB0aGUNCj4gICAgIFRpbWVTdGFtcCB0ZXh0dWFsIGNvbnZlbnRpb24gaW4gUkZDIDI1 NzksIGFuZCBpdCBhcHBsaWVzDQo+ICAgICBoZXJlLiAgRmlyc3RseSwgaXQgYXBwbGllcyBiZWNh dXNlIHRoZSBzZXQgb2YgdmFsdWVzDQo+ICAgICBwZXJtaXR0ZWQgZm9yIHJlcG9ydFNhbXBsZWRT dHVkeVNhbXBsaW5nSW50ZXJ2YWwgbWVhbnMNCj4gICAgIGl0IGlzIHBvc3NpYmxlIHRvIGNvbnN0 cnVjdCBhIHNpbmdsZSByZXBvcnQgaW4gd2hpY2gNCj4gICAgIHRoZSBzYW1wbGUgdGltZXMgYXJl IGFtYmlndW91cy4gIE1vcmUgc2lnbmlmaWNhbnRseSwNCj4gICAgIGZvciBoaXN0b3JpY2FsIHJl cG9ydHMsIGVzcGVjaWFsbHkgZm9yICJhcmNoaXZhbCIgcHVycG9zZXMsDQo+ICAgICB0aGUgc2Ft cGxlIHRpbWVzIGFyZSBhbG1vc3QgY2VydGFpbmx5IGFtYmlndW91cy4gIENvbnNlcXVlbnRseSwN Cj4gICAgIEkgdGhpbmsgdGhlcmUgbmVlZHMgdG8gYmUgYSByZS10aGluayBvZiB3aGV0aGVyIHRo aXMgaXMNCj4gICAgIHRoZSBjb3JyZWN0IGRhdGEgdHlwZSBmb3IgdGhlIGludGVuZGVkIHVzZS4N Cj4gDQo+ICAgLSBNYW55IGNvdW50ZXIgb2JqZWN0cyBoYXZlICJkaXNjb250aW51aXR5IGluZGlj YXRvcnMiIG90aGVyDQo+ICAgICB0aGFuIHN5c1VwVGltZS4gVGhpcyBtb2R1bGUgZG9lcyBub3Qg cHJvdmlkZSBhIHN0cmFpZ2h0Zm9yd2FyZA0KPiAgICAgd2F5IHRvIGNvcGUgd2l0aCB0aGVzZS4g IFNlZSBSRkMgMjk4MSAoc2VhcmNoIGZvciAiZGlzY29udGludWl0eSIpDQo+ICAgICB0byBzZWUg b25lIGFwcHJvYWNoLg0KPiANCj4gICAtIHJlcG9ydFNhbXBsZWRTdHVkeVNhbXBsaW5nSW50ZXJ2 YWwgbWF5IGJlIG1vZGlmaWVkIGR1cmluZyBhDQo+ICAgICByZXBvcnQuICBUaGlzIG1lYW5zIHRo YXQgY29udmVudGlvbmFsIGFsZ29yaXRobXMgZm9yIGRldGVjdGluZw0KPiAgICAgc3lzVXBUaW1l IGRpc2NvbnRpbnVpdGllcyB3aXRoaW4gYSByZXBvcnQgbWF5IG5vdCB3b3JrLg0KPiANCj4gQWNj ZXNzIENvbnRyb2wNCj4gICBUaGVyZSBhcmUgYSBjb3VwbGUgb2Ygd2F5cyBpbiB3aGljaCBhY2Nl c3MgY29udHJvbCBjb25zaWRlcmF0aW9ucw0KPiAgIG1pZ2h0IGFmZmVjdCB0aGUgZGVzaWduIG9m IHRoaXMgbW9kdWxlLiAgVGhlIHByZXNlbmNlIG9mDQo+ICAgcmVwb3J0U2FtcGxlZFN0dWR5T3du ZXIgc3VnZ2VzdHMgdGhhdCBzb21lb25lIHdhcyB0aGlua2luZyBhYm91dA0KPiAgIHRoaXMsIGJ1 dCBzb21lIGNoYW5nZXMgYXJlIG5lZWRlZCB0byBtYWtlIHRoaW5ncyB3b3JrLg0KPiANCj4gICAg ICgxKSByZXBvcnRTYW1wbGVkQ29udHJvbEVudHJ5IHNob3VsZCBoYXZlIGFuIElOREVYIG9mDQo+ ICAgICAgICAgeyByZXBvcnRTYW1wbGVkU3R1ZHlPd25lciwgcmVwb3J0U2FtcGxlZFN0dWR5SW5k ZXggfQ0KPiAgICAgICAgIFRoaXMgaXMgbmVjZXNzYXJ5IGlmIHlvdSB3YW50IHRvIGJlIGFibGUg dG8gbGltaXQgYWNjZXNzDQo+ICAgICAgICAgdG8gc3BlY2lmaWMgc3R1ZGllcyB0byBzcGVjaWZp YyB1c2VycyBpbiBhIHJlYXNvbmFibGUgd2F5LA0KPiAgICAgICAgIGFuZCB0byBwcmV2ZW50IGNv bGxpc2lvbnMgYmV0d2VlbiB1c2VycyBkdXJpbmcgdGhlIGNyZWF0aW9uDQo+ICAgICAgICAgb2Yg c3R1ZGllcy4NCj4gDQo+ICAgICAoMikgTGlrZXdpc2UsIHJlcG9ydFNhbXBsZWRDdXJyZW50UmVw b3J0c1N0YXR1c0VudHJ5IHNob3VsZA0KPiAgICAgICAgIGFsc28gaGF2ZSBhbiBJTkRFWCBvZg0K PiAgICAgICAgIHsgcmVwb3J0U2FtcGxlZFN0dWR5T3duZXIsIHJlcG9ydFNhbXBsZWRTdHVkeUlu ZGV4IH0sDQo+ICAgICAgICAgcmVwb3J0U2FtcGxlZEN1cnJlbnRSZXBvcnRzRW50cnkgc2hvdWxk IGhhdmUNCj4gICAgICAgICB7IHJlcG9ydFNhbXBsZWRTdHVkeUluZGV4LCByZXBvcnRTYW1wbGVk Q3VycmVudE1lYXN1cmVtZW50SW5kZXggfQ0KPiAgICAgICAgIHJlcG9ydFNhbXBsZWRIaXN0b3Jp Y2FsUmVwb3J0c0VudHJ5IHNob3VsZCBoYXZlDQo+ICAgICAgICAgeyByZXBvcnRTYW1wbGVkU3R1 ZHlPd25lciwgcmVwb3J0U2FtcGxlZFN0dWR5SW5kZXgsDQo+ICAgICAgICAgICByZXBvcnRTYW1w bGVkSGlzdG9yaWNhbFJlcG9ydEluZGV4LA0KPiAgICAgICAgICAgcmVwb3J0U2FtcGxlZEhpc3Rv cmljYWxNZWFzdXJlbWVudEluZGV4IH0NCj4gDQo+ICAgICAoMykgQSBjb25zZXF1ZW5jZSBpcyB0 aGF0IChmb3IgZXhhbXBsZSkgcmVwb3J0U2FtcGxlZFN0dWR5SW5kZXgNCj4gICAgICAgICBvbmx5 IG5lZWRzIHRvIGJlIHVuaXF1ZSBmb3IgYSBnaXZlbiBvd25lciwgYW5kIG5vdCBhbW9uZw0KPiAg ICAgICAgIGFsbCBzdHVkaWVzLg0KPiANCj4gICBOb3RlIHRoYXQgcmVwb3J0U2FtcGxlZERhdGFD b2xsZWN0aW9uRmFpbHVyZSBzdWZmZXJzIGZyb20gdGhlDQo+ICAgIndobydzIGJ1cmllZCBpbiBH cmFudCdzIFRvbWIiIHByb2JsZW0sIGFuZCBjYW4gYmUgc2ltcGxpZmllZC4NCj4gDQo+ICAgQSBz ZWNvbmQgd2F5IGluIHdoaWNoIGFjY2VzcyBjb250cm9sIG1hdHRlcnMgaGVyZSBpcyB0aGF0IHRo ZQ0KPiAgIHNhbXBsaW5nIHByb2Nlc3Mgc2hvdWxkIG5vdCBjaXJjdW12ZW50IGFjY2VzcyBjb250 cm9sLiAgSSBzdHJvbmdseQ0KPiAgIHVyZ2UgcHV0dGluZyBpbiBleHBsaWNpdCBsYW5ndWFnZSBh Ym91dCB0aGlzLiAgSSdkIHN1Z2dlc3QgdGhlIGZvbGxvd2luZw0KPiAgIGFzIGEgc3RhcnRpbmcg cG9pbnQgZm9yIGRpc2N1c3Npb246DQo+IA0KPiAgICAgIFNlY3VyaXR5IGZvciBsb2NhbCBhY2Nl c3MgZWZmZWN0aXZlbHkgcmVxdWlyZXMgcmVjb3JkaW5nIGFwcHJvcHJpYXRlDQo+ICAgICAgc2Vj dXJpdHkgY3JlZGVudGlhbHMgb2YgdGhlIGNyZWF0b3Igb2YgYSByZXBvcnRTYW1wbGVkQ29udHJv bEVudHJ5DQo+ICAgICAgYW5kIHVzaW5nIHRob3NlIHRvIGFjY2VzcyB0aGUgbG9jYWwgb2JqZWN0 cy4gIFRoZXNlIHNlY3VyaXR5DQo+ICAgICAgY3JlZGVudGlhbHMgYXJlIHBhcmFtZXRlcnMgbmVj ZXNzYXJ5IGFzIGlucHV0cyB0byBpc0FjY2Vzc0FsbG93ZWQNCj4gICAgICBmcm9tIHRoZSBBcmNo aXRlY3R1cmUgZm9yIERlc2NyaWJpbmcgU05NUCBNYW5hZ2VtZW50IEZyYW1ld29ya3MuDQo+ICAg ICAgVGhlIHN5c3RlbSBNVVNUIChjb25jZXB0dWFsbHkpIHVzZSBpc0FjY2Vzc0FsbG93ZWQgYXQg dGhlIHRpbWUgb2YNCj4gICAgICBlYWNoIGFjY2VzcyAobm90IGp1c3QgY3JlYXRpb24gb2YgdGhl IHJlcG9ydFNhbXBsZWRDb250cm9sRW50cnkpDQo+ICAgICAgdG8gZW5zdXJlIHRoYXQgaXQgZG9l cyBub3QgcGVybWl0IHVuYXV0aG9yaXplZCBhY2Nlc3MuDQo+IA0KPiAgICAgIFdoZW4gdXNpbmcg VkFDTSwgdGhlIHNlY3VyaXR5IGFkbWluaXN0cmF0b3IgU0hPVUxEIGVuc3VyZSB0aGF0DQo+ICAg ICAgYWNjZXNzIHBlcm1pdHRlZCB0byB0aGUgY29sbGVjdGVkIGRhdGEgYW5kIG5vdGlmaWNhdGlv bnMgKHRoYXQgaXMsDQo+ICAgICAgYWNjZXNzIHRvIHJlcG9ydFNhbXBsZWRDdXJyZW50UmVwb3J0 c1N0YXR1c1RhYmxlLiouPHVzZXI+LA0KPiAgICAgIHJlcG9ydFNhbXBsZWRDdXJyZW50UmVwb3J0 c1RhYmxlLiouPHVzZXI+LCBhbmQNCj4gICAgICByZXBvcnRTYW1wbGVkSGlzdG9yaWNhbFJlcG9y dHNUYWJsZS4qLjx1c2VyPikgaXMNCj4gICAgICBsaW1pdGVkIHRvIHRoZSA8dXNlcj4ncyBhcHBy b3ByaWF0ZSBWQUNNIGdyb3VwLg0KPiANCj4gT2RkcyBhbmQgZW5kczoNCj4gICBJdCdzIHByZXR0 eSBvYnZpb3VzIHRoYXQgdGhpcyBtb2R1bGUgaGFzIG5vdCBzZWVuIGEgTUlCIGNvbXBpbGVyDQo+ ICAgcmVjZW50bHkuICBJbiBhZGRpdGlvbiB0byB0aGUgc3ludGFjdGljIHByb2JsZW0sIHRoZXJl IGFyZSBzb21lDQo+ICAgZ2xhcmluZyBzdHlsaXN0aWMgaXNzdWVzIHRoYXQsIGlmIGZpeGVkIG5v dywgd2lsbCBtYWtlIGFuIGV2ZW50dWFsDQo+ICAgTUlCIGRvY3RvciByZXZpZXcgZ28gYSBsb3Qg c21vb3RoZXIuDQo+IA0KPiAgICAoMSkgVXNlIG9mIGRhdGEgdHlwZXMuICBFdmVyeSBzaW5nbGUg dXNlIG9mIEludGVnZXIzMiBpbiB0aGlzDQo+ICAgICAgICBtb2R1bGUgaXMgYXJndWFibHkgaW5j b3JyZWN0LiAgVW5zaWduZWQzMiB3b3VsZCBiZSBhIGJldHRlcg0KPiAgICAgICAgY2hvaWNlLCBz aW5jZSB0aGVzZSBhcmUgYWxsIHN1Yi10eXBlZCB0byBleGNsdWRlIG5lZ2F0aXZlDQo+ICAgICAg ICB2YWx1ZXMuDQo+IA0KPiAgICgyKSBVc2Ugb2YgZGF0YSB0eXBlcy4gIHJlcG9ydFNhbXBsZWRT dHVkeVNhbXBsaW5nSW50ZXJ2YWwNCj4gICAgICAgc2VlbXMgbGlrZSBpdCBzaG91bGQgbWFrZSB1 c2Ugb2YgUkZDIDI1NzkgVGltZUludGVydmFsLCBwZXJoYXBzDQo+ICAgICAgIGNvbnN0cmFpbmVk IHRvIGJlIGF0IGxlYXN0IDEwLg0KPiANCj4gICAoMykgVXNlIG9mIFVOSVRTLiAgVGhvdWdoIGl0 J3MgYSBsaXR0bGUgdW51c3VhbCAoYnV0IG5vdCB1bmhlYXJkLW9mKQ0KPiAgICAgICB0byB1c2Ug VU5JVFMgd2l0aCBub24tY291bnRlciB0eXBlcywgYSB2YWx1ZSBvZiAiY291bnQiIGluLA0KPiAg ICAgICBmb3IgZXhhbXBsZSwgcmVwb3J0U2FtcGxlZFN0dWR5TWF4aW11bU51bWJlck9mSGlzdG9y aWNhbFJlcG9ydHMsDQo+ICAgICAgIGlzIHJlYWxseSBub3QgaGVscGZ1bC4gIEluIHRoYXQgcGFy dGljdWxhciBjYXNlLCAicmVwb3J0cyINCj4gICAgICAgd291bGQgbWFrZSBtb3JlIHNlbnNlLg0K PiANCj4gICAoNCkgQXR0ZW50aW9uIHRvIGVycm9yIGNhc2VzOiB0aGVyZSBhcmUgYSBidW5jaCBv ZiBlcnJvciBzaXR1YXRpb25zDQo+ICAgICAgIHRoYXQgc2hvdWxkIGJlIGdpdmVuIGEgbGl0dGxl IGF0dGVudGlvbi4gIFdoYXQgaGFwcGVucyB3aGVuDQo+ICAgICAgIHRoZXJlJ3Mgbm8gbG9uZ2Vy IGVub3VnaCBtZW1vcnkgdG8ga2VlcCBhY2N1bXVsYXRpbmcgc3R1ZGllcz8NCj4gICAgICAgV2hh dCBoYXBwZW5zIHdoZW4gdGhlIG9iamVjdCBpbnN0YW5jZSByZWZlcnJlZCB0byBieQ0KPiAgICAg ICByZXBvcnRTYW1wbGVkU3R1ZHlPaWQgaXMgdGhlIHdyb25nIGRhdGEgdHlwZT8NCj4gDQo+ICAg KDUpIFRoZSB1c2Ugb2Ygbm9uLXZvbGF0aWxlIHN0b3JhZ2UgZG9lc24ndCBzZWVtIHRvIGhhdmUg YmVlbg0KPiAgICAgICBjb21wbGV0ZWx5IHRob3VnaHQgdGhyb3VnaC4gIEl0IGRvZXNuJ3QgbWFr ZSBzZW5zZSB0byBtZSwgZm9yDQo+ICAgICAgIGV4YW1wbGUsIHRvIGhhdmUgdGhlIGNvbnRyb2wg ZW50cmllcyBpbiBiYWNraW5nIHN0b3JhZ2UsIGJ1dA0KPiAgICAgICBub3QgdGhlICJhcmNoaXZh bCIgaGlzdG9yaWNhbCBkYXRhLiAgTGlrZXdpc2UsIGlmIGEgY29udHJvbA0KPiAgICAgICBlbnRy eSBpcyByZXN0b3JlZCBmcm9tIG5vbi12b2xhdGlsZSB1cG9uIHJlYm9vdCwgZG9lcyB0aGF0DQo+ ICAgICAgIGNhdXNlIGEgbmV3IHJlcG9ydCB0byBiZSBzdGFydGVkIG9yIGRvZXMgaXQgcGljayB1 cCB3aGVyZQ0KPiAgICAgICBpdCBsZWZ0IG9mZiBvbiBhIGV4aXN0aW5nIHJlcG9ydD8NCj4gDQo+ ICAgKDYpIE5vdGlmaWNhdGlvbiB0aHJvdHRsaW5nLg0KPiANCj4gUXVlc3Rpb25zIG9mIFBvd2Vy DQo+ICAgSSB0aGluayB0aGUgZGVjaXNpb24gdG8gbGltaXQgdGhlIG1vZHVsZSB0byBsb2NhbCBh Y2Nlc3MgaXMgcmVhc29uYWJsZQ0KPiAgIGdpdmVuIHRoZSBpbnRlbmRlZCBhcHBsaWNhYmlsaXR5 LiAgSSBkbyB0aGluaywgaG93ZXZlciwgdGhlcmUgc2hvdWxkDQo+ICAgYmUgYSBjbGVhciBleHBs YW5hdGlvbiBvZiB0aGUgcmF0aW9uYWxlIGJlaGluZCBsaW1pdGluZyBpdHMgZnVuY3Rpb25hbGl0 eQ0KPiAgIHRvIHRoZSBjdXJyZW50IFNOTVAgY29udGV4dCwgdW5saWtlIFJGQyAxOTgxLg0KPiAN Cj4gICBJIHRoaW5rIGl0IHdvdWxkIGJlIGhlbHBmdWwgdG8gYXQgbGVhc3Qgc3VnZ2VzdCBob3cg aXQgaXMgZW52aXNpb25lZA0KPiAgIHRoYXQgZnV0dXJlICJzdGF0aXN0aWNhbCIgZnVuY3Rpb25z IGFsbHVkZWQgdG8gaW4gdGhlIHRleHQgd291bGQgd29yaw0KPiAgIHdpdGggdGhpcyBNSUIgbW9k dWxlIC0gICBhcmUgdGhleSBleHBlY3RlZCB0byBiZSBleHRlbnNpb25zIG9mIHRoaXMNCj4gICBt b2R1bGUgb3IgY29tcGxldGVseSBuZXcgb25lcz8NCj4gDQo+ICAgSSBob25lc3RseSBoYXZlIHNv bWUgZGlmZmljdWx0eSBzZWVpbmcgd2hhdCBnb29kIHRoaXMgbW9kdWxlIHdvdWxkDQo+ICAgZG87 IHBlcmhhcHMgdGhlIFdHIGhhcyBkaXNjdXNzZWQgY29uY3JldGUgdXNlIGNhc2VzLCBidXQgZG9u J3QgYmUNCj4gICBzdXJwaXNlZCBpZiBhIGZ1dHVyZSByZXZpZXdlciByYWlzZXMgcXVlc3Rpb25z IG9uIHRoaXMgcG9pbnQuDQo+IA0KPiBSYW5keQ0KDQo= From nobody Mon Apr 20 11:16:09 2015 Return-Path: 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 EE9EB1A1A1D; Mon, 20 Apr 2015 11:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 QQtQYzE2-O0R; Mon, 20 Apr 2015 11:16:05 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA371A1A10; Mon, 20 Apr 2015 11:16:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=B2bM0MEq2TkmBxHon1irzRTi4zFC6urKSPZ8e+V+NcF9V5oQAoC1Wp2faqkiXlJe; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.51] (helo=mswamui-thinleaf.atl.sa.earthlink.net) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1YkGE2-000200-Qo; Mon, 20 Apr 2015 14:15:18 -0400 Received: from 76.254.48.97 by webmail.earthlink.net with HTTP; Mon, 20 Apr 2015 14:14:50 -0400 Message-ID: <15067240.1429553690764.JavaMail.root@mswamui-thinleaf.atl.sa.earthlink.net> Date: Mon, 20 Apr 2015 11:14:50 -0700 (GMT-07:00) From: Randy Presuhn To: "Cole,Robert G CIV USARMY CERDEC (US)" , "manet@ietf.org" Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b65b6112f89115376d7f1db1b680646c17222980ccabf53d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.51 Archived-At: 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 Reply-To: Randy Presuhn List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 18:16:08 -0000 Hi - >From: "Cole, Robert G CIV USARMY CERDEC (US)" >Sent: Apr 20, 2015 6:29 AM >To: Randy Presuhn , "manet@ietf.org" >Cc: "mib-doctors@ietf.org" , "disman@ietf.org" >Subject: Re: [MIB-DOCTORS] comments on draft-ietf-manet-report-mib-04 ... >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. Don't give too much weight to my comments, but I'd hope this sort of question would be worked through by any working group considering the development of any MIB module. I think a single, fully-worked-through example of how this would be used with an implementation of RFC 2981 to do something useful would be sufficient. If the intent is to provide detailed history of samples resulting in a DISMAN-EVENT-MIB trigger, I think you need some additional magic to somehow synchronize the sampling performed by this module and that performed by DISMAN-EVENT-MIB. If it's to provide other context (i.e., the data recorded here is for some object other than the one causing the trigger), the issue of potential timing skew should be made explicit. >I'll write up a justification for the module, to be placed >in the introductory text. There's some already there, but it seems to be the rationale for DISMAN-EVENT-MIB rather than for *this* module. AFAICT, this module isn't really going to reduce polling traffic or permit operation with intermittant connectivity. Rather, it *looks* like its function is to record a sampling history to provide debugging/contextual information for a trigger notification. > 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? The WG's voice is the one that matters. If the WG is convinced it's useful after working through the details of a use case, I'll be happy. Randy From nobody Tue Apr 21 01:07:08 2015 Return-Path: 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 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 , 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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.*., > reportSampledCurrentReportsTable.*., and > reportSampledHistoricalReportsTable.*.) is > limited to the '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 > . > From nobody Tue Apr 21 05:43:29 2015 Return-Path: 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 9A9D81ACD2F; Tue, 21 Apr 2015 05:43:28 -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 gfL2Wvm20o0B; Tue, 21 Apr 2015 05:43:21 -0700 (PDT) Received: from ucol19pa13.eemsg.mail.mil (ucol19pa13.eemsg.mail.mil [214.24.24.86]) by ietfa.amsl.com (Postfix) with ESMTP id ABF6F1ACD3C; Tue, 21 Apr 2015 05:43:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,615,1422921600"; d="scan'208";a="144291235" Received: from edge-eurd01.mail.mil ([214.24.180.6]) by ucol19pa13.eemsg.mail.mil with ESMTP; 21 Apr 2015 12:43:18 +0000 Received: from UPDCHU30.easf.csd.disa.mil (214.24.180.162) by edge-eurd01.mail.mil (214.24.180.6) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 21 Apr 2015 12:43:20 +0000 Received: from UCOLHPMM.easf.csd.disa.mil (131.64.104.41) by UPDCHU30.easf.csd.disa.mil (214.24.180.162) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 21 Apr 2015 12:43:19 +0000 Received: from UCOLHPKT.easf.csd.disa.mil ([169.254.2.143]) by ucolhpmm.easf.csd.disa.mil ([131.64.104.41]) with mapi id 14.03.0224.002; Tue, 21 Apr 2015 12:43:17 +0000 From: "Cole, Robert G CIV USARMY CERDEC (US)" To: Benoit Claise , Randy Presuhn , "manet@ietf.org" Thread-Topic: [MIB-DOCTORS] comments on draft-ietf-manet-report-mib-04 Thread-Index: AQHQfApB4PkU+fOlpU6ptluNDDGHfZ1XZ89Q Date: Tue, 21 Apr 2015 12:43:17 +0000 Message-ID: References: <18699062.1429399645552.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> <55360555.4020403@cisco.com> In-Reply-To: <55360555.4020403@cisco.com> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 12:43:28 -0000 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 robert.g.cole@us.army.mil > -----Original Message----- > From: MIB-DOCTORS [mailto:mib-doctors-bounces@ietf.org] On Behalf Of Beno= it Claise > Sent: Tuesday, April 21, 2015 4:08 AM > To: Randy Presuhn; manet@ietf.org > Cc: mib-doctors@ietf.org; disman@ietf.org > 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.*., > > reportSampledCurrentReportsTable.*., and > > reportSampledHistoricalReportsTable.*.) is > > limited to the '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 > > MIB-DOCTORS@ietf.org > > https://www.ietf.org/mailman/listinfo/mib-doctors > > . > > >=20 > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors From nobody Tue Apr 21 12:19:10 2015 Return-Path: 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 02ED61B2A6D; Tue, 21 Apr 2015 12:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 uYnnVIkq45ZX; Tue, 21 Apr 2015 12:19:07 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 6781D1B2A6F; Tue, 21 Apr 2015 12:19:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=F58CKRIoQwqen38LtXlfrAVVAD4dExB2D7tt8ivS9aWb4+wuXjK5U84VGftbkdyY; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.33] (helo=elwamui-darkeyed.atl.sa.earthlink.net) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1YkdhJ-0006NB-EB; Tue, 21 Apr 2015 15:19:05 -0400 Received: from 76.254.54.242 by webmail.earthlink.net with HTTP; Tue, 21 Apr 2015 15:19:05 -0400 Message-ID: <21091172.1429643945433.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net> Date: Tue, 21 Apr 2015 12:19:05 -0700 (GMT-07:00) From: Randy Presuhn To: Benoit Claise , manet@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b65b6112f89115379af53944a38a708884189f6b645529d7350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.33 Archived-At: 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 Reply-To: Randy Presuhn List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 19:19:09 -0000 Hi - >From: Benoit Claise >Sent: Apr 21, 2015 1:07 AM >To: Randy Presuhn , manet@ietf.org >Cc: disman@ietf.org, mib-doctors@ietf.org >Subject: Re: [MIB-DOCTORS] comments on draft-ietf-manet-report-mib-04 ... >This is inappropriate to ask for a MIB doctor review for a MIB module >that doesn't even compile. ... I wrote: >> This is *not* a full MIB doctor review; in my opinion some ... Sorry if that misled anyone. The reasons I CC-ed the mib-doctors@ietf.org list as well as the disman@ietf.org list were: 1) to let folks outside of manet@ietf.org know that *someone* had looked at this 2) to make sure that no one had a problem with my suggestions regarding how the work could fit in with disman infrastructure and accepted MIB practice. I think the timestamping issues in particular are of general concern, so if there is consensus among practitioners regarding the best way to deal with those issues beyond what we did with the Log MIB (the nlmLogTime and nlmLogDateAndTime hack) it would be good to be able to make a specific recommendation to the manet folk. That would be a lot more helpful than my comments, which amount to "this is busted." Kinda tangentially... (3) Given the current emphasis on Netconf, and this module is primarily about configuring functionality, is anyone prepared to argue that this MIB module should instead be a Yang module and managed via Netconf protocol? I think it would be a terrible fit, but that's not my problem. Randy