From owner-disman@dorothy.peer.com Mon Apr 3 09:10:25 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16934 for ; Mon, 3 Apr 2000 09:10:20 -0400 (EDT) Received: from dorothy.peer.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id IAA24794; Mon, 3 Apr 2000 08:07:45 -0500 (CDT) Received: (from root@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id GAA07983 for disman-list; Mon, 3 Apr 2000 06:02:44 -0700 (PDT) Received: from tangelo.bmc.com (root@tangelo [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id GAA07977; Mon, 3 Apr 2000 06:02:40 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id IAA23610; Mon, 3 Apr 2000 08:03:16 -0500 (CDT) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id OAA14259; Mon, 3 Apr 2000 14:58:47 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id OAA01930; Mon, 3 Apr 2000 14:58:32 +0200 Date: Mon, 3 Apr 2000 14:58:32 +0200 Message-Id: <200004031258.OAA01930@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: rpresuhn@dorothy.peer.com CC: disman@dorothy.peer.com In-reply-to: <200003310058.QAA21110@dorothy.peer.com> (message from Randy Presuhn on Thu, 30 Mar 2000 16:58:49 -0800 (PST)) Subject: Re: disman WG last call on Schedule MIB References: <200003310058.QAA21110@dorothy.peer.com> Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> Randy Presuhn writes: Randy> Since there appear to be no further issues, I'm starting a Randy> two-week disman WG last call on Randy> draft-ietf-disman-schedule-mib-v2-00.txt for advancement to Randy> Draft Standard status. This would obsolete RFC 2591. There were two issues that are not reflected in this ID: 02: Can the SNMP manager modify CalendarGroup objects and schedInterval object when the schedRowStatus is in 'active' state? Strawman: schedInterval and friends can be changed even if schedRowStatus is active and schedAdminStatus and schedOperStatus are enabled. 03: Clarification requires on multiple events in nonexistent times? Strawman: Add the following text below the last paragraph of section 3.4 in RFC 2591: This rule applies to all events scheduled for nonexistent time, regardless whether the scheduled events originate from one or multiple rows in the schedTable. At least one WG member said that the behaviour regarding issue 03 should be configurable. And that is where discussion stopped, if I remember right. Bottom line: I think I know the edits for 02. I am not so sure with regard to 03. (Personally, I prefer the strawman because making the behaviour in this corner case configurable adds quite some complexity which is hard to test.) In any case, I do not think we are ready for last call. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-disman@dorothy.peer.com Mon Apr 3 09:59:54 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17342 for ; Mon, 3 Apr 2000 09:59:53 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id IAA09894; Mon, 3 Apr 2000 08:58:15 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id GAA08087 for disman-list; Mon, 3 Apr 2000 06:57:12 -0700 (PDT) Received: from tangelo.bmc.com (root@tangelo [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id GAA08081; Mon, 3 Apr 2000 06:57:08 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id IAA09698; Mon, 3 Apr 2000 08:57:43 -0500 (CDT) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id PAA18678; Mon, 3 Apr 2000 15:57:52 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id PAA04350; Mon, 3 Apr 2000 15:57:40 +0200 Date: Mon, 3 Apr 2000 15:57:40 +0200 Message-Id: <200004031357.PAA04350@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: rpresuhn@dorothy.peer.com CC: disman@dorothy.peer.com In-reply-to: <200003310111.RAA21185@dorothy.peer.com> (message from Randy Presuhn on Thu, 30 Mar 2000 17:11:57 -0800 (PST)) Subject: Re: closing Script MIB issues References: <200003310111.RAA21185@dorothy.peer.com> Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> Randy Presuhn writes: Randy> We need to get closure on the Script MIB issues so we can do a Randy> WG last call before requesting advancement to Draft Standard. Randy> Issues from the i-d: Randy> 02: Restartable scripts I think the strawman here was to have an smLaunchFlags objects of type BITS which indicates whether a script is being restarted on reinitialization. Randy> 03: Error message during script retrieval or compilation ( Randy> smScriptError) I think the strawman here was to add an smScriptError object which contains the last error message generated. Randy> 04: Scripts that can run forever without having to reset Randy> smRunLifeTime I think the strawman here was to give the max. smRunLifeTime value a special meaning (which stops the timer from decrementing). Randy> 05: Index smLangTable and smExtsnTable by name rather than Randy> Integer32 Randy> 06: Dependencies between scripts and script versioning Randy> (Eamonn) Randy> 07: Storage type of script code versus storage type of Randy> script meta information Randy> All issues on which there are no contributions within the next Randy> two weeks will be closed with a status of "no action". I have a few more issues in my list: 08: Final polling missing in procedures 7.6 and 7.7 (Frank) I think a suitable clarification should be added to these sections. 09: Add procedures for suspend/resume/purge to section 7 (Frank) I think it is helpful to define these procedures. 10: Any changes needed for editing in the SNMP code table? (Juergen) There have been a few comments on the smCodeTable and its flexibility regarding the numbering scheme and so on. Do we want to keep it the way it is defined? Many implementations so far do not support it and we may get problems with it anyway once we want to advance to Draft standard. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-disman@dorothy.peer.com Mon Apr 3 10:33:34 2000 Received: from tangelo.bmc.com ([198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17877 for ; Mon, 3 Apr 2000 10:33:33 -0400 (EDT) Received: from dorothy.peer.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id JAA22565; Mon, 3 Apr 2000 09:32:24 -0500 (CDT) Received: (from root@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id HAA08140 for disman-list; Mon, 3 Apr 2000 07:30:55 -0700 (PDT) Received: from tangelo.bmc.com (root@tangelo [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id HAA08134; Mon, 3 Apr 2000 07:30:51 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id JAA22147; Mon, 3 Apr 2000 09:31:26 -0500 (CDT) Received: from France.Sun.COM ([129.157.188.1]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA28411; Mon, 3 Apr 2000 07:31:22 -0700 (PDT) Received: from sutur.France.Sun.COM by France.Sun.COM (8.8.8+Sun/SMI-SVR4-sd.fkk205) id QAA22520; Mon, 3 Apr 2000 16:17:52 +0200 (MET DST) Received: from noname.France.Sun.COM by sutur.France.Sun.COM (8.9.3+Sun/SMI-SVR4) id QAA23069; Mon, 3 Apr 2000 16:17:40 +0200 (MET DST) Received: from france.sun.com (localhost [127.0.0.1]) by noname.France.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id QAA04473; Mon, 3 Apr 2000 16:17:51 +0200 (MET DST) Message-ID: <38E8A80F.25DA4C18@france.sun.com> Date: Mon, 03 Apr 2000 16:17:51 +0200 From: Eamonn McManus Organization: Sun Microsystems, France X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u) MIME-Version: 1.0 To: Juergen Schoenwaelder CC: rpresuhn@dorothy.peer.com, disman@dorothy.peer.com Subject: Re: closing Script MIB issues References: <200003310111.RAA21185@dorothy.peer.com> <200004031357.PAA04350@henkell.ibr.cs.tu-bs.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id HAA08135 Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Juergen Schoenwaelder wrote: > >>>>> Randy Presuhn writes: > Randy> We need to get closure on the Script MIB issues so we can do a > Randy> WG last call before requesting advancement to Draft Standard. > Randy> Issues from the i-d: > [...] > I have a few more issues in my list: > [...] > 10: Any changes needed for editing in the SNMP code table? (Juergen) > > There have been a few comments on the smCodeTable and its flexibility > regarding the numbering scheme and so on. Do we want to keep it the > way it is defined? Many implementations so far do not support it and > we may get problems with it anyway once we want to advance to Draft > standard. I would like to re-suggest the scheme I described in my Simple Times article, http://www.simple-times.org/pub/simple-times/issues/7-2.html#tools * Entries can only be added to the smCodeTable before the corresponding smScriptAdminStatus is ``enabled.'' * The first entry to be added to the smCodeTable must have smCodeIndex 1, and every subsequent entry must have smCodeIndex one more than the current largest value. Each entry must have its smCodeRowStatus set to ``active'' before any subsequent entry can be added. Entries once added to the smCodeTable cannot be deleted. These constraints mean that during download the agent does not have to store smCodeRowStatus or smCodeIndex values anywhere. It does have to remember where each smCodeText object is within the script, but only while the script is being pushed. * Once the script has been pushed, the manager sets the smScriptAdminStatus to ``enabled.'' As at present, the fact that the code comes from the smCodeTable is indicated by an empty smScriptSource and an smScriptStorageType that is ``volatile.'' * When the smScriptRowStatus is set to ``active,'' an agent may choose to delete the smCodeTable, or it may reorganize it so that the same code is presented using a different division into smCodeText objects. In particular it may decide to chop up the presented text into fixed-length smCodeText objects so that it does not have to remember the offsets corresponding to smCodeIndex values. This means that the smCodeTable takes up no storage: the agent can construct replies to SNMP get requests on the fly. If the smScriptStorageType is then made non-volatile, the script text will be written to non-volatile storage. * The only way to modify the text of a script after it has been downloaded is to delete the smScriptEntry and create a new one. Éamonn (speaking in a personal capacity) From owner-disman@dorothy.peer.com Tue Apr 4 01:50:13 2000 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14108 for ; Tue, 4 Apr 2000 01:50:13 -0400 (EDT) Received: from dorothy.peer.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id AAA27979; Tue, 4 Apr 2000 00:49:00 -0500 (CDT) Received: (from root@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id WAA12197 for disman-list; Mon, 3 Apr 2000 22:47:09 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id WAA12191 for disman@dorothy.bmc.com; Mon, 3 Apr 2000 22:47:05 -0700 (PDT) Date: Mon, 3 Apr 2000 22:47:05 -0700 (PDT) From: Randy Presuhn Message-Id: <200004040547.WAA12191@dorothy.bmc.com> To: disman@dorothy.peer.com Subject: Re: disman WG last call on Schedule MIB Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi - > Date: Mon, 3 Apr 2000 14:58:32 +0200 > Message-Id: <200004031258.OAA01930@henkell.ibr.cs.tu-bs.de> > From: Juergen Schoenwaelder > To: rpresuhn@dorothy.peer.com > CC: disman@dorothy.peer.com > In-reply-to: <200003310058.QAA21110@dorothy.peer.com> (message from Randy > Presuhn on Thu, 30 Mar 2000 16:58:49 -0800 (PST)) > Subject: Re: disman WG last call on Schedule MIB > References: <200003310058.QAA21110@dorothy.peer.com> > > > >>>>> Randy Presuhn writes: > > Randy> Since there appear to be no further issues, I'm starting a > Randy> two-week disman WG last call on > Randy> draft-ietf-disman-schedule-mib-v2-00.txt for advancement to > Randy> Draft Standard status. This would obsolete RFC 2591. > > There were two issues that are not reflected in this ID: > > 02: Can the SNMP manager modify CalendarGroup objects and > schedInterval object when the schedRowStatus is in 'active' > state? > > Strawman: schedInterval and friends can be changed even if > schedRowStatus is active and schedAdminStatus and schedOperStatus > are enabled. > > > 03: Clarification requires on multiple events in nonexistent times? > > Strawman: Add the following text below the last paragraph of > section 3.4 in RFC 2591: > > This rule applies to all events scheduled for nonexistent > time, regardless whether the scheduled events originate from > one or multiple rows in the schedTable. > > At least one WG member said that the behaviour regarding issue 03 > should be configurable. And that is where discussion stopped, if I > remember right. > > Bottom line: I think I know the edits for 02. I am not so sure with > regard to 03. (Personally, I prefer the strawman because making the > behaviour in this corner case configurable adds quite some complexity > which is hard to test.) As a technical contributor, I also prefer the proposed resolution for item 03. As working group chair, I believe there has been ample opportunity to discuss this question, and will declare a rough consensus for the strawman resolution to 03 UNLESS I see reasoned objections posted to this list by Friday of this week. Unless such objections materialize, I do not believe it would be necessary to extend the WG last call further. > In any case, I do not think we are ready for last call. ... I'm missing something. The editor knows the edits. There are no contententious issues left. There are implementations. Once the updated draft appears, I don't see what could happen that would bring us any closer to being ready to hand it over to the IESG. So, let's do this: 1) close out all these issues by the end of this week 2) the editors will update the i-d at their earliest opportunity (and I do mean sooner rather than later :-) 3) I will consider extending the WG last call period if issues arise or if requested to do so by someone who requires additional time to do an in-depth review. I will NOT extend the time in the hope that a lengthy WG last call would increase the probability that someone might accidentally read the document. ------------------------------------------------------------------------ Randy Presuhn randy_presuhn@bmc.com http://www.bmc.com/ Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 2141 N. First Street Fax: +1 408 965-0359 San Jose, California 95131 USA ------------------------------------------------------------------------ Any relationship between my opinions and BMC's should be coincidental. ------------------------------------------------------------------------ From owner-disman@dorothy.peer.com Tue Apr 4 01:57:39 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14319 for ; Tue, 4 Apr 2000 01:57:38 -0400 (EDT) Received: from dorothy.peer.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id AAA29047; Tue, 4 Apr 2000 00:56:35 -0500 (CDT) Received: (from root@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id WAA12231 for disman-list; Mon, 3 Apr 2000 22:55:40 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id WAA12225 for disman@dorothy.bmc.com; Mon, 3 Apr 2000 22:55:37 -0700 (PDT) Date: Mon, 3 Apr 2000 22:55:37 -0700 (PDT) From: Randy Presuhn Message-Id: <200004040555.WAA12225@dorothy.bmc.com> To: disman@dorothy.peer.com Subject: RFC 2591 (schedule MIB) implementations Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi - It's time to consider whether we'll be ready to request that the RFC 2591 Schedule MIB be advanced from "Proposed Standard" to "Draft Standard." As a memory refresher, here are the requirements from RFC 2026: |4.1.2 Draft Standard | | A specification from which at least two independent and interoperable | implementations from different code bases have been developed, and | for which sufficient successful operational experience has been | obtained, may be elevated to the "Draft Standard" level. For the | purposes of this section, "interoperable" means to be functionally | equivalent or interchangeable components of the system or process in | which they are used. If patented or otherwise controlled technology | is required for implementation, the separate implementations must | also have resulted from separate exercise of the licensing process. | Elevation to Draft Standard is a major advance in status, indicating | a strong belief that the specification is mature and will be useful. | | The requirement for at least two independent and interoperable | implementations applies to all of the options and features of the | specification. In cases in which one or more options or features | have not been demonstrated in at least two interoperable | implementations, the specification may advance to the Draft Standard | level only if those options or features are removed. | | The Working Group chair is responsible for documenting the specific | implementations which qualify the specification for Draft or Internet | Standard status along with documentation about testing of the | interoperation of these implementations. The documentation must | include information about the support of each of the individual | options and features. This documentation should be submitted to the | Area Director with the protocol action request. (see Section 6) | | A Draft Standard must be well-understood and known to be quite | stable, both in its semantics and as a basis for developing an | implementation. A Draft Standard may still require additional or | more widespread field experience, since it is possible for | implementations based on Draft Standard specifications to demonstrate | unforeseen behavior when subjected to large-scale use in production | environments. | | A Draft Standard is normally considered to be a final specification, | and changes are likely to be made only to solve specific problems | encountered. In most circumstances, it is reasonable for vendors to | deploy implementations of Draft Standards into a disruption sensitive | environment. I think we will be able to meet these requirements. I know of two Schedule MIB implementations. I would like the implementors to fill me in on the details of their implementations with respect to the requirements above, e.g., whether any objects not implemented. ------------------------------------------------------------------------ Randy Presuhn randy_presuhn@bmc.com http://www.bmc.com/ Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 2141 N. First Street Fax: +1 408 965-0359 San Jose, California 95131 USA ------------------------------------------------------------------------ Any relationship between my opinions and BMC's should be coincidental. ------------------------------------------------------------------------ From owner-disman@dorothy.peer.com Tue Apr 4 02:33:01 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21670 for ; Tue, 4 Apr 2000 02:33:01 -0400 (EDT) Received: from dorothy.peer.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id BAA04184; Tue, 4 Apr 2000 01:31:52 -0500 (CDT) Received: (from root@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id XAA12492 for disman-list; Mon, 3 Apr 2000 23:30:55 -0700 (PDT) Received: from tangelo.bmc.com (root@tangelo [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id XAA12486; Mon, 3 Apr 2000 23:30:51 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id BAA04141; Tue, 4 Apr 2000 01:31:28 -0500 (CDT) Received: from ramk-95.cisco.com (ramk-dsl4.cisco.com [10.19.11.157]) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id XAA19612; Mon, 3 Apr 2000 23:29:45 -0700 (PDT) Message-Id: <4.1.20000403223958.00a2ef00@sigma.cisco.com> X-Sender: ramk@sigma.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 03 Apr 2000 22:40:57 -0700 To: Randy Presuhn , disman@dorothy.peer.com From: "Ramanathan R. Kavasseri" Subject: Re: Notification Log MIB and Informs In-Reply-To: <200003310048.QAA21075@dorothy.bmc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list At 04:48 PM 3/30/00 -0800, Randy Presuhn wrote: > >Hi - > >> Message-ID: <6DDA62170439D31185750000F80826AC015BA3FF@zmerd004.ca.nortel.com> >> From: "Sharon Chisholm" >> To: DISMAN >> Subject: Notification Log MIB and Informs >> Date: Fri, 28 Jan 2000 07:48:27 -0600 >> List-Id: IETF disman Working Group mailing list >... >> I just did a quick scan of the notification log MIB and I noticed that it >> does >> not explicitly say how to handle retransmission of informs. I am >> assuming that the notification only gets logged once, no matter how many >> times it gets sent out. Would it be worth explicitly stating this in a >> future >> version? >... > >Your interpretation is correct with respect to a log that is >recording notifications. A log recording the traps and informs >coming into a system may record the multiple arrivals. (Consider >the case where the network loses the response to an Inform.) >The editor will consider making this more explicit when it's >time to consider advancement of the documents. Ok. Will add text to this effect. :-) Ram > ------------------------------------------------------------------------ > Randy Presuhn randy_presuhn@bmc.com http://www.bmc.com/ > Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 2141 N. First Street > Fax: +1 408 965-0359 San Jose, California 95131 USA > ------------------------------------------------------------------------ > Any relationship between my opinions and BMC's should be coincidental. > ------------------------------------------------------------------------ > From owner-disman@dorothy.peer.com Tue Apr 4 02:46:27 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21978 for ; Tue, 4 Apr 2000 02:46:27 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id BAA06541; Tue, 4 Apr 2000 01:45:32 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id XAA12688 for disman-list; Mon, 3 Apr 2000 23:44:35 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id XAA12682 for disman@dorothy.bmc.com; Mon, 3 Apr 2000 23:44:31 -0700 (PDT) Date: Mon, 3 Apr 2000 23:44:31 -0700 (PDT) From: Randy Presuhn Message-Id: <200004040644.XAA12682@dorothy.peer.com> To: disman@dorothy.peer.com Subject: Re: closing Script MIB issues Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Hi - > Message-ID: <38E8A80F.25DA4C18@france.sun.com> > Date: Mon, 03 Apr 2000 16:17:51 +0200 > From: Eamonn McManus > To: Juergen Schoenwaelder > CC: rpresuhn@dorothy.peer.com, disman@dorothy.peer.com > Subject: Re: closing Script MIB issues > References: <200003310111.RAA21185@dorothy.peer.com> <200004031357.PAA04350@henkell.ibr.cs.tu-bs.de> ... > I would like to re-suggest the scheme I described in my Simple Times article, > http://www.simple-times.org/pub/simple-times/issues/7-2.html#tools > > > * Entries can only be added to the smCodeTable before the corresponding > smScriptAdminStatus is ``enabled.'' I'd really rather avoid introducing inter-table dependencies like this. They add significantly to implementation and test complexity. > * The first entry to be added to the smCodeTable must have smCodeIndex 1, and > every subsequent entry must have smCodeIndex one more than the current largest > value. Each entry must have its smCodeRowStatus set to ``active'' before any > subsequent entry can be added. Entries once added to the smCodeTable cannot be > deleted. This is a fair amount of added implementation complexity. What's the benefit? It looks like it would save about four bytes per "line" of pushed scripts after the download, and perhaps a bit more during download to manage "quarantined" lines. > These constraints mean that during download the agent does not have to store > smCodeRowStatus or smCodeIndex values anywhere. It does have to remember where > each smCodeText object is within the script, but only while the script is being > pushed. If "read-back" of scripts is permitted, the byte-offset to index mapping within a script has to be remembered by an implementation anyway, along with the length of the "line" and so on, so that those "lines" can be reconstructed for retrieval by a manager. > * Once the script has been pushed, the manager sets the smScriptAdminStatus to > ``enabled.'' As at present, the fact that the code comes from the smCodeTable is > indicated by an empty smScriptSource and an smScriptStorageType that is > ``volatile.'' I think that the implementation needs to consider all three in order to come to the right conclusion. > * When the smScriptRowStatus is set to ``active,'' an agent may choose to delete > the smCodeTable, or it may reorganize it so that the same code is presented > using a different division into smCodeText objects. In particular it may decide > to chop up the presented text into fixed-length smCodeText objects so that it > does not have to remember the offsets corresponding to smCodeIndex values. This > means that the smCodeTable takes up no storage: the agent can construct replies > to SNMP get requests on the fly. Hmm. This means that the number of "line images" read back could be larger or smaller than the number sent. Scary. This sounds like it would be a pain to test for interoperability. I think we could agree that there isn't much point to providing a read-back facility without also providing an edit capability. > If the smScriptStorageType is then made non-volatile, the script text will be > written to non-volatile storage. > > * The only way to modify the text of a script after it has been downloaded is to > delete the smScriptEntry and create a new one. > > Éamonn (speaking in a personal capacity) As much as I dislike patches, I've been around long enough to know that there are times when there's no other choice. The argument based on script size cuts both ways; on bandwidth- limited links it's a good motivation for providing incremental update facilities, which ARE still used in machine-to-machine communications today. Based on your article and this thread, I think we have several alternatives: 1) leave smCodeTable as it as 2) deprecate smCodeTable 3) create a smSimpleCodeTable with semantics like those you describe and deprecate smCodeTable 4) add smSImpleCodeTable while retaining smCodeTable, letting implementators choose and putting some yet- to-be-defined weasel words in smScriptTable to explain which gets used when. 5) something else... >From an SNMP-download feature perspective, we have: current: download, readback, edit/patch proposed: download, readback (questionable) Does SNMP-download without readback and edit/patch make sense? ------------------------------------------------------------------------ Randy Presuhn randy_presuhn@bmc.com http://www.bmc.com/ Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 2141 N. First Street Fax: +1 408 965-0359 San Jose, California 95131 USA ------------------------------------------------------------------------ Any relationship between my opinions and BMC's should be coincidental. ------------------------------------------------------------------------ From owner-disman@dorothy.peer.com Tue Apr 4 02:51:03 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22088 for ; Tue, 4 Apr 2000 02:51:03 -0400 (EDT) Received: from dorothy.peer.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id BAA07540; Tue, 4 Apr 2000 01:50:12 -0500 (CDT) Received: (from root@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id XAA12767 for disman-list; Mon, 3 Apr 2000 23:49:13 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id XAA12761 for disman@dorothy.bmc.com; Mon, 3 Apr 2000 23:49:10 -0700 (PDT) Date: Mon, 3 Apr 2000 23:49:10 -0700 (PDT) From: Randy Presuhn Message-Id: <200004040649.XAA12761@dorothy.bmc.com> To: disman@dorothy.peer.com Subject: Re: closing Script MIB issues Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi - > Date: Mon, 3 Apr 2000 15:57:40 +0200 > Message-Id: <200004031357.PAA04350@henkell.ibr.cs.tu-bs.de> > From: Juergen Schoenwaelder > To: rpresuhn@dorothy.peer.com > CC: disman@dorothy.peer.com > In-reply-to: <200003310111.RAA21185@dorothy.peer.com> (message from Randy > Presuhn on Thu, 30 Mar 2000 17:11:57 -0800 (PST)) > Subject: Re: closing Script MIB issues > References: <200003310111.RAA21185@dorothy.peer.com> ... (Juergen's proposed issue resolutions deleted) ... > 10: Any changes needed for editing in the SNMP code table? (Juergen) > > There have been a few comments on the smCodeTable and its flexibility > regarding the numbering scheme and so on. Do we want to keep it the > way it is defined? Many implementations so far do not support it and > we may get problems with it anyway once we want to advance to Draft > standard. ... Let's get it right first, and then decide whether it's appropriate to advance. Advancement will only be used as a "tie-breaker" between otherwise equally good solutions. ------------------------------------------------------------------------ Randy Presuhn randy_presuhn@bmc.com http://www.bmc.com/ Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 2141 N. First Street Fax: +1 408 965-0359 San Jose, California 95131 USA ------------------------------------------------------------------------ Any relationship between my opinions and BMC's should be coincidental. ------------------------------------------------------------------------ From owner-disman@dorothy.peer.com Tue Apr 4 03:09:21 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22611 for ; Tue, 4 Apr 2000 03:09:20 -0400 (EDT) Received: from dorothy.peer.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id CAA11918; Tue, 4 Apr 2000 02:08:33 -0500 (CDT) Received: (from root@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id AAA12881 for disman-list; Tue, 4 Apr 2000 00:07:15 -0700 (PDT) Received: from tangelo.bmc.com (root@tangelo [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id AAA12875; Tue, 4 Apr 2000 00:07:11 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id CAA11750; Tue, 4 Apr 2000 02:07:49 -0500 (CDT) Received: from ramk-95.cisco.com (ramk-dsl4.cisco.com [10.19.11.157]) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id XAA19609; Mon, 3 Apr 2000 23:29:44 -0700 (PDT) Message-Id: <4.1.20000403223728.009d8d20@sigma.cisco.com> X-Sender: ramk@sigma.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 03 Apr 2000 22:39:31 -0700 To: Randy Presuhn , disman@dorothy.peer.com From: "Ramanathan R. Kavasseri" Subject: Re: Expression MIB value identification issue In-Reply-To: <200003310041.QAA21048@dorothy.bmc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list At 04:41 PM 3/30/00 -0800, Randy Presuhn wrote: > >Hi - > >> Message-ID: <38B17DF4.EE60B298@ipb.pt> >> Date: Mon, 21 Feb 2000 18:03:32 +0000 >> From: rp >> To: disman list >> Subject: Expression MIB value identification issue >... >> In draft-ietf-disman-express-mib-11.txt, on 3.3.4. (Value >> Identification) it mentions >> that values >> "are identified with a combination of the object identifier (OID) for >> the data type >> from expValueTable (such as expValueCounter32Val), the expression name, >> and >> an OID fragment." >> >> According to the ExpExpressionTable, each expression is identified by >> owner >> and name. The obove mentioned "expression name" includes the owner also? >... > >The owner needs to be included. The definitions of expExpressionName >makes it clear that expression names by themselves are not necessarily >unique. Yes, not having the owner looks like an oversight that needs to be fixed... >If possible, the editor will make this clarification during the >publication process. If not, the editor will track this as I'll have a draft with the expExpressionOwner object posted tomorrow... Ram >a clarification to be made when it's time to consider progression. > > ------------------------------------------------------------------------ > Randy Presuhn randy_presuhn@bmc.com http://www.bmc.com/ > Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 2141 N. First Street > Fax: +1 408 965-0359 San Jose, California 95131 USA > ------------------------------------------------------------------------ > Any relationship between my opinions and BMC's should be coincidental. > ------------------------------------------------------------------------ > From owner-disman@dorothy.peer.com Tue Apr 4 06:01:39 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26774 for ; Tue, 4 Apr 2000 06:01:39 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id EAA02333; Tue, 4 Apr 2000 04:59:18 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id CAA13116 for disman-list; Tue, 4 Apr 2000 02:57:44 -0700 (PDT) Received: from tangelo.bmc.com (root@tangelo [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id CAA13110; Tue, 4 Apr 2000 02:57:39 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id EAA02002; Tue, 4 Apr 2000 04:58:16 -0500 (CDT) Received: from France.Sun.COM ([129.157.188.1]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA12951; Tue, 4 Apr 2000 02:58:03 -0700 (PDT) Received: from sutur.France.Sun.COM by France.Sun.COM (8.8.8+Sun/SMI-SVR4-sd.fkk205) id LAA09512; Tue, 4 Apr 2000 11:58:00 +0200 (MET DST) Received: from noname.France.Sun.COM by sutur.France.Sun.COM (8.9.3+Sun/SMI-SVR4) id LAA28101; Tue, 4 Apr 2000 11:57:47 +0200 (MET DST) Received: from france.sun.com (localhost [127.0.0.1]) by noname.France.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id LAA04623; Tue, 4 Apr 2000 11:57:58 +0200 (MET DST) Message-ID: <38E9BCA6.DACD3451@france.sun.com> Date: Tue, 04 Apr 2000 11:57:58 +0200 From: Eamonn McManus Organization: Sun Microsystems, France X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u) MIME-Version: 1.0 To: Randy Presuhn CC: disman@dorothy.peer.com Subject: Re: closing Script MIB issues References: <200004040644.XAA12682@dorothy.peer.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id CAA13111 Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Randy Presuhn wrote: > > From: Eamonn McManus > > I would like to re-suggest the scheme I described in my Simple Times article, > > http://www.simple-times.org/pub/simple-times/issues/7-2.html#tools > > * Entries can only be added to the smCodeTable before the corresponding > > smScriptAdminStatus is ``enabled.'' > > I'd really rather avoid introducing inter-table dependencies like this. > They add significantly to implementation and test complexity. I don't understand this objection. There are already several such dependencies, notably in the existing smCodeTable: "Modifications of the smCodeTable are only possible if the associated smScriptOperStatus object has the value `editing'." > > * The first entry to be added to the smCodeTable must have smCodeIndex 1, and > > every subsequent entry must have smCodeIndex one more than the current largest > > value. Each entry must have its smCodeRowStatus set to ``active'' before any > > subsequent entry can be added. Entries once added to the smCodeTable cannot be > > deleted. > > This is a fair amount of added implementation complexity. What's the > benefit? It looks like it would save about four bytes per "line" of > pushed scripts after the download, and perhaps a bit more during > download to manage "quarantined" lines. On the contrary, my intent was for there to be *less* implementation complexity as well as less memory overhead. You don't need to have a table mapping line numbers to script offsets at all. You just need the offsets themselves during download, and not even that once the download is completed. I'm trying to imagine the simplest possible model for pushing scripts: you accumulate successive blocks of "text" until you have the complete script. I don't know what you mean by "quarantined" lines. I believe that if nobody has implemented script pushing it is because the current definition is too costly both in terms of implementation complexity and in terms of memory needs. Those are certainly the reasons I didn't implement it. > > These constraints mean that during download the agent does not have to store > > smCodeRowStatus or smCodeIndex values anywhere. It does have to remember where > > each smCodeText object is within the script, but only while the script is being > > pushed. > > If "read-back" of scripts is permitted, the byte-offset to index > mapping within a script has to be remembered by an implementation > anyway, along with the length of the "line" and so on, so that > those "lines" can be reconstructed for retrieval by a manager. No. I explicitly said that once the script has been downloaded the agent may redivide it into "lines" as it pleases. Therefore it can arbitrarily decide that each line is 64 bytes, say, and convert line numbers into offsets by subtracting one and multiplying by 64. This is because I don't see the utility of reading parts but not the whole of the script. > > * Once the script has been pushed, the manager sets the smScriptAdminStatus to > > ``enabled.'' As at present, the fact that the code comes from the smCodeTable is > > indicated by an empty smScriptSource and an smScriptStorageType that is > > ``volatile.'' > > I think that the implementation needs to consider all three in order to > come to the right conclusion. I'm not sure what this comment means. > > * When the smScriptRowStatus is set to ``active,'' an agent may choose to delete > > the smCodeTable, or it may reorganize it so that the same code is presented > > using a different division into smCodeText objects. In particular it may decide > > to chop up the presented text into fixed-length smCodeText objects so that it > > does not have to remember the offsets corresponding to smCodeIndex values. This > > means that the smCodeTable takes up no storage: the agent can construct replies > > to SNMP get requests on the fly. > > Hmm. This means that the number of "line images" read back > could be larger or smaller than the number sent. Scary. I suppose I'm either brave or foolhardy, but this doesn't scare me. I don't care about the lines; I just want to see the whole script. How it gets broken down into blocks during transmission is of no interest. Possibly there is a difference in perspective due to the fact that the "scripts" I was dealing with in my implementation were binary files (Java JAR files). So the division into "lines" really was (or would have been) completely arbitrary. > This sounds like it would be a pain to test for > interoperability. I think we could agree that there isn't > much point to providing a read-back facility without also > providing an edit capability. No, I don't agree with that, for the reasons I stated in my article. I don't understand under what circumstances you would want to edit a script without either reading it back into the machine doing the editing or already having a copy on that machine. I really don't believe in hand-applied "patches" in this sort of environment. Do you imagine there being an editor with a GUI that talks SNMP to the agent in order to read a screenful of script text and propagate changes back to the agent? If not, how would you see patches being prepared and applied? It may be that I am blinkered by thinking about my implementation, but I just don't understand the sort of environment where the current smCodeTable would be useful. > Based on your article and this thread, I think we have several > alternatives: > 1) leave smCodeTable as it as > 2) deprecate smCodeTable > 3) create a smSimpleCodeTable with semantics like those > you describe and deprecate smCodeTable > 4) add smSImpleCodeTable while retaining smCodeTable, > letting implementators choose and putting some yet- > to-be-defined weasel words in smScriptTable to explain > which gets used when. As you might guess, I'd favour (3). (4) might be an interesting experiment to see whether anybody in the world chooses to implement the feature-laden smCodeTable. But standards are not really the place for experiments. > From an SNMP-download feature perspective, we have: > > current: download, readback, edit/patch > proposed: download, readback (questionable) To clarify, readback is not "questionable" but "optional". A management system dealing with an agent that doesn't support it must support another approach, such as remembering or refetching the script text. One reason not to support readback might be that the agent transforms the script into an internal form and would have no other reason to retain the original form than to send it back to the manager. But I wouldn't be unhappy with a decision that readback is mandatory. > Does SNMP-download without readback and edit/patch make sense? Yes. In the system I was working with, we wanted to be able to send scripts from a local repository to a remotely-managed system. We weren't interested in reading the scripts back, because the name of the script was enough to find its text in the local repository. But the Script MIB as it stands required us either to have a private HTTP or FTP server as part of the management system, or to support the smCodeTable. Both solutions seemed very ugly to me, but the former was less ugly than the latter, and shouldn't have been. Éamonn (writing in a personal capacity) From owner-disman@dorothy.peer.com Tue Apr 4 12:54:36 2000 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08804 for ; Tue, 4 Apr 2000 12:54:30 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id LAA04692; Tue, 4 Apr 2000 11:52:57 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA13969 for disman-list; Tue, 4 Apr 2000 09:49:07 -0700 (PDT) Received: from tangelo.bmc.com (root@tangelo [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA13964 for ; Tue, 4 Apr 2000 09:49:03 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id LAA03171 for ; Tue, 4 Apr 2000 11:49:40 -0500 (CDT) Received: from ccrle.nec.de (cologne.berlin.ccrle.nec.de [192.168.100.79]) by tokyo.ccrle.nec.de (8.8.7/3.6W980303HK) with ESMTP id SAA23494; Tue, 4 Apr 2000 18:48:37 +0200 (CEST) Message-ID: <38EA1E91.3867CDA8@ccrle.nec.de> Date: Tue, 04 Apr 2000 18:55:45 +0200 From: Juergen Quittek Organization: NEC Europe Ltd. X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Schoenwaelder CC: disman@dorothy.peer.com Subject: Re: closing Script MIB issues References: <200003310111.RAA21185@dorothy.peer.com> <200004031357.PAA04350@henkell.ibr.cs.tu-bs.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit I'd like to add another Script MIB issue that has not been discussed before: 11: Script resource consumption indication (in the run table) Scripts running on managed nodes consume resources. If you want to avoid overloading of a node it is very helpful to get information about the scripts' resource consumption. You might decide not to run a script on a certain node, if you find out that it is almost overloaded. Or you might decide to terminate the biggest consumer of resources before you start your new script. Similar to the Host Resources Running Software Performance Group (hrSWRunPerfTable) in the Host Resources MIB, I suggest to extend smRunEntry by two more objects: smRunPerfCPU INTEGER smRunPerfMem KBytes smRunPerfCPU indicates the number of centi-seconds of the total system's CPU resources consumed by the respective running instance of the script. smRunPerfMem indicates the total amount of real system memory allocated to the running instance. I see the problem, that this information might not available on all systems implementing the Script MIB or that it might not be available for all languages supported by a Script MIB implementation. However, I consider it very helpful to get this information whenever it is available. Unavailability could be indicated by value zero. An alternative would be the introduction of a separate table or even a separate (and optional?) group as it is the case in the Host Resource MIB. But I do not like the idea of adding another table. Implementing the existing tables already seems to be enough work. Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 30 254230-19 NEC Europe Ltd., C&C Research Laboratories Fax: +49 30 254230-99 Hardenbergplatz 2, 10623 Berlin, Germany http://www.ccrle.nec.de Juergen Schoenwaelder wrote: > > >>>>> Randy Presuhn writes: > > Randy> We need to get closure on the Script MIB issues so we can do a > Randy> WG last call before requesting advancement to Draft Standard. > Randy> Issues from the i-d: > > Randy> 02: Restartable scripts > > I think the strawman here was to have an smLaunchFlags objects of type > BITS which indicates whether a script is being restarted on > reinitialization. > > Randy> 03: Error message during script retrieval or compilation ( > Randy> smScriptError) > > I think the strawman here was to add an smScriptError object which > contains the last error message generated. > > Randy> 04: Scripts that can run forever without having to reset > Randy> smRunLifeTime > > I think the strawman here was to give the max. smRunLifeTime value a > special meaning (which stops the timer from decrementing). > > Randy> 05: Index smLangTable and smExtsnTable by name rather than > Randy> Integer32 > > Randy> 06: Dependencies between scripts and script versioning > Randy> (Eamonn) > > Randy> 07: Storage type of script code versus storage type of > Randy> script meta information > > Randy> All issues on which there are no contributions within the next > Randy> two weeks will be closed with a status of "no action". > > I have a few more issues in my list: > > 08: Final polling missing in procedures 7.6 and 7.7 (Frank) > > I think a suitable clarification should be added to these sections. > > 09: Add procedures for suspend/resume/purge to section 7 (Frank) > > I think it is helpful to define these procedures. > > 10: Any changes needed for editing in the SNMP code table? (Juergen) > > There have been a few comments on the smCodeTable and its flexibility > regarding the numbering scheme and so on. Do we want to keep it the > way it is defined? Many implementations so far do not support it and > we may get problems with it anyway once we want to advance to Draft > standard. > > /js > > -- > Juergen Schoenwaelder Technical University Braunschweig > Dept. Operating Systems & Computer Networks > Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany > Fax: +49 531 391 5936 From owner-disman@dorothy.peer.com Tue Apr 4 16:58:57 2000 Received: from tangelo.bmc.com ([198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16135 for ; Tue, 4 Apr 2000 16:58:57 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id PAA22055; Tue, 4 Apr 2000 15:57:35 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA17042 for disman-list; Tue, 4 Apr 2000 13:54:34 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id NAA17034 for disman@dorothy.bmc.com; Tue, 4 Apr 2000 13:54:28 -0700 (PDT) Date: Tue, 4 Apr 2000 13:54:28 -0700 (PDT) From: Randy Presuhn Message-Id: <200004042054.NAA17034@dorothy.peer.com> To: disman@dorothy.peer.com Subject: Re: closing Script MIB issues Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Hi - > Message-ID: <38E9BCA6.DACD3451@france.sun.com> > Date: Tue, 04 Apr 2000 11:57:58 +0200 > From: Eamonn McManus > To: Randy Presuhn > CC: disman@dorothy.peer.com > Subject: Re: closing Script MIB issues > References: <200004040644.XAA12682@dorothy.peer.com> > List-Id: IETF disman Working Group mailing list > > > Randy Presuhn wrote: > > > From: Eamonn McManus > > > I would like to re-suggest the scheme I described in my Simple Times article, > > > http://www.simple-times.org/pub/simple-times/issues/7-2.html#tools > > > * Entries can only be added to the smCodeTable before the corresponding > > > smScriptAdminStatus is ``enabled.'' > > > > I'd really rather avoid introducing inter-table dependencies like this. > > They add significantly to implementation and test complexity. > > I don't understand this objection. There are already several such dependencies, > notably in the existing smCodeTable: "Modifications of the smCodeTable are only > possible if the associated smScriptOperStatus object has the value `editing'." It's bad enough to make one table dependent on a value in another (the current situation). It's worse to make a table dependent on an object in another having not had some particular value at some time in the past (the proposal). It wouldn't bother me as much if the proposal read "when the corresponding smScriptAdminStatus is not 'enabled' rather than "before the corresponding smScriptAdminStatus is 'enabled'". > > > * The first entry to be added to the smCodeTable must have smCodeIndex 1, and > > > every subsequent entry must have smCodeIndex one more than the current largest > > > value. Each entry must have its smCodeRowStatus set to ``active'' before any > > > subsequent entry can be added. Entries once added to the smCodeTable cannot be > > > deleted. > > > > This is a fair amount of added implementation complexity. What's the > > benefit? It looks like it would save about four bytes per "line" of > > pushed scripts after the download, and perhaps a bit more during > > download to manage "quarantined" lines. > > On the contrary, my intent was for there to be *less* implementation complexity > as well as less memory overhead. You don't need to have a table mapping line > numbers to script offsets at all. You just need the offsets themselves during > download, and not even that once the download is completed. I'm trying to > imagine the simplest possible model for pushing scripts: you accumulate > successive blocks of "text" until you have the complete script. This is asking for trouble with typical "conformance" test tools that check mib implementations by checking that what comes back in response to a get request is the same as what was written by the most recent set request for that object. > I don't know what you mean by "quarantined" lines. A line image that is not "active". At least some level of quarantine is necessary to implement RowStatus correctly so that partially-created things (createAndWait) can be cleaned up. > I believe that if nobody has implemented script pushing it is because the > current definition is too costly both in terms of implementation complexity and > in terms of memory needs. Those are certainly the reasons I didn't implement > it. If we find that there are not at least two implementations of this capability, and we decide that the document is otherwise ready to advance, then our only sensible option is to deprecate the table. > > > These constraints mean that during download the agent does not have to store > > > smCodeRowStatus or smCodeIndex values anywhere. It does have to remember where > > > each smCodeText object is within the script, but only while the script is being > > > pushed. > > > > If "read-back" of scripts is permitted, the byte-offset to index > > mapping within a script has to be remembered by an implementation > > anyway, along with the length of the "line" and so on, so that > > those "lines" can be reconstructed for retrieval by a manager. > > No. I explicitly said that once the script has been downloaded the agent may > redivide it into "lines" as it pleases. Therefore it can arbitrarily decide > that each line is 64 bytes, say, and convert line numbers into offsets by > subtracting one and multiplying by 64. This is because I don't see the utility > of reading parts but not the whole of the script. If there is no editing facility, why bother reading it back at all? If the requirement is to verify that the right script has been downloaded, there are much cheaper ways, like a message digest. > > > * Once the script has been pushed, the manager sets the smScriptAdminStatus to > > > ``enabled.'' As at present, the fact that the code comes from the smCodeTable is > > > indicated by an empty smScriptSource and an smScriptStorageType that is > > > ``volatile.'' > > > > I think that the implementation needs to consider all three in order to > > come to the right conclusion. > > I'm not sure what this comment means. > > > > * When the smScriptRowStatus is set to ``active,'' an agent may choose to delete > > > the smCodeTable, or it may reorganize it so that the same code is presented > > > using a different division into smCodeText objects. In particular it may decide > > > to chop up the presented text into fixed-length smCodeText objects so that it > > > does not have to remember the offsets corresponding to smCodeIndex values. This > > > means that the smCodeTable takes up no storage: the agent can construct replies > > > to SNMP get requests on the fly. > > > > Hmm. This means that the number of "line images" read back > > could be larger or smaller than the number sent. Scary. > > I suppose I'm either brave or foolhardy, but this doesn't scare me. I don't > care about the lines; I just want to see the whole script. How it gets broken > down into blocks during transmission is of no interest. > > Possibly there is a difference in perspective due to the fact that the "scripts" > I was dealing with in my implementation were binary files (Java JAR files). So > the division into "lines" really was (or would have been) completely arbitrary. > > > This sounds like it would be a pain to test for > > interoperability. I think we could agree that there isn't > > much point to providing a read-back facility without also > > providing an edit capability. > > No, I don't agree with that, for the reasons I stated in my article. I don't > understand under what circumstances you would want to edit a script without > either reading it back into the machine doing the editing or already having a > copy on that machine. I really don't believe in hand-applied "patches" in this > sort of environment. Do you imagine there being an editor with a GUI that talks > SNMP to the agent in order to read a screenful of script text and propagate > changes back to the agent? If not, how would you see patches being prepared and > applied? It may be that I am blinkered by thinking about my implementation, but > I just don't understand the sort of environment where the current smCodeTable > would be useful. Perhaps because you deleted the following text from my message: | As much as I dislike patches, I've been around long enough | to know that there are times when there's no other choice. | The argument based on script size cuts both ways; on bandwidth- | limited links it's a good motivation for providing incremental | update facilities, which ARE still used in machine-to-machine | communications today. > > Based on your article and this thread, I think we have several > > alternatives: > > 1) leave smCodeTable as it as > > 2) deprecate smCodeTable > > 3) create a smSimpleCodeTable with semantics like those > > you describe and deprecate smCodeTable > > 4) add smSImpleCodeTable while retaining smCodeTable, > > letting implementators choose and putting some yet- > > to-be-defined weasel words in smScriptTable to explain > > which gets used when. > > As you might guess, I'd favour (3). (4) might be an interesting experiment to > see whether anybody in the world chooses to implement the feature-laden > smCodeTable. But standards are not really the place for experiments. > > > From an SNMP-download feature perspective, we have: > > > > current: download, readback, edit/patch > > proposed: download, readback (questionable) > > To clarify, readback is not "questionable" but "optional". A management system > dealing with an agent that doesn't support it must support another approach, > such as remembering or refetching the script text. One reason not to support > readback might be that the agent transforms the script into an internal form and > would have no other reason to retain the original form than to send it back to > the manager. But I wouldn't be unhappy with a decision that readback is > mandatory. Making readback optional would be a big mistake, in my opinion. It needs to be either a mandatory capability or not supported at all. The decision should depend on an understanding of the requirements. Possibilities might be: 1) verification that the script is intact - does not require readback per se, a message digest would suffice 2) support for editing / patching / incremental update - does not require readback per se, but does require that indexes and offsets into the script content remain stable > > Does SNMP-download without readback and edit/patch make sense? > > Yes. In the system I was working with, we wanted to be able to send scripts > from a local repository to a remotely-managed system. We weren't interested in > reading the scripts back, because the name of the script was enough to find its > text in the local repository. But the Script MIB as it stands required us > either to have a private HTTP or FTP server as part of the management system, or > to support the smCodeTable. Both solutions seemed very ugly to me, but the > former was less ugly than the latter, and shouldn't have been. ... RFC 2592's use of URLs doesn't limit implementations to FTP and HTTP. Those are just given as examples. The smCodeTable is a consequence of this requirement from section 4: | o The Script MIB must provide SNMP interfaces to all functions | required to delegate management scripts. However, other | protocols might be used in addition if they provide a | significant improvement in terms of convenience for | implementation or performance. In getting rid of smCodeTable (if no one supports it) and possibly replacing it with something else, we need to consider: - whether we need to support SNMP-based download, or are willing to depend on other protocols for that function - whether incremental updates / patches are something we need to support, especially in bandwidth-limited environments. - whether script readback is needed - whether other script integrity checks (e.g. MD5 or SHA) make sense ------------------------------------------------------------------------ Randy Presuhn randy_presuhn@bmc.com http://www.bmc.com/ Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 2141 N. First Street Fax: +1 408 965-0359 San Jose, California 95131 USA ------------------------------------------------------------------------ Any relationship between my opinions and BMC's should be coincidental. ------------------------------------------------------------------------ From owner-disman@dorothy.peer.com Tue Apr 4 17:32:09 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17193 for ; Tue, 4 Apr 2000 17:32:08 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id QAA05978; Tue, 4 Apr 2000 16:30:41 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA17309 for disman-list; Tue, 4 Apr 2000 14:28:05 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA17303; Tue, 4 Apr 2000 14:28:01 -0700 (PDT) Date: Tue, 4 Apr 2000 14:28:01 -0700 (PDT) From: Randy Presuhn Message-Id: <200004042128.OAA17303@dorothy.bmc.com> To: applmib@ietf.verio.net, disman@dorothy.peer.com Subject: DEFVAL for DateAndTimes Cc: mibs@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi - A conversation with Dave Perkins in an Australian airport uncovered a possible problem with RFCs 2592, 2591, and 2564. RFC 2579's description of DateAndTime says: | field octets contents range | ----- ------ -------- ----- | 1 1-2 year* 0..65536 | 2 3 month 1..12 | 3 4 day 1..31 | 4 5 hour 0..23 | 5 6 minutes 0..59 | 6 7 seconds 0..60 | (use 60 for leap-second) | 7 8 deci-seconds 0..9 | 8 9 direction from UTC '+' / '-' | 9 10 hours from UTC* 0..13 | 10 11 minutes from UTC 0..59 These other documents have DEFVALs for DateAndTime of '0000000000000000'H. These values would be technically illegal, and should probably be replaced with '0000010100000000'H when these documents are revised. (Alternatively, we could just recognize the existing, though technically illegal, practice and get on with more interesting problems. :-) A related annoying question: if the time has an offset of 00:00 from UTC, would the preferred value for byte 9 be a '+' or a '-'? ------------------------------------------------------------------------ Randy Presuhn randy_presuhn@bmc.com http://www.bmc.com/ Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 2141 N. First Street Fax: +1 408 965-0359 San Jose, California 95131 USA ------------------------------------------------------------------------ Any relationship between my opinions and BMC's should be coincidental. ------------------------------------------------------------------------ From owner-disman@dorothy.peer.com Wed Apr 5 04:24:08 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07131 for ; Wed, 5 Apr 2000 04:24:06 -0400 (EDT) Received: from dorothy.peer.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id DAA14970; Wed, 5 Apr 2000 03:22:42 -0500 (CDT) Received: (from root@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id BAA21189 for disman-list; Wed, 5 Apr 2000 01:20:10 -0700 (PDT) Received: from tangelo.bmc.com (root@tangelo [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id BAA21183; Wed, 5 Apr 2000 01:20:06 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id DAA14639; Wed, 5 Apr 2000 03:20:43 -0500 (CDT) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id KAA04272; Wed, 5 Apr 2000 10:20:50 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id KAA05775; Wed, 5 Apr 2000 10:20:37 +0200 Date: Wed, 5 Apr 2000 10:20:37 +0200 Message-Id: <200004050820.KAA05775@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: rpresuhn@dorothy.peer.com CC: disman@dorothy.peer.com In-reply-to: <200004042054.NAA17034@dorothy.peer.com> (message from Randy Presuhn on Tue, 4 Apr 2000 13:54:28 -0700 (PDT)) Subject: Re: closing Script MIB issues References: <200004042054.NAA17034@dorothy.peer.com> Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list [The comments below are slightly off topic but I had to jump in here.] >>>>> Randy Presuhn writes: Randy> It's bad enough to make one table dependent on a value in Randy> another (the current situation). There are IMHO cases where you need to have table interdependencies. Just saying it is bad makes me feel a bit uncomfortable since it ignores reality. (I would be interested to see how you can define the Script MIB functionality without any table interdependencies.) Randy> This is asking for trouble with typical "conformance" test Randy> tools that check mib implementations by checking that what Randy> comes back in response to a get request is the same as what was Randy> written by the most recent set request for that object. It is not our job to define MIBs so that typical "conformance" test tools make the right assumptions. Every object which triggers an underlying state machinery has the property that subsequent gets may return different values. We have several of these objects in various MIBs. I think an argument that this should be avoided since it breaks typical "conformance" test tools is not valid. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-disman@dorothy.peer.com Wed Apr 5 06:43:20 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07969 for ; Wed, 5 Apr 2000 06:43:19 -0400 (EDT) Received: from dorothy.peer.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id FAA08768; Wed, 5 Apr 2000 05:42:15 -0500 (CDT) Received: (from root@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id DAA21418 for disman-list; Wed, 5 Apr 2000 03:40:47 -0700 (PDT) Received: from tangelo.bmc.com (root@tangelo [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id DAA21412; Wed, 5 Apr 2000 03:40:42 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id FAA08618; Wed, 5 Apr 2000 05:41:19 -0500 (CDT) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id MAA13457; Wed, 5 Apr 2000 12:41:15 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id MAA10838; Wed, 5 Apr 2000 12:41:00 +0200 Date: Wed, 5 Apr 2000 12:41:00 +0200 Message-Id: <200004051041.MAA10838@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: rpresuhn@dorothy.peer.com CC: applmib@ietf.verio.net, disman@dorothy.peer.com, mibs@ops.ietf.org In-reply-to: <200004042128.OAA17303@dorothy.bmc.com> (message from Randy Presuhn on Tue, 4 Apr 2000 14:28:01 -0700 (PDT)) Subject: Re: DEFVAL for DateAndTimes References: <200004042128.OAA17303@dorothy.bmc.com> Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list [Please send any followups only to since this is really a cross WG issue.] >>>>> Randy Presuhn writes: Randy> A conversation with Dave Perkins in an Australian airport Randy> uncovered a possible problem with RFCs 2592, 2591, and 2564. Randy> RFC 2579's description of DateAndTime says: [...] Randy> These other documents have DEFVALs for DateAndTime of Randy> '0000000000000000'H. These values would be technically Randy> illegal, and should probably be replaced with Randy> '0000010100000000'H when these documents are revised. The TN3270E-MIB (RFC 2561), TN3270E-RT-MIB (RFC 2562) and WWW-MIB (RFC 2594) also use this not strictly legal default value. I could not find a single MIB which uses '0000010100000000'H. Randy> (Alternatively, we could just recognize the existing, though Randy> technically illegal, practice and get on with more interesting Randy> problems. :-) I think that recognizing the existing, though technically illegal, practice is the right thing to do. I will take care that the SMIng definition of DateAndTime fixes this problem by explicitely allowing the value '0000000000000000'H to indicate an unknown date and time value. ;-) Randy> A related annoying question: if the time has an offset of 00:00 Randy> from UTC, would the preferred value for byte 9 be a '+' or a Randy> '-'? I think both are valid and semantically identical. Not sure we need to agree on a preferred value for byte 9 (although I would choose '+'). /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-disman@dorothy.peer.com Wed Apr 5 07:06:08 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08200 for ; Wed, 5 Apr 2000 07:06:07 -0400 (EDT) Received: from dorothy.peer.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id GAA12157; Wed, 5 Apr 2000 06:05:20 -0500 (CDT) Received: (from root@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id EAA21474 for disman-list; Wed, 5 Apr 2000 04:04:24 -0700 (PDT) Received: from tangelo.bmc.com (root@tangelo [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id EAA21469 for ; Wed, 5 Apr 2000 04:04:20 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id GAA12062 for ; Wed, 5 Apr 2000 06:04:58 -0500 (CDT) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id NAA14997; Wed, 5 Apr 2000 13:04:58 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id NAA11728; Wed, 5 Apr 2000 13:04:44 +0200 Date: Wed, 5 Apr 2000 13:04:44 +0200 Message-Id: <200004051104.NAA11728@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: quittek@ccrle.nec.de CC: disman@dorothy.peer.com In-reply-to: <38EA1E91.3867CDA8@ccrle.nec.de> (message from Juergen Quittek on Tue, 04 Apr 2000 18:55:45 +0200) Subject: Re: closing Script MIB issues References: <200003310111.RAA21185@dorothy.peer.com> <200004031357.PAA04350@henkell.ibr.cs.tu-bs.de> <38EA1E91.3867CDA8@ccrle.nec.de> Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> Juergen Quittek writes: Juergen> I'd like to add another Script MIB issue that has not been Juergen> discussed before: Juergen> 11: Script resource consumption indication (in the run Juergen> table) [...] Juergen> I see the problem, that this information might not available Juergen> on all systems implementing the Script MIB or that it might Juergen> not be available for all languages supported by a Script MIB Juergen> implementation. However, I consider it very helpful to get Juergen> this information whenever it is available. Unavailability Juergen> could be indicated by value zero. I believe that this is nearly impossible to implement and that the numbers are hard to interpret on the manager's side. The Jasmin implementation is capable to execute multiple scripts in one runtime system (an operating system process) and it is really hard to calculate how much CPU time is consumed by each thread or how much memory consumption is caused by each thread. I believe that the only metric that can be reasonably implemented are resource usage statistics for the runtime systems but not for each running script. However, this requires to make the mapping of running scripts to runtime engines explicit (for examply by adding a column which contains the PID of the underlying operating system process). Once you have this mapping, you can actually look into the host resources MIB to get the actual numbers. Just to be clear: I certainly understand the need for resource consumption indicators. However, I do not see how you can define something which is sufficiently clear so that a manager can actually base decisions on it and which is at the same time implementable for arbitrary languages and runtime systems. Do you think smRunPerfCPU and smRunPerfMem are implementable in the Jasmin Java runtime without any guesses? /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-disman@dorothy.peer.com Wed Apr 5 12:10:00 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12254 for ; Wed, 5 Apr 2000 12:09:59 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id LAA18755; Wed, 5 Apr 2000 11:08:06 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA21971 for disman-list; Wed, 5 Apr 2000 09:05:29 -0700 (PDT) Received: from tangelo.bmc.com (root@tangelo [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA21966 for ; Wed, 5 Apr 2000 09:05:25 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id LAA17935 for ; Wed, 5 Apr 2000 11:06:03 -0500 (CDT) Received: from seymour47.SNMP.COM (seymour47.snmp.com [192.147.142.47]) by seymour39.SNMP.COM (8.9.3/m.000221) with ESMTP id MAA05142; Wed, 5 Apr 2000 12:05:51 -0400 (EDT) From: Alan Luchuk Received: (from luchuk@localhost) by seymour47.SNMP.COM (8.9.3/snmpclient.mc-990423) id MAA02597; Wed, 5 Apr 2000 12:05:51 -0400 (EDT) Date: Wed, 5 Apr 2000 12:05:51 -0400 (EDT) Message-Id: <200004051605.MAA02597@seymour47.SNMP.COM> To: disman@dorothy.peer.com Subject: Re: Closing sched MIB issues Cc: luchuk@snmp.com Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Hello all, I've shifted my brain out of "other project" mode and am now following (and (*gasp*) thinking about) DISMAN issues. And of course, I'm timely as always :-) >> There were two issues that are not reflected in this ID: >> >> 02: Can the SNMP manager modify CalendarGroup objects and >> schedInterval object when the schedRowStatus is in 'active' >> state? >> >> Strawman: schedInterval and friends can be changed even if >> schedRowStatus is active and schedAdminStatus and schedOperStatus >> are enabled. I support the strawman. I believe this is a correct operation from an SNMP perspective; that is, generally one can change values in table rows when the rows are active. >> 03: Clarification requires on multiple events in nonexistent times? >> >> Strawman: Add the following text below the last paragraph of >> section 3.4 in RFC 2591: >> >> This rule applies to all events scheduled for nonexistent >> time, regardless whether the scheduled events originate from >> one or multiple rows in the schedTable. >> >> At least one WG member said that the behaviour regarding issue 03 >> should be configurable. And that is where discussion stopped, if I >> remember right. >> >> Bottom line: I think I know the edits for 02. I am not so sure with >> regard to 03. (Personally, I prefer the strawman because making the >> behaviour in this corner case configurable adds quite some complexity >> which is hard to test.) I also support this strawman for the reason stated above: "making the behaviour in this corner case configurable adds quite some complexity." Regards, --Alan ----------------------------------------------------------------------------- Alan Luchuk SNMP Research, Inc. Voice: +1 865 573 1434 Software Engineer 3001 Kimberlin Heights Road FAX: +1 865 573 9197 luchuk@snmp.com Knoxville, TN 37920-9716 U.S.A. http://www.snmp.com/ ----------------------------------------------------------------------------- Note: Our area code changed to 865 from 423 in November. If you have trouble reaching us via area code 865, please try the old area code (423) and let us know. Both area codes should work until April. From owner-disman@dorothy.peer.com Wed Apr 5 12:35:31 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12574 for ; Wed, 5 Apr 2000 12:35:30 -0400 (EDT) Received: from dorothy.peer.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id LAA28333; Wed, 5 Apr 2000 11:34:34 -0500 (CDT) Received: (from root@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id JAA22052 for disman-list; Wed, 5 Apr 2000 09:33:26 -0700 (PDT) Received: from tangelo.bmc.com (root@tangelo [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA22047 for ; Wed, 5 Apr 2000 09:33:22 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id LAA28138 for ; Wed, 5 Apr 2000 11:33:59 -0500 (CDT) Received: from seymour47.SNMP.COM (seymour47.snmp.com [192.147.142.47]) by seymour39.SNMP.COM (8.9.3/m.000221) with ESMTP id MAA05880; Wed, 5 Apr 2000 12:33:54 -0400 (EDT) From: Alan Luchuk Received: (from luchuk@localhost) by seymour47.SNMP.COM (8.9.3/snmpclient.mc-990423) id MAA02687; Wed, 5 Apr 2000 12:33:53 -0400 (EDT) Date: Wed, 5 Apr 2000 12:33:53 -0400 (EDT) Message-Id: <200004051633.MAA02687@seymour47.SNMP.COM> To: disman@dorothy.peer.com Subject: Re: Closing Script MIB issues Cc: luchuk@snmp.com Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Hello all, >>>>>> Randy Presuhn writes: > >Randy> We need to get closure on the Script MIB issues so we can do a >Randy> WG last call before requesting advancement to Draft Standard. >Randy> Issues from the i-d: > >Randy> 02: Restartable scripts > >I think the strawman here was to have an smLaunchFlags objects of type >BITS which indicates whether a script is being restarted on >reinitialization. I support the proposal to add the smLaunchFlags objects of type BITS which indicates whether a script is being restarted on reinitialization. >Randy> 03: Error message during script retrieval or compilation ( >Randy> smScriptError) > >I think the strawman here was to add an smScriptError object which >contains the last error message generated. I support the proposal to add an smScriptError object which contains the last error message generated. >Randy> 04: Scripts that can run forever without having to reset >Randy> smRunLifeTime > >I think the strawman here was to give the max. smRunLifeTime value a >special meaning (which stops the timer from decrementing). I support the proposal to to give the maximum smRunLifeTime value a special meaning that stops the timer from decrementing. >Randy> 05: Index smLangTable and smExtsnTable by name rather than >Randy> Integer32 I can align with this proposal. >Randy> 06: Dependencies between scripts and script versioning >Randy> (Eamonn) > >Randy> 07: Storage type of script code versus storage type of >Randy> script meta information If possible, could someone (privately) refresh my memory about the meaning of these two terse descriptions or point me to a better description. >Randy> All issues on which there are no contributions within the next >Randy> two weeks will be closed with a status of "no action". > >I have a few more issues in my list: > > 08: Final polling missing in procedures 7.6 and 7.7 (Frank) > >I think a suitable clarification should be added to these sections. > > 09: Add procedures for suspend/resume/purge to section 7 (Frank) > >I think it is helpful to define these procedures. > > 10: Any changes needed for editing in the SNMP code table? (Juergen) > >There have been a few comments on the smCodeTable and its flexibility >regarding the numbering scheme and so on. Do we want to keep it the >way it is defined? Many implementations so far do not support it and >we may get problems with it anyway once we want to advance to Draft >standard. I support keeping the smCodeTable. Justification: 1. Keeping the smCodeTable in the MIB does not mandate its implementation. 2. Keeping the smCodeTable allows an all-SNMP solution for populating scripts in the script MIB. Omitting the smCodeTable would require the script MIB agent support TCP/HTTP and/or other protocols necess- ary only for pulling scripts into the script MIB. Eliminating other protocols (and their software code size) may be an issue in some embedded environments. 3. The implementation complexity of supporting "pushing" scripts into the smCodeTable is less than, or certainly no greater than, the implementation complexity of supporting "pulling" scripts into the agent. I argue that the complexity of supporting the smCodeTable and reading scripts from the smCodeTable is less than the complexity of parsing URLs, "pulling" scripts using FTP/HTTP, and handling possible download error conditions. 4. Although SNMP is inefficent as a bulk data transfer mechanism, SNMP's bulk data transfer efficiency is really a non-issue here because: a. scripts will tend to be loaded relatively infrequently; and b. scripts will be relatively small, not like booting a whole workstation over the net. 5. To be politically correct: celebrate diversity. Regards, --Alan ----------------------------------------------------------------------------- Alan Luchuk SNMP Research, Inc. Voice: +1 865 573 1434 Software Engineer 3001 Kimberlin Heights Road FAX: +1 865 573 9197 luchuk@snmp.com Knoxville, TN 37920-9716 U.S.A. http://www.snmp.com/ ----------------------------------------------------------------------------- Note: Our area code changed to 865 from 423 in November. If you have trouble reaching us via area code 865, please try the old area code (423) and let us know. Both area codes should work until April. From owner-disman@dorothy.peer.com Wed Apr 5 13:30:32 2000 Received: from tangelo.bmc.com ([198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13452 for ; Wed, 5 Apr 2000 13:30:26 -0400 (EDT) Received: from dorothy.peer.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id MAA16337; Wed, 5 Apr 2000 12:28:25 -0500 (CDT) Received: (from root@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id KAA22555 for disman-list; Wed, 5 Apr 2000 10:22:16 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA22549 for disman@dorothy.peer.com; Wed, 5 Apr 2000 10:22:13 -0700 (PDT) Date: Wed, 5 Apr 2000 10:22:13 -0700 (PDT) From: Randy Presuhn Message-Id: <200004051722.KAA22549@dorothy.bmc.com> To: disman@dorothy.peer.com Subject: Re: Closing Script MIB issues Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi - > From: Alan Luchuk > Date: Wed, 5 Apr 2000 12:33:53 -0400 (EDT) > Message-Id: <200004051633.MAA02687@seymour47.SNMP.COM> > To: disman@dorothy.peer.com > Subject: Re: Closing Script MIB issues > Cc: luchuk@snmp.com > List-Id: IETF disman Working Group mailing list ... > >Randy> 06: Dependencies between scripts and script versioning > >Randy> (Eamonn) > > > >Randy> 07: Storage type of script code versus storage type of > >Randy> script meta information > > If possible, could someone (privately) refresh my memory about > the meaning of these two terse descriptions or point me to a > better description. ... I agree that the descriptions are a bit terse. Here's my understanding of what the concerns are. Issue 06: Although the MIB has several objects to deal with the problem of language and language extension versions, there is nothing to explicitly identify the version of a script. As the MIB currently stands, administration would have to resort to things like file naming conventions to represent this information. Furthermore, going a bit further down the path of configuration management issues, there is no explicit representation of interdependencies between scripts. Whether either of these is a hard requirement is open to debate. Issue 07: The value of smScriptStorageType is currently defined as controlling the persistence of BOTH the smScriptEntry and the script itself. This seems reasonable in the case where the script is in smCodeTable, but is not what is intended if smScriptSource is an URL. This is explained in a couple locations in the document, so I think no action is needed. Please correct me if I've gotten these wrong. ------------------------------------------------------------------------ Randy Presuhn randy_presuhn@bmc.com http://www.bmc.com/ Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 2141 N. First Street Fax: +1 408 965-0359 San Jose, California 95131 USA ------------------------------------------------------------------------ Any relationship between my opinions and BMC's should be coincidental. ------------------------------------------------------------------------ From owner-disman@dorothy.peer.com Wed Apr 5 13:31:02 2000 Received: from tangelo.bmc.com ([198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13488 for ; Wed, 5 Apr 2000 13:31:01 -0400 (EDT) Received: from dorothy.peer.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id MAA16334; Wed, 5 Apr 2000 12:28:25 -0500 (CDT) Received: (from root@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id KAA22538 for disman-list; Wed, 5 Apr 2000 10:16:58 -0700 (PDT) Received: from tangelo.bmc.com (root@tangelo [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA22533 for ; Wed, 5 Apr 2000 10:16:55 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id MAA12997 for ; Wed, 5 Apr 2000 12:17:32 -0500 (CDT) Received: from seymour47.SNMP.COM (seymour47.snmp.com [192.147.142.47]) by seymour39.SNMP.COM (8.9.3/m.000221) with ESMTP id NAA07340; Wed, 5 Apr 2000 13:17:18 -0400 (EDT) From: Alan Luchuk Received: (from luchuk@localhost) by seymour47.SNMP.COM (8.9.3/snmpclient.mc-990423) id NAA02735; Wed, 5 Apr 2000 13:17:17 -0400 (EDT) Date: Wed, 5 Apr 2000 13:17:17 -0400 (EDT) Message-Id: <200004051717.NAA02735@seymour47.SNMP.COM> To: disman@dorothy.peer.com Subject: e: RFC 2591 (schedule MIB) implementations Cc: luchuk@snmp.com Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Hello all, >Hi - > >It's time to consider whether we'll be ready to request that >the RFC 2591 Schedule MIB be advanced from "Proposed Standard" >to "Draft Standard." As a memory refresher, here are the >requirements from RFC 2026: > >|4.1.2 Draft Standard >| >| A specification from which at least two independent and interoperable >| implementations from different code bases have been developed, and >| for which sufficient successful operational experience has been >| obtained, may be elevated to the "Draft Standard" level. For the >| purposes of this section, "interoperable" means to be functionally >| equivalent or interchangeable components of the system or process in >| which they are used. If patented or otherwise controlled technology >| is required for implementation, the separate implementations must >| also have resulted from separate exercise of the licensing process. >| Elevation to Draft Standard is a major advance in status, indicating >| a strong belief that the specification is mature and will be useful. >| >| The requirement for at least two independent and interoperable >| implementations applies to all of the options and features of the >| specification. In cases in which one or more options or features >| have not been demonstrated in at least two interoperable >| implementations, the specification may advance to the Draft Standard >| level only if those options or features are removed. >| >| The Working Group chair is responsible for documenting the specific >| implementations which qualify the specification for Draft or Internet >| Standard status along with documentation about testing of the >| interoperation of these implementations. The documentation must >| include information about the support of each of the individual >| options and features. This documentation should be submitted to the >| Area Director with the protocol action request. (see Section 6) >| >| A Draft Standard must be well-understood and known to be quite >| stable, both in its semantics and as a basis for developing an >| implementation. A Draft Standard may still require additional or >| more widespread field experience, since it is possible for >| implementations based on Draft Standard specifications to demonstrate >| unforeseen behavior when subjected to large-scale use in production >| environments. >| >| A Draft Standard is normally considered to be a final specification, >| and changes are likely to be made only to solve specific problems >| encountered. In most circumstances, it is reasonable for vendors to >| deploy implementations of Draft Standards into a disruption sensitive >| environment. > >I think we will be able to meet these requirements. > >I know of two Schedule MIB implementations. I would like the >implementors to fill me in on the details of their implementations >with respect to the requirements above, e.g., whether any objects >not implemented. I believe SNMP Research's DISMAN-SCHEDULE-MIB implementation implements all of the MIB objects in RFC 2591. I believe the DISMAN-SCHEDULE-MIB is stable and useful. SNMP Research has tested/demonstrated an implementation. I do not know if there has been enough actual field experience to identify "unforseen behavior". Although it would be my personal desire to advance the standard, I am uncomfortable doing so based upon the text in the next-to-last paragraph. Regards, --Alan ----------------------------------------------------------------------------- Alan Luchuk SNMP Research, Inc. Voice: +1 865 573 1434 Software Engineer 3001 Kimberlin Heights Road FAX: +1 865 573 9197 luchuk@snmp.com Knoxville, TN 37920-9716 U.S.A. http://www.snmp.com/ ----------------------------------------------------------------------------- Note: Our area code changed to 865 from 423 in November. If you have trouble reaching us via area code 865, please try the old area code (423) and let us know. Both area codes should work until April. From owner-disman@dorothy.peer.com Thu Apr 6 06:06:54 2000 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06356 for ; Thu, 6 Apr 2000 06:06:54 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id FAA14166; Thu, 6 Apr 2000 05:05:54 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id DAA22540 for disman-list; Thu, 6 Apr 2000 03:03:15 -0700 (PDT) Received: from tangelo.bmc.com (root@tangelo [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id DAA22535 for ; Thu, 6 Apr 2000 03:03:11 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id FAA13816 for ; Thu, 6 Apr 2000 05:03:49 -0500 (CDT) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id MAA13048; Thu, 6 Apr 2000 12:04:00 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id MAA04845; Thu, 6 Apr 2000 12:03:44 +0200 Date: Thu, 6 Apr 2000 12:03:44 +0200 Message-Id: <200004061003.MAA04845@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: luchuk@snmp.com CC: disman@dorothy.peer.com, luchuk@snmp.com In-reply-to: <200004051633.MAA02687@seymour47.SNMP.COM> (message from Alan Luchuk on Wed, 5 Apr 2000 12:33:53 -0400 (EDT)) Subject: Re: Closing Script MIB issues References: <200004051633.MAA02687@seymour47.SNMP.COM> Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> Alan Luchuk writes: [...] Randy> 05: Index smLangTable and smExtsnTable by name rather than Randy> Integer32 Alan> I can align with this proposal. I actually did not but a strawman here because I am not sure what the strawman position is. Are you saying that obsoleting smLangTable, smExtsnTable and smLangLanguage and replacing them with new tables indexed by name rather than Integer32 (1..2147483647) and a new column in the smScriptTable is a good idea? Or are you just saying that you won't object if it happens? /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-disman@dorothy.peer.com Thu Apr 6 07:43:52 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07182 for ; Thu, 6 Apr 2000 07:43:51 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id GAA28204; Thu, 6 Apr 2000 06:42:35 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id EAA22689 for disman-list; Thu, 6 Apr 2000 04:40:49 -0700 (PDT) Received: from tangelo.bmc.com (root@tangelo [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id EAA22684 for ; Thu, 6 Apr 2000 04:40:46 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id GAA28023 for ; Thu, 6 Apr 2000 06:41:23 -0500 (CDT) Received: from ccrle.nec.de (cologne.berlin.ccrle.nec.de [192.168.100.79]) by tokyo.ccrle.nec.de (8.8.7/3.6W980303HK) with ESMTP id NAA03036; Thu, 6 Apr 2000 13:40:19 +0200 (CEST) Message-ID: <38EC7942.E8FF7C42@ccrle.nec.de> Date: Thu, 06 Apr 2000 13:47:14 +0200 From: Juergen Quittek Organization: NEC Europe Ltd. X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Schoenwaelder CC: disman@dorothy.peer.com Subject: Re: closing Script MIB issues References: <200003310111.RAA21185@dorothy.peer.com> <200004031357.PAA04350@henkell.ibr.cs.tu-bs.de> <38EA1E91.3867CDA8@ccrle.nec.de> <200004051104.NAA11728@henkell.ibr.cs.tu-bs.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Juergen Schoenwaelder wrote: > > >>>>> Juergen Quittek writes: > > Juergen> I'd like to add another Script MIB issue that has not been > Juergen> discussed before: > > Juergen> 11: Script resource consumption indication (in the run > Juergen> table) > > [...] > > Juergen> I see the problem, that this information might not available > Juergen> on all systems implementing the Script MIB or that it might > Juergen> not be available for all languages supported by a Script MIB > Juergen> implementation. However, I consider it very helpful to get > Juergen> this information whenever it is available. Unavailability > Juergen> could be indicated by value zero. > > I believe that this is nearly impossible to implement and that the > numbers are hard to interpret on the manager's side. The Jasmin > implementation is capable to execute multiple scripts in one runtime > system (an operating system process) and it is really hard to > calculate how much CPU time is consumed by each thread or how much > memory consumption is caused by each thread. I believe that the only > metric that can be reasonably implemented are resource usage > statistics for the runtime systems but not for each running > script. However, this requires to make the mapping of running scripts > to runtime engines explicit (for examply by adding a column which > contains the PID of the underlying operating system process). Once > you have this mapping, you can actually look into the host resources > MIB to get the actual numbers. > > Just to be clear: I certainly understand the need for resource > consumption indicators. However, I do not see how you can define > something which is sufficiently clear so that a manager can actually > base decisions on it and which is at the same time implementable for > arbitrary languages and runtime systems. > > Do you think smRunPerfCPU and smRunPerfMem are implementable in the > Jasmin Java runtime without any guesses? Well, you can, but you do not want to. If you do so, you have to run each script in its own JVM. This is prohobitive, because the JVM eats up a lot of resources. You would get the information on used resources by using significantly more than without measuring the usage. If scripts share a JVM (as in the current Jasmin implementation), you can measure smRunPerfCPU. The scripts run as individual threads in the JVM and if you have kernel level threads, the CPU usage is accessible. However, since all threads share address space of the same process, you cannot measure individual usage of memory. This holds for Java, but if you consider other script languages, such as Tcl of python, the overhead of the interpreter is much less. For these languages you can run scripts as individual processes and implement smRunPerfCPU and smRunPerfMem. Anyway, I also like the idea of just adding a PID (smRunPID) to the run table. This is leaner and easier to implement, and it still provides sufficient means to retrieve the performance information as long as you also have support of the Host Resources MIB or another suited MIB. Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 30 254230-19 NEC Europe Ltd., C&C Research Laboratories Fax: +49 30 254230-99 Hardenbergplatz 2, 10623 Berlin, Germany http://www.ccrle.nec.de From owner-disman@dorothy.peer.com Thu Apr 6 08:20:36 2000 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07419 for ; Thu, 6 Apr 2000 08:20:36 -0400 (EDT) Received: from dorothy.peer.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id HAA04727; Thu, 6 Apr 2000 07:19:40 -0500 (CDT) Received: (from root@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id FAA22790 for disman-list; Thu, 6 Apr 2000 05:18:38 -0700 (PDT) Received: from tangelo.bmc.com (root@tangelo [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id FAA22785 for ; Thu, 6 Apr 2000 05:18:34 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id HAA04620 for ; Thu, 6 Apr 2000 07:19:11 -0500 (CDT) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id OAA23388; Thu, 6 Apr 2000 14:18:58 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id OAA09913; Thu, 6 Apr 2000 14:18:42 +0200 Date: Thu, 6 Apr 2000 14:18:42 +0200 Message-Id: <200004061218.OAA09913@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: quittek@ccrle.nec.de CC: disman@dorothy.peer.com In-reply-to: <38EC7942.E8FF7C42@ccrle.nec.de> (message from Juergen Quittek on Thu, 06 Apr 2000 13:47:14 +0200) Subject: Re: closing Script MIB issues References: <200003310111.RAA21185@dorothy.peer.com> <200004031357.PAA04350@henkell.ibr.cs.tu-bs.de> <38EA1E91.3867CDA8@ccrle.nec.de> <200004051104.NAA11728@henkell.ibr.cs.tu-bs.de> <38EC7942.E8FF7C42@ccrle.nec.de> Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> Juergen Quittek writes: Juergen> If scripts share a JVM (as in the current Jasmin Juergen> implementation), you can measure smRunPerfCPU. The scripts Juergen> run as individual threads in the JVM and if you have kernel Juergen> level threads, the CPU usage is accessible. Not quite true. Not all systems which have kernel supported threads treat them similar too processes. (Not all systems are running Linux yet. ;-) Juergen> However, since all threads share address space of the same Juergen> process, you cannot measure individual usage of memory. Juergen> This holds for Java, but if you consider other script Juergen> languages, such as Tcl of python, the overhead of the Juergen> interpreter is much less. For these languages you can run Juergen> scripts as individual processes and implement smRunPerfCPU Juergen> and smRunPerfMem. I think we should not impose this restriction on runtime systems. Juergen> Anyway, I also like the idea of just adding a PID (smRunPID) Juergen> to the run table. This is leaner and easier to implement, and Juergen> it still provides sufficient means to retrieve the Juergen> performance information as long as you also have support of Juergen> the Host Resources MIB or another suited MIB. Fine. What do others think? Making the PID of the runntime system accessible is IMHO relatively easy to implement (and may actually be useful for debugging purposes) and it allows us to use the HOST-RESOURCES-MIB or the APPLICATION-MIB to obtain performance statistics without having to reinvent the wheel. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-disman@dorothy.peer.com Thu Apr 6 10:24:41 2000 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08820 for ; Thu, 6 Apr 2000 10:24:40 -0400 (EDT) Received: from dorothy.peer.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id JAA12931; Thu, 6 Apr 2000 09:22:57 -0500 (CDT) Received: (from root@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id HAA22961 for disman-list; Thu, 6 Apr 2000 07:19:42 -0700 (PDT) Received: from tangelo.bmc.com (root@tangelo [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id HAA22956 for ; Thu, 6 Apr 2000 07:19:38 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id JAA11910 for ; Thu, 6 Apr 2000 09:20:14 -0500 (CDT) Received: from hansa.ibr.cs.tu-bs.de (IDENT:root@hansa [134.169.34.137]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id QAA01702; Thu, 6 Apr 2000 16:08:04 +0200 (MET DST) Received: (from strauss@localhost) by hansa.ibr.cs.tu-bs.de (8.9.3/8.9.3) id QAA14086; Thu, 6 Apr 2000 16:08:04 +0200 From: Frank Strauss To: disman@dorothy.peer.com Subject: Re: closing Script MIB issues References: <200004061218.OAA09913.disman@henkell.ibr.cs.tu-bs.de> Date: 06 Apr 2000 16:08:04 +0200 In-Reply-To: schoenw@ibr.cs.tu-bs.de's message of "6 Apr 2000 14:22:52 +0200" Message-ID: Lines: 32 User-Agent: Gnus/5.070097 (Pterodactyl Gnus v0.97) Emacs/20.6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list JQ> Anyway, I also like the idea of just adding a PID (smRunPID) JQ> to the run table. This is leaner and easier to implement, and JQ> it still provides sufficient means to retrieve the JQ> performance information as long as you also have support of JQ> the Host Resources MIB or another suited MIB. JS> Fine. What do others think? Making the PID of the runntime system JS> accessible is IMHO relatively easy to implement (and may actually be JS> useful for debugging purposes) and it allows us to use the JS> HOST-RESOURCES-MIB or the APPLICATION-MIB to obtain performance JS> statistics without having to reinvent the wheel. I assume you suggest to use the PID of that process that reflects `best' the identity of the running script, hence a thread's PID if it's available, otherwise the RTE's PID, only if the running scripts cannot be distinguished. Is this really easy to implement? Just some questions: - Should the agent try to find out what the `right' PID seems to be? or - Should SMX be enhanced to report a PID back in the 231 response on the start command? - How can a Java RTE detect whether green threads are used? - If green threads are used, how can we determine the `right' PID? - How can PIDs be retrieved in Java at all? - What is the `right' PID if a script spawns more threads, when we think about using a PID to identify resource consumption? From owner-disman@dorothy.peer.com Thu Apr 6 11:03:58 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09552 for ; Thu, 6 Apr 2000 11:03:58 -0400 (EDT) Received: from dorothy.peer.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id KAA28406; Thu, 6 Apr 2000 10:02:39 -0500 (CDT) Received: (from root@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id IAA23063 for disman-list; Thu, 6 Apr 2000 08:01:41 -0700 (PDT) Received: from tangelo.bmc.com (root@tangelo [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA23058 for ; Thu, 6 Apr 2000 08:01:38 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id KAA28234 for ; Thu, 6 Apr 2000 10:02:14 -0500 (CDT) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id QAA05886; Thu, 6 Apr 2000 16:59:28 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id QAA16053; Thu, 6 Apr 2000 16:59:27 +0200 Date: Thu, 6 Apr 2000 16:59:27 +0200 Message-Id: <200004061459.QAA16053@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: strauss@ibr.cs.tu-bs.de CC: disman@dorothy.peer.com In-reply-to: (message from Frank Strauss on 06 Apr 2000 16:08:04 +0200) Subject: Re: closing Script MIB issues References: <200004061218.OAA09913.disman@henkell.ibr.cs.tu-bs.de> Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> Frank Strauss writes: Frank> I assume you suggest to use the PID of that process that Frank> reflects `best' the identity of the running script, hence a Frank> thread's PID if it's available, otherwise the RTE's PID, only Frank> if the running scripts cannot be distinguished. No, I was thinking about exporting the PID of the runtime system process only. That is, all threads running in the same runtime system will return the same PID (regardless on which thread implementation you are executing). Sure, this means that you only get resource usage statistics per runtime engine. Depending on your OS, these numbers may be what you are looking for. However, on things like linux, these numbers are probably not really what you expect since CPU usage is I think not accumulated in the PID of the main thread. If we return the thread's PID where it is available, then you are correct that this requires an updated to the SMX protocol and more or less tricky code in the runtime engine and it is possible to hide resource consumption by creating new threads. The only answer to this would be to return the list of PIDs for all threads created from a thread executing a script, which gets a bit too complicated for my taste. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-disman@dorothy.peer.com Fri Apr 7 05:22:26 2000 Received: from tangelo.bmc.com ([198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05131 for ; Fri, 7 Apr 2000 05:22:25 -0400 (EDT) Received: from dorothy.peer.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id EAA05152; Fri, 7 Apr 2000 04:21:20 -0500 (CDT) Received: (from root@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id CAA01372 for disman-list; Fri, 7 Apr 2000 02:16:21 -0700 (PDT) Received: from tangelo.bmc.com (root@tangelo [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id CAA01367 for ; Fri, 7 Apr 2000 02:16:18 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id EAA04304 for ; Fri, 7 Apr 2000 04:16:55 -0500 (CDT) Received: from xxxx.ibr.cs.tu-bs.de (IDENT:root@xxxx [134.169.34.127]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id LAA12514; Fri, 7 Apr 2000 11:16:50 +0200 (MET DST) Received: (from schoenw@localhost) by xxxx.ibr.cs.tu-bs.de (8.9.3/8.9.3) id LAA31905; Fri, 7 Apr 2000 11:16:49 +0200 Date: Fri, 7 Apr 2000 11:16:49 +0200 Message-Id: <200004070916.LAA31905@xxxx.ibr.cs.tu-bs.de> X-Authentication-Warning: xxxx.ibr.cs.tu-bs.de: schoenw set sender to schoenw@ibr.cs.tu-bs.de using -f From: Juergen Schoenwaelder To: disman@dorothy.peer.com Subject: another schedule mib issue Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list I checked my email backlog and found another issue for the schedule mib which was raised by Thippanna Hongal : 04: Automatically disabling failing schedules. The idea here is to add controls that can automatically disable a schedule if the triggered set operation fails for a certain number of times (perhaps in a given time window). It may be useful to emit a notification when this happens. I can certainly see the utility of this. We have similar controls in the script MIB where we abort scripts if they do not terminate in the expected amount of time. What does the WG think about this? /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-disman@dorothy.peer.com Fri Apr 7 14:23:25 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14395 for ; Fri, 7 Apr 2000 14:23:25 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id NAA29003; Fri, 7 Apr 2000 13:21:46 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA02368 for disman-list; Fri, 7 Apr 2000 11:19:36 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id LAA02362 for disman@dorothy.BmC.CoM; Fri, 7 Apr 2000 11:19:32 -0700 (PDT) Date: Fri, 7 Apr 2000 11:19:32 -0700 (PDT) From: Randy Presuhn Message-Id: <200004071819.LAA02362@dorothy.peer.com> To: disman@dorothy.peer.com Subject: Re: closing Script MIB issues Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi - > Date: Thu, 6 Apr 2000 16:59:27 +0200 > Message-Id: <200004061459.QAA16053@henkell.ibr.cs.tu-bs.de> > From: Juergen Schoenwaelder > To: strauss@ibr.cs.tu-bs.de > CC: disman@dorothy.peer.com > In-reply-to: (message from Frank > Strauss on 06 Apr 2000 16:08:04 +0200) > Subject: Re: closing Script MIB issues > References: <200004061218.OAA09913.disman@henkell.ibr.cs.tu-bs.de> > List-Id: IETF disman Working Group mailing list ... > No, I was thinking about exporting the PID of the runtime system > process only. That is, all threads running in the same runtime system > will return the same PID (regardless on which thread implementation > you are executing). ... In that case, does there really need to be anything in the script MIB at all? The script service's name, PID, and other information could all be retrieved via the RFC 2564 application MIB, starting with the applSrvNameToSrvInstTable, and subsequently getting the relevant PID(s) from the applSrvInstToRunApplElmtTable. ------------------------------------------------------------------------ Randy Presuhn randy_presuhn@bmc.com http://www.bmc.com/ Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 2141 N. First Street Fax: +1 408 965-0359 San Jose, California 95131 USA ------------------------------------------------------------------------ Any relationship between my opinions and BMC's should be coincidental. ------------------------------------------------------------------------ From owner-disman@dorothy.peer.com Sat Apr 8 01:06:27 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26222 for ; Sat, 8 Apr 2000 01:06:26 -0400 (EDT) Received: from Dorothy.Bmc.Com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id AAA27867; Sat, 8 Apr 2000 00:05:21 -0500 (CDT) Received: (from root@localhost) by Dorothy.Bmc.Com (8.8.6 (PHNE_12836)/8.8.6) id WAA15891 for disman-list; Fri, 7 Apr 2000 22:02:45 -0700 (PDT) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id WAA15886 for ; Fri, 7 Apr 2000 22:02:37 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id AAA27485 for ; Sat, 8 Apr 2000 00:03:15 -0500 (CDT) Received: from ccrle.nec.de (belem.berlin.ccrle.nec.de [192.168.100.178]) by tokyo.ccrle.nec.de (8.8.7/3.6W980303HK) with ESMTP id RAA09340; Fri, 7 Apr 2000 17:46:24 +0200 (CEST) Message-ID: <38EE025D.A82EF2DA@ccrle.nec.de> Date: Fri, 07 Apr 2000 17:44:29 +0200 From: Juergen Quittek Organization: NEC Europe Ltd. X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Schoenwaelder CC: disman@dorothy.peer.com Subject: Re: closing Script MIB issues References: <200003310111.RAA21185@dorothy.peer.com> <200004031357.PAA04350@henkell.ibr.cs.tu-bs.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit I just browsed my note-book an found another Script MIB issue I ran into some weeks ago: 12: Setting row status to "active" is missing in procedure 7.5 between steps 2 and 3. Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 30 254230-19 NEC Europe Ltd., C&C Research Laboratories Fax: +49 30 254230-99 Hardenbergplatz 2, 10623 Berlin, Germany http://www.ccrle.nec.de From owner-disman@dorothy.peer.com Sat Apr 8 01:11:33 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26224 for ; Sat, 8 Apr 2000 01:06:27 -0400 (EDT) Received: from Dorothy.Bmc.Com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id AAA27882; Sat, 8 Apr 2000 00:05:28 -0500 (CDT) Received: (from root@localhost) by Dorothy.Bmc.Com (8.8.6 (PHNE_12836)/8.8.6) id WAA15904 for disman-list; Fri, 7 Apr 2000 22:04:07 -0700 (PDT) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id WAA15899 for ; Fri, 7 Apr 2000 22:04:00 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id AAA27720 for ; Sat, 8 Apr 2000 00:04:38 -0500 (CDT) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id RAA09974; Fri, 7 Apr 2000 17:50:57 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id RAA10338; Fri, 7 Apr 2000 17:50:57 +0200 Date: Fri, 7 Apr 2000 17:50:57 +0200 Message-Id: <200004071550.RAA10338@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: quittek@ccrle.nec.de CC: disman@dorothy.peer.com In-reply-to: <38EE025D.A82EF2DA@ccrle.nec.de> (message from Juergen Quittek on Fri, 07 Apr 2000 17:44:29 +0200) Subject: Re: closing Script MIB issues References: <200003310111.RAA21185@dorothy.peer.com> <200004031357.PAA04350@henkell.ibr.cs.tu-bs.de> <38EE025D.A82EF2DA@ccrle.nec.de> Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> Juergen Quittek writes: Juergen> I just browsed my note-book an found another Script MIB issue Juergen> I ran into some weeks ago: Juergen> 12: Setting row status to "active" is missing in Juergen> procedure 7.5 between steps 2 and 3. Thanks. This is now in my issues list. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-disman@dorothy.peer.com Mon Apr 10 10:14:05 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13207 for ; Mon, 10 Apr 2000 10:14:01 -0400 (EDT) Received: from Dorothy.Bmc.Com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id IAA22299; Mon, 10 Apr 2000 08:48:39 -0500 (CDT) Received: (from root@localhost) by Dorothy.Bmc.Com (8.8.6 (PHNE_12836)/8.8.6) id GAA24502 for disman-list; Mon, 10 Apr 2000 06:43:57 -0700 (PDT) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id GAA24487; Mon, 10 Apr 2000 06:39:54 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id IAA19607; Mon, 10 Apr 2000 08:40:32 -0500 (CDT) Received: from smtp1.cluster.oleane.net (smtp1.cluster.oleane.net [195.25.12.16]) by s1.smtp.oleane.net with ESMTP id PAA04365; Mon, 10 Apr 2000 15:40:05 +0200 Received: from oleane (dyn-1-2-129.Vin.dialup.oleane.fr [194.2.4.129]) by smtp1.cluster.oleane.net with SMTP id PAA40731; Mon, 10 Apr 2000 15:05:10 +0200 (CEST) Message-ID: <000f01bfa2ec$d7828520$0401a8c0@oleane.com> From: "Peter Lewis" Subject: IP Policing 2000 Date: Mon, 10 Apr 2000 15:00:13 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01BFA2FD.79104C00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list This is a multi-part message in MIME format. ------=_NextPart_000_000C_01BFA2FD.79104C00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IP Policing 2000, Paris, 12-15 September =20 The need to police IP networks has grown in importance with the rise of = a new generation of applications such as VPNs, VoIP or IPSec. Approaches under consideration include COPS, DEN/LDAP and PIB, but their = ultimate potential remains undecided. =20 See: http://www.upperside.fr/baippol.htm ------=_NextPart_000_000C_01BFA2FD.79104C00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
IP Policing 2000, Paris, = 12-15=20 September
 
The need to police IP = networks has=20 grown in importance with the rise of a new generation of applications = such as=20 VPNs, VoIP or IPSec.
Approaches under consideration include COPS, = DEN/LDAP=20 and PIB, but their ultimate potential remains undecided.
 
See:
http://www.upperside.fr/baip= pol.htm
 
 
------=_NextPart_000_000C_01BFA2FD.79104C00-- From owner-disman@dorothy.peer.com Tue Apr 11 05:07:59 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26686 for ; Tue, 11 Apr 2000 05:07:59 -0400 (EDT) Received: from Dorothy.Bmc.Com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id EAA01380; Tue, 11 Apr 2000 04:06:27 -0500 (CDT) Received: (from root@localhost) by Dorothy.Bmc.Com (8.8.6 (PHNE_12836)/8.8.6) id CAA22347 for disman-list; Tue, 11 Apr 2000 02:04:31 -0700 (PDT) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id CAA22341; Tue, 11 Apr 2000 02:04:26 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id EAA01040; Tue, 11 Apr 2000 04:05:05 -0500 (CDT) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id LAA13382; Tue, 11 Apr 2000 11:04:55 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id LAA18740; Tue, 11 Apr 2000 11:04:55 +0200 Date: Tue, 11 Apr 2000 11:04:55 +0200 Message-Id: <200004110904.LAA18740@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: rpresuhn@dorothy.peer.com CC: disman@dorothy.peer.com In-reply-to: <200004071819.LAA02362@dorothy.peer.com> (message from Randy Presuhn on Fri, 7 Apr 2000 11:19:32 -0700 (PDT)) Subject: Re: closing Script MIB issues References: <200004071819.LAA02362@dorothy.peer.com> Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> Randy Presuhn writes: Randy> In that case, does there really need to be anything in the Randy> script MIB at all? The script service's name, PID, and other Randy> information could all be retrieved via the RFC 2564 application Randy> MIB, starting with the applSrvNameToSrvInstTable, and Randy> subsequently getting the relevant PID(s) from the Randy> applSrvInstToRunApplElmtTable. This approach still requires that we agree on suitable service naming conventions, right? And then we have to through at last two tables in order to get the PID of the runtime of a running script. Note that the runtime and its PID is known by the script MIB implementation. So it looks like a rather complex way to achieve something which may have a much simpler solution... /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-disman@dorothy.bmc.com Tue Apr 11 14:02:38 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15252 for ; Tue, 11 Apr 2000 14:02:37 -0400 (EDT) Received: from Dorothy.Bmc.Com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id LAA08546; Tue, 11 Apr 2000 11:54:53 -0500 (CDT) Received: (from root@localhost) by Dorothy.Bmc.Com (8.8.6 (PHNE_12836)/8.8.6) id JAA23795 for disman-list; Tue, 11 Apr 2000 09:51:25 -0700 (PDT) Received: (from rpresuhn@localhost) by Dorothy.Bmc.Com (8.8.6 (PHNE_12836)/8.8.6) id JAA23789; Tue, 11 Apr 2000 09:51:21 -0700 (PDT) Date: Tue, 11 Apr 2000 09:51:21 -0700 (PDT) From: Randy Presuhn Message-Id: <200004111651.JAA23789@Dorothy.Bmc.Com> To: minutes@ietf.org Subject: Minutes of rperfman BOF in Adelaide Cc: disman@dorothy.peer.com, rmonmib@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi - These are the minutes, based on Andy Bierman's detailed notes, for the rperfman (Remote Performance Management) BOF session held on March 30, 2000 at the IETF meeting in Adelaide. Randy Presuhn opened the session with an overview of the proposed agenda, which required no changes. Andy Bierman agreed to take detailed notes for the minutes. For purposes of discussion, the larger problem space of remote performance management was divided into seven major areas: instrumentation, instrumentation control, metrics, data reduction, data reduction control, collection coordination, and performance management applications. Randy outlined how these mapped to current work in progress by various working groups. Carl Kalbfleisch gave a presentation of requirements arising from his experiences at Verio. Key points included the need to support multiple monitoring applications, to eliminate redundant polling, to make the configuration of the tests tractable, and, finally, to have useful applications for managing performance. Dan Romascanu gave a presentation on the use of active probes for performance monitoring, covering the material which is to appear in draft-cole-appm-00.txt. This presentation covered the roles and usage of active probes. It also contrasted them with classical RMONMIB passive monitoring. Examples of use included trouble-shooting, circuit pre-testing, fault management, end-to-end capacity management, and SLA monitoring. The discussion then turned to the various tradeoffs involved in using active and passive probe technologies. Some benefits of active probe technologies include control of the sampling and the probe characteristics. On the other hand, this generated traffic adds to network load, and is only a simulation, rather than measuring real user traffic. Randy asked the group some questions to get a sense of the room: Do we want to create new primary metrics? No. Is traffic injection being used for performance measurement? Yes, lots. Is it automated? Yes. Is there a need to standardized its management? Yes. A question came from audience regarding QoS performance monitoring and the need DIFFSERV monitoring. The responses were to use DS-MON to monitor DS flows (work from the rmonmib working group) and to use the DIFFSERV MIB to monitor the DS forwarding points. The discussion turned to APPM architectural issues, including the need for a framework to cover both network and application layers, transport metrics, configuration control, and the relationship to fault management and data reduction, based on standard instrumentation, or at least instrumentation that can be managed in a standard way. Deployment considerations, e.g., where to put active probes, can impact validity and usefulness of data. Security is also an issue, to control the configuration, traffic rate, type of traffic, and so on since active probes could easily be used for denial-of-service attacks. A brief survey of related work within the IETF mentioned IPPM, defining metrics to be collected, DISMAN, defining some active probe functions (remops) and data aggregation (expression, script MIB) capabilities, RMON, defining passive monitoring, application monitoring, and reporting, ApplMIB, defining additional application performance information measured at the application (client or server), as well as RTFM, BMWG, and frnetMIB's service work. Steve Waldbusser asked how the 'big picture' slide relates to traffic generation configuration. Randy sees more interesting work in the data collection from many points and data reduction (like snmpconf) that these are separate problems, but that historically the IETF has not made the distinction. Andy Bierman questioned the need for a standard to glue all components together, since this has traditionally done by management station applications. However, he does see a clear need for standard knobs to setup traffic generators. This led to the question of whether this can be modularized so the application does not have to provide all the components and set them up from scratch every time they are needed. A review of configuration issues for probes included sampling methods (IPPM describes some sampling strategies and implementation details), probe configuration details, such as data configuration and path selection, the choice of statistics, traffic rate, and many others. The review of implementation issues for probe control touched on several points. The packet generation needs to be carefully defined. The clock resolution of traffic generators needs to be understood. The error analysis phase needs to identify the errors that may be introduced in measurements. Discussion of potential work items in this area included the development of a framework document on active monitoring within the Internet framework, the development of a MIB for active probe configuration, and the definition of MIBs for access to the transport and network level metrics that have already been defined by various working groups. Follow-up questions included: How does the CAIDA work relate to this area? How about an IPPM implementation (source & sink)? A person who works for an ISP voiced the concern that active probes should be developed by IETF so that they are constrained and well-behaved in order to reduce risk of abuse. Steve Waldbusser argued that since people are already using this technology, and lots of companies are doing this, it is premature for IETF to standardize, and the work should be done in RMON when we are ready. He observed that doing synthetic transaction monitoring is not just sending octet string and waiting for a response, that synthetic transactions need lots of config details, including state machine for the protocols, knowledge of the network, transport and application layers. There are many ways to do this work, but it is too hard for PeopleSoft, that some generators are reduced to pushing buttons on the applications, that Ganymede does not do the real application, but instead does a very proprietary approach. Steve concluded that this work should be carried out in the RMON working group. He cited the TR-RMON's active components as precedent, and offered that active network layer probes were only deferred because of RMON-2 work. Furthermore, RMON was just chartered for APM, and this includes reporting of synth transactions. RMON will need to address this later; it will be harder if there is overlapping charters and RMON has to redo some work to fit with the PD and APM. Randy countered that there is a difference between "programming" an active probe, which requires between knowing all the details, and standardizing the 'on/off' button. He cited the application MIB work, which abstracts out the comment elements of applications, and doesn't even try to represent the peculiarities, leaving those aspects to device, vendor, or application-specific MIBs. Steve replied that RMON found on/off to be insufficient. Randy continued that aggregation of data from many points of collection is not covered by RMON. There may be a need to recombine into new tables, not just multiple instances of the RMON MIB. Dan Romascanu agreed with Steve on the need to increase the priority of those issues in the RMON WG; still need to correlate data from many different places. Russell Dietz gave the next presentation, explaining the RMON APM/TPM framework. The top-level elements were the APMCAPS, APM study, and TPM study. The APM and TPM linked by flow measurements; APM gives high-level and TPM gives microflow. The TPM serves as a drilldown for APM. APMCAPs has a hook to point to the control mechanism for a test, if available. It could point to standard MIBs like DISMAN remops or proprietary MIBs. TPM has a microflow decomposition for the APM user experience. TPM has statistical reporting. Russell wants feedback from the BOF so the drafts in progress can accommodate requirements from this work. Randy gave a recap of what had been covered and glossed over during the session, including configuration management issues for active probes, the correlation problems for relating measurements from different sources. Possible deliverables would depend on which working group or groups took up the project. This would also have to be done with some consciousness of the work already in progress. One possibility would be to generate an architecture document addressing the issues of cross-system reporting. The agenda turned to considering the possible paths forward. Randy asked for a sense of the room on each of the possibilities: a) a new WG -- no interest from anybody b) disman -- if we focus on infrastructure c) applmib -- not any interest; focused on apps, not network d) rmon e) something else The consensus emerged to let RMON continue to focus on the instrumentation, instrumentation control, and single-system reporting. Disman appeared to be the right place to handle multi-system data reduction and data reduction control. SNMPCONF would appear to be the right place to handle the cross-system collection configuration coordination. IPPM and other working groups would continue to define fundamental metrics. A gap is ensuring that those metrics, once defined, are somehow made visible to management. The following action items were agreed: RMON -- consider requirements for active probe control during the APM/TPM work, and start work right after APM/TPM DISMAN -- look at data correlation issues from multiple probes SNMPCONF -- allow for this work to use snmpconf Consequently, it was felt that there was no need for a new mailing list, and that these 3 lists would be appropriate for further discussion. ------------------------------------------------------------------------ Randy Presuhn randy_presuhn@bmc.com http://www.bmc.com/ Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 2141 N. First Street Fax: +1 408 965-0359 San Jose, California 95131 USA ------------------------------------------------------------------------ Any relationship between my opinions and BMC's should be coincidental. ------------------------------------------------------------------------ From owner-disman@dorothy.peer.com Wed Apr 12 12:34:49 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26753 for ; Wed, 12 Apr 2000 12:34:49 -0400 (EDT) Received: from Dorothy.Bmc.Com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id LAA08525; Wed, 12 Apr 2000 11:33:13 -0500 (CDT) Received: (from root@localhost) by Dorothy.Bmc.Com (8.8.6 (PHNE_12836)/8.8.6) id JAA00385 for disman-list; Wed, 12 Apr 2000 09:30:08 -0700 (PDT) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA00379 for ; Wed, 12 Apr 2000 09:30:03 -0700 (PDT) Received: from fw-us-hou2.bmc.com (fw-us-hou2.bmc.com [172.17.1.236]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id KAA01456 for ; Wed, 12 Apr 2000 10:00:30 -0500 (CDT) Received: from gab200r1.ems.att.com ([135.37.94.32]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id KAA10297 for ; Wed, 12 Apr 2000 10:58:12 -0400 (EDT) Received: from njb140bh2.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id KAA13132; Wed, 12 Apr 2000 10:59:20 -0400 (EDT) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2650.21) id <2ZA535SR>; Wed, 12 Apr 2000 08:59:13 -0400 Message-ID: From: "Cole, Robert G (Bob), ALSVC" To: disman-wg-ietf Subject: FW: I-D ACTION:draft-cole-appm-00.txt Date: Wed, 12 Apr 2000 10:57:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BFA48F.7BCEEB20" Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BFA48F.7BCEEB20 Content-Type: text/plain Just wanted to forward this note out to the disman wg. This draft relates to the rperfmon BOF held in Adelaide. I believe that Randy said it was OK to use the disman working group list for discussions and comments on this draft. Thanks, Bob > -----Original Message----- > From: Internet-Drafts@ietf.org [SMTP:Internet-Drafts@ietf.org] > Sent: Monday, April 10, 2000 7:34 AM > To: IETF-Announce; @loki.ietf.org@attrh2.attrh.att.com > Subject: I-D ACTION:draft-cole-appm-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : A Framework for Active Probes for Performance > Monitoring > Author(s) : R. Cole, C. Kalbfleisch, D. Romascanu > Filename : draft-cole-appm-00.txt > Pages : 18 > Date : 05-Apr-00 > > This memo discusses the use of 'active' probes within the context of > remote performance monitoring. It discusses the importance of > developing an 'active' probe monitoring capability within the > Internet. It develops a framework for active probes in performance > monitoring against the backdrop of previous, related work within the > IETF. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-cole-appm-00.txt > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-cole-appm-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-cole-appm-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. <> ------_=_NextPart_000_01BFA48F.7BCEEB20 Content-Type: message/rfc822 Content-Description: Untitled Attachment To: Subject: Date: Mon, 10 Apr 2000 11:09:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01BFA48F.7BCEEB20" ------_=_NextPart_002_01BFA48F.7BCEEB20 Content-Type: text/plain ------_=_NextPart_002_01BFA48F.7BCEEB20 Content-Type: application/octet-stream; name="ATT11197" Content-Disposition: attachment; filename="ATT11197" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000406142647.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-cole-appm-00.txt ------_=_NextPart_002_01BFA48F.7BCEEB20 Content-Type: message/external-body; site="internet-drafts"; dir="draft-cole-appm-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01BFA48F.7BCEEB20-- ------_=_NextPart_000_01BFA48F.7BCEEB20--