1 files changed, 0 insertions, 125 deletions
diff --git a/net-mgmt/netmond/files/README.eng b/net-mgmt/netmond/files/README.eng
deleted file mode 100644
index 07715e6c18dc..000000000000
--- a/net-mgmt/netmond/files/README.eng
+++ /dev/null
@@ -1,125 +0,0 @@
-Network Monitoring Dealer http://soft.risp.ru/netmond/
-------------------------------------------------------
-
-Netmond is an essential and flexible tool for network administrators.
-Netmond is a daemon providing an interface between low level network
-stack and a GUI monitoring program or a database.
-
-Netmond accumulates network neighborhood data, periodicaly polling network 
-objects by several methods and collecting SNMP traps. Gathered information
-is parsed so that client programs can comfortably request it via unified
-interface.
-
-Netmond can be used as primary data source and as a notification subsystem
-in a network monitoring framework.
-
-Netmond have a modular architecture. Modules work indepependently but use
-common task scheduler, session multiplexor, topology correlator, variables
-pool and output channels. The unique asynchronous polling algorithm
-does not limit a number of simultaneously controlled objects.
-
-Collected data can be saved by variuos methods periodically or conditionally.
-Also, a client program can request the data dynamically via network.
-
-Netmond considers the network as a collection of objects. All objects to be
-monitored have to be described preliminary in a configuration file. Objects
-polling works in parallel, not sequentially, like in other systems. Polling
-requests are distributed over the poll interval as optimally as possible.
-While executing, Netmond can dynamically determine topological dependences 
-of objects and interfaces and correct polling modes or even block polling for
-subordinate objects.
-
-The Netmond deal the with following object types:
-
-* OBJECT - primary monitoring target, an object with IP address;
-* INTERFACE - network interface, subobject of OBJECT;
-* BGPAS - autonomous system number, subobject of OBJECT;
-* BGPPEER - BGP peer for autonomous system, subobject of BGPAS;
-* ENVTEMP - environment temperature (Cisco only), subobject of OBJECT;
-* SERVICE - arbitrary network service, subobject of OBJECT;
-
-For any OBJECT type instance operator can define:
-
-* METHOD - list of polling methods;
-* TRAP - list of traps methods;
-* POLLING - polling interval (the time between METHOD calls);
-* VARIABLE - list of variables, optional;
-* SAVE - list of data saving methods, optional;
-* SAVING - data saving interval (the time between SAVE methods calls);
-* INTERFACE - list of network interfaces, optional;
-* BGPAS - list of autonomous systems, optional;
-* ENVTEMP - list of thermal sensors, optional;
-* SERVICE - list of arbitrary services, optional;
-
-If BGPPEER list is not defined for a BGPAS instance, Netmond builds
-this list automatically.
-
-The state of OBJECT is a result of execution of all associated methods from
-METHOD and/or TRAP lists. Methods are evaluated sequentially until the first
-error. The order of execution is defined by operator.
-
-VARIABLE values and state of subobjects INTERFACE, BGPPEER, ENVTEMP and SERVICE
-are also evaluated during execution of METHODs and TRAPs. All subobjects have
-their own SAVE list.
-
-Inside a METHOD definition the following protocols can be used:
-
-* PING - ICMP echo ő IP with Route Record option for topology discovery;
-* SNMP - simple SNMP v1 request for specified VARIABLE OID;
-* ROUTER - multiple SNMP v1 requests, indexing of certain tables,
-           extracting internal VARIABLEs values;
-* TCP - simple TCP session with text chat capabilities, extracting
-        VARIABLEs values from answers;
-* UDP - simple UDP sequence with arbitrary chat, extracting
-        VARIABLEs values from answers;
-* DNS - DNS service check;
-* RADIUS - RADIUS service check;
-* TACACS - TACACS+ service check;
-
-TRAP collector expects SNMP v1 traps, with BGP Enterprise (RFC1657),
-Cisco Private Enterprise or an arbitrary Enterprise defined by operator.
-
-The protocols are implemented as separate independent modules. New modules
-could be added in the future.
-
-A VARIABLE instance is reffered to by an unique alphanumeric name. The name
-can be used in the configuration file and for dynamic data request
-via NetState service. Typically, the list and the names of VARIABLEs are
-defined by operator. Several predefined VARIABLEs exist for some METHODs.
-
-A VARIABLE can be of any of the following types:
-
-* integer
-* float
-* IP address
-* string
-* SNMP OID
-
-The actual variable type is automatically determined on value assignment.
-During Netmond execution the number of associated values for every
-VARIABLE is maintained - the current value, previous value as well as
-minimal, maximal, average and delta during the SAVING time interval,
-if applicable.
-
-Netmod provides three SAVE methods to output VARIABLE values:
-
-* writing to a file;
-* pushing to a pipe;
-* passing as an argument for external program.
-
-SAVE methods are evaluated -
-
-* periodically, with SAVING interval
-* on change of VARIABLE value;
-* by condition - when a logical or expression with VARIABLE value become TRUE
-
-NetState service is an independent module of Netmond providing asynchronous
-network access to current VARIABLE values for client programs. The whole
-variables pool is presented as a hierarchy of variables and their owners in
-format: "object!subobject!variable = value". The request could contain an
-optional regular expression to filter the required output. This feature was
-introduced for flexible dynamic data transmission to operator's GUI.
-
-Please, address all questions, proposals and complains regarding Netmond to
-netmon@service.risp.ru mail list. To subscribe send a message with body text
-'subscribe netmon' to majordomo@service.risp.ru.