Internet Draft R.G. Cole Expiration Date: Sept 2000 AT&T C. Kalbfleisch Verio, Inc. D. Romascanu Lucent A Framework for Active Probes for Performance Monitoring Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. 2. Abstract 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. Distribution of this memo is unlimited. Cole, et al. [Page 1] Internet Draft draft-cole-appm-00.txt March 2000 3. Objectives and Motivation 3.1 Introduction There is much utility in fully defining a performance monitoring capability within the IETF. As the Internet architecture becomes more complex, as enhanced QOS capabilities are defined and deployed, performance monitoring capabilities must be developed to account for this richer transport and service infrastructure. ISP's will be offering enhanced transport services, content hosting services will offer differentiated hosting services, and customers will demand methods to monitor the quality of the services to which they subscribe. This memo defines a framework for the development of an 'active' probe capability for the purpose of enhancing remote performance monitoring capabilites within IP networks and services. By an 'active' probe, we mean a device or embedded software which generates a data packet (or packets) and injects it (them) into the network to a corresponding probe or existing server for the primary purpose of measuring some aspect of the performance of the end-to-end path or service. By performance monitoring we mean the act of collecting a specific set of measurements, either actively or passively, for the purpose of evaluating the quality of the path or the service. Much work within the IETF exists related to performance monitoring. One interesting aspect of this body of work is that it does not explicitly define an 'active' probe capability. An active probe is complimentary to existing capabilities, and should be developed by building as much as possible on this existing work. 3.2 Terms This section defines the terms used throughout this memo. + 'Performance monitoring' is the act of monitoring traffic for the purpose of evaluating a statistic of a metric related to the performance of the system. + A 'probe' is a device or embedded software program that is placed in the data flow path or on a client or server to provide a performance monitoring function. + An 'active probe' is a probe which generates a data packet (or packets) and injects it (them) onto the path to a corresponding probe or existing server and provides a performance monitoring function based upon measurements made upon the packets that it injects. An active probe may talk intrusively to existing application servers. Cole, et al. [Page 2] Internet Draft draft-cole-appm-00.txt March 2000 + A 'passive probe' is a probe which non-intrusively listens to packets flowing across the 'wire' or monitors request/responses on a client or server and provides a performance monitoring function based upon its observations. + A 'path' is a set of network transport components that provide a transport service between a given source and destination address pair. In its simpliest form the network components are a series of routers interconnected by links. In more complex scenarios, a path has a more complex topology due to asymetric routes, alternate paths, load balancing and redirection. + A 'service' is a collection of network components and servers designed to deliver a capability to an end user. The service could be a transport capability, a processing capability, etc. 3.3 Motivation There are a number reasons to develop an active probe capability for performance monitoring within the Internet. However, thay all fundamentally boil down to the single issue of control. As discussed at length in the IPPM framework document [1], if you do not control the nature of the traffic generation, then you do not control the sampling and hence you do not control the quality of the respective statistics. It is important to control the timing of the packet generation to ensure the quality of the statistic (i.e., the random nature of the underlying sample). It is important to control the path of the test packets (at least the source and destination) to ensure that enough measurements are taken over the path in order to accurately identify the quality of the path. It is important to control the 'size' of the transactions to ensure that the measurements are relavant to the metric, e.g., throughput statistics should be based upon measurements with large files. The utility of active probe capabilities will be found in: + troubleshooting paths - a pingMIB [3] identifies that connectivity exists but additional capabilities are required to determine the quality of the connectivity, + circuit pre-test and turn-up - prior to turning up a capability or customer, there is much value in monitoring the quality of their path or service prior to putting the customer on-line (without the capability of generating probe traffic this can be problematic), + fault management - allows determination of whether the application is operating or not, Cole, et al. [Page 3] Internet Draft draft-cole-appm-00.txt March 2000 + baselining enhancements - active probes could be used to base- line BEFORE and measure AFTER a certain set of QoS or routing policies are applied. This would try to provide an answer to the question 'how effective is my proposed policy strategy?'. + capacity management - typical capacity management programs monitor local, utilization statistics to drive a capacity management decision, e.g., upgrade a facility, a CPU, etc. An active probe could be used to monitor complimentary aspects of network performance, more akin to an end-to-end metric, whose results could drive capacity management decisions as well. (This can be correlated to component level measures and can trigger specific capacity upgrades.), + Service Level Agreement (SLA) monitoring - because the nature of the probe packets, which measure a metric, are tightly specified, the corresponding statistics will have significance within the context of an SLA. The bulk of the current development within the IETF is in the area of defining 'passive' monitoring, either self-monitoring as counters of local metrics or external-monitoring as defined within the RMON working group [2]. In contrast to passive monitoring is, what we refer to as, active monitoring. Active monitoring relies upon the injection of probe data or 'request' packets into the transport network or into a service. The active monitoring probe (or cooperating probes) then performs some type of measurement based upon the specific packet(s) it injects. There are distinct advantages and disadvantages of both passive and active performance monitoring. These two approaches are very complimentary in nature. Passive probes are, by their vary nature, non-intrusive; they add no additional load on the network or service. Passive monitors can provide a more extensive measurement capability (not only in the type of measurements but also in the amount of samples collected). Passive monitors do not, however, control the generation of data for the measurement samples. In contrast, active monitors are intrusive; they add load to the network or service. Because they control the generation of the probes, they also control the volume of traffic they introduce. In general, it is not expected that the objectives for generating active probes would necessitate high volumes of traffic. Combined, these attributes limit the volume of measurements collected from active monitoring probes. However, this will allow for a richer set of historical data to be maintained in the probe due to the relatively low volume of measurement data (as compared, say, to an RMON probe sitting on a highly utilized fast ethernet LAN segment). Cole, et al. [Page 4] Internet Draft draft-cole-appm-00.txt March 2000 In the next section we discuss issues of an architectural nature. We follow this with a section on related work, both previous and current, within various working groups at the IETF. Then, we present thoughts on Configuration Issues and Implementation Issues. Finally, because this area of work is not currently part of an existing working group's charter, we end with a brief presentation of Next Steps in order to move the discussion of these capabilities within the IETF along. 4. Architectural Considerations There are various architectural considerations when discussing active probes within the context of the Internet and it's standards. These include: + the target of the monitoring process, e.g., network transport versus server or process, + the 'layer' at which the probe functions, e.g., transport probes versus synthetic applications, + relationship between fault management and performance management data, + configuration - how to setup the behavior of the probe through a RW MIB table for configuring the probe, + communication channels to remote probes, + the deployment architecture and its relationship to other monitoring methods, e.g., passive monitoring devices, and + security - related to probe control and generation. We consider each of these issues in this section. It is envisioned that specific probes/monitoring capabilities are to be developed specific to the service being monitored. When the target of the monitoring process is a transport service, then one naturally thinks of delay probes, loss probes, throughput and jitter probes, etc. When one thinks of database access services, one naturally thinks of various types of application request probes. We will talk of 'network' or 'transport' probes when monitoring transport services. We will speak of 'process-level', 'application- level or 'synthetic-application' probes when speaking of monitoring applications or a combination of transport and application services depending upon the location of the probes. It may even make sense to define an intermediate probe type, e.g., and 'infrastructure' probe, Cole, et al. [Page 5] Internet Draft draft-cole-appm-00.txt March 2000 for the purpose of monitoring some common aspects of the service and transport services. Examples of 'transport-level' probes are delay, loss, delay variation, jitter, and throughput probes. Examples of 'synthetic- application' probes would be Oracle or SAP transaction probe or HTTP_get request probes, etc. Examples of 'infrastructure-level' probes might be DNS or DHCP probes, SIP probes for monitoring aspects of call setup delays, etc. Related to each defined transport or application service, we introduce the concept of a monitoring service, characterized by type of service, passive monitoring method (if relevant), active monitoring method (if relevant), metrics, passive probe and active probe. In this context, a passive probe is an implementation of a passive monitoring method. An active probe is an implementation of an active monitoring method. Such an approach is currently being discussed within the context of a passive monitoring capability in the RMON working group. See, for example, [14] and [16]. There are very few pieces of information that one might extract from a resource that are only useful for just one purpose, e.g., fault or performance monitoring. For most of the attributes available today, the differences are in the use to which the information is put, not the data itself. It is only after we have defined higher-level objects (computed from existing ones) that we really have "performance data" or "fault data". Thus it should be possible to report basic fault information as well as gather performance statistics. For instance, at a mininmum the detected operational state should be reportable with a notification to indicate the transitions. Given a probe, a framework can be built that looks something like: +-----------------+------------+ |performance app. | fault app. | +-----------------+------------+ | monitoring software | +------------------------------+ | central selection, | | aggregation & stats. | +------------------------------+ | remote selection, | | aggregation & stats. | +------------------------------+ | probe hardware | +------------------------------+ Cole, et al. [Page 6] Internet Draft draft-cole-appm-00.txt March 2000 In the context of performance, fault can be viewed as not performing at all. They should both be monitorable with the same probes to reduce network traffic. Various deployment scenarios are feasible, depending upon the functionality desired and the allocation of that functionality across components. Clearly, active and passive probes can be implemented as either stand-alone devices that sit on the wire, or they can be implemented as embedded software within specific network elements or clients or server applications. An architecture can be envisioned which combines active and passive probes, where the active probe is designed for the sole purpose of generating traffic at particular time points and the sample collection and statistical computations occur in already defined passive probes, e.g., RMON probes. Other architectural options relate to a) the fundamental nature of the active probe development and b) the communications with the remote probes and between the remote probes. The active probes could be developed along the lines of the DISMAN's pingMIB [3], i.e., it is defined within the context of a MIB, directly accessable through SNMP and resident on a remote device. It could, instead be developed within the framework of the DISMAN's scriptMIB [4], where the active probe is an application which is distributed to the remote monitoring device and run on that remote device. Within this latter architecture, access to the probe's configuration, etc., may be through means other than SNMP and a MIB. Also, depending upon the nature of the probes, some form of communication and control may be necessary between the communicating probes themselves (in addition to the probe packets). With respect to security considerations, past discussions related to active monitoring encountered a certain degree of pessimism, as did many other SNMP applications that involved configuration operations. However, the recent development of the SNMPv3 [references..] security model, improved this situation, and we are witnessing the increased acceptance of SNMP as a 'trusted' and 'secure' protocol. This framework will analyze the issue of security and propose if necessary extra measures for ensuring a safe and secure utilization of the active monitoring capabilities. Several security issues exists, including: + the security of the communication between a management application and the remote, active probes (at a minimum snmpv3 authentication mechanisms should be consider for this aspect of configuration.), Cole, et al. [Page 7] Internet Draft draft-cole-appm-00.txt March 2000 + when the probes are probing things at application levels we need to discuss the security of those applications. (For instance we may need to use secure protocols.) + there is the potential that the probes for monitoring will be perceived as secuirty violations (port scans) + the nature of the communications between the active probes themselves, + spoofing results (potentially disrupting communications), and + using the probes in denial of service attacks. {Comment: These and other security issues need to be further developed. Also see the note in Section 10 below on 'Security Considerations'.} 5. Relationship to Other Work Much work has already occurred within the IETF which has a direct bearing on the development of active performance probe definitions. This body of work is addressed in various working groups over the years. In this section we focus our attention to the work of a) the IPPM working group, b) the DISMAN working group, c) the RMON working group, d) the ApplMIB working group, and e) the RTFM working group. 5.1 IPPM The IPPM working group has defined in detail a set of performance metrics, sampling techniques and associated statistics for transport level measurements. The IPPM framework document [1] discusses numerous issues around samplying techniques, clock accuracy, resolution and skew, wire time versus host time, error analysis, etc. Much of these are considerations for Configuration and Implementation Issues discussed below. The IPPM working group has defined several metrics and their associated statistics, including + a connectivity metric [5] + one-way delay metric [6] + one-way loss metric [7] + round trip delay and loss metrics [8] Cole, et al. [Page 8] Internet Draft draft-cole-appm-00.txt March 2000 + delay variation metric [9] + a streaming media metric [10] + a throughput metric [11] and [12], and + others are under development. These (or a subset) could form the basis for a set of active, transport-level, probe types designed for the purpose of monitor the quality of transport services. A consideration of some of these metrics may form a set of work activites in a new working group developing active probe monitoring capabilities and a set of early deliverables out of such a working group. 5.2 DISMAN The DISMAN working group is defining a set of 'active' tools for remote management. Of relevance to this draft are: + the pingMIB [3], + the DNS Lookup MIB [3], + the tracerouteMIB [3], and + the scriptsMIB [4]. The pingMIB and tracerouteMIB define an active probe capability, primarily for the remote determination of path and path connectivity. There are some performance related metrics collected from the pingMIB and one could conceivably use these measurements for the evaluation of a limited set of performance statistics. But there is a fundamental difference in determining connectivity versus determining the quality of that connectivity. The DNS Lookup MIB also includes some probe-like capabilities and performance time measurements for the DNS lookup. In the context of performance monitoring, a fault can be viewed as not performing at all. Therefore, tThey should both be monitorable with the same probes to reduce network traffic. This was discussed further in the Architecture section above. Also mentioned in the Architecture section above, the scriptsMIB allows a network management application to distribute and manage scripts to remote devices. Conceivably, these scripts could be designed to run a set of active probe monitors on remote devices. Cole, et al. [Page 9] Internet Draft draft-cole-appm-00.txt March 2000 One possible outcome we would like to consider is the extension of the DISMAN work to monitoring of the quality of the connectivity. 5.3 RMON The RMON working group has developed a extensive, passive monitoring capability defined in [2], [13], ... Initially, the monitors collected statistics at the MAC layer, but has now been extended to high-layer statistics. Higher-layer statistics are identified through the definition of a Protocol Directory [2]. The working group is recently re-chartered and is now concentrating on, amoung other items, passive monitoring at the application level. {Comment: Is this statement true, that the RMON group is totally under the passive approach category?} The minutes of the Boston interim meeting in January 2000 are the best source right now for information about what these activities in the RMON WG [19]. A number of individual drafts exist which discuss a number of interesting areas such as: + application typing and relevant metrics [14] and [15] + transaction level statistics collection and reporting [15] and [16] One possible outcome we would like to consider is the extension of the RMON work as it relates to application monitoring. Further, RMON MIB data can be correlated with active probes actions. 5.4 ApplMIB The ApplMIB working group defined a series of MIBs which monitor various aspects of applications, processes and services. The system application MIB (RFC 2287 [20]) describes a basic set of managed objects for fault, configuration and performance management of applications from a systems perspective. More specifically, the managed objects it defines are restricted to information that can be determined from the system itself and which does not require special instrumentation within the applications to make the information available. The Application MIB (RFC 2564 [17]) complements the System Application MIB, providing for the management of applications' common attributes which could not typically be observed without the cooperation of the software being managed. There are attributes which provide information to application and communication performance. Cole, et al. [Page 10] Internet Draft draft-cole-appm-00.txt March 2000 {Comment: Should we include a list of attributes?} The WWW MIB (RFC 2594 [18]) describes a set of objects for managing network management protocols in the Internet Community, particularly World Wide Web (WWW) services. Performance attributes are available for the infomration about each WWW service, each each type of request, each type of response and top accessed documents. {Comment: Should we include a list of attributes?} In the development of synthetic application-level probes, consideration should be given to the relationship of the application MIBs to the measurements being performed through a synthetic application-level probe. Similar, cross-indexing issues arise within the context of the RMON monitoring and synthetic application-level active probes. 5.5 RTFM {Comment: This section is to discuss the relevant aspects of the RTFM working group to this draft.} 6. Configuration Issues It is primarily assumed within this memo that the configuration of the probes is accessable through a MIB and communications to the remote probe is via SNMP. Other options, exist; one such option was briefly discussed above in the Architecture section. The remainder of this section focuses on various configuration issues surrounding the definition and development of an active probe capability. Here we discuss a) sampling methodologies, b) useful probe configuration options, c) statistics, reporting and historical data, and d) correlation of results to other measurements. 6.1 Sampling {Comment: This section should cover frequency, interpacket times (deterministic, random), timeouts, number of packets sent, probe lifetime, etc. This section should also include reasonable defaults and recommended ranges for polling intervals and retries. For instance it may be fine for ping to have a 1 second retry. But for higher level applications we may not want to allow 1 second retries. } 6.2 Probe Configurations The configuration of the specific probes can be quite extensive, Cole, et al. [Page 11] Internet Draft draft-cole-appm-00.txt March 2000 given all of the potential options. The options would cover areas such as: + static, read only information related to the implementation of the active probes, + timing and frequency of the probe packets (see Sampling section above), + data configuration (payload size, data fill, etc), + protocol options (could include multiple layers of protocol processing), + path configuration options (source and destination addresses, TOS field settings, do not fragment settings, ifNumber, TTL, etc.), and + others? 6.3 Statistics, Reports and Historical Data {Comments: This section should cover the statistics computed locally, the nature of the reports generated, and the storage of historical data. Reference [16] has a good discussion of a general set of statistics to maintain in probes, the complexities involved and the utility of the various statistics. Also, the work of the IPPM working group and their specific documents discusses or recommends statistics related to the metrics they define. This should be covered in this section.} 6.4 Indexing to Other Measurements There will potentially be a great deal of performance related information collected across numerous MIBs. The definition of a set of active probes only adds to this data. Methods are available within subsets of this data to cross-correlate results through standard indexing tables. Various MIBs from the Appl working group, i.e., [17], [18], and [20], are related through a service instance identifier. To quote [18], "The WWW Service MIB interfaces to the Application MIB [17] by using the service instance identifier {applSrvIndex} for wwwServiceIndex if an applicable instance of applSrvIndex is available." The discussion and early drafts from the RMON working group, i.e., [16] and [14], discuss the relationship between the metrics of application-level and transport-level measurements and their cross-indexing. To quote [16], .... Cole, et al. [Page 12] Internet Draft draft-cole-appm-00.txt March 2000 {Comment: Get quote from [16].} The definition of active probes and their related statistics should be defined in such a way that useful cross-correlation of results is possible. This type of correlation is currently possible for certain definitions of "service" in RFC 2564 [17]. For instance in Section 6.1 or RFC 2594 [18] indicates that for long lived services like http and smtp there would be instances in the service-level tables. For finger there may not be an entry. From here we can determine the reference points back to system application MIB and deteremine all of the information about the application. Clearly, it would be desirable to be able to correlate, e.g., the results of a synthetic application probe running on a remote device into an application server with the measurements found within the applMIB for that same application running on that server. To take this example further, then to correlate the applications-level probe's measurements to transport-level measurments and even to the individual component level. This would require the ability to relate the path of the probes to the specific components, which may be complicated due to asymmetries in routing, load balancing across paths and servers, etc. 7. Implementation Issues Implementation of active probes and their corresponding measurements is a tricky business, as discussed in detail in the body of the IPPM WG documents, in particular references [1] and [6]. In this section we reinforce some of the discussion in these references in the area of measurement accuracy, etc. Specifically, we discuss a) requirements on implementations, b) error analysis statements, and c) compliance tests. 7.1 Requirements on Implementations {Comment: This section should discuss potential requirements on specific implementations. Areas to cover include clock resolution, and skew, types of packet injection process supported, requirements on the upper and lower bounds on packet generation rates, etc.} 7.2 Error Analysis Statements Performance measurements, whether they are based on active or passive monitoring, are error prone. It may make sense to define Cole, et al. [Page 13] Internet Draft draft-cole-appm-00.txt March 2000 an error analysis statement/methodolgy so that implementations can clearly define their source of errors and hence the accuracy of their results. There is a fair amount of discussion within the IPPM framework document surrounding this issue, which should be drawn upon extensively. 7.3 Compliance Tests {Comment: this section should cover identifying supported probe types, test to determine the accuracy of the specific implementations, etc.} 8. Next Steps There are several steps to move this work forward. A BOF is being held in Adelaide to discuss this area of work as a potential basis for a working group at the IETF. Here we throw out some thoughts on moving this work forward. This includes a proposed set of possible deliverables for the working group. + The first step is to have the BOF and see what momentum is gained from it. At that point it will likely be more clear what the next steps should be, where the work will be done within the IETF and so forth. If the decision is to move forward, we suspect several documents may be reasonable. For example, we suggest: + Develop a framework/architecture document defining the architecture of an active performance monitoring capability, its tradeoffs relative to other potential architecures, and its relationship to other, already defined monitoring capabilities. + (possibly) Develop a seperate security document, + Develop a MIB for active probes and another for a usage of that MIB for some specific network or application layer. To accomplish the later, then + Define a set of transport level metrics, drawing from the work of the IPPM working group for the purpose of defining assocaited active, transport-level probes. + Develop a set of related transport level performance probes. These may require a document defining the metrics and a common structure for the transport level probes, with a method for extending this to include other transport level probes (as alluded to in the above bullet). Then the seperate transport-level probes Cole, et al. [Page 14] Internet Draft draft-cole-appm-00.txt March 2000 may be seperately defined. + If interest merits it, there may be a set documents surrounding the definition of synthetic application-level probes. 9. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 10. Security Considerations {Comment: This needs a very close examination, probably more than usual. Some security issues are briefly mentioned in the Architecture section above, but the issue of security was one of the reasons for this work being deferred in the past. We may want to create a special document or a special section in this document that deals with the issue.} 11. Acknowledgements to be supplied. 12. References: [1] Paxson, V., Almes, G., Mahdavi, J. and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998. [2] Waldbusser, S., "Remote Network Monitoring Management Information Base Version 2 using SMIv2", RFC 2021, January 1997. Cole, et al. [Page 15] Internet Draft draft-cole-appm-00.txt March 2000 [3] White, K., "Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations", Internet Draft, , August 1999. [4] Levi, D. and J. Schoenwaelder, "DDDefinitions of Managed Objects for the Delegation of Management Scripts", RFC 2592, May 1999. [5] IPPM connectivity metric (?) [6] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999. [7] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-Way Packet Loss Metric for IPPM", Internet Draft, , May 1999. [8] Almes, G., Kalidindi, S. and M. Zekauskas, "A Round-Trip Delay Metric for IPPM", RFC 2681, September 1999. [9] Chimento, P., "Instantaneous PPPacket Delay Variation Metric for IPPM", Internet Draft, , March 2000. [11] Mathis, M. and M. Allman, "Empirical Bulk Transfer Capacity", Internet Draft, , Octobet 1999. [12] Mathis, M., "TReno Bulk transfer Capacity", Internet Draft, , February 1999. [13] Waldbusser, S., "Remote Network Monitoring Management Information Base", RFC 1757, February 1995. [14] Waldbusser, S., "Application performance measurement MIB", , March 2000. [15] Warth, A. and J. McQuaid, "Application Response Time (ART) MIB", Internet Draft, , October 1999. [16] Dietz, R. "Transport Performance Metrics MIB", Internet Draft, , March 2000. [17] Kalbfleisch, C., Krupczak, C., Presuhn, R. and J. Saperia, "Application Management MIB", RFC 2564, May 1999. [18] Hazewinkel, H., Kalbfleisch, C., and J. Schoenwaelder, Cole, et al. [Page 16] Internet Draft draft-cole-appm-00.txt March 2000 "Definitions of Managed Objects for WWW Services", RFC 2594, May 1999. [19] Meeting minutes from the interim meeting of the RMON working group on January 11 and 12, 2000 in Boston, MA. [20] Krupczak, C. and J. Saperia, "Definitions of System-Level Managed Objects for Applications", RFC 2287, February 1998. 13. Author Information Robert G. Cole AT&T Laboratories Network Design and Performance Analysis Department 330 Saint John Street, 2nd Floor Havre de Grace, MD 21078 Phone: +1 410-939-8732 Fax: +1 410-939-8732 Email: rgcole@att.com Carl W. Kalbfleisch Verio, Inc. 1950 Stemmons Freeway Suite 2026 Dallas, TX 75207 Phone: + 1 214-853-7339 Fax: +1 214-744-0742 Email: cwk@verio.net Dan Romascanu Lucent Technologies Atidim Technology Park, bldg. #3 Tel Aviv, 61131 Israel Phone: +972-3-645-8414 Fax: +972-3-648-7146 Email: dromasca@lucent.com A. Full Copyright Statement This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published Cole, et al. [Page 17] Internet Draft draft-cole-appm-00.txt March 2000 and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Cole, et al. [Page 18]